Opened 9 years ago
Last modified 7 years ago
#360 reopened defect
pp->jj+0,1j results very different between 2.1.1 and 2.2.0
Reported by: | Frank Siegert | Owned by: | Steffen Schumann |
---|---|---|---|
Priority: | major | Milestone: | rel-2.2.1 |
Component: | Parton Shower | Version: | 2.2.0 |
Keywords: | Cc: |
Description
I'm looking at a simple merging setup for 93 93 -> 93 93 93{1} and find very different results in particular for high-pt leading jets between 2.1.1 and 2.2.0.
This might again be due to a change in the clustering, probably with respect to unordered configurations. If I use METS_CLUSTER_MODE=16 then both results are closer.
Pasted below is the total XS for pT_jet1>410 GeV with different options. By the way, the integrated cross sections are quite compatible between the the two default setups. But you can already see that the number of New_Event's from CSS is much higher in the 2.1.1 default.
Does anybody have an idea where this might be coming from?
Sherpa 2.1.1 METS_CLUSTER_MODE=0 (default)
2534.11 pb +- ( 141.11 pb = 5.56 % ) From "Jet_Evolution:CSS": 7059 (17059) -> 41.3 %
Sherpa 2.1.1 METS_CLUSTER_MODE=16
6327.44 pb +- ( 377.109 pb = 5.95 % ) From "Jet_Evolution:CSS": 2385 (12385) -> 19.2 %
Sherpa 2.1.1 SCALES=VAR{sqr(100)}
8495.67 pb +- ( 491.022 pb = 5.77 % ) From "Jet_Evolution:CSS": 1340 (11340) -> 11.8 %
Sherpa 2.2.0 METS_CLUSTER_MODE=0 (default)
9986.43 pb +- ( 892.532 pb = 8.93 % ) From "Jet_Evolution:CSS": 1821 (11821) -> 15.4 %
Sherpa 2.2.0 METS_CLUSTER_MODE=16
9233.85 pb +- ( 604.638 pb = 6.54 % ) From "Jet_Evolution:CSS": 1790 (11790) -> 15.1 %
Sherpa 2.2.0 SCALES=VAR{sqr(100)}
10566.2 pb +- ( 740.119 pb = 7 % ) From "Jet_Evolution:CSS": 1852 (11852) -> 15.6 %
Attachments (4)
Change History (11)
Changed 9 years ago by
Attachment: | Run.211.dat added |
---|
Changed 9 years ago by
Attachment: | Run.220.dat added |
---|
comment:1 Changed 9 years ago by
comment:2 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Please recheck the unlops branch
comment:3 follow-up: 4 Changed 9 years ago by
I'm looking at a similar setup as above and comparing the results with some Rivet analyses. Doing so (first with Sherpa 2.2.0) I realized two problems:
1) The differential cross section in the "Measurement of multi-jet cross sections(ATLAS_2011_S9128077)" is to large. (Already to be seen in the benchmarks: http://www.slac.stanford.edu/~shoeche/pub/bm/rel-2.2.0/HL_JQCD7000/JQCD_MEPS4_Ahadic_Rivet/index.html#ATLAS_2011_S9128077 )
2) The differential cross sections depend on the merging cut.
Both problems are still existing in branches/unlops, revision 28152.
Plots with 2.2.0:
http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/2.2.0/all/ATLAS_2011_S9128077/index.html http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/2.2.0/all/MC_QCD_PARTONS/index.html
Plots with unlops, revision 28152:
http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/unlops/all/ATLAS_2011_S9128077/index.html http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/unlops/all/MC_QCD_PARTONS/index.html
The used run card is attached.
Changed 9 years ago by
comment:4 Changed 9 years ago by
I checked Stefans fixes on the unlops branch a while ago (r27097) and they looked fine. The results can be found here:
http://ippp.dur.ac.uk/~kuttimalai/ATLAS_2011_S9128077_unlops_r27097/ATLAS_2011_S9128077/index.html
I'm also attaching the run card I used.
Replying to jk:
I'm looking at a similar setup as above and comparing the results with some Rivet analyses. Doing so (first with Sherpa 2.2.0) I realized two problems:
1) The differential cross section in the "Measurement of multi-jet cross sections(ATLAS_2011_S9128077)" is to large. (Already to be seen in the benchmarks: http://www.slac.stanford.edu/~shoeche/pub/bm/rel-2.2.0/HL_JQCD7000/JQCD_MEPS4_Ahadic_Rivet/index.html#ATLAS_2011_S9128077 )
2) The differential cross sections depend on the merging cut.
Both problems are still existing in branches/unlops, revision 28152.
Plots with 2.2.0:
http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/2.2.0/all/ATLAS_2011_S9128077/index.html http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/2.2.0/all/MC_QCD_PARTONS/index.html
Plots with unlops, revision 28152:
http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/unlops/all/ATLAS_2011_S9128077/index.html http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/unlops/all/MC_QCD_PARTONS/index.html
The used run card is attached.
comment:5 Changed 9 years ago by
I used Silvan's run card and tried to reproduce his plots. With r27097 my results are very similar, but with r28152 they differ.
plots: r27097: http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/rev27097/plots/ATLAS_2011_S9128077/index.html r28152: http://iktp.tu-dresden.de/~jk/offshell-merging/jj-qcd/rev28152/plots/ATLAS_2011_S9128077/index.html
Cheers, Johannes
comment:6 Changed 8 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:7 Changed 7 years ago by
This problem is still present at the 2.2.4 release, independent weather I use the default or the QCD core scale. However, in trunk (r31022) it looks much better:
results with 2.2.4: https://wwwpub.zih.tu-dresden.de/~s0118321/multijet/224/rivet-plots/ATLAS_2011_S9128077/index.html
results with trunk: https://wwwpub.zih.tu-dresden.de/~s0118321/multijet/trunk/rivet-plots/ATLAS_2011_S9128077/index.html
I just ran into the same problem, it is indeed the clustering. The crucial commit is r25927. Stefan is working on a fix (new clustering) at the moment.