Star-tpc-l mailing list

["Van Buren, Gene" <gene AT bnl.gov>]

Regarding the "Twist" (and "Clock") portions of this note from last week....

Yuri has corrected me:
The "Twist" and "Clock" distortion corrections have not actually been used 
for the past decade, beginning with the prior "New Tpc Alignment" that was 
introduced around that time. StMagUtilities prints these numbers, but there 
has been no distortion correction applied. The alignment work introduced in 
this PR has resulted in the printed values being zero, but no actual effect 
on the applied distortion corrections for old datasets.

Yuri absorbed these two distortion corrections into the alignment a decade 
ago, and his latest alignment will absorb the ""SectorAlign" distortion 
correction as well.

-Gene

> On Oct 4, 2024, at 12:38 PM, Frank Geurts <geurts AT rice.edu> wrote:
> 
> 
>> 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.
>> 
>