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.

[ckierans]

I plan to update this considering all of the class cleanup work Andreas has been doing. Hold off on the review for now.

[ckierans]

I've rebased this PR and now it compiles and gives the assigned position with the detector volume for GR and XE hits (without defined position to be handled in revan). Still to-do is to improve the fault tolerance, especially in the GRDetector definition and figure out how to make it past the failing Nuclearizer Tests.

[ckierans]

The same events shown above now look like this:

ID 999
TI 1752086301.590697765
HT 3;-1.45508;-0.403631;1.32867;365.288;0.0336036;0.0108784;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

Event ID 999 has no change

ID 1000
TI 1752086301.590716838
XE 3.47831;0.271062;-2.96898;137.792
XE 3.51217;-0.706715;2.01167;12.2433
XE -0.486893;0.359485;2.80692;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

The positions given for the XE hits have changed since these are randomly generated and only need to be somewhere in the detector volume.

SE
ID 1092
TI 1752086301.653759717
HT 3;0.640234;-0.261012;-1.9307;240.615;0.0336036;0.0144355;0.0336036;0.93588
XE 0.782459;0.592877;-0.0787267;13.421
GR -3.27347;0.471883;-3.84373;44.4647
CC NStripHits 6
BD DepthCalibrationError (Out of Range)
BD GR Veto
PQ 3.65235

The GR and XE hit positions have changed. And now I'm more confident that the GR hit is actually within the GR volume.

[ckierans]

Also, to do, check that this hit info is properly streamed to all file types. So far, I've only checked evta files.

[ckierans]

Updated to now include the same GR and XE information in the .dat file.

Here is the output in the .dat file for the same events above shown for the .evta file:

ID 999
TI 1752086301.590697765
HT -1.45508 -0.403631 1.32867 365.288 366.214 364.111
SH 0 l 19 1 4247.03485 3826 366.214284 1.2855423 4
SH 0 h 20 1 4178.50483 3751 364.111102 1.4497052 4
QA StripHitBelowThreshold (Strip hit removed with energy 8.611698)
PQ 1.17822681
SE
ID 1000
TI 1752086301.590716838
XE -2.46234;0.377755;0.982664;137.792
SH 0 h 51 1 4315.55534 2336 137.791761 1.33754408 4
SH 0 l 52 1 1709.1889 1721 27.360547 1.27447088 0
SH 0 l 53 1 4147.99753 2672 179.791312 1.23832431 4
XE -0.825155501;-0.369018537;1.80040285;55.3573515
SH 0 h 58 1 4269.71855 1867 55.3573515 1.24812198 4
SH 0 l 52 1 1709.1889 1721 27.360547 1.27447088 0
SH 0 l 53 1 4147.99753 2672 179.791312 1.23832431 4
BD DepthCalibrationError (Multiple hits on single strip)
QA StripHitBelowThreshold (Strip hit removed with energy 12.243347)
QA StripPairing (Best reduced chi square is not below 25 (30.144551)) (Event contains multiple hits on a single strip)
PQ 30.144551

ID 1092
TI 1752086301.653759717
HT 0.640234 -0.261012 -1.9307 240.615 240.988 240.237
SH 0 l 37 1 4193.79887 3036 240.988222 1.31871564 4
SH 0 h 48 1 4165.14152 3073 240.23656 1.32840706 4
GR 2.72265872;-0.680158793;4.01276848;44.4647188
SH 0 l 58 1 4108.76258 1782 43.7611669 1.27877867 4
SH 0 h 64 1 0 1880 46.6654598 2.26168324 5
QA StripHitBelowThreshold (Strip hit removed with energy 7.762298) (Strip hit removed with energy 13.421008)
BD GR Veto
PQ 0.705392641

I also robustified the GR Detector finding in MModuleDepthCalibration::LoadDetectorDimensions and confirmed that this works for the STTC mass model and the COSI-SMEX-Payload mass model.

The UnitTests fail and the and MModuleRevan currently crashes (even after updating with PR #211), I'm assuming because the XE and GR events aren't handled properly. When running the .evta file through revan manually, I get these warnings printed to screen:

Position of XE does not represent a drift chamber!
Position of GR does not represent a detector with guard ring!

[ckierans]

@zoglauer copying my message from above that still applies:

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. I assume we're not using the MDDetector GuardRing class since we cannot define it's shape as accurately as we need?

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?

Let me know if you want me to do more checks. I think this is good for you to review and make the appropriate changes in MEGAlib.

[zoglauer]

What data should I use for testing?

[zoglauer]

Can you merge in the latest changes in nuclearizer, too?

[zoglauer]

hacked the merge myself and getting it to crash with the unit tests - investigating...

[zoglauer]

To prevent the crash you have to set in MModuleRevan:
MRERawEvent* RawEvent = new MRERawEvent(m_ReconstructionGeometry);
instead of:
MRERawEvent* RawEvent = new MRERawEvent();

[ckierans]

What data should I use for testing?

@zoglauer Do you still need data to test this with or did you make some yourself? I assume you're looking for an evta file with the XE and GR hit types?