[Rivet] Rivet 2.4 and xsec/event counter information

[David Grellscheid]

Hi Leif,

That's a neat idea! I assume you would do this just at the level of the 
HepMC converter? Otherwise, you get problems in the places that assume 
that the current event number corresponds to the number of unweighted 
events generated so far.

   David



On 09/11/2015 08:49, Leif Lönnblad wrote:
> Yes, they are called called attributes. But there is also the event
> number, which is used for counter events (consecutive events with the
> same event number are to be treated as event and counter events). I
> think the easiest way of handling zero weight events is to not write
> them out, but allow a jump in the event number reflect the number of
> zero-weight events which have been skipped.
>
> /Leif
>
>
> On 2015-11-07 15:08, Andy Buckley wrote:
>> HepMC3 has a generic attributes system (I can't remember if that's the
>> noun we used, but no matter), so hopefully is already flexible enough
>> for this.
>>
>> Would we need to pass an array of these, for multi-weight systematic
>> variations etc.? Marek Schoenherr has pointed out to me that we'll need
>> something like that for xsecs, which generally vary with scales, PDFs,
>> etc.
>>
>> Andy
>>
>>
>> On 06/11/15 22:31, David Grellscheid wrote:
>>> Hi Andy,
>>>
>>> Simon and I were discussing this at Les Houches. It will need support
>>> from
>>>
>>> - Generators
>>> - HepMC
>>> - Rivet
>>> (- YODA)
>>>
>>> to pass a new value 'attempts' through, just like xsec at the moment;
>>> but the benefit is that we can finally do the stats correctly.
>>>
>>> Passing 0-weight events along can be done as a workaround, but for the
>>> sake of future efficiency it would be good to have this value passed
>>> along explicitly.
>>>
>>>    David
>>>
>>>
>>> On 06/11/2015 12:40, Andy Buckley wrote:
>>>> On 06/11/15 10:16, Daniel Rauch wrote:
>>>>> Hi Andy,
>>>>>
>>>>> oh sorry, our bad - we were only looking at the individual histograms.
>>>>>
>>>>> So what we were/are looking for is the number of 'attempts' which
>>>>> would
>>>>> differ from the number of 'events' by the count of events with zero
>>>>> weight (that also contribute to the calculation of the cross section).
>>>>> Obviously this would have to be communicated to Rivet from the
>>>>> generator
>>>>> for which there currently is no existing infrastructure, right?
>>>>
>>>> That sounds correct. Generators will usually have some minimum weight
>>>> cut, below which they don't bother "sending" the event. If they output
>>>> events with zero weight this would work, of course, but would be
>>>> wasteful (unless they also made sure that the event was ~empty.)
>>>>
>>>>> The motivation for this is to calculate the statistical MC error also
>>>>> using the second part "-(sum of weights)^2/N" where N is the number of
>>>>> attempts. You can find a copy of my master's thesis at
>>>>> <http://www.itp.kit.edu/prep/diploma/PSFiles/ms-thesis-daniel-rauch.pdf>http://www.itp.kit.edu/prep/diploma/PSFiles/ms-thesis-daniel-rauch.pdf
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - the corresponding sections would be 4.2 & 4.3 for the equations for
>>>>> the combination of 1D histos and their MC errors, appendices B and C
>>>>> for
>>>>> the derivations and sec 5.4 for the implementation in the
>>>>> Herwig-Parallel toolset.
>>>>>
>>>>>> We're avoiding building any special interpretation of such variables
>>>>>> into YODA (and especially yodamerge), so that it remains a generic
>>>>>> data analysis package with capabilities useful for these studies,
>>>>>> rather than a one-trick package specifically for MC analysis, so at a
>>>>>> later point we plan to have a rivet-merge or similar script which
>>>>>> will
>>>>>> use the logic of yodamerge with added MC-specific use of this
>>>>>> information.
>>>>> So I understand this is the reason for going with the sqrt( sum of (
>>>>> weights^2 ) ) error definition - we will then most probably try to
>>>>> check
>>>>> if we can somehow develop similar patches for Rivet 2.4 to do the
>>>>> communication of the number of attempts from Herwig to Rivet.
>>>>
>>>> Well, we use that because it is the standard definition of weighted
>>>> binomial error. If the generators could pass the number of failed
>>>> attempts in their output stream, we could certainly feed it through
>>>> into
>>>> the yoda files... but it would need a bit of work to decide how to pass
>>>> it. I guess it's a bit like the cross-section, the estimate of which
>>>> evolves through the run, hence we write a "current xsec estimate" in
>>>> every event, and use the last one given when normalizing histograms
>>>> etc.
>>>> (via the crossSection() method as called in Rivet's finalize()).
>>>>
>>>> Andy
>>>>
>>
>>
>
>