On May 23, 2017, at 9:23 PM, Omar Moreno <[log in to unmask]> wrote:
A few comments:
1) I'm confused, the conditions record that cause this problem was modified in December of 2016. However, Rafo found a log file that shows this issue was present in October of 2016. This is strange.2) I'm not sure why the timestamp is being used, but the rest of the conditions code should be checked to make sure the disambiguation is being done in a reasonable way. The only reason the rest of the conditions weren't affected is because they weren't updated. However, if the disambiguation is being done in the same manner, then we may see this issue with other conditions in the future. Jeremy wrote most of the code so it's probably easy for him to check this. If the same issue exist for other conditions sets, we should fix before we run pass1.3) We should check that the correct conditions were used for 2015 Pass 6. The log file from October 2016 has me worried that we might have used the wrong conditions for previous passes.
On Tue, May 23, 2017 at 9:19 PM, Omar Moreno <[log in to unmask]> wrote:
A few comments:
1) I'm confused, the conditions record that cause this problem was modified in December of 2016. However, Rafo found a log file that shows this issue was present in October of 2016. This is strange.2) I'm not sure why the timestamp is being used, but the rest of the conditions code should be checked to make sure the disambiguation is being done in a reasonable way. The only reason the rest of the conditions weren't affected is because they weren't updated. However, if the disambiguation is being done in the same manner, then we may see this issue with other conditions in the future. Jeremy wrote most of the code so it's probably easy for him to check this. If the same issue exist for other conditions sets, we should fix before we run pass1.3) We should check that the correct conditions were used for 2015 Pass 6. The log file from October 2016 has me worried that we might have used the wrong conditions for previous passes.
On Tue, May 23, 2017 at 8:29 PM, Graf, Norman A. <[log in to unmask]> wrote:
even better.
From: McCormick, Jeremy I.
Sent: Tuesday, May 23, 2017 6:52 PM
To: Graham, Mathew Thomas
Cc: Rafayel Paremuzyan; Graf, Norman A.; Omar Moreno; [log in to unmask]; hps-software
Subject: RE: [Hps-analysis] Test pass1 StatusHi,
Conditions for reconstruction passes should always be tagged to avoid exactly these kinds of issues. We have had this capability for a long time and it should be part of the process of preparing the pass. It used to be and I don’t know why we stopped doing this…
So please can we make a “pass1_2016” tag with all the conditions sets we want to use for pass1 in order that this doesn’t happen again?
I’m not sure if we want to make one retroactively for pass0 but it wouldn’t be a bad idea.
--Jeremy
From: Graham, Mathew Thomas
Sent: Tuesday, May 23, 2017 6:38 PM
To: McCormick, Jeremy I.
Cc: Rafayel Paremuzyan; Graf, Norman A.; Omar Moreno; [log in to unmask]; hps-software
Subject: Re: [Hps-analysis] Test pass1 Status
For the future though we will change the code so it disambiguates overlapping run ranges by using the conditions set that was most recently created. That’s the default for most conditions anyways.
Nah, I think there should be some sort of pseudo-tag like “best_calibration_constants”, so that we don’t have to just assume that the last set entered for a run range are the set that should be used.
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS- SOFTWARE&A=1