eic
Save the beam conditions to a metadata tree
The beam energies and divergence settings used in the simulation should be stored so they can be read back by EICrecon. This is essential for correct reconstruction of the FF/FB particles.
Currently there are metadata trees written by podio to the edm4hep file but it's not clear to me if DD4hep has an interface to those or whether this needs to be implemented there before we can add it into the epic workflow.
I don't see how one can pass divergence settings from afterburner to DD4hep. The beam energies can be fished out from the MCParticles collection right now.
Maybe, we should upstream functionality of afterburner into DD4hep. Then the configuration options can be saved uniformly.
Do you know how to go about saving to the podio metadata trees from DD4hep? It seems quite wasteful to infer a constant from the MCParticles tree every event.
The afterburner already adds a bunch of comment lines to the output hepmc file, if we can add these (and maybe a few more) into the epic edm4hep file metadata.
Whatever implementation narrows down the legitimate workflows currently available to collaborators. Either everyone will have to pass their events through the afterburner, or if the afterburner is added, presumably into npsim, this moves away from having a simple ddsim interface.
The afterburner already adds a bunch of comment lines to the output hepmc file, if we can add these (and maybe a few more) into the epic edm4hep file metadata.
I see in HepMC3 there is a support for storing arbitrary attributes in GenRunInfo: https://gitlab.cern.ch/hepmc/HepMC3/-/blob/master/include/HepMC3/GenRunInfo.h Perhaps, that's what afterburner may be using to write those. I think, DD4hep can be relatively easily made to copy those over into the PODIO metadata.
Do you know how to go about saving to the podio metadata trees from DD4hep? It seems quite wasteful to infer a constant from the MCParticles tree every event.
It shouldn't be too hard, since HepMC and EDM4hep logic are both part of DDG4 module. It's pretty much the same as https://github.com/AIDASoft/DD4hep/pull/1059
Whatever implementation narrows down the legitimate workflows currently available to collaborators. Either everyone will have to pass their events through the afterburner, or if the afterburner is added, presumably into npsim, this moves away from having a simple ddsim interface.
If the values are not present we could just assume some sensible defaults or completely disable some functionality.