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.

Omar sorry, the log file path was correct, but I pasted wrong text for Oct 2016,
This should be the correct one, i.e. table is created on 2016-02-26 14:42:17.0
/work/hallb/hps/data/physrun2016/pass0/logs/hps_008054.27_R3.9.err
2016-10-19 17:02:02 [INFO] org.hps.conditions.database.AbstractConditionsObjectConverter getData :: loading conditions set...
id: 1397
name: svt_calibrations
runStart: 7566
runEnd: 99999
tableName: svt_calibrations
collectionId: 20
updated: 2016-02-26 14:42:17.0
created: 2016-02-26 14:42:17.0
tag: eng_run
createdBy: phansson
notes: Pedestals and noise. Loaded using SvtConditionsLoader.

Rafo

On 05/24/2017 12:23 AM, Omar Moreno 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 Status

 

Hi,

 

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

---

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

_______________________________________________
Hps-analysis mailing list
[log in to unmask]
https://mailman.jlab.org/mailman/listinfo/hps-analysis