crash at Compiling MCatNLO

Hello Azar,
weird problem, I cannot reproduce it on my laptop.

I assume you are using the StdHEP version we provide in the package, and you did not change anything in it.
StdHEP does not find those functions (pyerrm, ...), that are in the Pythia main code (which is not linked when
you use Herwig), but I'm not sure why it looks for them.

Let's see if recompiling StdHEP helps.
- Go in vendor/StdHEP/src/stdhep and type 'make realclean' and then 'make'.
- Go in vendor/StdHEP/mcfio/src and type 'make realclean' and then 'make'.
- Go in vendor/STdHEP/lib and check that the libraries in there are the newly created ones (for example by checking
   if they have been created now or hours ago).
- Go in your z+j directory (I call it ppzj from now on), and in particular in ppzj/MCatNLO/lib; remove the links in there
   and replace them with the libraries 'libFmcfio.a' and 'libstdhep.a' you have just created in vendor/STdHEP/lib.

From ppzj, run ./bin/shower run_01 (or whatever other run_** where you have the Herwig6 events), and see if it goes
through or not.

Let me know.
Cheers.
Paolo

Hi Paolo,

Yes, I am using STDHEP and other packages installed from within MG, i.e.
with "install" command.
I just recompiled STDHEP as you described and the process went OK -- no
error messages, and the libraries appeared to be freshly created.
But when I tried to run bin/shower on those events it didn't go through
producing the same message as before. I attached the debug log file.
Could it be that STDHEP package uses some of Pythia routines to print
error output? Judging by the name 'pyerrm' appeared to be dealing with
error output.

Thank you,
    Azar

On 07/03/2014 08:15 AM, Paolo Torrielli wrote:
> Hello Azar,
> weird problem, I cannot reproduce it on my laptop.
>
> I assume you are using the StdHEP version we provide in the package, and you did not change anything in it.
> StdHEP does not find those functions (pyerrm, ...), that are in the Pythia main code (which is not linked when
> you use Herwig), but I'm not sure why it looks for them.
>
> Let's see if recompiling StdHEP helps.
> - Go in vendor/StdHEP/src/stdhep and type 'make realclean' and then 'make'.
> - Go in vendor/StdHEP/mcfio/src and type 'make realclean' and then 'make'.
> - Go in vendor/STdHEP/lib and check that the libraries in there are the newly created ones (for example by checking
> if they have been created now or hours ago).
> - Go in your z+j directory (I call it ppzj from now on), and in particular in ppzj/MCatNLO/lib; remove the links in there
> and replace them with the libraries 'libFmcfio.a' and 'libstdhep.a' you have just created in vendor/STdHEP/lib.
>
> >From ppzj, run ./bin/shower run_01 (or whatever other run_** where you have the Herwig6 events), and see if it goes
> through or not.
>
> Let me know.
> Cheers.
> Paolo
>

Hi Azar,
> Yes, I am using STDHEP and other packages installed from within MG, i.e.
> with "install" command.
> I just recompiled STDHEP as you described and the process went OK -- no
> error messages, and the libraries appeared to be freshly created.
> But when I tried to run bin/shower on those events it didn't go through
> producing the same message as before. I attached the debug log file.
Ok. The log file you attached is run_01_tag_1_debug.log. Could you also
look at and attach file
/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/mcatnlo.log ?

> Could it be that STDHEP package uses some of Pythia routines to print
> error output? Judging by the name 'pyerrm' appeared to be dealing with
> error output.
Yes, it uses the Pythia routines when it is linked to Pythia, and they
should never appear when you use Herwig.

Could you go in MCatNLO, do ‘gunzip ../Events/run_01/events.lhe.gz’, and
then try compiling by hand from there, by typing './MCatNLO_MadFKS.inputs'?
This should still fail, but maybe the error message will say something
more clear.

Could you also tell me what are the characteristics of the computer you’re
running on? Mainly operative system and gfortran version.

Cheers.
Paolo

