Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move event.mcheader and/or replace it with a metadata dict #922

Closed
kosack opened this issue Jan 10, 2019 · 2 comments
Closed

move event.mcheader and/or replace it with a metadata dict #922

kosack opened this issue Jan 10, 2019 · 2 comments

Comments

@kosack
Copy link
Contributor

kosack commented Jan 10, 2019

Right now there is a lot of MC header info in a Container (MCHeaderContainer) in the event data structure. Two things should be done:

  1. move this outside of the event data structure, since it does not change per event (similar to the inst container, which will also move soon

  2. decide whether it makes sense that this info is in a Container at all: Containers represent rows in an output table, so if there is no use-case for writing this as a row, we could just directly copy all header info in a simtel file into e.g. the event.mc.meta dictionary (the metadata for the event.mc table), which would be output as attributes or header keywords in the output file by a TableWriter subclass.

@kosack
Copy link
Contributor Author

kosack commented Jan 10, 2019

It was noted in #921 that there is a use case for (2) being a Container, in that we might merge multiple simtel files into one output file, in which case we'd want a table of these parameters (and also perhaps that means we need to store the mc run number with each event to be able to associate the two)

@kosack kosack changed the title move event.mcheader or replace it with a metadata dict move event.mcheader and/or replace it with a metadata dict Jan 10, 2019
@maxnoe
Copy link
Member

maxnoe commented Oct 26, 2020

I think with the dl1 tool developement it is pretty clear that we want to have access to this kind of information in a container and that it makes sense that an event knows about its mc header, since we might work on an event stream from several runs.

@maxnoe maxnoe closed this as completed Oct 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants