Integration results different between single process and within process group
I am comparing the integration results (in Results.zip
) for the same d ub -> W+ W+ u db
process between running it within a process group (93 93 -> ...
) or running it as single process (1 -2 -> ...
). They differ significantly:
$ cd single
$ cat Sherpa.yaml
BEAMS: 2212
BEAM_ENERGIES: 6500
EVENT_GENERATION_MODE: W
FRAGMENTATION: Off
MI_HANDLER: None
SHOWER_GENERATOR: CSS
AMEGIC_LIBRARY_MODE: 0
SCALES: VAR{sqr(90.0)}
PROCESSES:
- 1 -2 -> 11 13 -12 -14 -1 2:
Order:
EW: 6
QCD: Any
PSI_ItMin: 25000
Integration_Error: 0.05
SELECTORS:
- [Mass, 11, -12, 2, E_CMS]
- [Mass, 13, -14, 2, E_CMS]
- [PT, 90, 5, E_CMS]
- FastjetFinder:
Algorithm: kt
N: 2
PTMin: 25
DR: 0.4
$ unzip Results.zip; head -n 1 Comix/XS_2_*/2_* | cut -d " " -f 1-3,7
2_6__d__ub__e-__mu-__veb__vmub__u__db 2.079910834764798e-12 2.676173311577072e-14
$ cd group
$ cat Sherpa.yaml
BEAMS: 2212
BEAM_ENERGIES: 6500
EVENT_GENERATION_MODE: W
FRAGMENTATION: Off
MI_HANDLER: None
SHOWER_GENERATOR: CSS
AMEGIC_LIBRARY_MODE: 0
SCALES: VAR{sqr(90.0)}
PROCESSES:
- 93 93 -> 11 13 -12 -14 93 93:
Order:
EW: 6
QCD: Any
PSI_ItMin: 25000
Integration_Error: 0.05
SELECTORS:
- [Mass, 11, -12, 2, E_CMS]
- [Mass, 13, -14, 2, E_CMS]
- [PT, 90, 5, E_CMS]
- FastjetFinder:
Algorithm: kt
N: 2
PTMin: 25
DR: 0.4
$ unzip Results.zip; head -n 1 Comix/XS_2_6__j__j__e-__mu-__veb__vmub__j__j/2_6__d__ub__e-__mu-__veb__vmub__u__db | cut -d " " -f 1-3,7
2_6__d__ub__e-__mu-__veb__vmub__u__db 1.509400443490704e-12 4.131361708566111e-14
For reference, rel-2-2-7
gives:
single: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.024183010387973e-12 9.05670342079186e-15
group: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.005802282597058e-12 2.605913790007446e-14
But the initial state symmetrisation is handled differently there(?), so a factor of 2 is to be expected.
Further tests with master:
34bdb6c2 (after svn -> git migration)
group: TODO
8646684d (before bugfix in comix PS)
group: doesn't work yet, have to check (returns 0 0)
10350cea (before process group separation
group: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.497063738794587e-12 4.342845163924471e-14
8172f68a (21 Jan 2019) before YAML implementation
single: 2_6__d__ub__e-__mu-__veb__vmub__u__db 2.015219002920607e-12 2.596148420038333e-14
group: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.504591322160397e-12 4.472688758835573e-14
current master (see above)
single: 2_6__d__ub__e-__mu-__veb__vmub__u__db 2.079910834764798e-12 2.676173311577072e-14
group: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.509400443490704e-12 4.131361708566111e-14
So this seems to exist even before the YAML transition... Here is the group
Run.dat with which I'll test further.
Obsolete tests with master from bisecting:
eb96f45c (24 Jan 2019) after YAML implementation
single: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.929764425752016e-12 3.809738795772497e-14
group: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.497063738794587e-12 4.342845163924471e-14
58d2b1df (18 Mar 2019)
single:
group: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.497435303950418e-12 4.996653327094852e-14
f4e3273e (19 Mar 2019) MPI bindings C++ -> C
single: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.94215356028781e-12 2.082922798786334e-14
group: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.497063738794587e-12 4.342845163924471e-14
a670d0fb (21 May 2019)
single: 2_6__d__ub__e-__mu-__veb__vmub__u__db 2.14591712152546e-12 4.217396286086446e-14
group: 2_6__d__ub__e-__mu-__veb__vmub__u__db 1.713527753370593e-12 1.160706536812547e-13
Edited by Frank Siegert