> On 07/03/2014 08:15 AM, Paolo Torrielli wrote:
>> Hello Azar,
>> weird problem, I cannot reproduce it on my laptop.
>>
>> I assume you are using the StdHEP version we provide in the package, and you did not change anything in it.
>> StdHEP does not find those functions (pyerrm, ...), that are in the Pythia main code (which is not linked when
>> you use Herwig), but I'm not sure why it looks for them.
>>
>> Let's see if recompiling StdHEP helps.
>> - Go in vendor/StdHEP/src/stdhep and type 'make realclean' and then 'make'.
>> - Go in vendor/StdHEP/mcfio/src and type 'make realclean' and then 'make'.
>> - Go in vendor/STdHEP/lib and check that the libraries in there are the newly created ones (for example by checking
>> if they have been created now or hours ago).
>> - Go in your z+j directory (I call it ppzj from now on), and in particular in ppzj/MCatNLO/lib; remove the links in there
>> and replace them with the libraries 'libFmcfio.a' and 'libstdhep.a' you have just created in vendor/STdHEP/lib.
>>
>>> From ppzj, run ./bin/shower run_01 (or whatever other run_** where you have the Herwig6 events), and see if it goes
>> through or not.
>>
>> Let me know.
>> Cheers.
>> Paolo
>>
>
>
> ** Attachment added: "run_01_tag_1_debug.log"
> https://bugs.launchpad.net/bugs/1334014/+attachment/4145003/+files/run_01_tag_1_debug.log
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1334014
>
> Title:
> crash at Compiling MCatNLO
>
> Status in MadGraph5_aMC@NLO Generator:
> New
>
> Bug description:
> Hello,
>
> I am trying to learn how to generate NLO events and decided to
> reproduce Z+j results from your paper, but MG crashed compiling
> MCatNLO. Here is the relevant screen output
>
> INFO: Events generated
> decay_events -from_cards
> INFO: Prepairing MCatNLO run
> INFO: Compiling MCatNLO for HERWIG6...
> ../lib/libstdhep.a(luntmp.o): In f...

Hi Paolo,

On 07/03/2014 07:56 PM, Paolo Torrielli wrote:
> Hi Azar,
>> Yes, I am using STDHEP and other packages installed from within MG, i.e.
>> with "install" command.
>> I just recompiled STDHEP as you described and the process went OK -- no
>> error messages, and the libraries appeared to be freshly created.
>> But when I tried to run bin/shower on those events it didn't go through
>> producing the same message as before. I attached the debug log file.
> Ok. The log file you attached is run_01_tag_1_debug.log. Could you also
> look at and attach file
> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/mcatnlo.log ?
That file is attached. It seems to contain the same info as I get on the
screen.
>> Could it be that STDHEP package uses some of Pythia routines to print
>> error output? Judging by the name 'pyerrm' appeared to be dealing with
>> error output.
> Yes, it uses the Pythia routines when it is linked to Pythia, and they
> should never appear when you use Herwig.
>
> Could you go in MCatNLO, do ‘gunzip ../Events/run_01/events.lhe.gz’, and
> then try compiling by hand from there, by typing './MCatNLO_MadFKS.inputs'?
> This should still fail, but maybe the error message will say something
> more clear.
It did fail and produced the following output

gfortran -w -fno-automatic -ffixed-line-length-132
/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/herwig6521.o
/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/madfks_hwdriver.o
/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/madfks_hwlhin.o
/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/mcatnlo_str.o
/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/mcatnlo_hwan_stdhep.o
/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/mcatnlo_pdftomlm.o
/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/mcatnlo_libofpdf.o
/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/dummies.o
-L../lib -lstdhep -lFmcfio -o HW_EXE_DEFAULT
../lib/libstdhep.a(luntmp.o): In function `luntmp_':
luntmp.F:(.text+0x82): undefined reference to `pyerrm_'
luntmp.F:(.text+0x5bc): undefined reference to `pyerrm_'
luntmp.F:(.text+0x61c): undefined reference to `pycomp_'
luntmp.F:(.text+0xaa6): undefined reference to `pyerrm_'
luntmp.F:(.text+0xee6): undefined reference to `pycomp_'
luntmp.F:(.text+0xfee): undefined reference to `pyerrm_'
../lib/libstdhep.a(lutran.o): In function `lutran_':
lutran.F:(.text+0x2a8): undefined reference to `pyerrm_'
lutran.F:(.text+0x2e2): undefined reference to `pyerrm_'
lutran.F:(.text+0x30d): undefined reference to `pyerrm_'
lutran.F:(.text+0xaf4): undefined reference to `pyerrm_'
collect2: error: ld returned 1 exit status
make: *** [HW_EXE_DEFAULT] Error 1
mv: cannot stat ‘HW_EXE_DEFAULT’: No such file or directory
chmod: cannot access
‘/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/HW_EXE_DEFAULT’:
No such file or directory

***** All parameters read from event file run_01/events.lhe
***** Now ready for showering 10000 events with

mv: cannot stat ‘HW_EXE_DEFAULT’: No such file or directory

>
>...

Hi Azar,
I tried on Scientific Linux and on a Mac, and I cannot reproduce this problem.
Could you check on a Linux distribution other than Fedora or on a Mac and see
if you still get it?
Meanwhile, I’ll try to understand what is its source (it should be some compilation
option that is not properly understood by some OS).
Cheers.
Paolo

