Naming of weights from systematics and reweighting

Hi,

1) Note that a convention agreed by all generators already exists.
Not in the name per se, but you should have in the <initrwgt>
in the definition of the weight the following:
<weight id="1" MUR="0.5" MUF="0.5" PDF="247000" > FREE TEXT </weight>
You can have additional attribute but those are mandatory.

So the easiest if you want to have the name in another way is to use those information as a input in your parser such that you remap the name of the weight to what you want when reading the file. This is a quite strong approach since it will work for any generator (and you can complain to them if they do not follow the convention lhef version 3)

I have nothing against allowing an option
--weightformat for the systematics program
which will allow to have input likd MUR%(mur)2f_ MUF%(mur)2f_PDF%(pdf)i
But then this will be your responsability to check that your format produce unique name (it will not be the case for the standard running scheme).

Actually even for only running MUR/MUF and PDF, your weight name is not unique since you SHOULD have two time the wieght
 MUR1.0_ MUF1.0_PDF_(CENTRAL)
one weight to be included in the MUR/MUF envelope
and a second one for the computation of the PDF uncertainty (one weight can not be in two group in the <initrwgt> group)

Do you have a smart idea on this? I do not see any.

> 2) When running the reweighting module one can use a user-defined weight ID but the name of the weight in the header will document all changes to the parameter card and can contain '#'s and multiple lines. This has caused some trouble downstream in the event simulation. Is it possible to also use a user-defined string for that part of the weight name?

This should be possible (this would be your responsability to put enough information there obviously to make the weight re-computable when a physicist read the information)

Cheers,

Olivier

> On 12 Aug 2019, at 17:47, Hannes <email address hidden> wrote:
>
> New question #682824 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/682824
>
> Hi,
>
> I have two related questions:
>
> 1) We would like to have a naming convention for systematic weights of different generators like this: MURX_MUFY_PDFZ (which is e.g. already used in Sherpa). What would be the best way to make sure weights are named appropriately (other than doing find and replace in the generated LHE file)?
>
> 2) When running the reweighting module one can use a user-defined weight ID but the name of the weight in the header will document all changes to the parameter card and can contain '#'s and multiple lines. This has caused some trouble downstream in the event simulation. Is it possible to also use a user-defined string for that part of the weight name?
>
> Cheers,
> Hannes
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

thanks a lot for the detailed reply.

Regarding the convention you mention, is this documented somewhere, so we can point other generator authors to it if necessary?

The --weightformat option you propose would be fantastic to have.
Would the fact that the central weight name is there twice cause any issue within MadGraph?
I had a quick discussion with ATLAS Herwig and Pythia experts and they think it will be fine downstream in our framework.

The pattern MUR%(mur)2f_ MUF%(mur)2f_PDF%(pdf)i will also generate duplicate weights for weights with different functional form, I assume, but this would be fine for us since we tend to turn off this feature.

Just to be sure, we are talking only about the python reweighting module, this will not affect the NLO on-the-fly reweighting, correct?

The possibility to name the reweighting weights would also be much appreciated (just having the option to have weight_name=weight_id would already be great). I assume will try to make sure within the collaboration that reweight names are meaningful (and reweight cards are stored anyway).

Cheers,
Hannes

Hi,

The document is arXiv:1803.10379<http://arXiv.org/abs/arXiv:1803.10379>

Would the fact that the central weight name is there twice cause any issue within MadGraph?

I would expect some issue with the writting of the weight and of the banner in particular.
This is the kind of problem that will certainly creates a lot of issue in the future.
Since this is a case that no one will expect to face.

The pattern MUR%(mur)2f_ MUF%(mur)2f_PDF%(pdf)i will also generate
duplicate weights for weights with different functional form, I assume,
but this would be fine for us since we tend to turn off this feature.

Yes and also for the MLM scale variation (but I guess you also turn it off)

Just to be sure, we are talking only about the python reweighting
module, this will not affect the NLO on-the-fly reweighting, correct?

Yes, I speak of the systematics.py module (which can also be used on NLO as well but which is indeed not present by default in advantage of a fortran version allowing to keep less data in the final lhe file).

The possibility to name the reweighting weights would also be much
appreciated (just having the option to have weight_name=weight_id would
already be great). I assume will try to make sure within the
collaboration that reweight names are meaningful (and reweight cards are
stored anyway).

Here I'm not sure to understand your comment...

Cheers,

Olivier

On 13 Aug 2019, at 13:33, Hannes <<email address hidden><mailto:<email address hidden>>> wrote:

Question #682824 on MadGraph5_aMC@NLO changed:
https://answers.launchpad.net/mg5amcnlo/+question/682824

Hannes posted a new comment:
Hi Olivier,

thanks a lot for the detailed reply.

Regarding the convention you mention, is this documented somewhere, so
we can point other generator authors to it if necessary?

The --weightformat option you propose would be fantastic to have.
Would the fact that the central weight name is there twice cause any issue within MadGraph?
I had a quick discussion with ATLAS Herwig and Pythia experts and they think it will be fine downstream in our framework.

The pattern MUR%(mur)2f_ MUF%(mur)2f_PDF%(pdf)i will also generate
duplicate weights for weights with different functional form, I assume,
but this would be fine for us since we tend to turn off this feature.

Just to be sure, we are talking only about the python reweighting
module, this will not affect the NLO on-the-fly reweighting, correct?

