[Clas12_rgb] Review recommendation to be addressed

[Christopher Dilks]

Dear Silvia,

> This recommendation concerns only the 4-GeV runs at the end of F19. In one
> of our last RGB meetings, it was agreed not to correct the helicity in
> post-processing in order to be consistent with what was done for pass1. If
> you all still agree with this decision, I will reply to the committee that
> we will add clearly to our cooking documentation the need to flip the
> helicity by hand in the analysis for those few runs. If you think we
> should change strategy and correct it while cooking, please let me know
> soon. I don't have a very strong opinion on this. I understand wanting
> consistency with pass1, but part of me thinks it would be more effective
> to correct directly in the cooking to avoid complications at the analysis
> stage.
The helicity sign is also wrong for the entire Spring 19 data set, at 
least for Pass 1. Was this corrected for Pass 2?

Personally I would prefer REC::Event:helicity to be corrected overall 
for all datasets, but if Spring 19 still has the wrong sign, maybe it's 
better to be consistent with past errors and not change anything. I plan 
to encode the correct helicity sign in the QADB, and good documentation 
would help as well.

Another alternative is to make REC::Event:helicity have the wrong sign 
for everything in RG-B, then at least everything is consistently wrong 
(and also consistent with RG-A). In this case, analyzers of RG-A and 
RG-B would just have to know to flip the sign.

Chris

P.S. the corresponding Spring 19 readiness review QA timelines may have 
shown the correct beam spin asymmetry sign, since back then we were 
silently correcting the helicity; we no longer do this correction in the 
QA, so nowadays we see which datasets still have the wrong helicity sign.



On 11/8/23 04:36, Silvia Niccolai via Clas12_rgb wrote:
> Dear all,
> the pass2 review went well but a few recommendations need to be addressed
> before having the green light to start cooking.
> The ones on Status table validation and cooking time estimation are being
> dealt by Florian and Zhiwen.
> I need your input on the other one:
>
> "The helicity shows a different sign definition between low energy (4GeV)
> and high energy (11 GeV) runs. RGB should define a clear strategy (keep
> the different signs and correct when physics analysis will be performed or
> correct with the existing post-processing procedure) and document it to
> avoid confusion in the future."
>
> This recommendation concerns only the 4-GeV runs at the end of F19. In one
> of our last RGB meetings, it was agreed not to correct the helicity in
> post-processing in order to be consistent with what was done for pass1. If
> you all still agree with this decision, I will reply to the committee that
> we will add clearly to our cooking documentation the need to flip the
> helicity by hand in the analysis for those few runs. If you think we
> should change strategy and correct it while cooking, please let me know
> soon. I don't have a very strong opinion on this. I understand wanting
> consistency with pass1, but part of me thinks it would be more effective
> to correct directly in the cooking to avoid complications at the analysis
> stage.
>
> Thanks a lot for your feedback.
>
> The RGB meetings will resume next week after the CLAS meeting ends.
> Best regards,
> Silvia
>
>
> _______________________________________________
> Clas12_rgb mailing list
> Clas12_rgb at jlab.org
> https://mailman.jlab.org/mailman/listinfo/clas12_rgb