-
Notifications
You must be signed in to change notification settings - Fork 30
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
Use JANA's new first-class PODIO integration #578
Conversation
404d6c4
to
4f50384
Compare
f3daa2a
to
d0a603c
Compare
…to segvios when reading back association objects from podio file. will all be replaced by PR eic#578 but this helps keep things working in advance of that.
9c5b74a
to
f3c8290
Compare
f3c8290
to
f176c96
Compare
01f373b
to
e767de6
Compare
3ee7a97
to
9fa09ff
Compare
Merge with tracking
Squash me with MatchClusters
This means that we won't need to modify 100+ files again
9fa09ff
to
3e6440f
Compare
Fails clang-tidy check:
|
Hmm, strange, how did it handle that correctly before? We've always had a glue header. .. |
I'm guessing clang-tidy is complaining about the "" instead of doing the full #include <services/io/podio/datamodel_glue.h> |
@@ -34,7 +34,7 @@ plugin_glob_all(${PLUGIN_NAME}) | |||
# but that never really worked quite right. Thus, we just force-run it | |||
# whenever cmake is run. | |||
execute_process ( | |||
COMMAND python3 ${PROJECT_SOURCE_DIR}/make_datamodel_glue.py WORKING_DIR=${PROJECT_BINARY_DIR} EDM4HEP_INCLUDE_DIR=${EDM4HEP_INCLUDE_DIR} EDM4EIC_INCLUDE_DIR=${EDM4EIC_INCLUDE_DIR} | |||
COMMAND python3 ${PROJECT_SOURCE_DIR}/make_datamodel_glue.py WORKING_DIR=${PROJECT_SOURCE_DIR} EDM4HEP_INCLUDE_DIR=${EDM4HEP_INCLUDE_DIR} EDM4EIC_INCLUDE_DIR=${EDM4EIC_INCLUDE_DIR} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the reason for this change? I'm wondering why re-building is now very slow, but reverting this change seems to help speed things up (only tested on one of my development branches).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nathanwbrei in case he didn't get this (I created the PR so I may be the only one getting the notifications)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's because every factory now needs datamodel_glue.h for the PodioTypeMap that defines the relationship between podio types and their collections. The build dir for the podio plugin isn't on the include path for the other plugins, and the source dir is. I understand that using datamodel_glue all over the place is undesirable because it makes compile times longer and is just generally ugly. Luckily this is temporary. By adding one using MyPodioObject::collection_t = MyPodioObjectCollection
to the generated EDM headers we can get rid of this. That requires a new release of both JANA and an approved PODIO PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Contrary to this report, the compilation times don't change for me when I try to compile revisions before this PR.
### Briefly, what does this PR introduce? No need to keep `hello world` examples around in the source tree. ### What kind of change does this PR introduce? - [x] Bug fix (issue: debt) - [ ] New feature (issue #__) - [ ] Documentation update - [ ] Other: __ ### Please check if this PR fulfills the following: - [ ] Tests for the changes have been added - [ ] Documentation has been added / updated - [ ] Changes have been communicated to collaborators ### Does this PR introduce breaking changes? What changes might users need to make to their code? No. ### Does this PR change default behavior? No.
Briefly, what does this PR introduce?
This PR allows eicrecon to use PODIO associations correctly, resolving a major source of confusion, entropy, and bugs.
As of v2.1.0, the JANA2 framework has first-class support for PODIO. This means that users can directly read and
write PODIO collections. Even if users continue to use the classic JANA vector-of-pointers style, under the hood the PODIO objects are always registered to a collection and that collection is registered to a frame. JANA understands and abides by PODIO's memory ownership semantics, including supporting subset collections.
This PR also converts three problematic factories into multifactories, which support multiple outputs. These factories used direct object ID rewriting in order to set up valid associations, and/or had particularly thorny PODIO ownership issues. They are now models for how to write factories in the future. These factories are: MatchClusters_factory, ParticlesWithTruthPID_factory, and TrackingResult_factory.
What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
The way that users should write future factories has changed. Users should look to TrackingResult_factory as an example of how to write factories with multiple outputs.
Output files are now written using Podio's Frame writer, which is incompatible with Podio's older EventStore writer.
Does this PR change default behavior?