 |
 |
Hello Jeremy, I think that what Stepan refers to can be seen as run periods in which there were particular conditions. I can see wanting to query on the following: Data Quality Run Type (production, calibration, cosmic, zero-field, ...) Beam Energy We could add a parameter like "run group" instead of Beam Energy, where we create a unique number for each combination of Beam Energy, Magnet settings, Trigger setup. That way you would not need to tag each file with a lot of separate items. We can query what the conditions are for a run group from the conditions database, or have the conditions database return the correct run group for a specific set of conditions. I suspect there will be only a handful of different run groups. Best, Maurik On Jun 4, 2014, at 6:16 PM, Stepan Stepanyan <[log in to unmask]> wrote: > Hi Jeremy, > > It is fine with me, either way. Just to add that it is not uncommon to have > runs at the same beam energy but with different magnet settings. For example, > HPS may have high energy runs with and without muon system. These two > cases will have different magnet locations and perhaps different fields. > > Thanks, Stepan > > On 6/4/14, 6:04 PM, McCormick, Jeremy I. wrote: >> Hi, Stepan. >> >> There are a few condition-like variables which we might want to include in the data catalog, if it is likely that these values would be directly queried a lot. >> >> I think beam energy is one of these, in that it will likely be a common operation to look up files based on the beam energy of the associated run. Instead of having a two step process for this particular query, it might make more sense to directly associate the beam energy to the files. >> >> But I don't think it will be so common to try and look up files based on very specific alignment and calibration conditions of the run like positions of magnets, low-level DAQ state, etc. >> >> In that case, it would be more likely that you will find out which runs had the matching detector state via the conditions system. Then the files associated to those runs can be retrieved via the data catalog scripts. >> >> At least, that's how I see it working. >> >> --Jeremy >> >> -----Original Message----- >> From: Stepan Stepanyan [mailto:[log in to unmask]] >> Sent: Wednesday, June 04, 2014 2:46 PM >> To: McCormick, Jeremy I.; Francois-Xavier Girod >> Cc: hps-software >> Subject: Re: data catalog meta data >> >> Jeremy, >> >> That's a good point, but is it true also for beam energy for example. >> By the way, magnet field settings are coupled to beam energy. >> >> Stepan >> >> On 6/4/14 5:39 PM, McCormick, Jeremy I. wrote: >>> Thanks for the suggestions... >>> >>> I would think most of these values belong in the conditions database instead, retrievable as some kind of "run conditions" object. >>> >>> If we tag the files in the data catalog with all this kind of information, then actually managing this could be a huge hassle and time sink. >>> They would need to be manually assigned to each data file somehow. >>> >>> Rather I would think you'd query the conditions system to find out >>> which runs you're interested in based on these parameter values, and then feed the list of run numbers you get back to the scripts that find files in the data catalog. >>> >>> --Jeremy >>> >>> -----Original Message----- >>> From: Francois-Xavier Girod [mailto:[log in to unmask]] >>> Sent: Wednesday, June 04, 2014 10:31 AM >>> To: McCormick, Jeremy I. >>> Cc: hps-software >>> Subject: Re: data catalog meta data >>> >>> >>> Dear Jeremy, >>> >>> Some possible additions below, for consideration. >>> >>> Best regards, >>> FX >>> >>> PS magnet current >>> PS magnet position >>> Frascati magnets current >>> Collimator state >>> >>> Half-wave plate position ? >>> DAQ live-time ? >>> trigger bit prescale factors ? >>> >>> ----- Original Message ----- >>> From: "Jeremy I. McCormick" <[log in to unmask]> >>> To: "hps-software" <[log in to unmask]> >>> Sent: Tuesday, June 3, 2014 4:59:14 PM >>> Subject: data catalog meta data >>> >>> Hi, >>> >>> I have started trying to sketch out what meta data fields we should have in our data catalog. >>> >>> Preliminary notes are here: >>> >>> https://confluence.slac.stanford.edu/display/~jeremym/HPS+Data+Catalog >>> +Meta+Data >>> >>> This is based on some discussion with various people in the collaboration including Matt, Sho and Norman. >>> >>> If you have any reponse or additions then either comment on that page or send a message to this email list. >>> >>> Thanks. >>> >>> --Jeremy >>> >>> ###################################################################### >>> ## >>> 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 >> >> ######################################################################## >> 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 ######################################################################## 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