https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-1110 Instrument control development <p>This has cropped up in a couple of places. SPS, MCS, and AGC variously need to know the telescope positions (alt/az/rot/adc/focus/etc), the environmental conditions (temperature/humidity/etc), and the observing conditions (seeing, cloud conditions, etc). All of this comes from Gen2, via the gen2Actor.</p> <p>As it stands, the <tt>mcs_exposure</tt> and <tt>tel_condition</tt> tables and the MCS and SPS headers have some/all of this information, all populated from the gen2 MHS keywords, which are direct copies of the gen2 keywords.</p> <p>Can we create system-independent tables just for these properties, and have the appropriate mcs, arc, and sps tables link to them? The gen2Actor can <em>easily</em> add rows periodically and/or at roughly the right times for each system's exposures, and can certainly create one row per MCS/AGC/SPS integration or readout (thinking about H4s and AGC here). </p> <p>I do not know about the timing properties of the telescope or environmental info in the gen2 keywords &#8211; there is no point in doing better than that. On the PFS side, the H4/AGC cadence (one per 5-10s) is the fastest we would ever care about. <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=eric" class="user-hover" rel="eric">eric</a>?</p> <p><tt>tel_condition</tt> is empty, so we can rethink that completely.<br/> I think two tables (telescope and everything else), but one would also work and be nicer for queries. Or also split out the human-generated conditions into its own table? </p> INSTRM-1110

Factor out telescope and environmental conditions into new table(s)

Task Normal Done Done Kiyoto Yabe cloomis EngRun PFI Fri, 13 Nov 2020 18:27:15 +0000 Fri, 5 Nov 2021 00:41:09 +0000 Fri, 5 Nov 2021 00:41:09 +0000 spt_operational_database 0 3 <p>My initial, very naive thought is:</p> <p>Assuming that we can get every status periodically and utilizing `tel_visit_id`, we have three tables:</p> <ul> <li>tel_condition <ul> <li>pfs_visit_id (not null)</li> <li>tel_visit_id  (not null)</li> <li>tel_az</li> <li>tel_el</li> <li>tel_ra</li> <li>tel_dec</li> <li>tel_rot</li> <li>tel_adc</li> <li>tel_focus</li> <li>timestamp</li> <li>...</li> </ul> </li> <li>env_condition <ul> <li>pfs_visit_id (not null)</li> <li>tel_visit_id (not null)</li> <li>dome_temperature</li> <li>dome_humidity</li> <li>dome_pressure</li> <li>outside_temperature</li> <li>...</li> </ul> </li> <li>obs_condition <ul> <li>pfs_visit_id (not null)</li> <li>tel_visit_id (not null)</li> <li>seeing</li> <li>transparency</li> <li>cloud_condition</li> <li>...</li> </ul> </li> </ul> <p>, where `tel_visit_id` is just like a counter with a certain cadence starting just after pfs_visit_id is issued. (pfs_visit_id, tel_visit_id) is a unique key, so we probably need to have `tel_visit_id` in mcs_exposure, sps_exposure, agc_exposure, and obslog table, which should be the closest one to each exposure, so that we can easily identify conditions we want to know for each subsystem.</p> <p>I surely do not know if this works and how to do this, but any comments are welcome.</p> <p>Yes. I think all the tables should have pfs_visit_id and timestamp columns, but am not sure what the benefit of tel_visit_id is or what the value should be. </p> <p>There will be multiple AGCC and MCS exposures per visit, and I think we can guarantee that there will be at least one (and probably no more than one) tel/env/obs update per AGCC/MCS exposure. So a variant of <tt>(visit == $visit AND timestamp between $agcc_tStart and $agcc_tEnd)</tt> query should be good for all reasonable sps/agcc/mcs investigations. I think that would be simpler than tracking some additional "telescope"/agcc/mcs id, since it would work in all cases.</p> <p>As a side note, I would add some other dome information that we know we can track. For now:</p> <ul class="alternate" type="square"> <li>dome shutter open/closed/unknown</li> <li>dome (room) light mask integer.</li> </ul> <p>Thank you for your comments. </p> <p>I feel timestamp is essentially all what we need to identify conditions of interest. `tel_visit_id` (or any <em>unique</em> identifiers) is beneficial only if we cannot guarantee the uniquness of the timestamp, but probably not? So, `timestamp` (or a combination with `pfs_visit_id` just in case) would be a primary key (if we want PK in each table). I'm not sure whether this is a standard design method, though.</p> <p>One stupid question is whether we guarantee these timestamps are syncronized well enough with each subsystem (probably yes because we use the same gen2actor)? The record timing may be what we need to think about seriously.</p> <p>Additional columns such as dome shutter/light status are surely fine to me.</p> <p>The actual values dribble in from parts of the telescope systems at various rates and without any exploitable synchronization. The gen2Actor currently queries for new values when it needs to, but it could also passively listen to a 1 Hz update stream from gen2. The sunssActor currently does that.</p> <p>The obvious times when we want good values are at the start of integration, particularly for the faster exposures (AGCC, MCS, H4 reads), and otherwise every 15s or so while observing.</p> <p>Given the understandable reluctance to use timestamps in a key, I propose that all tables have a primary key of (pfs_visit_id, status_sequence_id), where the sequence id is maintained per-visit by the gen2Actor, and that all tables also have an indexed timestamp column. The gen2Actor would grow an updateConditions command which would force a update; that could be called by the agcc/mcs actors when they start an integration.</p> <p>I am worried about delays if the real gen2 pauses as it seems to occasionally pause when getting a new frame/visit id. So will probably use the passive 1Hz stream whenever safe.</p> <p>Per 2021-08-18 phone con, will be implemented as written.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=kiyoto.yabe" class="user-hover" rel="kiyoto.yabe">Kiyoto Yabe</a> : what is the progress on this ticket? Can we close it based on your branch?</p> <p>I believe so. <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>?</p> <p>Since the current schema at summit actually includes this revision, I'll merge the branch and close this ticket. We will file a new ticket if further revisions are necessary.</p> Relates INSTRM-1325 INSTRM-1008 Development Rank 0|zzs8vb:k Sprint EngRun03 Story Points 3.0