sherpa is hosted by Hepforge, IPPP Durham
close Warning: Can't synchronize with repository "(default)" (/hepforge/svn/sherpa does not appear to be a Subversion repository.). Look in the Trac log for more information.
Modify

Opened 8 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)

Run.211.dat (502 bytes) - added by Frank Siegert 8 years ago.
Run.220.dat (502 bytes) - added by Frank Siegert 8 years ago.
Run.jk.dat (1.0 KB) - added by Johannes Krause 8 years ago.
used for both, 2.2.0 and unlops
Run.dat (850 bytes) - added by silvan 8 years ago.

Download all attachments as: .zip

Change History (11)

Changed 8 years ago by Frank Siegert

Attachment: Run.211.dat added

Changed 8 years ago by Frank Siegert

Attachment: Run.220.dat added

comment:1 Changed 8 years ago by silvan

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.

comment:2 Changed 8 years ago by Stefan Hoeche

Resolution: fixed
Status: newclosed

Please recheck the unlops branch

Changed 8 years ago by Johannes Krause

Attachment: Run.jk.dat added

used for both, 2.2.0 and unlops

comment:3 Changed 8 years ago by Johannes Krause

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 8 years ago by silvan

Attachment: Run.dat added

comment:4 in reply to:  3 Changed 8 years ago by silvan

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 8 years ago by Johannes Krause

comment:6 Changed 8 years ago by Frank Siegert

Resolution: fixed
Status: closedreopened

comment:7 Changed 7 years ago by Johannes Krause

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

Modify Ticket

Change Properties
Action
as reopened The owner will remain Steffen Schumann.
as The resolution will be set.
to The owner will be changed from Steffen Schumann to the selected user.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.