You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow up with Francesco on the question of whether we need to reprocess the data vs rerun CAF making:
The change from Anna is "good enough" with some caveat:
The CRT PMT matching stores a flashClassification and the relative time difference between flash and the CRTs.
In absence of issues, checking both flashClassification and the relative time difference is redunt.
But there was a bug (fixed in the producer). Anna's fix to CAFs make it so that the analyzers can use the delta-T in CAFs to evaluate their selection. This will solve the need to rerun the production. In this case the analyzers can ignore the flashClassification variable, which in some cases is wrong.
One thing we can do, to make it even more analyzers proof, is asking Anna to include in her PR the re-evaluation of the flashClassification.
so basically we can make it so that the flashClassification gets automatically filled correct and the analyzers are agnostic of any issues.
We now have @francesco's bug fix for the producer module in the v09_89_01_01p03 release. But I understand from this morning's infrastructure meeting that we also need Anna's fix? Can either @francesco or @anna comment? If we need another PR can we get that this week based on the SBN2024A branch for the next release along this branch? Thanks!
hi @SFBayLaser, my fix only affects the CAFMaker. v09_89_01_01p03 could be fine for production to start with and we could rerun the CAFMaker on the stage1 files to pick up my updates to the CAF entries. I do have the fix ready in an sbncode PR based on develop and am currently making a sbncode PR based on SBN2024A.
Activity
cerati commentedon Oct 22, 2024
we would need to back port #760.
@francescopoppi is this affecting only the CAF stage or also stage1?
SFBayLaser commentedon Oct 22, 2024
This is the problem/fix along the develop branch: SBNSoftware/sbncode#477
This provides an explanation of the issue.
SFBayLaser commentedon Oct 22, 2024
Follow up with Francesco on the question of whether we need to reprocess the data vs rerun CAF making:
The change from Anna is "good enough" with some caveat:
The CRT PMT matching stores a flashClassification and the relative time difference between flash and the CRTs.
In absence of issues, checking both flashClassification and the relative time difference is redunt.
But there was a bug (fixed in the producer). Anna's fix to CAFs make it so that the analyzers can use the delta-T in CAFs to evaluate their selection. This will solve the need to rerun the production. In this case the analyzers can ignore the flashClassification variable, which in some cases is wrong.
One thing we can do, to make it even more analyzers proof, is asking Anna to include in her PR the re-evaluation of the flashClassification.
so basically we can make it so that the flashClassification gets automatically filled correct and the analyzers are agnostic of any issues.
I can ask Anna to include that.
SFBayLaser commentedon Oct 28, 2024
We now have @francesco's bug fix for the producer module in the v09_89_01_01p03 release. But I understand from this morning's infrastructure meeting that we also need Anna's fix? Can either @francesco or @anna comment? If we need another PR can we get that this week based on the SBN2024A branch for the next release along this branch? Thanks!
aheggest commentedon Oct 28, 2024
hi @SFBayLaser, my fix only affects the CAFMaker. v09_89_01_01p03 could be fine for production to start with and we could rerun the CAFMaker on the stage1 files to pick up my updates to the CAF entries. I do have the fix ready in an sbncode PR based on develop and am currently making a sbncode PR based on SBN2024A.
francescopoppi commentedon Dec 10, 2024
@SFBayLaser #786 (#787 for develop) Should close this issue once for all.