Missing conversion of run header and other file metadata

[Zehvogel]

The standalone conversion has this using:
https://github.com/key4hep/k4EDM4hep2LcioConv/blob/bbc776d91e4882b3c14418b6033af7d4eb78e7cb/k4EDM4hep2LcioConv/src/k4Lcio2EDM4hepConv.cpp#L144-L157

Some lcio files have useful metadata like the cross section of the generated process or the polarisations of the beams that we loose this way. I would't even know where to put this conversion as the current one is event-by-event.

This is only part of a more general problem: even if we put in a standalone converted edm4hep file that has that metadata in a tree called "runs" this tree will be missing from the edm4hep file after reconstruction... (but this is an issue for another repo)

[Zehvogel]

@tmadlener do you have an idea for a simple way to address this? We would like to do a bigger miniDST production soon and it would be really useful to be able to access beam polarisations, cross section (+errors) etc. like in lcio

[tmadlener]

In principle the conversion should be quite straight forward, once you have the data in your hands. The problem currently is probably mostly getting the necessary data into the framework and out again.

For getting data in one would probably need to touch the LcioEvent algorithm to not just skip Runs / Run headers.

For getting data out you would probably need to hack another frame category into the PodioDataSvc and make the PodioOutput write that as well.

The overarching issue is that I have no idea whether Gaudi supports something like a Run, i.e. whether there are hooks that we can use to trigger reading new run level data, and write old ones...

[Zehvogel]

After taking another look at this I am not interested in the run header that much anymore.

The stuff I need is actually stored in the event parameters. We are also missing the conversion for those in the wrapper at the moment but this should be as simple as

LCIO2EDM4hepConv::convertObjectParameters<EVENT::LCEvent>(lcioEvt, evtFrame);

I have not checked the other direction (edm4hep to lcio).

[tmadlener]

I have not checked the other direction (edm4hep to lcio).

Actually not entirely sure whether we have functionality already in that direction.