Move LSTGeometry repo into ESProducer#203
Conversation
|
I expect that the final code will not use a csv file to generate the geometry bin/txt file. |
|
After binning, it takes about 15 seconds, which is starting to be reasonable. There are more improvements that can be made to make it faster, but for now I'll switch gears to get the CMSSW part in place. |
c2d0f53 to
a5accdb
Compare
|
Not sure if it will work, but let's see what happens. /run cmssw |
|
There was a problem while building and running with CMSSW. The logs can be found here. |
1 similar comment
|
There was a problem while building and running with CMSSW. The logs can be found here. |
a91bad2 to
14afa6a
Compare
|
There was a problem while building and running with CMSSW. The logs can be found here. |
|
The PR was built and ran successfully with CMSSW. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
|
The plots actually look better than I expected. I'll take another look at the standalone comparison and post it here. I'll also do some cleanup and look into what could be the source of the differences in the |eta|~1-2 range. |
|
/run cmssw |
There was a problem hiding this comment.
Pull request overview
This PR refactors the LST (Line Segment Tracking) geometry handling by moving geometry computation logic into a dedicated structure and making it available through both an ESProducer (for CMSSW integration) and a standalone binary. The key changes include:
- Introduction of a new
LSTGeometrydata structure containing centroids, slopes, pixel maps, and module connections - New geometry computation methods using Eigen for matrix operations
- An ESProducer (
LSTGeometryESProducer) that generates geometry fromTrackerGeometry - A standalone binary (
lst_make_geometry) for offline geometry generation - Integration with existing LST code through new overloaded methods
Key Changes
- New geometry computation framework with multiple helper classes (Module, DetectorGeometry, etc.)
- Refactored
LSTESDatato accept both file-based andLSTGeometry-based initialization - Updated parameter handling to use string-based
ptCutlabels for ES record lookups
Reviewed changes
Copilot reviewed 41 out of 42 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
RecoTracker/LSTCore/plugins/LSTGeometryESProducer.cc |
New ESProducer for generating LSTGeometry from TrackerGeometry |
RecoTracker/LSTCore/standalone/bin/lst_make_geometry.cc |
New standalone binary for geometry generation |
RecoTracker/LSTCore/interface/LSTGeometry/*.h |
New geometry data structures and computation methods |
RecoTracker/LSTCore/src/LSTESData.cc |
Added overload for LSTGeometry-based initialization |
RecoTracker/LSTCore/src/TiltedGeometry.cc |
Added overload to load from LSTGeometry slopes |
RecoTracker/LSTCore/src/EndcapGeometry.cc |
Added overload to load from LSTGeometry slopes |
RecoTracker/LSTCore/test/DumpLSTGeometry.cc |
New test analyzer for dumping geometry |
RecoTracker/LST/plugins/alpaka/LSTProducer.cc |
Updated ptCut parameter handling |
RecoTracker/LSTCore/standalone/Makefile |
Added build rules for geometry binary |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
There was a problem while building and running with CMSSW. The logs can be found here. |
|
is the copilot reviewer feature something to be manually added? I don't see this option in #212 |
|
The PR was built and ran successfully with CMSSW. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
|
/run cmssw |
|
The PR was built and ran successfully with CMSSW. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
|
/run cmssw lowpt |
|
/run cmssw |
|
There was a problem while building and running with CMSSW. The logs can be found here. |
|
The PR was built and ran successfully with CMSSW. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
|
The PR was built and ran successfully in standalone mode running on CPU. Here are some of the comparison plots.
The full set of validation and comparison plots can be found here. Here is a timing comparison: |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 48 out of 49 changed files in this pull request and generated 11 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
I applied some of the copilot suggestions. I didn't touch the phi computation because it is set up in a weird way and it doesn't work if you simplify it to a more common expression. I'll run the CI one last time before squashing and opening a PR upstream. |
|
run-ci: [cmssw, checks] |
|
The PR was built and ran successfully with CMSSW running on CPU. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
d7a0ed3 to
e612f24
Compare
|
run-ci: all |
|
The PR was built and ran successfully in standalone mode running on CPU. Here are some of the comparison plots.
The full set of validation and comparison plots can be found here. Here is a timing comparison: |
|
The PR was built and ran successfully with CMSSW running on CPU. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
|
run-ci: [all, hlt] |
|
The PR was built and ran successfully in standalone mode running on CPU. Here are some of the comparison plots.
The full set of validation and comparison plots can be found here. Here is a timing comparison: |
|
The PR was built and ran successfully with CMSSW running on CPU. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
|
The PR was built and ran successfully with HLT setup running on CPU (procModifiers = ). Here are some plots. HLT General Plots
The full set of validation and comparison plots can be found here. |
59f2ef5 to
4e3de58
Compare
|
run-ci: [cmssw, hlt] |
|
The PR was built and ran successfully with CMSSW running on CPU. Here are some plots. OOTB All Tracks
The full set of validation and comparison plots can be found here. |
|
The PR was built and ran successfully with HLT setup running on CPU (procModifiers = ). Here are some plots. HLT General Plots
The full set of validation and comparison plots can be found here. |
|
@ariostas IIUC, the new LSTGeometryESProducer is much slower than the older version from files. If that's the case, more GPU modules unrelated to LST/tracking might contribute device data products or be already running on the GPU compared to the older setup. Also it's more likely that all 16 LST modules across different streams will start running simultaneously (in the old setup chances are that the earlier patatrack tracking modules with some variance in time to completion spread out the start time of the LST modules). The profiler timeline should clarify if we suffer from accumulation of some other work or if it's mostly from multiple LST starting at the same time. |
|
@slava77 yeah, from looking at nvidia-smi I suspect something like that is happening. With the old setup things there's more variance in the streams, so some of them end up finishing before others reach peak vram usage, whereas with the new setup all streams finish more or less at the same time, so peak vram usage is higher. One thing I've been trying to figure out is why with multiple streams the vram usage is so much higher. I expected that each stream should use about the same vram as if you ran everything in one stream. However, they end up using more than twice of the single stream peak. I was thinking that the caching allocator was causing some memory fragmentation, so I was experimenting with allocating memory in fixed block sizes, but it didn't really make a difference. I'll run the profiler for the new and old setups, using 1 and 16 streams, and let you know what I find. Thanks! |
if there's some LST kernel herding/crowding, perhaps a solution is to write some dummy CPU module that just checks something trivial from the LSTGeometry, and schedule it early in the tracking sequence. It's probably more economical to put it in a beginRun (but then I recall there are some subtleties about declaring ES availability at beginRun vs event) |
4e3de58 to
46de12c
Compare




























This is still a work in progress, but I'm opening a draft PR so you can track the progress.
This is relatively close to working for standalone, but I still have to figure out the ESProducer part.