[Halld-cal] [EXTERNAL] Re: new energy correction scheme

[Shepherd, Matthew]

Igal,

Yes, shifting to the end is fine so people can tune out if they want.

I assume that since you have merged code into the master and are moving to this scheme for the PrimEx data you have demonstrated that it works better than the existing scheme (otherwise at best you're re-inventing the wheel with increased complexity).  If your algorithm improves performance for PrimEx we should adopt it for all data eventually after double checking tuning.  Having only one approach that is the best is the way to go -- given the demands, what is good for PrimEx will be great for GlueX.

Matt


On May 9, 2020, at 1:09 PM, Igal Jaegle <ijaegle at jlab.org<mailto:ijaegle at jlab.org>> wrote:

Sure if so it might be better that I give the last talk so that people not interested in this discussion can easily quit the session w/o missing anything or maybe we can discuss this at the next CAL meeting where all CAL experts are present? Also, I am not proposing a new approach, I will just present what I have done for the PRIMEX data.

tks ig.

________________________________
From: Shepherd, Matthew <mashephe at indiana.edu<mailto:mashephe at indiana.edu>>
Sent: Saturday, May 9, 2020 10:44 AM
To: Igal Jaegle <ijaegle at jlab.org<mailto:ijaegle at jlab.org>>
Cc: Hall-D Calorimetry <halld-cal at jlab.org<mailto:halld-cal at jlab.org>>
Subject: [EXTERNAL] new energy correction scheme


Hi Igal,

I see that you checked in and merged a energy correction scheme for the FCAL.  Could we discuss it in one of the afternoon sessions this week?  Maybe Wednesday afternoon during your talk?

In particular it would be great to show that it provides an improvement over the standard GlueX approach.  If this is so, I am strongly in favor of using the PrimEx approach going forward in the future for GlueX.  (Although probably not for the batch of data we are about to process.)

My concern is that if we end up diverging in how detectors are calibrated then it makes it harder to compare systematic uncertainties in GlueX and PrimEx data.  There is generally an advantage to keep things as common as possible to minimize duplication of effort in doing systematic checks which are incredibly time consuming, but of course I understand the need to meet PrimEx demands for low systematic errors.

Cheers,

Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-cal/attachments/20200512/2617162b/attachment.html>