 |
 |
On Tue, May 23, 2017 at 11:13 PM, McCormick, Jeremy I. < [log in to unmask]> wrote: > Several of the SVT conditions classes are using the strategy of looking at > the update date to disambiguate between overlapping conditions, which is > set via markup on the class. You can go ahead and change that to creation > date if you want that to be used instead. > I'm not sure using the creation date is the right strategy either. Let me think about this a bit ... > > For passes, the only reasonable way to do this is using tags. Otherwise, > you would rely on a particular un-tagged conditions configuration that > might change later and affect the recon results. > > 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 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