[Rivet] Normalization issue in a Rivet STAR analysis?

[Andy Buckley]

On 08/10/15 12:14, Leif Lönnblad wrote:
> On 2015-10-08 12:50, Andy Buckley wrote:
>> On calling finalize() multiple times... *sigh* no, not yet. The problem
>> is that finalize() calls tend to invalidate the histograms for further
>> filling, hence copying of the data objects is needed before making the
>> call... and the user shouldn't be aware that that is going on. It's a
>> technical issue -- not complicated, but requiring some re-engineering of
>> how we mix the "system" and "user" views of data objects.
>
> I suggested a while back that rivet should explicitly separate between
> "fill" histograms and "output" histograms. The analyses would then not
> be allowed to scale/divide/whatever fill histograms in finalize(), but
> only use them read-only to produce output histograms. (And I think the
> user SHOULD be aware that this is what is going on.) This would then
> allow for calling finalize() several times, and also facilitate adding
> runs together. In the latter case it should be fairly easy to add fill
> histograms from different YODA files and then run finalize() again on
> the added histograms.

Hi Leif,

Yes, this is the scheme that we're following. There is already some 
implementation of special histo path structures which are ignored by the 
plotting tools for this reason.

The user needs to be aware of that to some extent -- for example any 
weight counters used in finalize() will need to be proper persistent 
objects rather than C++ primitives. But some things are implicit, e.g. 
the histogram pointers seen in finalize() are actually copies of the 
central ones, and the finalize() will be "secretly" run multiple times 
(for the different weight streams).

Andy

-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow