Handle Replan/Reopen schedules correctly

[jeanconn]

No description provided.

[taldcroft]

I've wondered if starcheck should strictly check the load commands starting at the run schedule time. This would be robust as long as we can guarantee that the commands prior to the schedule time are never uplinked, i.e. there is no CLD associated with them that gets into the database for possible uplink.

[jeanconn]

I had the same thought. But I wondered if starcheck should use backstop to complete an idea of "history" or if the actual History files should just be complete through schedule run start time.

[jeanconn]

I've wondered if starcheck should strictly check the load commands
starting at the run schedule time. This would be robust as long as we can
guarantee that the commands prior to the schedule time are never uplinked,
i.e. there is no CLD associated with them that gets into the database for
possible uplink.

Though I wasn't as concerned about confirming that the commands prior to
the schedule time are never uplinked; I figured it was fine if they were
uplinked as long as they were strictly checked as part of the previously
approved product's review. That seems to be what we are doing now, but the
hand-off on this is already unclear (if we don't get the DOT for the
beginning, we're not strictly checking those beginning commands now
anyway). I suppose I don't really know if starcheck is supposed to be /
intended to be checking everything that we get in the new products , or
just the range of commands for the change for the reopen and that is a
fundamental discussion / problem.

[taldcroft]

Actually I just talked to Brent and in the case of re-open like this we really need to be checking all the backstop commands since they do get uplinked. So the fact that we cannot do a full review is somewhat more of a problem than I previously appreciated. I guess to be rigorous we could do a command load diff for the corresponding commands from the reopened load. But perhaps that check is done by CM?

[taldcroft]

To say another way, we are assuming the commands are the same as in the previously approved loads, but we don't explicitly check that.

[jeanconn]

Up to this point, starcheck has done its checks with only the files
available in released products. For replan/reopen, should the previously
approved load be included in another way in the tarball for checking? That
would also give us access to the "missing" DOT commands and such that are
usually a problem (not as much for the MAR0615A products as there are no
star catalogs in the schedule before the schedule run time)​

[jeanconn]

If CM is doing the check, are we comfortable with setting starcheck to just check products from the DOT start time?

[taldcroft]

It makes me just a bit nervous and I'm on the fence. I'm going to ping Eric to see what he thinks (since he would need to buy in anyway).

[jeanconn]

I just removed this from my plan for the next release.

[taldcroft]

Might be useful to start using milestones for starcheck issues.

[jeanconn]

Am I using them incorrectly?

[taldcroft]

Oops. But I was fooled since this issue now has no milestone. You should have created a new milestone 11.6 and then assigned this one to 11.6 since I'm pretty sure we'll do something on this. You can also create a "Future" milestone for things that are kind of out there but not necessarily expected to get done. Also, I don't think you need "Candidate" in the version milestone label.

[emartin496]

My 2¢ :

When I do PCAD reviews in replan/reopen cases, I check commands, maneuvers, unloads, etc., from the beginning of the .backstop file. All commands for a given schedule that can/will be uplinked are in the .backstop file (and the Timeline Report, .tlr), including quaternions, OBC catalogs, fid light commands, momentum unloads, etc.

My preference is to have checks for any given schedule be "self-contained", i.e., don't use anything from a previous (approved) schedule.

Let's use FEB1715A as an example. In this case, the DOT starts at 2015:049:00:27:23.657 while the .backstop & .tlr files start at 2015:048:11:50:00.000.

Looking at the starcheck WARNINGS for ObsID NONE1:

• The ObsID is in the .backstop/.tlr files.
• There is no entry in the Guide Star Summary for this ObsID, but all the OBC catalog & quaternion/attitude information is in the .backstop/.tlr files, so target RA, Dec & Roll and catalog entry number, image number, RA, Dec, AGASC ID, etc., can be determined (just not PASS & NOTES).
• The AOMANUVR command is in the .backstop/.tlr files, as are the target quaternions, so the maneuver size, start & stop times, and duration can be computed.
• There is no entry in the Maneuver Error Summary for this ObsID, but our heuristic value could be computed based on the maneuver size.
• Momentum unloading & dither commands are in the .backstop/.tlr files.

It seems to me that starcheck could extract almost all the information it normally supplies by using available sources other than the OFLS products.

That said, I do like the idea of a dividing line to show which ObsIDs are not in the DOT!

Eric

[jeanconn]

With #281 @taldcroft suggests just skipping observations before the DOT. Now that CM has a check for observations in the interval between Backstop start and DOT start, I'm good with this.