You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#16 is making the first step for restructuring FLArE output trees. Currently we have:
flare_hits: full hits from the liquid argon volume;
hcal_hits: full hits from the HCAL (BabyMind or legacy);
.h5 file with pixel map 3D output;
(optional) 2D histograms, per event and per prong;
(optiocal) pseudo-reco tree;
There a few points to think about:
The size of flare_hits can be challenging. I did a series of quick tests using the same 5 genie events. The current solution is to remove the step size user limit. Is this acceptable?
Can we reduce the output size by merging hits in 3D? For instance, we could do something similar to what PixelMap3D does at a single particle level instead of binning all energy deposits from all particles together.
But if we do so, isn't it the same of having larger steps? Should we just settle to larger step sizes?
no max step size -> ~20 MB/event
1.0 mm max step size -> ~33 MB/event
0.5 mm max step size -> 64 MB/event
Enabling the pseudo-reco output requires a lot of acrobatics... and it's currently no longer working as before because we are not updating the primaries list (only using native G4 vertex primaries). There are also places in which we require a FPFNeutrino, which can't always be there.
Given the proposed changes in Merge primaries and trajectories into a single "particles" tree #18 -- full particle hierarchy tree in output -- can we completely move the pseudo-reco in a downstream ad-hoc FLArE-only package?
Should create separate hit/SD classes for the FLArE HCAL?
#16 is making the first step for restructuring FLArE output trees. Currently we have:
flare_hits: full hits from the liquid argon volume;hcal_hits: full hits from the HCAL (BabyMind or legacy);.h5file with pixel map 3D output;There a few points to think about:
flare_hitscan be challenging. I did a series of quick tests using the same 5 genie events. The current solution is to remove the step size user limit. Is this acceptable?Can we reduce the output size by merging hits in 3D? For instance, we could do something similar to what
PixelMap3Ddoes at a single particle level instead of binning all energy deposits from all particles together.But if we do so, isn't it the same of having larger steps? Should we just settle to larger step sizes?
Enabling the pseudo-reco output requires a lot of acrobatics... and it's currently no longer working as before because we are not updating the primaries list (only using native G4 vertex primaries). There are also places in which we require a
FPFNeutrino, which can't always be there.Given the proposed changes in Merge
primariesandtrajectoriesinto a single "particles" tree #18 -- full particle hierarchy tree in output -- can we completely move the pseudo-reco in a downstream ad-hoc FLArE-only package?Should create separate hit/SD classes for the FLArE HCAL?