Add a Gaudi Algorithm filling EventHeader eventNumber and runNumber

[BrieucF]

I open this PR so that people can already use it. @ebrondol let me know if that fits your needs or not.

Some open questions:

• shall we handle thread safety for the event counter? Would setting eventNumber as a class member and protecting it with mutex be a solution? Or maybe we could retrieve the eventNumber directly from Gaudi?
• Is there a way to hook this to k4run so that it is always ran unless specified otherwise?
• we may hit a problem in the future: edm4hep::EventHeader also holds the MC event weight. This should be filled by retrieving information from the MC generator (e.g. aMC@NLO). IMHO the eventNumber filling should not be tight to MC generation. We would then have to create a second eventHeader collection for the MC weights since it is const (or is there a workaround?) which is not nice. Maybe we should separate the MC weight from the eventNumber in edm4ehp?
• This is not related to this PR but the MC weight should probably not be a single number (a lot of theoretical systematic uncertainties can be nicely estimated by storing multiple weights).

BEGINRELEASENOTES

• Add a Gaudi Algorithm 'EventHeaderCreator' for filling EventHeader eventNumber and runNumber

ENDRELEASENOTES

[tmadlener]

I think this is very useful. One comment on the naming: Could that reflect that this creates an EventHeader collection? I.e. s/Filler/Creator/

Also this is most likely useful mainly for debugging / developments, as in "proper workflows" something outside the framework should probably populate this (?).

---

shall we handle thread safety for the event counter? Would setting eventNumber as a class member and protecting it with mutex be a solution? Or maybe we could retrieve the eventNumber directly from Gaudi?

Making this thread safe from a technical point of view could probably be done with either an atomic or a mutex/lock. However, there is a more conceptual question of what this "event counter" even means in a multi threaded context. At least the expectation that the event numbers are sequential has to be dropped.

we may hit a problem in the future: edm4hep::EventHeader also holds the MC event weight. This should be filled by retrieving information from the MC generator (e.g. aMC@NLO). IMHO the eventNumber filling should not be tight to MC generation. We would then have to create a second eventHeader collection for the MC weights since it is const (or is there a workaround?) which is not nice. Maybe we should separate the MC weight from the eventNumber in edm4ehp?

At least ddsim fills this information now from the input generator file, since AIDASoft/DD4hep#1059

This is not related to this PR but the MC weight should probably not be a single number (a lot of theoretical systematic uncertainties can be nicely estimated by storing multiple weights).

This is probably more related to EDM4hep itself.

[tmadlener]

Could you also resolve the conflict in the CMakeLists file. From a quick glance it should be fairly straight forward and it should be possible to keep everything.

[BrieucF]

Hi @tmadlener, thanks for taking a look. Is it ok to have the "Merge branch main" commit or do you want me to rebase?

• One comment on the naming: Could that reflect that this creates an EventHeader collection? I.e. s/Filler/Creator/

Done

• in "proper workflows" something outside the framework should probably populate this (?).

Why would this have to live outside of the framework? I anticipated that a job submitter could interact with this algorithm by setting the runNumber and eventNumberOffset properties.

[tmadlener]

Depending on when you enter the framework, you already have an event (and a run number), e.g. from the generator / simulation or the DAQ. So the "normal user" doesn't have to populate this information, unless they start from the vacuum effectively. Obviously, if you start from empty events or if you have to add this after the fact, this is very useful.

Is it ok to have the "Merge branch main" commit or do you want me to rebase?

That is OK. We will squash in any case when merging.

[BrieucF]

Ok thanks, then that would probably be another algorithm retrieving the info from external source.

[BrieucF]

Any further comment on this PR?

[ebrondol]

Not from my side - thanks for including this feature!

[andresailer]

for developing: install somehow pre-commit, and pre-commit install inside the repository.

[BrieucF]

for developing: install somehow pre-commit, and pre-commit install inside the repository.

Done

[tmadlener]

Stupid question (and I should know this), does this produce the expected output file if we don't use our Key4hep data service (k4DataSvc)?

[BrieucF]

If I understand you question correctly: this steering file does not produce any output file.

[tmadlener]

Ah yes, you are obviously right. Could you make it produce an output file by adding the necessary algorithm. Mainly to make everyone see how a complete example looks like and so that they then also have an output file that they can look at after running the tests.

[BrieucF]

Sure, here it is

[ebrondol]

That is indeed very useful.