Changes between Version 64 and Version 65 of Reweight


Ignore:
Timestamp:
Mar 25, 2022, 11:45:09 AM (3 years ago)
Author:
Olivier Mattelaer
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Reweight

    v64 v65  
    169169
    170170   1. The re-weighting assumes that the matrix-element is symmetric for identical particles. This is a limitation for process like
    171       generate p p > Z j j, z > j j. In general such issues are automatically detected but in some particular case the re-weighting can fail to detect it and produce result which might be un-expected.
     171      generate p p > Z j j, z > j j. Starting at 3.4.0, the re-weighting is done as an average of the various combination to alleviate the ambiguity.
     172      This should give a good approximation as long as the Narrow-Width-Approximation is valid.
     173      You can change the parameter "identical_particle_in_prod_and_decay" to "max" to only consider the highest weight evaluated, or set it to "crash" to make the code to crash.
     174
     175      The option for version older than 3.4.0 is still valid: you can set the parameter "keep_ordering" to  True (via "change keep_ordering True"). This assumes that particle written in the leshouches file are in the exact same order as the one used by madgraph (looks at the Feynman diagram for the the ordering) --use with great care-- (new in 2.7.0)
     176
    172177   2. The ordering of the particles in the event file is not guaranteed and information about internal propagator not save to use. Consequently process like
    173178      "p p > e+ e- X, X > mu+ mu-" and "p p > mu+ mu- Y, Y > e+ e-" can not be distinguish. The re-weighting will systematically crash when this happens.
    174179
    175    Work around for those limitations can be done by setting some special flag in the reweight_card and carefully generating the input event:
    176    a. '''use_eventid True''': This allow to use the event id flag of the leshouche event file to distinguish different process. Within MG5aMC, you should use the "@" syntax in order to put such eventid in the leshouches file: for example "generate p p > e+ e- X, X > mu+ mu- @1; add process p p > mu+ mu- Y, Y > e+ e- @2" (new in 2.7.4)
    177    b. '''change keep_ordering True''': This assumes that particle written in the leshouches file are in the exact same order as the one used by madgraph (looks at the Feynman diagram for the the ordering) --use with great care-- (new in 2.7.0)
    178 
     180   Work around for this limitation: '''change use_eventid True''': This allow to use the event id flag of the leshouche event file to distinguish different process. Within MG5aMC, you should use the "@" syntax in order to put such eventid in the leshouches file: for example "generate p p > e+ e- X, X > mu+ mu- @1; add process p p > mu+ mu- Y, Y > e+ e- @2" (new in 2.7.4)
     181 
    179182
    180183 == Content of the reweight_card
     
    194197   9. '''change virtual_path PATH''': Allow to use an external library of standalone matrix-element (see details [#Generateexternallibrary here]) for the new theory for the virtual contribution. '''new in 2.5.6'''
    195198   10. '''change systematics OPTS''': '''only for ouptut mode '2.0' ''', allows to run the systematics computation on the new flight with options "OPTS". Note that this assume that the orignal and final theory have the SAME power of alpha_s at born level. '''new in 2.5.6'''
    196    11. '''change use_eventid''': see above
    197    12. '''change keep_ordering'': see above --dangerous flag--
     199   11. '''change use_eventid''': see above (new in 2.7.4)
     200   12. '''change keep_ordering'': see above --dangerous flag-- (new in 2.7.0)
     201   13. '''change identical_particle_in_prod_and_decay [average|max|crash]''': handling the case where particle identity is not secure (see above) (new in 3.4.0)
    198202
    199203 2. '''Benchmark definition''':[[BR]]