[Rivet] YODA excptions

[Andy Buckley]

On 21/01/16 10:58, David Grellscheid wrote:
> Hi Andy,
>
>> I also took David's email to mean this. Not sure what is meant by the
>> "new" YODA stance on this -- we have raised exceptions for a long time.
>
> Sorry for adding to the confusion! I mixed up the "new" NaN write-outs
> with throwing exceptions. Both are good as they are in YODA, but Rivet
> needs to handle them carefully.

Yes, that makes sense. They are meant to be quiet-NaNs, so presumably 
Rivet is not choking on them, but just writing out NaNs into the .yoda 
file, which then need to be carefully handled in post-processing? Or are 
FPEs/similar being raised?

(Note that there is a yoda-15x branch for continuation of the current 
bugfix release out before we've adapted to this new error propagation.)

>> But like Chris, I'm not sure that this is a great idea, at least not
>> with the current production version
>
> I agree. That's what I meant by handling properly. There needs to be a
> try - catch block at an appropriate level to isolate analyses from one
> another.

Sure.

>> -- how do we avoid ending up with histograms in an inconsistent state
>
> In my thinking, that analysis as a whole is dead at that point. Any
> inconsistent histos lead to abandoning the analysis. Once all analyses
> are dead, you stop the run, but not before.

Hmm, it's not obvious to me that this is a good plan... although 
probably it's very unlikely for all-but-one (or a similar breakdown) 
analyses to screw up in this way. If they do, then someone -- hopefully 
not us -- really screwed up on the analysis validation!

Although as I said, I think considering the analysis dead is probably 
pessimistic. It could be a one-off messed-up event and it's ok to just 
ignore that one and carry on. But track how many failures there have 
been, and warn loudly at the end of the run if more than a percent or so 
of events have been vetoed like that. Needs some design thought.

> Most of the time, the bug is not in the data coming in, but in a badly
> written analysis that doesn't catch edge-cases properly. In that case
> it's quite rude to kill the whole production run rather than just the
> culprit. :-) Remember that we don't run Rivet stand-alone but in the
> generator run directly.

Yeah, and I appreciate that different use-cases may want different 
behaviours. Being a direct API use of Rivet means that we can at least 
initially try this out as a mode flag on AnalysisHandler and only expose 
it via the rivet command-line options if there is demand.

Andy

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