Need multiple cS1 variables corresponding to each position? about hax HOT 5 CLOSED

Correction maps were added to run-db collections to unify/simplify applying different maps to different runs. With the FDC-3D using NN positions we're starting to build multiple sets of corrections for each set of runs. We should maintain a single set of corrections, or implement something else on the collections level to keep this tidy.

from hax.

If S1 map is defined as function of nn positions, in principle we should check whether it's applicapable to tpf positions. Not sure if we should create two cS1s at the stage from different algorithms for now. Maybe @pelssers can check whether we see some strange effect on the TPF position distributions using NN based FDC.

I'm fine with keeping NN as the default maps for signal corrections, as I don't see position resolution is that significant in terms of S1&S2 variations. Which algrithms to use for FV definition could be another independent topic, if we can not prove NN FDC can be applied to TPF, probably we need to use NN as position indicator and TPF as a cut to ensure quality. But my understanding could be wrong.

from hax.

@berget2 I think when this Corrections treemaker was implemented, the RunsDB collection implementation became obsolete, right @coderdj? i.e. Run dependence now handled in hax.ini.

@feigaodm I agree. How about #156?

from hax.

@pdeperio yeah we got rid of this run DB logic for everything except the electron lifetime correction. It's all in hax now and should be easier to oversee. That whole mess with all these DB entries was not a really well thought out system but we needed something to avoid bumping pax versions 10 times during the SR0 workshop.

As far as the subject of this thread. We should settle on a position then just have one correction. It's relatively easy to unapply and reapply custom corrections (with the other position for example) for people studying that kind of thing but I wouldn't necessarily formalize it.

from hax.

Implemented in #156

from hax.