search

GRIFFINCollaboration / GRSISort

A lean, mean, sorting machine.
MIT License
21 stars 54 forks source link

Walk correction implementation #252

Closed SmithJK closed 9 years ago

SmithJK commented 9 years ago

During the 2014 GRIFFIN runs, the triggering and timing as done with a leading-edge discrimination. This means we have a significant (up to 30 clock ticks) amount of walk for low energy gammas.

Time shifts in general could effect the event construction, the events that pass the "coincidence" window, and the addback algorithms. As long as we keep such a large time window for event construction, the effect of a walk correction there would be minimal. It's fairly easy to execute the correction before judging "coincident" events in MakeMatrices. The problem we're encountering right now is how to incorporate this into the creation of the addback hits.

Is there existing infrastructure that we could take advantage of to implement a walk correction? If there is no existing infrastructure, are there pre-existing ideas/plans for implementing this? I imagine this might be related to implementations of the CFD sub-timestamp correction, but I haven't located where that occurs in the code.

r3dunlop commented 9 years ago

Here are my final result....Closable now? screenshot 2015-04-02 17 12 28 screenshot 2015-04-02 17 12 03

SmithJK commented 9 years ago

I agree that this is a satisfying implementation, but I'd like to keep this open until @jpore can also confirm this in her analysis.

pcbend commented 9 years ago

sure; I did the above fits for her data so this will work.

jpore commented 9 years ago

I am fine with closing this. Just one quick question, now that the walk correction in in the .cal file, is grsisort going to be taking it into account when it is sorting? so that we can get time-corrected matrices?

pcbend commented 9 years ago

Every time the GetTimeStamp() function is called it will be taken into account. Currently both event building and addback building use this function. Anything where someone decideds to reconstruct the timestamp themselves using TimeStampHigh and TimeStampLow will still have to have the correction applied.

On Tue, Apr 14, 2015 at 4:41 PM, Jennifer Pore notifications@github.com wrote:

I am fine with closing this. Just one quick question, now that the walk correction in in the .cal file, is grsisort going to be taking it into account when it is sorting? so that we can get time-corrected matrices?

— Reply to this email directly or view it on GitHub https://github.com/pcbend/GRSISort/issues/252#issuecomment-93053203.

jpore commented 9 years ago

sounds good to me.

pcbend commented 9 years ago

Excellent, closed.