`reboost-hpge` needed features

[tdixon97]

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

hit tier

HPGe dead layer model

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

Run grouping

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

• [x] possibility to read multiple files
• [x] 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

• [x] start thinking about a prototype
• [x] 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.

  • [x] decide the format where to place this etc
  • [x] package for generating kinematics https://github.com/tdixon97/pyvertexgen/tree/main
  • [x] 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?
  • [x] 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 ?