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

[Frank Siegert]

Andy Buckley, Monday 14 December 2009:
> Frank Siegert wrote:
> > Andy Buckley, Wednesday 09 December 2009:
> >> Frank Siegert wrote:
> >>> 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.
> >
> > But how does this contradict my suggestion? It would still be
> > available in the analysis init() method.
> 
> At present the Analysishandler only knows about events from the
> AnalysisHandler::analyze() method onwards, so the Analysis::init()s,
> which are called from AnalysisHandler::initialize() can't know about
>  the first event's beam configuration. We'd have to change the API
>  anyway to get around this.

My suggestion was: Move the Analysis::init()s into an "if (firstevent)" 
block in AnalysisHandler::analyze(). I understand that this is not as 
clean as your solution, but it is not impossible.

> >> 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.
> >
> > Is there any easy way for Hw++/Sherpa/... to protect this inside an
> > #ifdef block? I couldn't think of one, when I wrote my other email.
> 
> We (you) can add a #ifdef to include/Rivet/Config/RivetConfig.hh.in ...
> that's why it's good to think of these things *before* we release ;)

Ok, if that's possible (and since there are only 3 users of the 
programmatic interface), I guess I can live with this.
But I would prefer the solution I suggested above (which doesn't mean I 
don't appreciate the work of making it nicer that you have done). Your 
solution means, that every interface to Rivet will have to extract the 
relevant information (sqrts, beams) out of the event themselves, which 
seems unnecessarily complicated given that we could just as well do it in 
one place, namely Rivet's AnalysisHandler.

Frank