Draft: FPGATrackSim: Add FPGATrackSimGNN as GNN Pipeline to FPGATrackSim
FPGATrackSim implementation of GNN-based pattern recognition.
This is an ongoing effort to implement each piece of the GNNPatternRecoTool as a configurable option for pattern recognition within FPGATrackSim. Each step of the GNN-based pattern recognition is isolated in it's own tool and it's progress is tracked through the following checklist.
-
FlagConfiguration: Not a tool, but add flag configuration capabilities for when running the python script in athena. -
GraphHitSelectorTool: Converts FPGATrackSimHit to FPGATrackSimGNNHit (strip SPs with both cluster information). -
GraphConstructionTool: Builds edges between hits using user-configured tool, default is doublet module map with minmax tolerance. -
EdgeClassifierTool: Score edges using interaction network graph neural network inferencing. -
RoadMakerTool: Use ConnectedComponents to build list of FPGATrackSimGNNHits chained together, then find the original FPGATrackSimHits and make a vector as each FPGATrackSimRoads. -
Add proper header information and detailed comments to match athena-etiquette.
Merge request reports
Activity
added EFTracking Trigger main labels
assigned to @jaburles
- Resolved by Jared Dynes Burleson
- Resolved by Jared Dynes Burleson
- Resolved by Jared Dynes Burleson
1 #include "FPGATrackSimGNNRoadUnionTool.h" So perhaps we could add functionality to the existing RoadUnionTool. My code here doesn't add anything new, but there is a portion of the RoadUnionTool that is written for only Hough.
If that could be configured to only be used for Hough then I could call the existing RoadUnionTool rather than have my own, but at the moment the current configuration is not suited to run for GNN pipeline.
changed this line in version 18 of the diff
45 // Currently only Doublet Module Map with minmax cuts exist, but others can be implemented later on as desired 46 47 if(m_moduleMapType == "doublet") { 48 loadDoubletModuleMap(); 49 getDoubletEdges(hits, edges); 50 } 51 else { 52 ATH_MSG_FATAL("ERROR! Only Doublet Module Map for GNN Graph Construction is implemented currently."); 53 } 54 } 55 56 void FPGATrackSimGraphConstructionTool::loadDoubletModuleMap() 57 { 58 // Store the module map as vectors for each TBranch in the ROOT file 59 if(m_moduleMapPath == "") { ATH_MSG_FATAL("ERROR! No Module Map provided. Please provide a valid path to a ROOT file."); } 60 TFile* file = TFile::Open(m_moduleMapPath.value().c_str()); Please use THistSvc for this. You can see examples in the HoughRootOutputTool: https://gitlab.cern.ch/atlas/athena/-/blob/main/Trigger/EFTracking/FPGATrackSim/FPGATrackSimHough/src/FPGATrackSimHoughRootOutputTool.cxx
changed this line in version 8 of the diff
- Resolved by Jared Dynes Burleson
- Resolved by Jared Dynes Burleson
69 69 70 70 // --- Unmapped Location --- 71 71 void setIdentifier(unsigned int v) { m_identifier = v; } // 32 bit (short) module identifier 72 void setIdentifier64(unsigned long int v) {m_identifier64 = v; } // 64 bit (long) module identifier It is needed temporarily. Our current module map uses the 64 bit module_id. I have tried to find a list of modules that has both the 32 bit and 64 bit module id (which I can then replace the 64 bit module id with the 32 bit module id), but I have not found it.
In the future, we will do a re-"training" of the module map using the output from the DataPrepAlg in which the 32 bit module ids are going to be fine, but for now I need to keep the 64 bit module ids, unless we have a resource that I can use to manually convert them in the module map.
I don't have any idea on the timeline of the training. This hasn't begun. This would require full graphs from FPGATrackSim as well, something that we don't have yet. And the event generation and training would take a long time. It would be easier if we just had a tool to convert the 64 bit module ID to the 32 bit module ID, then I could modify the ROOT file and remove this extra variable.
Can you please add the ATLAS bot to your fork such that the CI status is properly displayed? Thanks
https://atlassoftwaredocs.web.cern.ch/athena/git/gitlab-fork/#add-your-friendly-build-bot
We will see with the next pipeline. We should see the green/red sign on this page https://gitlab.cern.ch/atlas/athena/-/merge_requests
added 295 commits
-
be65e3ed...b0a46552 - 258 commits from branch
atlas:main
- b0a46552...b1409a14 - 27 earlier commits
- 1e6dd4d5 - latest status, no hits in GNNPatternRecoTool
- 8a3abf79 - Add GNNRoadUnionTool
- 669bb669 - fixes to RoadFinder/GNNRoadUnionTool
- f4939703 - fixing extra spacing
- 38953d7e - one day...
- edab7716 - almost there...
- 9ebcdc06 - Add FPGATrackSimHit recording
- c42de48c - Add flag capabilities to set GraphConstructionTool via python script
- 536c893f - Finalizing GraphConstruction flag configuration
- ff4089cc - Replace CSV output with ROOT using THistSvc
Toggle commit list-
be65e3ed...b0a46552 - 258 commits from branch
added 1 commit
- a3726f8f - cleaning up code, adding header comments, removing redundant includes