Add Corrections minitree #109
Conversation
…into corrections_minitree
…into corrections_minitree
…into corrections_minitree
…into corrections_minitree
|
This looks pretty great already. I think it raises a rather fundamental question though. This is 'how do we keep track of corrections versions?' The way this is implemented corrections versions would follow global hax versions. Honestly I don't see a problem with that but curious if others have opinions. So if we go this way we probably can the DB-based correction for everything except gains and NN-weights (and any other gain/posrec/otherwise fundamental corrections that come up later). All energy-based corrections would be rolled into this treemaker and its version would get bumped every time there's a new correction file. Another point: once we get all corrections in hax that are going there, do we want to drop them from pax? So then cs1, cs2, etc would exist only in this minitree and not in Basics. |
|
You would have to increment this minitree's version to bump the corrections, the hax global version does nothing (though it is being tracked during minitree creation, and there is an option to set a minimum requirement on it). But indeed, using this would move to a global correction version. One problem is the corrections for non-standard interactions, e.g. for double scatter and delayed decay analyses. The reason we made the interaction concept in pax was to compute such corrections for several interaction pairs. If we now move corrections into hax there's a risk of duplicating code between this minitree and double scatter / delayed decay analysis minitrees. |
|
@JelleAalbers so even if hax global version changes, minitrees will not be regenerated if the minitree version did not change? |
|
Exactly. This could be changed of course, but at the moment there is no automatic process to regenerate minitrees so they are accessible for everyone. Imagine what happened this week with the Extended minitree multplied to all minitrees at once... |
|
For versioning that's exactly the behavior we want. You don't want to change something totally different then have your minutes minitrees all recreated just because version was bumped. For non-standard interactions I think we should just make the corrections here as well. The benefit of saving the time and effort of reprocessing is worth the extra complexity of putting it here. Maybe we can split the actual correction application into a more general function that could be applied to any interaction? |
| result['x_observed'] = x_observed | ||
| result['y_observed'] = y_observed | ||
|
|
||
| result['cs2'] = s2.area * s2_correction |
There was a problem hiding this comment.
Does this ensure cs2 = cs2_top + cs2_bottom? i.e. if you have top and bottom maps, why not use them both and then sum for total? should get better resolution this way, right?
'Corrections' must precede 'Basics', according to XENON1T/hax#109
This adds a minitree "Corrections" which provides the corrected S2 area (total, top and bottom) and the observed (uncorrected) interaction positions for the main interaction. It is envisaged to move all high-level corrections for which there is no good reason to compute during processing with pax here eventually.
Important caveat: the corrected, total S2 area is called 'cs2' just like in the Basics minitree. This could cause some problems since in Basics the S2 correction is not applied correctly (due to a pax bug). Therefore to get the correction applied correctly, while the key is duplicated, Corrections has to come before Basics in the list of treemakers passed to hax.minitrees.load:
hax.minitrees.load(datasets, ['Corrections', 'Basics'])not
hax.minitrees.load(datasets, [ 'Basics','Corrections'])The map to use for the S2 correction is chosen based on the run number (change at the end of science run 0). The position reconstruction correction (which is undone to give the uncorrected positions) comes from pax.
This treemaker fixes all the problems (that I know about) related to applying the S2 correction and I have checked that the correction applied using it within hax looks reasonable.