Fix areal density by using geometry to tag y and v bars, and fixing CalculateTrackLength

[jdkio]

Removed the assumption that bars are y view bars. Instead TMS_Geom.h now uses the geometry to figure out which bar type it's looking at. The geometry flags y and v bars using the names "modulelayervol1" and "modulelayervol2". Also added the ability to add x and u bars using "modulelayervol3" and "modulelayervol4" as their names.

But please note, currently TMS_Reco has many ProjectHits(vector<TMS_Hit>, TMS_Bar::kYBar); statements. This means that by labeling the hits properly, the default reconstruction only takes into account hits along the y views and ignores all v views. This may interfere with @AsaNehm's work in some way depending on how they implemented their changes. We probably only want a single ProjectHits statement in the initial track finding call that does y view and then again for v view, and then it reconciles all the tracks.

The second fix removes if ((point2-point1).Mag() > 100) continue; from TMS_TrackFinder::CalculateTrackLength and fixes the calculation to properly take into account the views.

The continue statement skips hit pairs that are over 10cm apart. However, with the extra length caused by the 3 deg plane rotation, this skips many hits. This is especially noticeable in the thick region where each plane is 8cm apart to start. And then when you properly take into account the y and v views, then all hit pairs would be skipped. Plus there was no justification for this inclusion so it feels safe to remove.

The second part of the change is to take into account the views. That is, you don't want to zig zag between y and v views because that adds to your path length in an unrealistic way. In the future, we'll want to incorporate the 3d information in this calculation but for now it takes track length from view type that has the most n nodes. Because of the point about ProjectHits above, this means that the track length is calculated with the y view exclusively.

For more information, see my 2023-11-16 talk at the TMS studies meeting.

[ast0815]

Just to double check: So this means there is nothing wrong with the geometry itself? Then why did the appear/disappear depending on which geometry you used?

[jdkio]

That's explained in the talk, but basically because geom v1 had overlapping planes. This meant that hits always were y view. So then the areal density calculation was correct because the tracks were actually straight. With y and v views, tracks have zig zags. The > 100mm cut that I removed caused the areal density to be skipped for those hit pairs reducing the overall areal density