Draft: FPGATrackSim: implement basics of second stage algorithm
This isn't quite ready but it does seem to be actually working, and I thought I'd make a draft MR to track it going forward and let other people take a look.
We now have a third algorithm, FPGATrackSimSecondStageAlg, that can be turned on by setting the flag Trigger.FPGATrackSim.Hough.secondStage=True when running the main analysis config script. The second stage algorithm extrapolates from tracks found in the "first stage" run of pattern recognition and scoring by adding in hits from any extra layers that were not used as part of that first pass. So in our default 1D/2D Hough configuration, this extends tracks from 9 layers up to 13.
The layers used in the second stage are determined by the plane map file. In the past there was the idea that a physical layer could be mapped to different logical layers in the first and second stages, so there are PlaneMap_1st() and PlaneMap_2nd() classes. We decided to effectively deprecate that; so now logical layers 0-8 are assigned to the layers used in the first stage and logical layers 9-12 are assigned to the unused inner pixel layers. Second stage maps for regions other than the barrel are still a work in progress. As a result, at least until the mapping-related changes in !73952 from @wcastigl get merged, we now use the second stage plane map to map all the hits, and then use the region maps to test whether or not a hit is part of the first stage or second stage. (The plane map files in cvmfs will need to be updated accordingly). The data preparation algorithm then sorts the hits into buckets, sends the 1st stage ones on to LogicalHitsProcessAlg, and the 2nd stage ones onto SecondStageAlg via storegate.
The main algorithm then runs and generates first stage tracks. The first stage tracks also get sent via storegate to the SecondStageAlg, which retrieves them and then runs a new "track extension tool" (FPGATrackSimTrackExtensionTool), a new generic interface with a function that takes tracks and hits and creates a new set of roads. There is currently only one implementation of the track extension tool, and that is the "window" algorithm originally developed in HTTSim by @alancast, and one of the last pieces of 21.9 that was never ported over. We are currently using the window sizes that I found in the HTTSim git repository; though this definitely will need more study.
After running the extension tool, we then proceed through the normal steps of road filtering (if necessary due to spacepoints), track scoring (via the 2nd stage linear fitter or NN), and duplicate removal. At the moment the second stage track fitting is all turned off, because we don't have the necessary inputs like second stage fit constants. But support for that can be reenabled in a future MR. Unfortunately, at the moment we still need placeholder fit constants because the sector bank tries to load both the first stage and the second stage at the same time.
For local testing I created /data/brosser/eftrack/secondstage/maps and /data/brosser/eftrack/secondstage/banks on the Chicago analysis facility by copying what's currently in cvmfs, modifying the plane map to change the ordering (as described above), and adding placeholder second stage sector files.
Tagging @jahreda, @alancast, @jsurduto, @imaznas, @wcastigl; feel free to add others as needed!
Looking at the diff I see that some whitespace changes (automatically deleting trailing whitespace, etc.) got swept into this, which is inflating the number of modified lines a bit-- sorry about that. I can probably remove them before we actually merge, if that would be helpful. Also one thing I did not do is move the matchIdealGeoSector function (duplicated between several places now, including this tool and both Hough transforms) into the sector bank-- but that probably should also get done before we merge.