Generator-level info in event output tree

[mvicenzi]

This PR closes #17 .

Summary of changes:

• Added new GeneratorVertexMetadata struct to hold generator-level information. A std::vector of GeneratorVertexMetadata is owned by the GeneratorBase class (one metadata object per vertex in the event). Each specific generator implementation fills the metadata with available information.
• The generator metadata is stored in the event through EventInformation, derived from G4UserEventInformation. This is set immediately after the generation of the primaries in PrimaryGeneratorAction.
• In the AnalysisManager, this information is recovered from the event and saved in the event output tree.
• Previously, some generator-level info for the genie generator was carried to the AnalysisManager by setting a custom PrimaryParticleInformation object (derived by G4UserPrimaryParticleInformation) for each primary particle. This is no longer needed, so that class has been removed.
• The FPFNeutrino class is also no longer needed and has been removed.
• Since no custom classes are used in the output files, the creation of the FPFClasses dictionary has been removed from the CMakeLists file.

Open questions:

• The hepmc files do not seem to offer much metadata. There is a possibility to save custom attributes in the event header, but the current files do not show any. The metadata being propagated is therefore lacking. We should investigate whether the parameters of the model(s) used can be saved into the file (instead of just the file name) so that we can encode them properly.
• Depending on Merge primaries and trajectories into a single "particles" tree #18 , we might decide to add to the event tree a vector of primaries for each vertex.

[benw22022]

Hi @mvicenzi, thanks for this! I'll try and review this as soon as I get a chance
To answer your question about the hepmc metadata - it appears like we should be able to included this info - I'd have to discuss this with the FORESEE authors about how to add this. Might need some careful thought since not all LLP models have the same free parameters that we'd need to keep track of

[benw22022]

Hi @mvicenzi, thanks for this really nice PR - I like how this is implemented! I still need to look into how to add metadata to the hepmc inputs from FORESEE - but that can be for a future PR. Before merging please can you check that the genie macros still work? I tried running nue_genie.mac and it either crashes for me with a munmap error or throws a memory related warning Warning in <THnSparseT<TArrayF>::GetSparseFractionMem>: Cannot determine type of elements! - my guess is some kind of memory problem in PixelMap3D?

[mvicenzi]

Hi @mvicenzi, thanks for this really nice PR - I like how this is implemented! I still need to look into how to add metadata to the hepmc inputs from FORESEE - but that can be for a future PR. Before merging please can you check that the genie macros still work? I tried running nue_genie.mac and it either crashes for me with a munmap error or throws a memory related warning Warning in <THnSparseT<TArrayF>::GetSparseFractionMem>: Cannot determine type of elements! - my guess is some kind of memory problem in PixelMap3D?

I see the same behaviour -- thanks for pointing this out!
Unfortunately I was testing with only numu_genie.mac, so I missed this... I will investigate a bit more into PixelMap3D.

[mvicenzi]

@benw22022 I believe I fixed it -- it was a combination of the map not being filled correctly due to a bad if and also bad vector indexes (primary track IDs go from 1 to N, so they can't be used directly as index).

[benw22022]

Thanks @mvicenzi! I think the fix is working, I don't see the memory errors anymore - feel free to merge this 🚀