The possibility to name the reweighting weights would also be much
appreciated (just having the option to have weight_name=weight_id would
already be great). I assume will try to make sure within the
collaboration that reweight names are meaningful (and reweight cards are
stored anyway).

Cheers,
Hannes

--
You received this question notification because you are an answer
contact for MadGraph5_aMC@NLO.

Hi Olivier,

regarding the comment you didn't understand: I meant to say, in response to your comment "this would be your responsability to put enough information there obviously to make the weight re-computable when a physicist read the information" that we are able to figure out what was done in the reweighting, for Atlas samples, also without it being stored in the reweight name.

Cheers,
Hannes

Hi,

You will find here:
https://code.launchpad.net/~mg5core1/mg5amcnlo/2.6.7
the patch to add the option --weight_format for the systematics module.

As expected weird stuff appears if the format is not unique (even if the systematics code does not crash).

Cheers,

Olivier

On 13 Aug 2019, at 22:52, Hannes <<email address hidden><mailto:<email address hidden>>> wrote:

Question #682824 on MadGraph5_aMC@NLO changed:
https://answers.launchpad.net/mg5amcnlo/+question/682824

Hannes posted a new comment:
Hi Olivier,

regarding the comment you didn't understand: I meant to say, in response
to your comment "this would be your responsability to put enough
information there obviously to make the weight re-computable when a
physicist read the information" that we are able to figure out what was
done in the reweighting, for Atlas samples, also without it being
stored in the reweight name.

Cheers,
Hannes

--
You received this question notification because you are an answer
contact for MadGraph5_aMC@NLO.

and here the patch for adding --rwgt_info in the launch syntax of the re-weighting:

https://bazaar.launchpad.net/~mg5core1/mg5amcnlo/2.6.7/revision/298

Cheers,

Olivier

Hi Olivier,

thanks a lot for the patches, I was able to run it locally and will now test it with our setup.

Cheers,
Hannes

Hi Olivier,

thanks, indeed I am able to enforce the ATLAS naming convention with
"--weight_format=MUR%(mur).1f_MUF%(muf).1f_PDF%(pdf)i".
From initial tests I don't see any weird stuff, is there something I should look out for?

I know this is silly, but I am now able to change what I would call the "id" of the weight:
<weight id="MUR0.5_MUF2.0_PDF247000" MUR="0.5" MUF="2.0" PDF="247000" > MUR=0.5 MUF=2.0 </weight>
but it is actually the middle part ("MUR=0.5 MUF=2.0") which will be picked up downstream in the production for us (I am not even sure wheter this is Pythia or the ATLAS-specific interface).
Would it be hard to make this particular part configurable as well?

Cheers,
Hannes

Hi,

Those flags are mandatory according to the lhef version 3 of the code and Pythia relies strongly on those. Pythia authors complains (a lot) when we do not include those flags.

I guess the best here is that you change your parser to ignore those flags in your case but breaking a community convention does not sounds a good strategy.
Now if this is not possible then I guess that you will need to organise a meeting with PY8 authors and me. Such that we can see if we can agree on a modification of the format. (they were some discussion on a lhef version4 at some point (in the last but one leshouches) but those discussion did not lead to an update of the standard.

Cheers,

Olivier

> On 26 Aug 2019, at 14:37, Hannes <email address hidden> wrote:
>
> Question #682824 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/682824
>
> Hannes posted a new comment:
> Hi Olivier,
>
> thanks, indeed I am able to enforce the ATLAS naming convention with
> "--weight_format=MUR%(mur).1f_MUF%(muf).1f_PDF%(pdf)i".
>> From initial tests I don't see any weird stuff, is there something I should look out for?
>
> I know this is silly, but I am now able to change what I would call the "id" of the weight:
> <weight id="MUR0.5_MUF2.0_PDF247000" MUR="0.5" MUF="2.0" PDF="247000" > MUR=0.5 MUF=2.0 </weight>
> but it is actually the middle part ("MUR=0.5 MUF=2.0") which will be picked up downstream in the production for us (I am not even sure wheter this is Pythia or the ATLAS-specific interface).
> Would it be hard to make this particular part configurable as well?
>
> Cheers,
> Hannes
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

thanks again for your detailed answer.
Just to be clear, I mean the part between > and </, is that the one that can not be changed?
If that is so, then we might indeed find a better way to go about this (in ATLAS) and I will talk to people who came up with the convention.

Cheers,
Hannes

Ah ok no that part is completely free. It should contain human readable information.
But is not fixed by convention.
So for that part, I can put another flag in order to let the user defines the format of that string. (similar to what I did for the reweighting)

Cheers,

Olivier

> On 28 Aug 2019, at 19:57, Hannes <email address hidden> wrote:
>
> Question #682824 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/682824
>
> Hannes posted a new comment:
> Hi Olivier,
>
> thanks again for your detailed answer.
> Just to be clear, I mean the part between > and </, is that the one that can not be changed?
> If that is so, then we might indeed find a better way to go about this (in ATLAS) and I will talk to people who came up with the convention.
>
> Cheers,
> Hannes
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

thanks, that would be fantastic!

Cheers,
Hannes

Here you are:
https://bazaar.launchpad.net/~mg5core1/mg5amcnlo/2.6.7/revision/299

Cheers,

Olivier