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

Use JANA's new first-class PODIO integration #578

Merged
merged 9 commits into from
Apr 14, 2023
Merged

Conversation

wdconinc
Copy link
Contributor

@wdconinc wdconinc commented Mar 28, 2023

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?

  • Bug fix (issue #__)
  • 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?

  • 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?

  • JEventProcessorPODIO used to maintain a list of factories that have thrown an exception. After it crashed once, it would never be called again. Now, it will be called again on every event. The reason for this change in behavior is that PODIO v0.16.3 has a bug where collection IDs depend on insertion order, which causes the PODIO frame writer to crash. Excepting factories still produce an empty collection (thus preserving the insertion order), which the JEventProcessorPODIO then persists.

@wdconinc wdconinc marked this pull request as draft March 28, 2023 21:25
steinber added a commit to steinber/EICrecon that referenced this pull request Apr 12, 2023
…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.
@nathanwbrei nathanwbrei changed the title Nbrei jana podio Use JANA's new first-class PODIO integration Apr 13, 2023
@nathanwbrei nathanwbrei marked this pull request as ready for review April 13, 2023 15:06
@wdconinc wdconinc enabled auto-merge (squash) April 14, 2023 03:12
@wdconinc wdconinc merged commit e14e81b into main Apr 14, 2023
@wdconinc wdconinc deleted the nbrei_jana_podio branch April 14, 2023 15:07
@veprbl
Copy link
Member

veprbl commented Apr 14, 2023

Fails clang-tidy check:

/home/runner/work/EICrecon/EICrecon/src/services/io/podio/JFactoryPodioT.h:11:10: error: 'datamodel_glue.h' file not found [clang-diagnostic-error]
#include "datamodel_glue.h"
         ^~~~~~~~~~~~~~~~~~

@wdconinc
Copy link
Contributor Author

Hmm, strange, how did it handle that correctly before? We've always had a glue header. ..

@nathanwbrei
Copy link
Contributor

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}
Copy link
Member

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).

Copy link
Contributor Author

@wdconinc wdconinc Apr 16, 2023

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)

Copy link
Contributor

@nathanwbrei nathanwbrei Apr 16, 2023

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.

Copy link
Member

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.

@nathanwbrei nathanwbrei mentioned this pull request Apr 18, 2023
7 tasks
@nathanwbrei nathanwbrei mentioned this pull request Apr 28, 2023
7 tasks
wdconinc added a commit that referenced this pull request Jul 28, 2023
wdconinc added a commit that referenced this pull request Jul 28, 2023
wdconinc added a commit that referenced this pull request Jul 29, 2023
wdconinc added a commit that referenced this pull request Jul 30, 2023
### 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.
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

Successfully merging this pull request may close these issues.

4 participants