Priority: Soon after merging
Integrate accumulated algorithm developments held back during integration PR review
Update LST README, printouts and minor fixes.
Links to specific comments
Covered partially by #55. A follow up to accommodate the developments made in #72 will be needed.
Deal with the configurability of the pT threshold
Covered by #39.
LST in HLT
Changes in LST conditions data
LST workflow
Make general-purpose functions widely available in CMSSW
The plan would be to move all general-purpose functions (work started in #71):
- Follow up PR with general functions.
- Follow up PR moving LST to use those and delete custom implementations.
Priority: Short-term plan
Rewrite the loops in the kernels using uniform_elements, independent_groups, independent_group_elements, etc.
Rewrite kernels with proper, concrete dimensions instead of templated types
Priority: Long-term plan
Improvements to the data format interface between LST and CMSSW
Construct LST condition data from the existing EventSetup info
Improvements in storing and using "magic numbers
Miscellaneous improvements
Improvements to ESProducer
Priority: Soon after merging
Integrate accumulated algorithm developments held back during integration PR review
Update LST README, printouts and minor fixes.
Links to specific comments
Covered partially by #55. A follow up to accommodate the developments made in #72 will be needed.
Deal with the configurability of the pT threshold
Covered by #39.
LST in HLT
Changes in LST conditions data
I would prefer if the possibility of overriding the conditions data setting
LST_BASEorTRACKLOOPERDIRwould be disabled when building this code inside CMSSW.LSTESData::geometryDataDirneeds a check thatgetenv("CMSSW_SEARCH_PATH")is not null.LST workflow
Respect new relval_2026.py structure.
Decide if we want different workflows for different backends.
Implement a "GPU vs CPU" workflow.
Fill seed stop info when LST runs (expected by DQM/validation).
Make general-purpose functions widely available in CMSSW
The plan would be to move all general-purpose functions (work started in #71):
Priority: Short-term plan
Rewrite the loops in the kernels using uniform_elements, independent_groups, independent_group_elements, etc.
CMSSW Integration of LST cms-sw/cmssw#45117 (comment):
Experiment with
make_workdiv.CMSSW Integration of LST cms-sw/cmssw#45117 (comment):
No need to set the grid size to 1, the alpaka execution will run the blocks one after the other automatically. You can set the grid size to 1 - the difference will be in how the kernel are executed over the elements. Either way, I think whatever approach you choose should be documented.
CMSSW Integration of LST cms-sw/cmssw#45117 (review)
Links to specific comments
Rewrite kernels with proper, concrete dimensions instead of templated types
CMSSW Integration of LST cms-sw/cmssw#45117 (review):
Links to specific comments
Priority: Long-term plan
Improvements to the data format interface between LST and CMSSW
CMSSW Integration of LST cms-sw/cmssw#45117 (review):
Define the LST inputs and output as PortableCollections, and pass them (or their Views) to the LST algorithm.
Links to specific comments
Fill a host SoA directly in
LSTPhase2OTHitsInputProducer, copy it to device, and avoid the 6 intermediate copies of thestd::vectors.Performance-wise best would be to move them in
LSTProducer::produce(), that would require theLST::hits()etc to either return a mutable reference, or a value that was moved-from in thehits()method itself.Eventually (or ideally) we'd want to issue the
alpaka::memcpy()calls to copy the data from device to host inacquire(), and have the destination host memory accessed only inproduce().Construct LST condition data from the existing EventSetup info
Improvements in storing and using "magic numbers
CMSSW Integration of LST cms-sw/cmssw#45117 (review):
Links to specific comments
Miscellaneous improvements
Try std::binary_search(data, data + ndata, search_val) from C++20.
Review uint4 usage.
Improvements to ESProducer
Make it more clear which members are on the device memory and which are on the host memory. Suggest to consider moving all data that are used only in host code into a separate ES data product.