[Rivet] HepMC multi weight convention for central weight

[Marek Schoenherr]

Hi Stefan, all,

I agree that "central weight" is not the best choice of names for it, 
but in my opinion neither is "EventWeight" since all the weights we will 
write out are equally valid event weights computed simply for different 
choices of scales. It thus, in the historical sense, the nominal weight 
of the event, if there needs to be one. Keeping in mind the well 
motivated historic restriction, and the only one we definitely need to 
adhere to, is that any event has a nominal weight. As for the naming, we 
can of course call it whatever we like, and the shortest legible answer 
there is just "Weight". As said by Stefan "CentralWeight" would be 
confusing, "NominalWeight" would be fine for me, but I do not think 
there is a necessity to write 7 extra characters into the output file 
for every event.

As for all the other alternative event weights, I agree that the format 
of LH13 is tailored to LHC events with variations only in the 
fixed-order ME and thus very limited, and it would be good to think 
about an extension. Whether we should separate key and value in the 
identifying string by "=", ":" or anything else is something I do not 
have a strong opinion of. Even having no delimiter does not pose a 
problem in situations with different beams when the beams are identified 
not as "1" and "2" but as, e.g., "A" and "B". However, it is strictly 
mandatory in my opinion that the numerical values are relative to the 
central scale. Otherwise, you would first have to scan the entire weight 
container, order all elements by value of each double encoded in the 
string to figure out which key-value-pair corresponds to the up or down 
variation of which scale. The relative factors are constant and allow 
Rivet for example to simply histogram all occurrences in the 
WeightContainer with a given key as they come. The absolute values of 
the nominal scales can be made part of HepMC as well, either as 
additional entries in the WeightContainer (as this currently the only 
object in HepMC that allows arbitrary entries) or some to-be-implemented 
special object for the purpose.

Keeping with the format of LH13 as minimal suggestion, might it be a 
good idea to have the following form?

minimal, simplest LHC variation, as LH13: MUR<fac>_MUF<fac>_PDF<id>

extended LHC variations: MUR<fac>_MUF<fac>_PDF<id>_MUQ<fac>_Qcut<fac>

extended DIS variations: 
MUR<fac>_MUF<fac>_PDFA<id>_PDFB<id>_MUQ<fac>_Qcut<fac>

The precise nature of the string of course is irrelevant to any 
histogramming/analysis tool, it only matters that the string is the same 
for every recurring variation in every event (and possibly should not 
have spaces). The output would then be N histograms with the given name 
identifying its type of variation. What the user then wants to with it 
needs to be up to him since at the very least different sources of 
uncertainties due to these variations have to be treated differently, 
only thinking of PDF uncertainties and scale uncertainties for that 
matter and how to combine them.

Just my two cents.
Cheers,
Marek



On 2016-02-08 00:03, Prestel, Stefan wrote:
> 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 [2] 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 [2], 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> 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
>> https://www.hepforge.org/lists/listinfo/rivet [1]
> 
> 
> 
> Links:
> ------
> [1] https://www.hepforge.org/lists/listinfo/rivet
> [2] http://arxiv.org/pdf/1405.1067.pdf
> 
> _______________________________________________
> sherpa mailing list
> sherpa at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/sherpa