`reboost-hpge` needed features

[tdixon97]

For a first basic (but complete) HPGe simulation we need the following features:

hit tier

HPGe dead layer model

• extraction of detector positions from GDML (for DLs)
• Create a legend-pygeom-hpges HPGe object per detector, from GDML or metadata?
• processors for distance to surface

Run grouping

Note

this could probably also be done in the evt tier or elsewhere, need some general solution.

• possibility to read multiple files
• just read n evtids
  I think the code should be do this as early as possible but maybe should be flexible (any tier can read just n rows).

Energy response / other heuristics

• possibility of a more advanced smearing functionality i.e. mixture models
• consider a mode of processors of sampling where instead of:

$$ x^{\text{new}}_i = f(\overbrace{\vec{x_i}}^{\text{other vars.}}, \theta) \rightarrow x^{\text{new}}_i \sim p(x,\vec{x_i}, \theta) $$

Where p is some PDF.

HPGe usability

Should this come in the hit part of the code or in evt, current L-200 simflow puts it in evt but I think it makes more sense in hit so that the hit tier sims are already directly comparable to hit tier data.

evt tier

• start thinking about a prototype
• should we directly build a TCM like object? - in future yes for now probably not
• start prototyping a basic example
• how do we merge the optical info (@ManuelHu )
  Should we also find a way to use some pygama functionality? probably not needed yet

vtx tier

Probably does not belong in reboost but we should think about vertex and primary generation. I think it is easier and better to have another python program eg for generating events on HPGe surfaces, or for $\beta$ (also $\beta\beta$) decay kinematics from theorists.

• decide the format where to place this etc
• package for generating kinematics https://github.com/tdixon97/pyvertexgen/tree/main
• do we add a mode to remage then to not save vertexs (save space)? probably not vertices dont take much space
• allow remage to read an LH5 file of vertexs? how should the format look?
• will it be too much disk space (also of events maybe have no hits)? probably not vertices dont take much space

[tdixon97]

From discussion with @gipert about evt tier.

• we shouldn't have the distinction in hpge/optical, or at least there should be a unified build_hit() interface
• consider whether to build events via a TCM like object (needed?)
• should we split files by run at hit or evt (hit is closer to data but might mean we have to often rerun both steps)

[tdixon97]

Processors:

• map evaluation (eg. drift time map)
• vectorised expression over many inputs (higher dim VoV)
• clustering, how?
• R90 / other heuristics,
• pileup / delayed coincidences
  Interested in helping with this @willquinn ?