Comment 11 for bug 1334014

Revision history for this message
Azar Mustafayev (azar) wrote : Re: [Bug 1334014] Re: crash at Compiling MCatNLO

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/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: *** [HW_EXE_DEFAULT] Error 1
>> mv: cannot stat ‘HW_EXE_DEFAULT’: No such file or directory
>>
>> Then there are some lengthy fortran compiler lines and the program crashes suggesting to report the error.
>> Could you tell what went wrong and how to fix this?
>>
>> Thanks,
>> Azar
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/mg5amcnlo/+bug/1334014/+subscriptions