aMCSushi "No such file or directory" cannot generate events

[Riccardo Manzoni]

Following the installation and usage instruction in http://arxiv.org/abs/1504.0662, the generation step does not even start.
Madgraph itself considers this as a bug and suggests to report it [**].
Full log file in attachment.

[*]
MadGraph5_aMC@NLO VERSION 5.2.2.3, aMCSusHi version 2.2.3

[**]
Command "launch " interrupted with error:
OSError : [Errno 2] No such file or directory
Please report this bug on https://bugs.launchpad.net/madgraph5

[Marius Wiesemann (dr-wiesemann)]

Although its very hard to judge for me from the error message, let me try pin down the problem.

Did you check carefully that you use the most recent version of MG5_aMC_v2.2.3 and the compatible aMCSusHi version (*not* the one for 2.3.0.beta)?

Does this error occur when running the command ./bin/generate_events inside the <ggH-folder> ?

If you run the aMCSusHi script (with a new dummy folder), but simply abort the script when it asks you to download FeynHiggs, do you still have that problem when running in that dummy folder?

[Riccardo Manzoni (manzoni)]

Thanks Marius for your feedback.

To answer your questions:

_ the MG5_aMC version I used is indeed 2.2.3. I downloaded it one month ago, but no update happened in the meanwhile, so it should have been ok anyways.

_to rule out any possible obsolescence problem, I redid everything from a clean install of both MG5_aMC and aMCSusHi, unfortunately I get the same error as before.

_ I launch the event generation from inside the <ggH-folder> (which sits inside MG folder, as it should, provided that I understood the instructions correctly)

_ if I abort (CTRL+C) the script at the point where it asks about FeynHiggs, and then I run ./bin/generate_events, I manage to get past the problem I bumped into before, but later on I get stuck anyways

the full log file is in attachment.

For completeness, I am running on a lxplus SLC6 CERN machine

[Marius Wiesemann (dr-wiesemann)]

Hi Riccardo,

It is a bit strange that you get an error even after setting up the process in the HEFT model (which is what you get when aborting before the FeynHiggs message).

Do other processes work fine? Better: could you try generating exactly what the script is supposed to do first:

Start the MG5 script ./bin/mg5_aMC (in the main folder), then:

MG5_aMC>import model heft-no_b_mass
MG5_aMC>define p = p b b~
MG5_aMC>generate p p > h [real=QCD]
MG5_aMC>output some_folder_name
MG5_aMC>exit

Then, try running in that folder. If you get an error it appears to be a more general problem.

Another question: is the src_ggH_mod folder you get from unpacking the aMCSusHi tar-file inside the MG5_aMC main directory? If not (not sure that it has to), please put it as a direct sub-folder of the MG5_aMC directory.

As I understand the ggH-folder is already a sub-directory of MG5_aMC, which it has to be.

[Riccardo Manzoni (manzoni)]

Hi Marius,

I tried out your test from MG5_aMC prompt and it does get stuck too, precisely at this point [*].
Other processes, using either mssm or sm models seem to work fine and I successfully generate the lhe events.
Moving the src_ggH_mod inside MG5 folder and starting over from scratch does not help either.

Riccardo

