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

Add more CUDADataFormats packages for the Patatrack integration #1395

Merged
merged 2 commits into from
Oct 20, 2020
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion categories_map.py
Original file line number Diff line number Diff line change
Expand Up @@ -849,11 +849,19 @@
"Validation/Shashlik",
],
"heterogeneous": [
"CUDADataFormats/Common",
"CUDADataFormats/BeamSpot",
"CUDADataFormats/CaloCommon",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if these are supposed to be used in reco CUDA, I think that a reco signature is needed as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fwyzard , any idea if these will be used by reco CUDA?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you please update the PR to add these under reconstruction too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shall I also add under "heterogeneous" all packages that do or will contain any kind of CUDA code ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is a good question, dependency of a category X should not be responsibility of that category X.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, what I meant is: should heterogeneous (currently, only CUDA) code be signed by the heterogeneous category ?
If the answer is "no", then what about the data formats just added under reconstucrtion ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a vague recollection that the last time this was discussed (sorry no reference) the outcome was not to add heterogeneous on every package with CUDA code, but to be assigned by other L2s when necessary. I'm fine with moving all other CUDADataFormats than CUDADataFormats/Common and CUDADataFormats/StdDictionaries only under reconstruction.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me add (post-merge) that after some further thought I think I contradicted myself in above (assign heterogneous on PRs on demand, but leave CUDADataFormats packages out from heterogeneous), and leaving all CUDADataFormats packages (also) under heterogeneous is more consistent.

"CUDADataFormats/Common",
"CUDADataFormats/EcalDigi",
"CUDADataFormats/EcalRecHitSoA",
"CUDADataFormats/HcalDigi",
"CUDADataFormats/HcalRecHitSoA",
"CUDADataFormats/SiPixelCluster",
"CUDADataFormats/SiPixelDigi",
"CUDADataFormats/StdDictionaries",
"CUDADataFormats/Track",
"CUDADataFormats/TrackingRecHit",
"CUDADataFormats/Vertex",
"HeterogeneousCore/CUDACore",
"HeterogeneousCore/CUDAServices",
"HeterogeneousCore/CUDATest",
Expand Down