[Rivet] [Rivet-svn] r2130 - in trunk: . bin include/Rivet pyext src/Core

[Andy Buckley]

Frank Siegert wrote:
> I have a question/comment about this commit:
> 
> blackhole at projects.hepforge.org, Wednesday 02 December 2009:
>> Author: buckley
>> Date: Wed Dec  2 16:37:20 2009
>> New Revision: 2130
>>
>> Log:
>> Restructuring of Run, and making first event sqrt(s) and beams
>>  accessible from later in the run via the AnalysisHandler. Requires a
>>  Python build dir deletion since Python-facing Run and AnalysisHandler
>>  APIs have changed.
>>
>> Modified:
>>    trunk/ChangeLog
>>    trunk/bin/rivet
>>    trunk/include/Rivet/AnalysisHandler.hh
>>    trunk/include/Rivet/Run.hh
>>    trunk/pyext/rivet.i
>>    trunk/src/Core/AnalysisHandler.cc
>>    trunk/src/Core/Run.cc
> 
> The sqrts/beam info is now being extracted by Run.cc and passed into 
> AnalysisHandler from there. This means, that interfaces to Rivet will 
> break, because until now everything relevant for initialisation of the 
> analyses happened in AnalysisHandler. Now it will also be necessary for 
> each interface to Rivet to extract the sqrts/beam information themselves 
> and pass them into the AnalysisHandler. I assume this will be pretty 
> difficult, because these methods didn't exist in Rivet <1.2.0, so whenever 
> an interface is updated, it won't compile with older versions of Rivet 
> anymore.
> 
> Would it be possible, to leave the parsing of the first event in 
> AnalysisHandler in any way? I know why you moved it, because you needed 
> the first event before doing the analyses init. But maybe that could be 
> done by having AnalysisHandler extract the information and call the 
> analysis init in an "if (firstevent)" block within 
> AnalysisHandler::analyze?
> 
> What do you think?

I think you're right that there's a problem in the design, but I think 
that getting rid of the "if (firstevent)" test in Run was one of the 
nicer features of the re-design. And having the first event info 
available in the analysis init() methods is a *really* nice feature.

I think the best way to do this is to push this functionality into an 
initRun (or whatever) method on AnalysisHandler. That makes a lot of 
sense to me, since the Run is really an interface for handling the HepMC 
reading: AnalysisHandler is the place that should know about the physics 
of the incoming events. Removing one level of indirection seems like a 
good idea. However, you'd need to be able to protect the required call 
to this method inside a #ifdef block.

Any thoughts on this? I'm currently trying to get a load of the 
validation tickets ticked off --- please validate your own analyses too, 
or you might find them disappeared from the release! --- but will return 
to this before the release.

Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh