Open tmadlener opened 1 month ago
This is a brief summary the outcome of todays meeting, where we also discussed this (@mirguest, please correct me if anything is wrong in the following).
CEPCSW is currently using a "frozen" version of EDM4hep and other externals since they are heavily involved in preparing the TDR. As such, at least from that point of view we (as in EDM4hep) are pretty much at liberty to break things as far as CEPCSW is concerned. We have then decided to remove some of the drift chamber study related datatypes for EDM4hep v1.0 and bring them back in a more consistent form afterwards. For that we also need to consult with IDEA / FCC reconstruction developers (@BrieucF just as a heads up) and check how to bring everything into a consistent shape, also considering the discussion / resolution in #322. CEPCSW should then be able to "catch up" / migrate from the TDR status to EDM4hep v1.0, once the TDR is done.
Keeping this open, but moving it out of the EDM4hep v1.0 project.
There are a few inconsistencies in the datatypes that were introduced in https://github.com/key4hep/EDM4hep/pull/179 for the drift chamber study. A tangential but related discussion is also in #322. Opening this issue as a sort of summary discussion board to see if this situation can be improved, also keeping in mind the proposed new datatypes in #299
My main complaints for these are:
HitLevelData
is a rather generic lwo level datatype to store pretty much any detector hit / readout. However, it has a few members that make it very gaseous detector specific. I think this should be reflected in the name https://github.com/key4hep/EDM4hep/blob/bd9f45039149781a9c54799a6d03df56b1b5ed49/edm4hep.yaml#L239-L244Hypothesis
is not properly documented and seems to be lacking andf
field(?). Specifically it has achi2
value, but it's not really documented what thischi2
value represents. Also thesigma
docstring could be refined. https://github.com/key4hep/EDM4hep/blob/bd9f45039149781a9c54799a6d03df56b1b5ed49/edm4hep.yaml#L232-L236Overall the structure of the dataypes is fairly involved, but also quite separate from the rest of EDM4hep and I am wondering whether there is a way to (re-)organize the information in a cleaner way in order to make them better integrated into the rest of EDM4hep. Relation diagram of the datatypes and some EDM4hep datatypes:![image](https://github.com/key4hep/EDM4hep/assets/16774861/b8c4a6b5-1876-4acf-a92a-2b960bafccb0)