COMIX crashes when using Sherpa in multithreading mode

[Generic User (don't modify these fields)]

Dear all,

we want to generate QCD with up to 5 jets and a pt_hat cut of 30 GeV (please check the attached files for the Sherpa setup). Using a Sherpa which was setup without multithreading all works fine, with multithreading things fail either when the cross sections of the 2->5 process are being calculated or when events are being generated. If you don't want to wait for some days before testing this, use also the 'Process' and 'Result' contents from the attached tarball.

Cheers, Markus

[Generic User (don't modify these fields)]

Run.dat

[Generic User (don't modify these fields)]

'Process' content

[Generic User (don't modify these fields)]

Hi,

unfortunately, 'Result' is too big. If you need it, please contact me privately.

Cheers, Markus

[Stefan Hoeche]

Hi Markus,

just a quick question before i start on this. Is the 'Order_EW'setting in your Run.dat intentionally? Thanks

Stefan

[Generic User (don't modify these fields)]

Hi Stefan,

um, yes?!? Good question... Didn't some of you recommend this at some point, or should it only be used when dealing with vector boson production? Do you suggest to eliminate this line?

Cheers, Metin and Markus

[Stefan Hoeche]

If you are after pure QCD processes, this line should change to 'Order_EW 0' (or be omitted, in which case you will also simulate the (mostly negligible) QCD/EW interferences). I guess that's also the reason why the integration takes that long, Comix should be pretty quick for pure QCD. In any case, the multithreading is a seperate issue and the crash should not be triggered by the Order_EW setting. I will have a look at it.

[Stefan Hoeche]

Hi Markus,

can you check whether Comix initializes without crashes using the attached 'minimal' setup for 5-jet production?

Thanks

Stefan

(run){

# avoid comix re-init after runcard modification WRITE_MAPPING_FILE 3;

}(run) (beam){

BEAM_1 2212; BEAM_ENERGY_1 3500; BEAM_2 2212; BEAM_ENERGY_2 3500;

}(beam) (processes){

Process 93 93 -> 93 93 93{3}; CKKW sqr(30/E_CMS); Integration_Error 0.02 {4}; Integration_Error 0.04 {5}; End process;

}(processes) (selector){

NJetFinder 2 20 0 1;

}(selector) (me){

ME_SIGNAL_GENERATOR Comix;

}(me)

[Stefan Hoeche]

Hi Markus,

could you please try whether the attached patch (cps_threading_1.patch) solves the threading problems?

Thanks

Stefan

[Generic User (don't modify these fields)]

Hi Stefan,

OK, I've checked the minimal setup you proposed and things are working. So the problem seems to be linked to whether one uses '93 93 -> 93{5}' (-> bad) or '93 93 -> 93 93 93{3}' (-> good).

Here comes a short list of all 'Order_EW' combinations I've tried:

93{5}, no OEW : not OK (crash when performing tests) 93{5}, OEW 0 : not OK (crash when performing tests) 93{5}, OEW 2 : OK 93 93 93{3}, no OEW : OK 93 93 93{3}, OEW 0 : OK 93 93 93{3}, OEW 2 : OK

('Order_EW 4' always yields NaN crossections)

Any ideas? (-> let me go for the patch now...)

[Stefan Hoeche]

Hi Markus,

sorry, I forgot to mention this earlier: a setup like 93 93 -> 93{5} will not work as the curly brackets specify the number of _additional_ particles. Thus in this case you would request a leading order process which is 93 93 -> <nothing>, which we can simply not cope with in standard collinear factorisation. Order_EW 4 only makes sense if your leading order process contains at least 4 final state particles. In this case the setup would have to be 93 93 -> 93 93 93 93 93{1}, i.e. up to one extra jet on top of 4 already existing jets. As far as I understand this is not what you wanted, so I would go for the unrestricted couplings like in the runcard I sent you.

Cheers

Stefan

[Generic User (don't modify these fields)]

Hi Stefan,

using the patch seems to have cured the multithreading problems.

Cheers, Markus

[Stefan Hoeche]

Milestone old deleted