-
Notifications
You must be signed in to change notification settings - Fork 57
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
Enhancement: Interested in contributing EDM4hepLoader #478
Comments
Current thoughts are to extend the |
Possibly useful info: I'm at ICHEP if any of the devs is and we can chat about this. |
Indeed, this would be great to have! For completeness, I also link to a relevant section of the docs: https://github.com/HSF/phoenix/blob/master/guides/developers/event-data-loader.md |
Thanks for the interest @wdconinc. TypeScript boils down to JavaScript, so if you know JavaScript, I don't think there would be major problems. I am not too sure about the similarities between the root event data and the EDM4HEP data that's stored in root files. But keeping the architectural aspects in mind, if it's too different or doesn't have any overlap, I will recommend creating a separate loader that can scale independently of the jsroot event loader. @vvolkl already pointed you to the docs we have for creating a custom event loader. That should already be plenty helpful. What I recommend is going through the following steps:
If you need any help, please feel free to reach out. We can have a call or pairing session if needed as well. :) |
I don't have any TypeScript experience :-) but I'm interested in contributing an event loader for the EDM4hep data model used by the key4HEP project. The data model contains both simulated and reconstructed quantities which would be useful to implement, but an initial goal is these simulated quantities:
My approach would be to use the ScriptLoader to use JSROOT to read edm4hep.root files.
The EDM4hep data model does not contain geometry information beyond position (and in some cases momentum). Connection to geometry is done through the cellID fields which connect to DD4hep geometry objects. This will not be possible to replicate here unless there is some way of connecting the cellID back to the geometry in Phoenix. That's out of scope here (and likely not necessary until we need to show entire calorimeter blocks instead of simple hit positions).
The files in the EDM4hep data model do not use prescribed names for the collections of event-level information. A SimTrackerHits collection can be stored under any name, which will need to be defined in the event loader configuration (MCParticles are typically stored under that name, though, so it presents a convenient target for initial implementation).
Cc'ing @vvolkl since of interest.
The text was updated successfully, but these errors were encountered: