Code review comment for lp:~maddevelopers/mg5amcnlo/bias_function

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

Hi rikkert,

I have taken a look at the code and this is my comment

1) I do not like very much to use "event_norm" to trigger the bias. The main reason is that this flag is used to control how the weight of the event should be written. How would I set the normalization of the event to "Sum" in presence of bias?

Do we really need a flag in the run_card? Can't we have the default bias function to be "1"?

Like this, this will creates problem with the re-weighting/systematics module (but trivial to fix) since they are all using that variable to know how to handle the weights.

2) the HTML/printout results, only display the un-physical number (with a very nice warning).
Should not we automatically display the correct result? I guess that this is fine like this since we want to have this only for very advanced user.

3) So For the moment, the only way to get the physical cross-section is trough the systematics printout. However for the "example" bias [pt_t**3]. This returns a wrong number (for p p > t t~):
It returns:
   --------------------------------------------------------------
      Scale variation (computed from LHE events):
          Dynamical_scale_choice -1 (envelope of 9 values):
              8.060e+02 pb +11.0% -12.0%
instead of
   --------------------------------------------------------------
      Scale variation (computed from LHE events):
          Dynamical_scale_choice -1 (envelope of 9 values):
              6.875e+02 pb +9.6% -11.7%

It seems to be a numerical precision issue, since if I change the bias to pt_top:
   --------------------------------------------------------------
      Scale variation (computed from LHE events):
          Dynamical_scale_choice -1 (envelope of 9 values):
              6.742e+02 pb +9.5% -11.6%
   --------------------------------------------------------------
However already using pt_top^2 seems bad:
   --------------------------------------------------------------
      Scale variation (computed from LHE events):
          Dynamical_scale_choice -1 (envelope of 9 values):
              7.187e+02 pb +8.8% -11.3%
   --------------------------------------------------------------
If for this bias pt_top^2, I increase the statistic to 250k, then I have:
   --------------------------------------------------------------
      Scale variation (computed from LHE events):
          Dynamical_scale_choice -1 (envelope of 9 values):
              6.886e+01 pb +8.8% -10.3%
   --------------------------------------------------------------

So maybe we should a comment about this "problem" in cuts.f (looks like we are much more sensitive than at LO)

4) After fixing systematics.py in order to assume that bias normalisation is equivalent to average.
Then I have the following results
4.1)from the online version:
   --------------------------------------------------------------
      Summary:
      Process p p > t t~ [QCD]
      Run at p-p collider (6500.0 + 6500.0 GeV)
      Number of events generated: 10000
      Total cross section, incl. bias (DO NOT USE): 8.236e+04 +- 5.0e+02 pb
   --------------------------------------------------------------
      Scale variation (computed from LHE events):
          Dynamical_scale_choice -1 (envelope of 9 values):
              7.028e+02 pb +7.8% -9.7%
   --------------------------------------------------------------
4.2)and from the offline version:
INFO: #***************************************************************************
#
# original cross-section: 0.281024661372
# scale variation: +7.85% -9.72%
# central scheme variation: + 0% -9.72%
# PDF variation: +1.86% -1.86%
#
# dynamical scheme # 1 : 0.2729 +10% -10.8% # \sum ET
# dynamical scheme # 2 : 0.253701 +10.8% -11% # \sum\sqrt{m^2+pt^2}
# dynamical scheme # 3 : 0.281025 +7.85% -9.72% # 0.5 \sum\sqrt{m^2+pt^2}
# dynamical scheme # 4 : 0.254814 +12.4% -11.8% # \sqrt{\hat s}
#***************************************************************************

So this indicates a problem in the way the weight is written in the file.
Did you change that format? did you add one entry?
This is important since this will also forbid the re-weighting actually.
(We can skype about this if you want to).

review: Needs Fixing

« Back to merge proposal