<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Hi,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"> </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"> </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Peter</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"> </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"> </div> <div id="bloop_sign_1454924821600131072" class="bloop_sign"> <title></title> <div> — 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: <a href="mailto:peter.skands@monash.edu">peter.skands@monash.edu</a> W: <a href="http://skands.physics.monash.edu">skands.physics.monash.edu</a> -- Sent with Airmail </div> </div> On 8 February 2016 at 8:11:40 pm, Marek Schoenherr (<a href="mailto:marek.schoenherr@physik.uzh.ch">marek.schoenherr@physik.uzh.ch</a>) wrote: <blockquote type="cite" class="clean_bq"><div><div></div><div>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@cern.ch> > SENT: Sunday, February 7, 2016 2:09 PM > TO: Holger Schulz > CC: Rivet; herwig@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@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@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@projects.hepforge.org > https://www.hepforge.org/lists/listinfo/sherpa _______________________________________________ Pythia8 mailing list Pythia8@projects.hepforge.org https://www.hepforge.org/lists/listinfo/pythia8 </div></div></blockquote></body></html>