First event weight not nominal

Hi Josh,

Concerning lhefv3, I see your point, but to my point of view this is an example. It is not written anywhere that the id=1 should be central weight. If it was written I would have oppose to it. This does not make sense to me to force to write that line when the central weight has written in the first line of the event. What would be the point to repeat the same number below. So I do not consider that putting it as id=1 is a good idea and I interpret the convention in that way (and I did more than just signing the convention).

Now this being said, if you ask for
[--mur=1,0.5,2', '--muf=1,0.5,2', '--pdf=errorset']

Then you should have the main weight as the first entry.

Now I was thinking to add an option
--remove_id_weight
which is removing from the systematics set and pdf set the weights which correspond to the identity one (the issue with that option is that the user need to put it back for the correct computation of the systematics
at the same time, I can also add another option
--insert_id_as_first
which would solve your issue.

First event weight not nominal
Asked by Josh McFayden 8 hours ago

Hi MG5_aMC team,

We have observed in the ATLAS software in v2.6.1 and have reproduced with a standalone setup using v2.6.6 that the first weight in the LHE file is not the nominal weight. E.g. with:
[--mur=0.5,1,2', '--muf=0.5,1,2', '--pdf=errorset'] = systematics_arguments

We see something like the following in the LHEF:
<initrwgt>
<weightgroup name="Central scale variation" combine="envelope">
<weight id="1" MUR="0.5" MUF="0.5" PDF="260000" > MUR=0.5 MUF=0.5 </weight>
<weight id="2" MUR="0.5" MUF="0.5" DYN_SCALE="1" PDF="260000" > MUR=0.5 MUF=0.5 dyn_scale_choice=sum pt </weight>
<weight id="3" MUR="0.5" MUF="0.5" DYN_SCALE="2" PDF="260000" > MUR=0.5 MUF=0.5 dyn_scale_choice=HT </weight>
...

<event>
 4 1 +4.5600700e-02 1.74785200e+02 7.54677100e-03 1.07475900e-01
       21 -1 0 0 501 502 +0.0000000000e+00 +0.0000000000e+00 +9.0884757352e+01 9.0884757352e+01 0.0000000000e+00 0.0000e+00 1.0000e+00
       21 -1 0 0 502 503 -0.0000000000e+00 -0.0000000000e+00 -3.7554094781e+02 3.7554094781e+02 0.0000000000e+00 0.0000e+00 1.0000e+00
        6 1 1 2 501 0 +1.5198609831e+01 -1.9745396748e+01 -6.6786755993e+01 1.8711052672e+02 1.7300000000e+02 0.0000e+00 1.0000e+00
       -6 1 1 2 0 503 -1.5198609831e+01 +1.9745396748e+01 -2.1786943447e+02 2.7931517844e+02 1.7300000000e+02 0.0000e+00 1.0000e+00
<mgrwt>
<rscale> 2 0.17478524E+03</rscale>
<asrwt>0</asrwt>
<pdfrwt beam="1"> 1 21 0.13982270E-01 0.17478524E+03</pdfrwt>
<pdfrwt beam="2"> 1 21 0.57775531E-01 0.17478524E+03</pdfrwt>
<totfact> 0.14259007E+05</totfact>
</mgrwt>
<rwgt>
<wgt id='1'> +5.7582231e-02 </wgt>
<wgt id='2'> +7.0903054e-02 </wgt>
<wgt id='3'> +4.5600700e-02 </wgt>
...

>This is pretty dangerous since it puts one of the scale variations as the first weight which is the default weight for the entire analysis chain...

The default weight for the entire analysis chain should be the main weight of the event (the one written in the first line) nothing else to my point of view. The presence of <rwgt> is optional and therefore you should not count on it. I actually believe that you have a parsing issue here.

Cheers,

Olivier

Hi Olivier,

Of course we can parse in whatever way we need to once we know what the convention is (note that there is not much point in keeping two copies of the nominal weight). Anyway, now we know that our interpretation of the LHE3 convention is not the same as yours we can correct things accordingly...

--insert_id_as_first is not really a great option unless it's always possible to simply know where the nominal weight will be before running (running twice, once just to find out where the nominal weight is, is not a good solution).

Best,

Josh

Hi,

> (note that there is not much point in keeping two copies
> of the nominal weight).

Do I guess correctly that you consider that setting the nominal weight in the rwgt block is then a bad idea (and therefore as first entry in particular)

> --insert_id_as_first is not really a great option unless it's always
> possible to simply know where the nominal weight will be before running
> (running twice, once just to find out where the nominal weight is, is
> not a good solution).

OK will not add such option then. Thanks for the fedback.

Cheers,

Olivier

> On 3 Jul 2019, at 22:57, Josh McFayden <email address hidden> wrote:
>
> Question #681766 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/681766
>
> Josh McFayden posted a new comment:
> Hi Olivier,
>
> Of course we can parse in whatever way we need to once we know what the
> convention is (note that there is not much point in keeping two copies
> of the nominal weight). Anyway, now we know that our interpretation of
> the LHE3 convention is not the same as yours we can correct things
> accordingly...
>
> --insert_id_as_first is not really a great option unless it's always
> possible to simply know where the nominal weight will be before running
> (running twice, once just to find out where the nominal weight is, is
> not a good solution).
>
>
> Best,
>
> Josh
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.