Update LoadReweightGenieEvent.cpp

[S81D]

When running LoadReweightGenieEvent, it was noticed that some events have parameter throws that make the calculated cross section negative (xsec_total < 0). I'm not sure what the specific cause is, but in the meantime I have added some error handling to account for events where re-weighting failed. We can use a recovery point where the given weight will automatically be assigned as 1.0 if such a problematic value is sampled in multisim/unisim.

Without any error handling, this error causes the toolchain to crash at entry N, leading to a large loss in statistics. Say you're running over 1000 events, you therefore lose out on 1000 - N. This particular issue is observed more in World events (at the ~1% level) than in tank samples.

Here's an example of the particular error (/pnfs/annie/persistent/simulations/genie3/G1810a0211a/standardv1.0/world/gntp.85.ghep.root):

Executing tool LoadWCSim with MC entry 20, trigger 0 Analyse: GReWeightXSecMEC.cxx:500: double genie::rew::GReWeightXSecMEC::CalcWeightPNDelta(const genie::EventRecord&): Assertion `xsec_tot > 0.' failed. Aborted (core dumped)

The abort message seems to exclusively happen in GReWeightXSecMEC. The default knobs set that I believe affect this are:

NormCCMEC sigma = 1.0
NormNCMEC sigma = 2.0

I have tested the error handling and its stable over many (~1000) files. It just assigns a weight = 1.0 if it encounters said problem. I also haven't noticed any glaring oddities in the resulting weight distributions. More work is obviously needed to understand what could be going wrong.

Describe your changes

Checklist before submitting your PR

• This PR implements a single change (one new/modified Tool, or a set of changes to implement one new/modified feature)
• This PR alters the minimum number of files to affect this change
• [N/A] If this PR includes a new Tool, a README and minimal demonstration ToolChain is provided
• [N/A] If a new Tool/ToolChain requires model or configuration files, their paths are not hard-coded, and means of generating those files is described in the readme, with examples provided on /pnfs/annie/persistent
• [N/A] For every new usage, there is a reason the data must be on the heap
• [N/A] For every new there is a delete, unless I explicitly know why (e.g. ROOT or a BoostStore takes ownership)

Additional Material

In discussions with Andy, he says he does not recall observing this in any MicroBooNE analysis. The worry is that we may a mismatch in the version, model configuration, or phase space type when events are generated vs. reweighted, or else the interaction is amiss somehow. Given it happens more in World events, maybe it suggests a target dependence (C, H, O, Si, etc...). James and I don't have a ton of time to track down the source of the bug, so this is the best solution in the short term.

[jminock]

Looks good! Thank you for this!!

[marc1uk]

Interesting! I've never used such old-school techniques myself but it seems like it should be fine. I've asked @brichards64 if he can see any problems, but otherwise I'd be happy to merge.