[Rivet] [Rivet-svn] r1860 - trunk/src/Analyses

Frank Siegert frank.siegert at durham.ac.uk
Wed Oct 7 13:38:47 BST 2009


Andy Buckley, Wednesday 07 October 2009:
> Frank Siegert wrote:
> > Cool, that's a nice addition to our LEP analyses.
> > Have you considered doing something similar as I have done (recently)
> > for the JADE_OPAL analysis, such that actually only the E_cms
> > appropriate histograms get initialised and written out? Otherwise
> > lots of empty histograms get written to the aida file, wouldn't they?
> > (and then also get plotted)
>
> I'll take a look at what you've done: it's certainly not so nice to
> have 104 plots from each run, 76 of which are empty, but fortunately
> they can be selectively plotted with e.g. "make-plots *-y02.dat"

If you do all the plotting "manually", then yes.

> Directionless mental wander:
>    I'm still not so fond of the putting histo bookings in the analyze
> loop, since it's a bit non-intuitive: maybe we could instead augment
> the tests on the first event to make the beams and E_cms available via
> the AnalysisHandler/Analysis classes? Or is there a reason why we might
> expect a single event stream to contain events at several CMS energies?
> While I quite like the idea of "lazy booking", it concerns me that if
> Analysis::bookHistogram1D() is silent about attempted duplicate
> bookings (which would be the way to make this neat), then
> copy-and-paste errors in the booking code will be harder to find...

I agree, but didn't want to make such a big change: After all you would 
have to scan the first event without analyzing it yet and then come back 
to it. But if we have more and more analyses where this would be useful (I 
also recall that there is a 630/1800 GeV analysis?) this might be 
worthwhile.

Frank



More information about the Rivet mailing list