On 04 Jul 2014, at 18:22, Azar Mustafayev <email address hidden> wrote:

> Hi Paolo,
>
> On 07/03/2014 07:56 PM, Paolo Torrielli wrote:
>> Hi Azar,
>>> Yes, I am using STDHEP and other packages installed from within MG, i.e.
>>> with "install" command.
>>> I just recompiled STDHEP as you described and the process went OK -- no
>>> error messages, and the libraries appeared to be freshly created.
>>> But when I tried to run bin/shower on those events it didn't go through
>>> producing the same message as before. I attached the debug log file.
>> Ok. The log file you attached is run_01_tag_1_debug.log. Could you also
>> look at and attach file
>> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/mcatnlo.log ?
> That file is attached. It seems to contain the same info as I get on the
> screen.
>>> Could it be that STDHEP package uses some of Pythia routines to print
>>> error output? Judging by the name 'pyerrm' appeared to be dealing with
>>> error output.
>> Yes, it uses the Pythia routines when it is linked to Pythia, and they
>> should never appear when you use Herwig.
>>
>> Could you go in MCatNLO, do ‘gunzip ../Events/run_01/events.lhe.gz’, and
>> then try compiling by hand from there, by typing './MCatNLO_MadFKS.inputs'?
>> This should still fail, but maybe the error message will say something
>> more clear.
> It did fail and produced the following output
>
> gfortran -w -fno-automatic -ffixed-line-length-132
> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/herwig6521.o
> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/madfks_hwdriver.o
> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/madfks_hwlhin.o
> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/mcatnlo_str.o
> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/mcatnlo_hwan_stdhep.o
> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/mcatnlo_pdftomlm.o
> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/mcatnlo_libofpdf.o
> /home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo/MCatNLO/objects/dummies.o
> -L../lib -lstdhep -lFmcfio -o HW_EXE_DEFAULT
> ../lib/libstdhep.a(luntmp.o): In function `luntmp_':
> luntmp.F:(.text+0x82): undefined reference to `pyerrm_'
> luntmp.F:(.text+0x5bc): undefined reference to `pyerrm_'
> luntmp.F:(.text+0x61c): undefined reference to `pycomp_'
> luntmp.F:(.text+0xaa6): undefined reference to `pyerrm_'
> luntmp.F:(.text+0xee6): undefined reference to `pycomp_'
> luntmp.F:(.text+0xfee): undefined reference to `pyerrm_'
> ../lib/libstdhep.a(lutran.o): In function `lutran_':
> lutran.F:(.text+0x2a8): undefined reference to `pyerrm_'
> lutran.F:(.text+0x2e2): undefined reference to `pyerrm_'
> lutran.F:(.text+0x30d): undefined reference to `pyerrm_'
> lutran.F:(.te...

Hi Azar,

could you also try to generate and shower a sample with PYTHIA6Q instead of HERWIG6, and see if you get the
same kind of problem?

Another question: are you sure that while compiling StdHEP you use the same fortran and c++ compilers that you
use to compile HERWIG6 in the shower phase? Normally this is the case, unless you specify some particular compiler
in the input/mg5_configuration.txt file.
If you use different compilers, there may be some compilation conflict or something similar.

Cheers.
Paolo

Hi Paolo,

I tried to generate events with PYTHIA6Q as you suggested and it did go
through returning cross esction of 8903 pb. This is close to 9.7e3 pb
you have for Z+j at NLO in Table 1 of your paper. I guess the difference
can be attributed different PDFs and scale used.

In running the code I received multiple messages of the following type,
but I guess they are harmless:
Exception AttributeError: AttributeError("'_DummyThread' object has no
attribute '_Thread__block'",) in <module 'threading' from
'/usr/lib64/python2.7/threading.pyc'> ignored

As for the StdHEP compilation, I used the install command from MG and
presume it used the same compliers for all. Here is my configuration
file, just in case.

Best,
   Azar

On 07/14/2014 12:02 AM, Paolo Torrielli wrote:
> Hi Azar,
>
> could you also try to generate and shower a sample with PYTHIA6Q instead of HERWIG6, and see if you get the
> same kind of problem?
>
> Another question: are you sure that while compiling StdHEP you use the same fortran and c++ compilers that you
> use to compile HERWIG6 in the shower phase? Normally this is the case, unless you specify some particular compiler
> in the input/mg5_configuration.txt file.
> If you use different compilers, there may be some compilation conflict or something similar.
>
> Cheers.
> Paolo
>

Hi Azar,

> I tried to generate events with PYTHIA6Q as you suggested and it did go
> through returning cross esction of 8903 pb. This is close to 9.7e3 pb
> you have for Z+j at NLO in Table 1 of your paper. I guess the difference
> can be attributed different PDFs and scale used.
Ok, this seems consistent with the fact that, in the relevant files of
StdHEP, no internal Herwig6 routine is called, while this is the case
for Pythia6. Thus, while running Pythia6, StdHEP finds what it wants.
I still don’t understand why StdHEP misses the Pythia6 routines while
using Herwig6; this is a compiler/setup dependent fact that unfortunately
I can’t reproduce.
Anyway, as a very dirty patch to get Herwig6 running in your case,
(since I don’t know right now how to solve the issue properly), you
can do the following:
- copy the file MCatNLO/srcPythia/pythia6428.f to MCatNLO/srcHerwig.
- edit the file MCatNLO/Scripts/MCatNLO_MadFKS_HERWIG6.Script and
replace “ HWUTI+=' jimmy.o’ “ with “ HWUTI+=' jimmy.o pythia6428.o’ “
at line 145.
This links the Pythia6 source code also in the case of a Herwig6 run,
but still you will never use it during the shower, it is just to avoid
StdHEP complaining.
Let me know if the Herwig6 shower goes through in this case.

As for the cross section, the exact setup employed in the paper is
specified right before the tables, and the difference you see it may
be due to scale and PDFs, as you say, or to cuts.
In order to change PDF, you just need to edit run_card.dat. To change
the functional form for reference scale, you edit the file SubProcesses/
setscales.f and in particular function scale_global_reference(pp), at
the bottom of that file. To change cuts, you edit run_card again, or
SubProcesses/cuts.f for non-standard cuts.

> In running the code I received multiple messages of the following type,
> but I guess they are harmless:
> Exception AttributeError: AttributeError("'_DummyThread' object has no
> attribute '_Thread__block'",) in <module 'threading' from
> '/usr/lib64/python2.7/threading.pyc'> ignored
Yes, this is harmless.

Cheers.
Paolo

> On 07/14/2014 12:02 AM, Paolo Torrielli wrote:
>> Hi Azar,
>>
>> could you also try to generate and shower a sample with PYTHIA6Q instead of HERWIG6, and see if you get the
>> same kind of problem?
>>
>> Another question: are you sure that while compiling StdHEP you use the same fortran and c++ compilers that you
>> use to compile HERWIG6 in the shower phase? Normally this is the case, unless you specify some particular compiler
>> in the input/mg5_configuration.txt file.
>> If you use different compilers, there may be some compilation conflict or something similar.
>>
>> Cheers.
>> Paolo
>>
>
>
> ** Attachment added: "mg5_configuration.txt"
> https://bugs.launchpad.net/bugs/1334014/+attachment/4152648/+files/mg5_configuration.txt
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1334014
>
> Title:
> crash at Compiling MCatNLO
>
> Status in MadGraph5_aMC@NLO Generator:
> New
>
> Bug description:
> Hello,
>
> I am trying to learn how to generate NLO events and decided to
> reproduce Z+j resul...

Hi Azar,
i don't understand one thing: also by selecting HW6 as a shower, you should
get a number for the total cross-section before showering the events, right?
does the shower work ok with pythia6?
Cheers,

Marco

Marco Zaro

On Tue, Jul 15, 2014 at 1:56 AM, Azar Mustafayev <email address hidden>
wrote:

> Hi Paolo,
>
> I tried to generate events with PYTHIA6Q as you suggested and it did go
> through returning cross esction of 8903 pb. This is close to 9.7e3 pb
> you have for Z+j at NLO in Table 1 of your paper. I guess the difference
> can be attributed different PDFs and scale used.
>
> In running the code I received multiple messages of the following type,
> but I guess they are harmless:
> Exception AttributeError: AttributeError("'_DummyThread' object has no
> attribute '_Thread__block'",) in <module 'threading' from
> '/usr/lib64/python2.7/threading.pyc'> ignored
>
> As for the StdHEP compilation, I used the install command from MG and
> presume it used the same compliers for all. Here is my configuration
> file, just in case.
>
> Best,
> Azar
>
>
> On 07/14/2014 12:02 AM, Paolo Torrielli wrote:
> > Hi Azar,
> >
> > could you also try to generate and shower a sample with PYTHIA6Q instead
> of HERWIG6, and see if you get the
> > same kind of problem?
> >
> > Another question: are you sure that while compiling StdHEP you use the
> same fortran and c++ compilers that you
> > use to compile HERWIG6 in the shower phase? Normally this is the case,
> unless you specify some particular compiler
> > in the input/mg5_configuration.txt file.
> > If you use different compilers, there may be some compilation conflict
> or something similar.
> >
> > Cheers.
> > Paolo
> >
>
>
> ** Attachment added: "mg5_configuration.txt"
>
> https://bugs.launchpad.net/bugs/1334014/+attachment/4152648/+files/mg5_configuration.txt
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1334014
>
> Title:
> crash at Compiling MCatNLO
>
> Status in MadGraph5_aMC@NLO Generator:
> New
>
> Bug description:
> Hello,
>
> I am trying to learn how to generate NLO events and decided to
> reproduce Z+j results from your paper, but MG crashed compiling
> MCatNLO. Here is the relevant screen output
>
> INFO: Events generated
> decay_events -from_cards
> INFO: Prepairing MCatNLO run
> INFO: Compiling MCatNLO for HERWIG6...
> ../lib/libstdhep.a(luntmp.o): In function `luntmp_':
> luntmp.F:(.text+0x82): undefined reference to `pyerrm_'
> luntmp.F:(.text+0x5bc): undefined reference to `pyerrm_'
> luntmp.F:(.text+0x61c): undefined reference to `pycomp_'
> luntmp.F:(.text+0xaa6): undefined reference to `pyerrm_'
> luntmp.F:(.text+0xee6): undefined reference to `pycomp_'
> luntmp.F:(.text+0xfee): undefined reference to `pyerrm_'
> ../lib/libstdhep.a(lutran.o): In function `lutran_':
> lutran.F:(.text+0x2a8): undefined reference to `pyerrm_'
> lutran.F:(.text+0x2e2): undefined reference to `pyerrm_'
> lutran.F:(.text+0x30d): undefined reference to `pyerrm_'
> lutran.F:(.text+0xaf4): undefined reference to `pyerrm_'
> collect2: error: ld returned 1 exit status
> make:...

Hi Marco,

Yes, I did get a number for Herwing run and it was 8787pb. But there
also was an error stamp atthis run, so I wasn't sure how reliable that
number was.
When I switched to pythia6Q, as Paolo suggested, the shower worked
without problems.

Best,
   Azar

On 07/14/2014 08:27 PM, marco zaro wrote:
> Hi Azar,
> i don't understand one thing: also by selecting HW6 as a shower, you should
> get a number for the total cross-section before showering the events, right?
> does the shower work ok with pythia6?
> Cheers,
>
> Marco
>
>
> Marco Zaro
>
>
> On Tue, Jul 15, 2014 at 1:56 AM, Azar Mustafayev <email address hidden>
> wrote:
>
>> Hi Paolo,
>>
>> I tried to generate events with PYTHIA6Q as you suggested and it did go
>> through returning cross esction of 8903 pb. This is close to 9.7e3 pb
>> you have for Z+j at NLO in Table 1 of your paper. I guess the difference
>> can be attributed different PDFs and scale used.
>>
>> In running the code I received multiple messages of the following type,
>> but I guess they are harmless:
>> Exception AttributeError: AttributeError("'_DummyThread' object has no
>> attribute '_Thread__block'",) in <module 'threading' from
>> '/usr/lib64/python2.7/threading.pyc'> ignored
>>
>> As for the StdHEP compilation, I used the install command from MG and
>> presume it used the same compliers for all. Here is my configuration
>> file, just in case.
>>
>> Best,
>> Azar
>>
>>
>> On 07/14/2014 12:02 AM, Paolo Torrielli wrote:
>>> Hi Azar,
>>>
>>> could you also try to generate and shower a sample with PYTHIA6Q instead
>> of HERWIG6, and see if you get the
>>> same kind of problem?
>>>
>>> Another question: are you sure that while compiling StdHEP you use the
>> same fortran and c++ compilers that you
>>> use to compile HERWIG6 in the shower phase? Normally this is the case,
>> unless you specify some particular compiler
>>> in the input/mg5_configuration.txt file.
>>> If you use different compilers, there may be some compilation conflict
>> or something similar.
>>> Cheers.
>>> Paolo
>>>
>>
>> ** Attachment added: "mg5_configuration.txt"
>>
>> https://bugs.launchpad.net/bugs/1334014/+attachment/4152648/+files/mg5_configuration.txt
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1334014
>>
>> Title:
>> crash at Compiling MCatNLO
>>
>> Status in MadGraph5_aMC@NLO Generator:
>> New
>>
>> Bug description:
>> Hello,
>>
>> I am trying to learn how to generate NLO events and decided to
>> reproduce Z+j results from your paper, but MG crashed compiling
>> MCatNLO. Here is the relevant screen output
>>
>> INFO: Events generated
>> decay_events -from_cards
>> INFO: Prepairing MCatNLO run
>> INFO: Compiling MCatNLO for HERWIG6...
>> ../lib/libstdhep.a(luntmp.o): In function `luntmp_':
>> luntmp.F:(.text+0x82): undefined reference to `pyerrm_'
>> luntmp.F:(.text+0x5bc): undefined reference to `pyerrm_'
>> luntmp.F:(.text+0x61c): undefined reference to `pycomp_'
>> luntmp.F:(.text+0xaa6): undefined reference to `pyerrm_'
>> luntmp.F:(.text+0xee6): undefined reference to `pycomp_'
>> luntmp.F...

Hi Paolo,

I couldn't implement your patch, because there is no reference to
jimmy.o in that script file as you described. I attached my script file.
Should I add the line you described somewhere below line 155?
Also, I have only pythia6426.f not pythia6428.f

Thanks,
   Azar

On 07/14/2014 08:21 PM, Paolo Torrielli wrote:
> Hi Azar,
>
>> I tried to generate events with PYTHIA6Q as you suggested and it did go
>> through returning cross esction of 8903 pb. This is close to 9.7e3 pb
>> you have for Z+j at NLO in Table 1 of your paper. I guess the difference
>> can be attributed different PDFs and scale used.
> Ok, this seems consistent with the fact that, in the relevant files of
> StdHEP, no internal Herwig6 routine is called, while this is the case
> for Pythia6. Thus, while running Pythia6, StdHEP finds what it wants.
> I still don’t understand why StdHEP misses the Pythia6 routines while
> using Herwig6; this is a compiler/setup dependent fact that unfortunately
> I can’t reproduce.
> Anyway, as a very dirty patch to get Herwig6 running in your case,
> (since I don’t know right now how to solve the issue properly), you
> can do the following:
> - copy the file MCatNLO/srcPythia/pythia6428.f to MCatNLO/srcHerwig.
> - edit the file MCatNLO/Scripts/MCatNLO_MadFKS_HERWIG6.Script and
> replace “ HWUTI+=' jimmy.o’ “ with “ HWUTI+=' jimmy.o pythia6428.o’ “
> at line 145.
> This links the Pythia6 source code also in the case of a Herwig6 run,
> but still you will never use it during the shower, it is just to avoid
> StdHEP complaining.
> Let me know if the Herwig6 shower goes through in this case.
>
> As for the cross section, the exact setup employed in the paper is
> specified right before the tables, and the difference you see it may
> be due to scale and PDFs, as you say, or to cuts.
> In order to change PDF, you just need to edit run_card.dat. To change
> the functional form for reference scale, you edit the file SubProcesses/
> setscales.f and in particular function scale_global_reference(pp), at
> the bottom of that file. To change cuts, you edit run_card again, or
> SubProcesses/cuts.f for non-standard cuts.
>
>> In running the code I received multiple messages of the following type,
>> but I guess they are harmless:
>> Exception AttributeError: AttributeError("'_DummyThread' object has no
>> attribute '_Thread__block'",) in <module 'threading' from
>> '/usr/lib64/python2.7/threading.pyc'> ignored
> Yes, this is harmless.
>
> Cheers.
> Paolo
>
>
>
>
>> On 07/14/2014 12:02 AM, Paolo Torrielli wrote:
>>> Hi Azar,
>>>
>>> could you also try to generate and shower a sample with PYTHIA6Q instead of HERWIG6, and see if you get the
>>> same kind of problem?
>>>
>>> Another question: are you sure that while compiling StdHEP you use the same fortran and c++ compilers that you
>>> use to compile HERWIG6 in the shower phase? Normally this is the case, unless you specify some particular compiler
>>> in the input/mg5_configuration.txt file.
>>> If you use different compilers, there may be some compilation conflict or something similar.
>>>
>>> Cheers.
>>> Paolo
>>>
>>
>> ** Attachment added: "mg5_configuration.txt"
>> https://bugs.launchpad.net/bugs/1...

Hi Azar,

event generation and showering are independent, so when you get
a run summary, the LH event file has already been produced and
the cross section is reliable.

As for my suggested patch, sorry I was referring to our latest
release 2.1.2, while now I see from your error messages that you
are using 2.1.1.
I don’t think the new version 2.1.2 will naturally cure your StdHEP
compilation problem without patch; anyway I always recommend to use
the latest version. If you want to try that one, you should refer
to the patch I suggested in my latest email (but I would also try
without patch to see if the problem has naturally gone).

If you instead want to patch 2.1.1, you copy pythia6426.f in srcHerwig
and then, in the script MCatNLO_MadFKS_HERWIG6.Script, you add

HWUTI+=' pythia6426.o’

at line 153, just before

read -a HWUTIA <<< "$HWUTI”

Let me know whether the various solutions work.
Cheers.
Paolo

On 16 Jul 2014, at 01:42, Azar Mustafayev <email address hidden> wrote:

> Hi Paolo,
>
> I couldn't implement your patch, because there is no reference to
> jimmy.o in that script file as you described. I attached my script file.
> Should I add the line you described somewhere below line 155?
> Also, I have only pythia6426.f not pythia6428.f
>
> Thanks,
> Azar
>
> On 07/14/2014 08:21 PM, Paolo Torrielli wrote:
>> Hi Azar,
>>
>>> I tried to generate events with PYTHIA6Q as you suggested and it did go
>>> through returning cross esction of 8903 pb. This is close to 9.7e3 pb
>>> you have for Z+j at NLO in Table 1 of your paper. I guess the difference
>>> can be attributed different PDFs and scale used.
>> Ok, this seems consistent with the fact that, in the relevant files of
>> StdHEP, no internal Herwig6 routine is called, while this is the case
>> for Pythia6. Thus, while running Pythia6, StdHEP finds what it wants.
>> I still don’t understand why StdHEP misses the Pythia6 routines while
>> using Herwig6; this is a compiler/setup dependent fact that unfortunately
>> I can’t reproduce.
>> Anyway, as a very dirty patch to get Herwig6 running in your case,
>> (since I don’t know right now how to solve the issue properly), you
>> can do the following:
>> - copy the file MCatNLO/srcPythia/pythia6428.f to MCatNLO/srcHerwig.
>> - edit the file MCatNLO/Scripts/MCatNLO_MadFKS_HERWIG6.Script and
>> replace “ HWUTI+=' jimmy.o’ “ with “ HWUTI+=' jimmy.o pythia6428.o’ “
>> at line 145.
>> This links the Pythia6 source code also in the case of a Herwig6 run,
>> but still you will never use it during the shower, it is just to avoid
>> StdHEP complaining.
>> Let me know if the Herwig6 shower goes through in this case.
>>
>> As for the cross section, the exact setup employed in the paper is
>> specified right before the tables, and the difference you see it may
>> be due to scale and PDFs, as you say, or to cuts.
>> In order to change PDF, you just need to edit run_card.dat. To change
>> the functional form for reference scale, you edit the file SubProcesses/
>> setscales.f and in particular function scale_global_reference(pp), at
>> the bottom of that file. To change cuts, you edit run_card again, or
>> SubProcesses/cuts.f for non-standard cuts.
>>
...

Hi Paolo,

I tried your patch at MG version 2.1.1 and it worked -- no error
messages. Although the answer is slightly different from what I get with
PYTHIA6Q showering: Pyhtia gave 8903 ± 61
<cid:<email address hidden>> pb, while HERWIG6 with
your patch returned 8780 ± 63
<cid:<email address hidden>> pb. Is this a reasonable
spread?

Then I upgraded MG to 2.1.2. Using PYTHIA6Q for showering worked ok, but
the result is 9026 ± 58 <cid:<email address hidden>>
pb, which is different from the previous one. I guess this is because
2.1.2 version is using a different PDF set as default.
When I tried to use HERWIG6 it failed and using your quick patch did not
help. In both cases I got the following error message

INFO: Events generated
decay_events -from_cards
INFO: Prepairing MCatNLO run
INFO: Compiling MCatNLO for HERWIG6...
../srcHerwig/herwig6521.f:156: Error: Can't open included file
'HERWIG65.INC'
make: ***
[/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo_2/MCatNLO/objects/herwig6521.o]
Error 1
mv: cannot stat ‘HW_EXE_DEFAULT’: No such file or directo
***** Now ready for showering 10000 events with

ph/MG5_aMC_v2_1_1/Zj_nlo_2/MCatNLO/HW_EXE_DEFAULT’: No such file or
directory
mv: cannot stat ‘HW_EXE_DEFAULT’: No such file or directory

I think something is not working correctly for Herwig installation on
Fedora. Unfortunately I cannot test it on other platforms.

Best,
  Azar

On 07/15/2014 08:18 PM, Paolo Torrielli wrote:
> Hi Azar,
>
> event generation and showering are independent, so when you get
> a run summary, the LH event file has already been produced and
> the cross section is reliable.
>
> As for my suggested patch, sorry I was referring to our latest
> release 2.1.2, while now I see from your error messages that you
> are using 2.1.1.
> I don’t think the new version 2.1.2 will naturally cure your StdHEP
> compilation problem without patch; anyway I always recommend to use
> the latest version. If you want to try that one, you should refer
> to the patch I suggested in my latest email (but I would also try
> without patch to see if the problem has naturally gone).
>
> If you instead want to patch 2.1.1, you copy pythia6426.f in srcHerwig
> and then, in the script MCatNLO_MadFKS_HERWIG6.Script, you add
>
> HWUTI+=' pythia6426.o’
>
> at line 153, just before
>
> read -a HWUTIA <<< "$HWUTI”
>
> Let me know whether the various solutions work.
> Cheers.
> Paolo
>
>
> On 16 Jul 2014, at 01:42, Azar Mustafayev <email address hidden> wrote:
>
>> Hi Paolo,
>>
>> I couldn't implement your patch, because there is no reference to
>> jimmy.o in that script file as you described. I attached my script file.
>> Should I add the line you described somewhere below line 155?
>> Also, I have only pythia6426.f not pythia6428.f
>>
>> Thanks,
>> Azar
>>
>> On 07/14/2014 08:21 PM, Paolo Torrielli wrote:
>>> Hi Azar,
>>>
>>>> I tried to generate events with PYTHIA6Q as you suggested and it did go
>>>> through returning cross esction of 8903 pb. This is close to 9.7e3 pb
>>>> you have for Z+j at NLO in Table 1 of your paper. I guess the difference
>>>> can be attributed different P...

Hi Azar,

> I tried your patch at MG version 2.1.1 and it worked -- no error
> messages. Although the answer is slightly different from what I get with
> PYTHIA6Q showering: Pyhtia gave 8903 ± 61
> <cid:<email address hidden>> pb, while HERWIG6 with
> your patch returned 8780 ± 63
> <cid:<email address hidden>> pb. Is this a reasonable
> spread?
Yes, it seems a reasonable spread, 123 pb with a combined error of roughly
90 pb is not much more than one sigma. You can confirm this requiring a
better accuracy, and checking that the spread gets consequently reduced.

> Then I upgraded MG to 2.1.2. Using PYTHIA6Q for showering worked ok, but
> the result is 9026 ± 58 <cid:<email address hidden>>
> pb, which is different from the previous one. I guess this is because
> 2.1.2 version is using a different PDF set as default.
I guess the same, and you can confirm this by trying a run with the same
pdf set you used for 2.1.1.

> When I tried to use HERWIG6 it failed and using your quick patch did not
> help. In both cases I got the following error message
>
> INFO: Events generated
> decay_events -from_cards
> INFO: Prepairing MCatNLO run
> INFO: Compiling MCatNLO for HERWIG6...
> ../srcHerwig/herwig6521.f:156: Error: Can't open included file
> 'HERWIG65.INC’
> make: ***
> [/home/amustaf/packages/MadGraph/MG5_aMC_v2_1_1/Zj_nlo_2/MCatNLO/objects/herwig6521.o]
> Error 1
> mv: cannot stat ‘HW_EXE_DEFAULT’: No such file or directo
> ***** Now ready for showering 10000 events with
>
> ph/MG5_aMC_v2_1_1/Zj_nlo_2/MCatNLO/HW_EXE_DEFAULT’: No such file or
> directory
> mv: cannot stat ‘HW_EXE_DEFAULT’: No such file or directory
> I think something is not working correctly for Herwig installation on
> Fedora. Unfortunately I cannot test it on other platforms.
Yes, this is strange. You can check whether the file HERWIG65.INC is indeed
in the folder MCatNLO/include or not. If it is not there (why?), you should
put it there (this file is just a one-line file with the following statement:
       INCLUDE 'herwig6521.inc'
seven blank spaces before 'INCLUDE’).
If it is there, as I suppose, then it seems to be slinking problem in your setup,
and you could try and copy HERWIG65.INC in MCatNLO/srcHerwig, and rerun.

Let me know.
Cheers.
Paolo

>> Hi Azar,
>>
>> event generation and showering are independent, so when you get
>> a run summary, the LH event file has already been produced and
>> the cross section is reliable.
>>
>> As for my suggested patch, sorry I was referring to our latest
>> release 2.1.2, while now I see from your error messages that you
>> are using 2.1.1.
>> I don’t think the new version 2.1.2 will naturally cure your StdHEP
>> compilation problem without patch; anyway I always recommend to use
>> the latest version. If you want to try that one, you should refer
>> to the patch I suggested in my latest email (but I would also try
>> without patch to see if the problem has naturally gone).
>>
>> If you instead want to patch 2.1.1, you copy pythia6426.f in srcHerwig
>> and then, in the script MCatNLO_MadFKS_HERWIG6.Script, you add
>>
>> HWUTI+=' pythia6426.o’
>>
>> at line 153...