[Rivet] NLOHisto1D

[Frank Siegert]

Hi Leif,

Thanks for your comments.

On 20 May 2015 at 16:36, Leif Lönnblad <leif.lonnblad at thep.lu.se> wrote:
> On 2015-05-20 13:52, Frank Siegert wrote:
>>
>> 1) Do we want to always use this in all analyses, i.e. do we accept
>> the (probably minor) overhead from this bookkeeping? I don't know
>> whether it would be an option to introduce a switch which dynamically
>> enables this functionality within the histogram class.
>
>
> Since this is determined by the input events, I guess it is impossible to
> say beforehand which analyses should have it or not. So yes, it should be
> used in all analysis. Always? Well, there is currently no way of knowing if
> a HepMC file has counter events (it is just flagged by two consecutive
> events having the same event number) I suggest we do it always.

I agree, and I don't think the overhead will be significant, but
haven't done any benchmarking on it yet.

>> 2) Should this live in a Rivet wrapper around YODA::Histo1D or is this
>> more a functionality of the histogram class that should be moved into
>> YODA? Of course, in the latter case we would not fill using
>> Rivet::Event but just event weight and event number.
>
>
> I think this should live in Rivet. Cf. also my previous comment about only
> allowing filling of histograms in the analyse function, which would also
> require a wrapper around YODA histos.
>
> We have also discussed to use smooth filling of histogram bins, where not
> only one histogram bin is filled, but depending on how close a point is to
> the bib border, also the adjacent bin would be filled (with modified
> weights). This is to get correct statistics when an event is fills close the
> bin border, and the counter event fills close to the adjacent one. (I
> include code for this below).

Interesting, thanks for sharing this, I hadn't thought of this yet.

One could discuss whether this should really be the job of the
histogramming framework, or whether the generator itself would not be
better equipped to handle this already at the event generation level.
For example, in Sherpa we offer the possibility of such a smearing
which uses the subtraction dipole kinematics as a measure of how much
of the weight to transfer between event and counter-event to avoid
these misbinning effects:
http://sherpa.hepforge.org/doc/SHERPA-MC-2.1.1.html#Avoiding-misbinning-effects

But it might be a nice (switchable?) option on the Rivet side. I think
it would have to be switchable to allow users control over whether
they want to do this kind of "smearing".

Cheers,
Frank