[Rivet] [Pythia8] HepMC multi weight convention for central weight

[Peter Skands]

Hi,

I’d like to retain enough flexibility that not all variations have to be clear-cut up/down variations. E.g., for multi-scale problems a single scale choice with a constant up/down factor may not provide a complete exploration of the uncertainty envelope. In both Vincia and Pythia one variation is using k*mQQ istead of pT as renormalization scale for G->QQ vertices (which may give either a larger or smaller alphaS depending on the z value). Another common example is W + jets, where you can decide on different ways if/whether to include mW in the renormalisation scale definition. I don’t fully understand the argument about needing to know which variations are up/down ones, but I think it could be easily specified in the header whether a given variation is of a strict up/down type (if that is useful) or of a more complex type.

Peter



—
PETER SKANDS
Associate Professor

School of Physics and Astronomy
Monash University 
10 College Walk, Clayton Campus
Melbourne, VIC 3800
Australia

T: +61 3 990 53692
E: peter.skands at monash.edu  
W: skands.physics.monash.edu  

-- 
Sent with Airmail 

On 8 February 2016 at 8:11:40 pm, Marek Schoenherr (marek.schoenherr at physik.uzh.ch) 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  
_______________________________________________  
Pythia8 mailing list  
Pythia8 at projects.hepforge.org  
https://www.hepforge.org/lists/listinfo/pythia8  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.hepforge.org/lists-archive/rivet/attachments/20160208/b2416a81/attachment.html>