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

[Andy Buckley]

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.

> If there is no reason except for nicer design, 
> I'd very much prefer to keep this as simple (and backwards-compatible) as 
> possible for users. And although not having looked at the recent code 
> changes in detail, I'd also volunteer to make this change.

I hacked this a bit on the train yesterday, and it ties in with other 
improvements which will be relevant for asymmetric beam analyses. I've 
just committed this stuff, so please take a look.

It's always an incentive to keep things backwards compatible, but 
equally I think it's only become clear relatively recently that to 
specify some run properties before the run starts (possibly by passing 
an example event to the analysis handler) is a very useful thing to do. 
Since (to my knowledge) it's just Sherpa, Hw++ and Atlas (via James and 
myself) who are currently using the Rivet API, and backwards compatible 
analyses are always possible via a HepMC pipe, I'd like to be able to 
update an API that no longer quite matches the analysis behaviour. 
Anyway, I think it's clear that no-one who's really clued-in should be 
using Rivet 1.1.3: the head/alpha version is miles better.

>> 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 ;)

Andy

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