search

chime-experiment / dias

A data integrity framework
https://dias.readthedocs.io/
GNU General Public License v3.0
2 stars 0 forks source link

Chimestack files at the start of acquisition contain update ids from earlier timestamps #196

Closed anjakefala closed 2 years ago

anjakefala commented 3 years ago

A chimestack file, from the start of an acquisition (00000_0000.h5) which has the index_map/time/ctime which spans Fri Jul 16 2021 18:29:43 GMT+0000 to Fri Jul 16 2021 19:54:22 GMT+0000 actually has states associated with this flaginput id: flaginput_20210715T172153.583519Z_raw'

It contains states associated with update ids which are a day older than the timespan it supposedly covers. This results in the dataset analyzer being unable to find the update ids in the appropriate flag files which match the chimestack timespan, and it throws an exception.

The dataset analyzer can accomodate this by grabbing one earlier flag file, but before we implement this, we should make sure that this is not a bug earlier in the pipeline.

ketiltrout commented 3 years ago

Wouldn't this be a bug in kotekan and not dias?

jrs65 commented 3 years ago

I don't see why you both say this would be a bug in kotekan, the flaginput files contain the flags generated within a 24 hour period, not all the flags applied within that period. This could always have broken but, but is much more likely to have issues now it's hot and we are restarting.

  1. Correlator running. Flags being generated within and saved into a file for that UTC day,.
  2. Gets too hot. Correlator stopped at somepoint before 5pm (i.e. midnight UTC)
  3. 5pm (midnight UTC) happens. New flaginput file started.
  4. Cools down after 5pm (typically 8pm ish), correlator restarted and the last flag update is re-sent. This last flag update was from before the correlator shutdown and so is in the file for the previous UTC day.