Follow-up tasks for the LST algorithm #46746
Comments
|
cms-bot internal usage |
|
A new Issue was created by @VourMa. @Dr15Jones, @antoniovilela, @makortel, @mandrenguyen, @rappoccio, @sextonkennedy, @smuzaffar can you please review it and eventually sign/assign? Thanks. cms-bot commands are listed here |
|
assign reconstruction, heterogeneous, alca, hlt, upgrade |
|
@cms-sw/tracking-pog-l2 |
|
New categories assigned: reconstruction,heterogeneous,alca,hlt,upgrade @atpathak,@consuegs,@fwyzard,@jfernan2,@makortel,@mandrenguyen,@Martin-Grunewald,@mmusich,@Moanwar,@perrotta,@srimanob,@subirsarkar you have been requested to review this Pull request/Issue and eventually sign? Thanks |
|
+hlt
|
|
The following items have been addressed by #46857 and have been marked as done in the description:
|
|
The following items have been addressed by #46967 and have been marked as done in the description:
|
This issue is a simplified version of SegmentLinking#75, meant to list and keep track of the various upcoming developments for the LST algorithm that were either brought up during the PR #45117 review or planned by the development team. The order of the tasks below roughly corresponds to their priority/timescale, as estimated by the developers.
Integrate accumulated algorithm developments held back during integration PR review (Devel changes that need to be rebased SegmentLinking/cmssw#117).
More details
Update LST README, printouts and minor fixes:
Links to specific comments
Deal with the configurability of the pT threshold:
LST in HLT
More details
Changes in LST conditions data
More details
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
More details
Respect new relval_Run4.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
More details
CMSSW Integration of LST #45117 (comment)
CMSSW Integration of LST #45117 (comment)
The plan would be to move all general-purpose functions (work started in More work on Constants and removal of vector copies SegmentLinking/cmssw#71):
Rewrite the loops in the kernels using uniform_elements, independent_groups, independent_group_elements, etc.
More details
CMSSW Integration of LST #45117 (comment):
Experiment with
make_workdiv.CMSSW Integration of LST #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 #45117 (review)
Links to specific comments
Rewrite kernels with proper, concrete dimensions instead of templated types
More details
CMSSW Integration of LST #45117 (review):
Links to specific comments
Improvements to the data format interface between LST and CMSSW
More details
CMSSW Integration of LST #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
More details
Improvements in storing and using "magic numbers
More details
CMSSW Integration of LST #45117 (review):
Links to specific comments
Miscellaneous improvements
More details
Try std::binary_search(data, data + ndata, search_val) from C++20.
Review uint4 usage.
Improvements to ESProducer
More details
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.
FYI @slava77 @ariostas
The text was updated successfully, but these errors were encountered: