Naming of weights from systematics and reweighting

Asked by Hannes on 2019-08-12

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

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
2019-08-12
Last reply:
2019-08-13

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.

Hannes (hannes3) said : #2

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.

Hannes (hannes3) said : #4

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

Can you help with this problem?

Provide an answer of your own, or ask Hannes for more information if necessary.

To post a message you must log in.