Star-tpc-l mailing list

[Frank Geurts <geurts AT rice.edu>]

Begin forwarded message:

From: Gene Van Buren <notifications AT github.com>

Subject: Re: [star-bnl/star-sw] 💥DO NOT MERGE💥 ❗ add new TPC alignment, hit errors and slewing corrections for 2024 (PR #702)

Date: October 4, 2024 at 11:05:22 AM CDT

To: star-bnl/star-sw <star-sw AT noreply.github.com>

Cc: Frank Geurts <geurts AT rice.edu>, Mention <mention AT noreply.github.com>

Reply-To: star-bnl/star-sw <reply+AEMNVR6PVQ67TU7N4GHG4NWFBPZUFEVBNHHJEYYC7A AT reply.github.com>

@genevb commented on this pull request.

---

In StRoot/Sti/StiTrackNodeHelper.cxx:

> +    if (tpcHit) {
+      if ((tpcHit->detector() == kTpcId || tpcHit->detector() == kiTpcId)) {
+	if (tpcHit->flag() == 2) {
+	  fudgeFactor = 16.;
+	}
+      }
+    }

Yuri suggested that these lines of code in Sti/StiTrackNodeHelper.cxx, modifying some TPC hit errors, might be responsible for the differences seen in nightly tests with this PR vs. DEV for pre-iTPC datasets where the alignment should be unaffected. Processing a few events with and without this bit of code is quite easy, and comparing the log files obviates that the bulk of the difference in track counts does disappear when removing this section of code.

However....from looking at the log file, I see that the new alignment scheme appears to alter TPC distortion corrections for these old, pre-iTPC datasets without any change to the reconstruction chain. This is in addition to the modification to TPC distortion corrections ("OSectorAlign") that Yuri wants to impose with the "CorrZ" chain option he has proposed for iTPC-era datasets for which I have expressed an interest in seeing a justification (through data, not anecdotally).

< StMagUtilities::XTWIST        =  -0.38 mrad
< StMagUtilities::YTWIST        =  0.25 mrad
---
> StMagUtilities::XTWIST        =  0 mrad
> StMagUtilities::YTWIST        =  0 mrad

< StMagUtilities::WestClock     =  -0.43 mrad
---
> StMagUtilities::WestClock     =  0 mrad

I do not recall this being discussed before, neither in the context of pre-iTPC datasets, nor with the new alignment. If the TPC alignment calibration was truly performed without any correction for the distortions due to the misalignment of the E and B fields (represented by the XTWIST & YTWIST numbers), I have significant concerns about this TPC alignment. Hopefully I am missing something and this is not the case.

---

I have placed output of the nightly test without this particular code (but including the rest of this PR) at this location:

This PR minus hit error change :
/star/rcf/test/gitdev/daq_sl302.stica/Mon/year_2016/AuAu200_production_2016_64bit/

This is for comparison with other iterations:

DEV :
/star/rcf/test/dev/daq_sl302.stica/Sat/year_2016/AuAu200_production_2016_64bit/
This PR :
/star/rcf/test/gitdev/daq_sl302.stica/Tue/year_2016/AuAu200_production_2016_64bit/
This PR before the Sept. 11th commits :
/star/rcf/test/gitdev/daq_sl302.stica/Wed/year_2016/AuAu200_production_2016_64bit/

I am making note of the last two in particular because Yuri's study involved the output from the last one (those jobs were started on September 11th before the time of Yuri's last commits), even though data with those commits was available. (Side note, please pay no heed to the "Tue" or "Mon" in the gitdev paths, as I moved files there from other days to avoid them being over-written.) I will note that I didn't see any effective impact of those commits on this particular test's track counts (i.e. the last two outputs may be identical).

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <star-bnl/star-sw/pull/702/review/2348366613@github.com>