 |
 |
> 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] > <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DHPS-2DSOFTWARE-26A-3D1&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=0HDJrGO9TZQTE97J9Abt2A&m=DMp8qpkY3-s4od0HwD3KFNWNfeGtlE57HVF_iidbqy0&s=pmotITKtxLRkKfMEHvhXz_RbNc5hlZMOdbxHkoe_csY&e=> > > > > > > ------------------------------------------------------------------------ > > 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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DHPS-2DSOFTWARE-26A-3D1&d=DwMFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=0HDJrGO9TZQTE97J9Abt2A&m=DMp8qpkY3-s4od0HwD3KFNWNfeGtlE57HVF_iidbqy0&s=pmotITKtxLRkKfMEHvhXz_RbNc5hlZMOdbxHkoe_csY&e=> > > ######################################################################## 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