sot / kadi

Chandra commands and events
https://sot.github.io/kadi
BSD 3-Clause "New" or "Revised" License
5 stars 3 forks source link

obs_stop for last "observation" of 62619 looks wrong #318

Closed jeanconn closed 4 months ago

jeanconn commented 4 months ago

The last entry here with 'obs_stop': '2024:042:06:13:08.510', seems to just go right past the new ERs and ORs in the recovery products.

--

In [5]: obss = get_observations(obsid=62619)

In [6]: obss Out[6]: [{'obsid': 62619, 'simpos': -99616, 'obs_stop': '2024:036:20:42:12.000', 'manvr_start': '2024:036:02:18:00.250', 'targ_att': (-0.06609208, -0.06505933, 0.91929395, 0.38248889), 'npnt_enab': False, 'obs_start': '2024:036:20:42:12.000', 'prev_att': (-0.5968393229436381, -0.04291310973785076, 0.5444975476907872, 0.5877616085408689), 'source': 'CMD_EVT'}, {'obsid': 62619, 'simpos': -99616, 'obs_stop': '2024:042:06:13:08.510', 'manvr_start': '2024:037:03:59:54.250', 'targ_att': (-0.0734461, -0.09617344, 0.91597702, 0.38254731), 'npnt_enab': True, 'obs_start': '2024:037:04:06:42.777', 'prev_att': (-0.06609208, -0.06505933, 0.91929395, 0.38248889), 'source': 'CMD_EVT'}, {'obsid': 62619, 'simpos': -99616, 'obs_stop': '2024:042:06:13:08.510', 'manvr_start': '2024:037:04:36:10.250', 'targ_att': (-0.14281354, -0.28517376, 0.84659287, 0.42609944), 'npnt_enab': True, 'obs_start': '2024:037:04:52:05.911', 'prev_att': (-0.0734461, -0.09617344, 0.91597702, 0.38254731), 'source': 'CMD_EVT'}]


jeanconn commented 4 months ago

@taldcroft How is the design actually supposed to work for this? Meaning, is there code in there to go through and update the observations OBS commands in the cmds archive as needed to fix obs_stop when you interrupt or resume science?

taldcroft commented 4 months ago

I can't reproduce that on my machine:

>>> import kadi.commands as kc
>>> obss = kc.get_observations(obsid=62619)
>>> Table(obss)["manvr_start", "obs_start", "obs_stop"].pprint_all()
     manvr_start            obs_start              obs_stop      
--------------------- --------------------- ---------------------
2024:036:02:18:00.250 2024:036:20:42:12.000 2024:037:03:59:44.000
2024:037:03:59:54.250 2024:037:04:06:42.777 2024:037:04:36:00.000
2024:037:04:36:10.250 2024:037:04:52:05.911 2024:038:01:15:00.000
taldcroft commented 4 months ago

Huh, this is interesting because I'm able to reproduce on kady:

In [3]: >>> import kadi.commands as kc
   ...: >>> obss = kc.get_observations(obsid=62619)
   ...: >>> Table(obss)["manvr_start", "obs_start", "obs_stop"].pprint_all()
     manvr_start            obs_start              obs_stop      
--------------------- --------------------- ---------------------
2024:036:02:18:00.250 2024:036:20:42:12.000 2024:036:20:42:12.000
2024:037:03:59:54.250 2024:037:04:06:42.777 2024:042:06:13:08.510
2024:037:04:36:10.250 2024:037:04:52:05.911 2024:042:06:13:08.510

Huh.

jeanconn commented 4 months ago

Which at least matches that I was seeing this from ska3-flight with SKA=/proj/sot/ska from fido. I had assumed that it would be the same everywhere but should have indicated my env.

jeanconn commented 4 months ago

Though to answer my "How is the design actually supposed to work for this?" question -- in slack chat Tom indicated 'it does always use dynamic command loads for the last month except with "flight" scenario' which would mean that one wouldn't need to "update" obs_stop because it should just be calculated correctly/dynamically.

jeanconn commented 4 months ago

I think this was fixed by https://github.com/sot/kadi/pull/319