This is a slightly subtle bug that showed up in https://github.com/acisops/acis_thermal_check/pull/30#issuecomment-665240053. When requesting states starting within a maneuver it could happen that datestart > datestop in the first state. The first datestart was incorrect, but otherwise the state values were good. For example:
This is a consequence of the way maneuvers are handled, in particular that there is a command AOMANUVR that kicks off a maneuver and internally a number of pseudo-commands are injected in order to change the attitude and pitch, yaw, roll etc appropriately.
When calling get_states without a continuity specified, it first gets continuity for the start date. The bug here was that the continuity was providing continuity at the time of the AOMANUVR command, which would be OK except that the subsequent states processing was aware of the pseudo-commands that followed and created states accordingly. However, the states code assumes that the first state contains the continuity time. It explicitly sets the datestart of the first state to the input start time based on that assumption, but in this case a couple of new states due to the pseudo-commands were intervening and so the inconsistency appeared.
The fix is to ensure that the states which are generated in order to determine continuity go out to the desired continuity date instead of the time of the last actual (non-pseudo) command before that date. That gets everybody on the same page.
Testing
[x] Passes unit tests on MacOS, linux, Windows (at least one required)
Description
This is a slightly subtle bug that showed up in https://github.com/acisops/acis_thermal_check/pull/30#issuecomment-665240053. When requesting states starting within a maneuver it could happen that
datestart > datestop
in the first state. The firstdatestart
was incorrect, but otherwise the state values were good. For example:This is a consequence of the way maneuvers are handled, in particular that there is a command AOMANUVR that kicks off a maneuver and internally a number of pseudo-commands are injected in order to change the attitude and pitch, yaw, roll etc appropriately.
When calling
get_states
without a continuity specified, it first gets continuity for the start date. The bug here was that the continuity was providing continuity at the time of the AOMANUVR command, which would be OK except that the subsequent states processing was aware of the pseudo-commands that followed and created states accordingly. However, the states code assumes that the first state contains the continuity time. It explicitly sets thedatestart
of the first state to the input start time based on that assumption, but in this case a couple of new states due to the pseudo-commands were intervening and so the inconsistency appeared.The fix is to ensure that the states which are generated in order to determine continuity go out to the desired continuity date instead of the time of the last actual (non-pseudo) command before that date. That gets everybody on the same page.
Testing
Functional testing
Confirmed that this fixes the original issue noted in https://github.com/acisops/acis_thermal_check/pull/30#issuecomment-665240053