[Hps-analysis] Fwd: Re: Test pass1 Status

Wed May 24 00:31:27 EDT 2017

> 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 <email at omarmoreno.net 
> <mailto:email at omarmoreno.net>> 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.
>     <ngraf at slac.stanford.edu <mailto:ngraf at slac.stanford.edu>> 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;
>         hps-analysis at jlab.org <mailto:hps-analysis at jlab.org>; 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;
>         hps-analysis at jlab.org <mailto:hps-analysis at jlab.org>; 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=> 
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/hps-analysis/attachments/20170524/aaad9999/attachment.html>