 |
 |
OK, that makes more sense. Thanks for the clarification Rafo. On Tue, May 23, 2017 at 9:31 PM, Rafayel Paremuzyan <[log in to unmask]> wrote: > 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 >>> <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=> > > > > _______________________________________________ > Hps-analysis mailing list > [log in to unmask] > https://mailman.jlab.org/mailman/listinfo/hps-analysis > > ######################################################################## 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