[Rivet] HepMC multi weight convention for central weight

[Prestel, Stefan]

Hi all,


Sorry for the radio silence. I've also included the Pythia mailing list and Leif Lonnblad on this thread.


First and foremost, I think it's dangerous to think it's dangerous to talk about a "central weight". We of course all know what we mean, but it's good to keep in mind that it might not be clear what the "central weight" is central of. For us, that's probably only semantics, but for the user (and an analysis tool like Rivet), it might lead to confusion.


For my personal taste, "Weight" is perfectly acceptable, albeit being not very specific. Maybe that's how we want it in order to ensure that no weight naming cargo cult emerges. In my mind, a more natural name would be "EventWeight", simply because I would imagine that this weight would be the direct descendant of the event weight in the older "Les Houches 1.0" accord. This latter weight does not in principle have to be a "central weight" of any collection of weights appearing as additional weights. Thus, a name like "CentralWeight" is clearly dangerous. "Weight" or "EventWeight" seem reasonable to me.


I'll call the event weight (i.e. what Holger called the "central weight") "EventWeight" from now on, just to give the child a name. Thinking more about the naming scheme, I think it would in general be sensible to (optionally) be able to include more information into any weight name, by e.g. extending the weight names like


  EventWeight_MyAdditionalInformation


An example where this would be sensible is a merging scale variation. In this case, the event weight of an input (fixed-order) event can have several EventWeight descendants. This could be conveyed by having different weights for each merging scale, with names given by


  EventWeight_MergingScale=10, EventWeight_MergingScale=20, EventWeight_MergingScale=30


and so on. Having this flexibility available would allow to also convey differences in how the (multi-weighted) inputs are handled by the subsequent event generation. The fixed-order part is not the only part of the event generation that has uncertainties that can be captured by having multiple weights, and we should not limit ourselves unnecessarily by thinking only about the "simple" fixed-order variations. I strongly feel that we should allow such a flexibility. Of course, a different format might be more reasonable.


Some further issues that I have with the suggestions that we put forward on page 162 of http://arxiv.org/pdf/1405.1067.pdf is that the separation between "name" and "value" concatenated in a weight name is not clear, and might indeed lead to issues. Say that a weight was generated with mu_R=2*mu_central, mu_F = mu_central, and LHAPDF number 11000. Currently, this will

mean that the weight name is


MUF1_MUR0.5_PDF11000


Now imagine the weight is associated with a DIS collision, and I want to convey that the simulation has been performed with an electron PDF with number 99999. (Please only take this as an example, I don't want to argue if and why this could be sensible.) Then, it feels natural to have a PDF1 and PDF2 identifier. In the current suggestion, this would be problematic, since a weight name


MUF1_MUR0.5_PDF111000_PDF299999


could also mean we've used PDF 111000 or 299999. Again, this is just an (most likely academic) example. The point I want to make is that this issue is trivially solved if we instead use a convention like

MUF=1_MUR=0.5_PDF1=11000_PDF2=99999


with an equal sign separating the attribute and the value. This should also make parsing easier and more transparent.


Finally -- and this is really only personal taste -- I would argue that if we stick to the convention that the value of the "MUR/MUF" attributes is a number of O(1) (NB: That's not specified in http://arxiv.org/pdf/1405.1067.pdf, but all the examples shown there might lead to such a usage), then it would be sensible to also have an attribute defining the "central" scale. Potential names could be "MURCENTRAL/MUFCENTRAL". However, I think the best solution would be to simply use the actual numerical value of the scales as values. Since this leads to weight names that may differ from event to event, parsing is clearly more difficult, which might mean that this is just a pie-in-the-sky idea.


Sorry for the long mail. Hope at least some if it makes sense.


Cheers,

Stefan



________________________________
From: Chris Pollard <cpollard at cern.ch>
Sent: Sunday, February 7, 2016 2:09 PM
To: Holger Schulz
Cc: Rivet; herwig at projects.hepforge.org; Prestel, Stefan; Torbjorn Sjostrand; Sherpa
Subject: Re: [Rivet] HepMC multi weight convention for central weight

Hi,

I am fine with the name "Weight" for the central weight. I guess it's most important to hear from the other generator authors, though.

Chris

On Tue, Feb 2, 2016 at 12:52 PM, Holger Schulz <holger.schulz at durham.ac.uk<mailto:holger.schulz at durham.ac.uk>> wrote:
Hi all,

the alpha version of rivet 3 (which supports multiple weights natively)
triggered a discussion on what the central weight name should be.

As far as I know there is only a convention for scale and pdf variations in the
2013 LesHouches proceedings.
What was (I think) agreed upon is that the central weight should simply come
first in the weight vector when writing out to HepMc. This however
states a tiny technical problem as the write out of the WeightContainer
in HepMc2 does not preserve the order of weights.

Within Sherpa the name "Weight" was used and if I understand correctly,
would also be fine from Stefan Prestel's point of view.

It is maybe not that urgent but it would help us in the development
of HepMC and Rivet 3 if we could agree on a name for the central
weight.


Thanks,
Holger
_______________________________________________
Rivet mailing list
Rivet at projects.hepforge.org<mailto:Rivet at projects.hepforge.org>
https://www.hepforge.org/lists/listinfo/rivet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20160207/2394f421/attachment.html>