[*]
WARNING: A compilation Error occurs when trying to compile /afs/cern.ch/work/m/manzoni/mc-generation/CMSSW_7_1_13/src/MSSM_AZh_LLTauTau_MG5_aMCNLO_SusHi/MG5_aMC_v2_2_3/marius_test_2/SubProcesses/P0_gg_h.
The compilation fails with the following output message:
    gfortran -O -fno-automatic -ffixed-line-length-132 -c -I. symmetry_fks_test_ME.f
    genps.inc:10.59:
        Included at symmetry_fks_test_ME.f:10:

          parameter (max_tree=200, max_dim=max_tree*(max_branch+1))
                                                               1
    Error: Symbol 'max_branch' at (1) has no IMPLICIT type
    genps.inc:13.51:
        Included at symmetry_fks_test_ME.f:10:

          parameter (ng = 96, maxdim = 3*(max_particles-2)-1, maxinvar= 4*max_parti
                                                       1
    Error: Symbol 'max_particles' at (1) has no IMPLICIT type
    genps.inc:36.36:
        Included at symmetry_fks_test_ME.f:10:

          parameter (maxprb = maxconfigs*maxplace*maxpoints)
                                        1
    Error: Parameter 'maxconfigs' at (1) has not been declared or is a variable, which does not reduce to a constant expression
    genps.inc:38.35:
        Included at symmetry_fks_test_ME.f:10:

          parameter (maxfprb = maxinvar*maxplace*maxpoints)
                                       1
    Error: Parameter 'maxinvar' at (1) has not been declared or is a variable, which does not reduce to a constant expression
    symmetry_fks_test_ME.f:23.50:

          integer iforest(2,-max_branch:-1,lmaxconfigs)
                                                      1
    Error: Symbol 'lmaxconfigs' at (1) has no IMPLICIT type
    symmetry_fks_test_ME.f:38.47:

          integer r2b(lmaxconfigs),b2r(lmaxconfigs)
                                                   1
    Error: The module or main program array 'b2r' at (1) must have constant shape
    symmetry_fks_test_ME.f:23.35:

          integer iforest(2,-max_branch:-1,lmaxconfigs)
                                       1
    Error: Symbol 'max_branch' at (1) has no IMPLICIT type
    symmetry_fks_test_ME.f:35.52:

          integer biforest(2,-max_branch:-1,lmaxconfigs)
                                                        1
    Error: The module or main program array 'biforest' at (1) must have constant shape
    symmetry_fks_test_ME.f:23.51:

          integer iforest(2,-max_branch:-1,lmaxconfigs)
                                                       1
    Error: The module or main program array 'iforest' at (1) must have constant shape
    symmetry_fks_test_ME.f:26.37:

          integer itree(2,-max_branch:-1)
                                         1
    Error: The module or main program array 'itree' at (1) must have constant shape
    symmetry_fks_test_ME.f:37.54:

          integer fksconfiguration,mapbconf(0:lmaxconfigs)
     ...

[Riccardo Manzoni (manzoni)]

I found out another bit of information that may be useful.

If I take the 'proc_card_mg5.dat' produced by aMCSusHi, which looks like this [*], use it to configure mg5, create the PROC_MSSM_AZH_HEFT_SUSHI_2 folder and subsequently generate the events, all goes smoothly.

[*]
set group_subprocesses Auto
set ignore_six_quark_processes False
set loop_optimized_output True
set complex_mass_scheme False
import model heft-no_b_mass
define p = g u c d s u~ c~ d~ s~
define j = g u c d s u~ c~ d~ s~
define l+ = e+ mu+
define l- = e- mu-
define vl = ve vm vt
define vl~ = ve~ vm~ vt~
define p = p b b~
generate p p > h [real=QCD]
output PROC_MSSM_AZH_HEFT_SUSHI_2

[Riccardo Manzoni (manzoni)]

Hi again,

I traced down the point where it the event generation gets stuck.
It is in <ggH-folder>/bin/internals/common_run_interface.py, line 2052, precisely this command, equivalent to 'lhapdf-config --version' fails:

2052 self.lhapdf_version = \
2053 subprocess.Popen([self.options['lhapdf'], '--version'],
2054 stdout = subprocess.PIPE).stdout.read().strip()

Browsing around I see that also in SusHi_make.log, 'lhapdf-config' command fails:

make: lhapdf-config: Command not found

Not sure what this exactly mean, but to me it looks like the lha pdf libraries are not linked when they should.
Of course, I don't exclude my interpretation may be completely wrong...

Hope this is helps

[Marius Wiesemann (dr-wiesemann)]

Ok, I am still trying to understand the implications of your other posts, but let me comment on the most recent one.

It appears that LHAPDF is not configured correctly on the system (lhapdf-config not found). Can you try running
without LHAPDF

--> go to Cards/run_card.dat and set

 nn23nlo = pdlabel ! PDF set
 244600 = lhaid ! if pdlabel=lhapdf, this is the lhapdf number

The linking of LHAPDF in MadGraph seems to be the problem. From SusHi only the library is used which should not care wether LHAPDF was correctly linked or not.

[Marius Wiesemann (dr-wiesemann)]

Concerning your previous messages:

I don't really understand what you mean by
"'proc_card_mg5.dat' produced by aMCSusHi, which looks like this [*], use it to configure mg5"

This 'proc_card_mg5.dat' is exactly what I obtain by doing

MG5_aMC>import model heft-no_b_mass
MG5_aMC>define p = p b b~
MG5_aMC>generate p p > h [real=QCD]
MG5_aMC>output some_folder_name
MG5_aMC>exit

Thus, I don't understand how you used it "to configure mg5" and it was working then, while it was not working when typing these commands directly in the MG5_aMC shell.

Could you explain how you configured mg5 with that file?

[Riccardo Manzoni (manzoni)]

Apologies for my poor description, it simply reflects my inexperience with MG...

From inside the MG5 folder I did

    [manzoni@lxplus0148 madgraph5]$ ./bin/mg5_aMC proc_card_ggA.dat

where proc_card_ggA.dat reads [*].
This created this folder

   PROC_GGH_HEFT

from which I generate a bunch of LHE events, by launching

    [manzoni@lxplus0148 PROCH_GGH_HEFT]$ ./bin/generate_events

This went smooth.

[*]
set group_subprocesses Auto
set ignore_six_quark_processes False
set loop_optimized_output True
set complex_mass_scheme False
import model heft-no_b_mass
define p = g u c d s u~ c~ d~ s~
define j = g u c d s u~ c~ d~ s~
define l+ = e+ mu+
define l- = e- mu-
define vl = ve vm vt
define vl~ = ve~ vm~ vt~
define p = p b b~
generate p p > h [real=QCD]
output PROC_GGH_HEFT

[Marius Wiesemann (dr-wiesemann)]

Hi, thanks for the clarification.

This is really unexpected, since this should do exactly the same as

MG5_aMC>import model heft-no_b_mass
MG5_aMC>define p = p b b~
MG5_aMC>generate p p > h [real=QCD]
MG5_aMC>output PROC_GGH_HEFT
MG5_aMC>exit

Anyway, lets work with that folder where the HEFT event generation works.
Can you run the aMCSusHi script on top of that one by:

./set_up_ggH_MSSM_script.pl ../PROC_GGH_HEFT

when it asks to overwrite it press "n" to not overwrite it but continue. Then
follow the steps to link FeynHiggs and SusHi (you can simply re-download
and re-compile if you like).

After that, go into the PROC_GGH_HEFT folder and

--> go to Cards/run_card.dat and set

 nn23nlo = pdlabel ! PDF set
 244600 = lhaid ! if pdlabel=lhapdf, this is the lhapdf number

[Riccardo Manzoni (manzoni)]

What I mean in the post above is that I tried to completely exclude SusHi and run the bare MG5_aMC.
That worked.
To make it clear, it's not that from the MG5_aMC shell I cannot make it work, while I can if I do it the other way round.

In general, regardless of using SusHi or not, when I switch to lhapdf PDFs the generation always fails, even using the bare MG5_aMC.
However, if I use aMCSusHi with nn23nlo PDFs, I get past the first error, but the generation still fails later on.

Probably there are two problems, one with lhspdf, that is not really related to aMCSusHi, and another problem that possibly has something to do with aMCSusHi.

[Marius Wiesemann (dr-wiesemann)]

Ok, to conclude:

This issue was purely caused by LHAPDF not being configured correctly. The aMCSusHi script automatically turns on LHAPDF by replacing the run_card.dat in Cards. This will be changed (fixed) in an update of the script. Until then the fix of the problem (which only exists when LHAPDF is not configured correctly) will be to simply turn off LHAPDF again after running the aMCSusHi script:

--> go to Cards/run_card.dat and set

 nn23nlo = pdlabel ! PDF set
 244600 = lhaid ! if pdlabel=lhapdf, this is the lhapdf number