GuardRing Hits and XE in EVTA file

[ckierans]

This is a draft PR that addresses issues with the position determination in the Depth Calibration. I presented at the CDEE meeting in April showing examples of these "bad" events in the evta file:

Andreas's comments for me at the meeting:

(Julian handed 5 already)

With this PR, I'm saving the GR hits in the evta file with the "GR" keyword and assigning them a random position in the guard ring volume. For events that fail the depth calibration, we're using the "XE" keyword and again just assign the hit a random position within the detector volume. These keywords are streamed to the evta file though the MHit::StreamEvta function, but I haven't yet done the same for the .dat files.

Now, looking at the same events as above, we now get

ID 999
TI 1752086301.590697765
HT 3;-1.45508;-0.403469;1.32867;365.288;0.0336036;0.0217617;0.0336036;0.961842
CC NStripHits 3
QA StripPairing (Best strip pairing leaves at least one grouping of strips unpaired (unpaired energy: 8.611698))
PQ 1.17823

Note this is a good event, and now we have the TI information from PR #124 , and better QA details from Strip pairing from PR #121 .

SE
ID 1000
TI 1752086301.590716838
XE 0.276994;0.3894;-2.94184;137.792
XE 3.56288;0.753757;-0.862971;12.2433
XE -2.24436;-0.563929;-1.24495;55.3574
CC NStripHits 5
BD DepthCalibrationError (Multiple hits on single strip)
QA StripPairing (Event contains multiple hits on a single strip)
PQ 0.386063

This event consisted of multiple hits on a single strip. It's only a QA flag in strip pairing since Julian is able to figure out the most likely ordering, but the depth calibration still fails to find the right position. Here these three hits are given the XE flag to track the extra energy deposit.

SE
ID 1092
TI 1752086301.653759717
HT 3;0.640234;-0.260901;-1.9307;240.615;0.0336036;0.0231942;0.0336036;0.93588
XE 3.27438;-0.281045;1.91529;13.421
GR -1.67307;0.345954;-3.75344;44.4647
CC NStripHits 6
BD DepthCalibrationError (Out of Range)
BD GR Veto
PQ 3.65235

Previously, this event didn't get any position calibration since there's a GR hit and it got passed over. Now, we have one hit properly calibrated, another hit which was >5 sigma out of the expected CTD range, therefore it's flagged as just an XE event, and there's a GR hit as well.

I've also cleaned up the MModuleDepthCalibration code quite a bit, and removed white spaces from MHit.

And, against my better judgement, I also included the QA flag button/selection in MEventSaver in this same PR. If you want, I can remove that here and make it a stand-alone PR for that commit.

I'll save the redefinition of the CC NStripHits keyword and the BD VETO keyword for another PR since this one has already become length.

[ckierans]

@zoglauer The newly defined GR and XE hits don't make it through revan.

The GR hits have the error "Position of GR does not represent a detector with guard ring!" since we define the guard ring volume as either Simple or Scintillator. Why don't we use the MDDetector class GuardRing in the geometry?

The XE hits have the error "Position of XE does not represent a drift chamber!" since it's checking to see whether the hit is in a DriftChamber detector type. This MREAM class does what we want, but the MREAMDriftChamber is too specific and, obviously, has the wrong detector type. Should we make a new MREAM class to handle these hits with no position calibration in the GeDs? Maybe MREAMEnergyDeposit?

[zoglauer]

I will handle that.

[ckierans]

I will handle that.

Let me know when you'll get to the revan changes @zoglauer. I'd like to test this all the way through.