[Rivet] HepMC multi weight convention for central weight

[Holger Schulz]

On 08/02/16 11:24, Andy Buckley wrote:
> A couple more points:
>
> Unless people try very hard to break it, "0" should sort first in the 
> dumb alphabetically ordered name output of HepMC2. I think this is a 
> pretty strong practical argument, given that HepMC3 is not in 
> production use yet and HepMC2's broken weights implementation won't be 
> "properly" fixed.
>
> And re. the redundancy of "weight" in the names, actually the names do 
> not refer to weights per se, but configurations. So there's another 
> reason to cut that word out.
>
> </bikeshed> ;-)
>
Thanks for all your input.

I strongly agree with Andy on the "0" for those reasons.

I would also like to make the point that if we don't define
a standard it is going to be rather painful comparing
different generators.


Holger


> Andy
>
>
> On 08/02/16 11:09, Andy Buckley wrote:
>> On the name (cf. https://en.wikipedia.org/wiki/Law_of_triviality) can I
>> suggest one more iteration? I like NominalWeight better than
>> CentralWeight, but it's obvious that they are weights so how about just
>> "Nominal"?
>>
>> Either that or "0", which will be the automatic stringified name of the
>> first-position weight in HepMC if no explicit name is given.
>>
>> Andy
>>
>>
>>
>> On 08/02/16 09:10, Marek Schoenherr wrote:
>>> 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
>>> _______________________________________________
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org
>>> https://www.hepforge.org/lists/listinfo/rivet
>>
>>
>
>