Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State data missing from 2001:001 to 2003:001 #242

Open
Gregg140 opened this issue Jul 7, 2022 · 5 comments
Open

State data missing from 2001:001 to 2003:001 #242

Gregg140 opened this issue Jul 7, 2022 · 5 comments

Comments

@Gregg140
Copy link

Gregg140 commented Jul 7, 2022

State data from early in the mission is missing. It would be useful to populate the state information from at least 2000 to 2003 (if not from launch). Last I heard state data was guaranteed only from 2003 onward.

In [2]: orbit_states = states.get_states("2000:001", "2003:001", state_keys = ["simpos", "grating"])

ValueError Traceback (most recent call last)
in
----> 1 orbit_states = states.get_states("2000:001", "2003:001", state_keys = ["simpos", "grating"])

/proj/sot/ska3/flight/lib/python3.8/site-packages/kadi/commands/states.py in get_states(start, stop, state_keys, cmds, continuity, reduce, merge_identical, scenario)
1329 # Get initial state at start of commands
1330 if continuity is None:
-> 1331 continuity = get_continuity(start, state_keys, scenario=scenario)
1332
1333 # Get transitions, which is a list of dict (state key

/proj/sot/ska3/flight/lib/python3.8/site-packages/kadi/commands/states.py in get_continuity(date, state_keys, lookbacks, scenario)
1597 missing_keys = set(state_keys) - set(continuity)
1598 if missing_keys:
-> 1599 raise ValueError('did not find transitions for state key(s)'
1600 ' {} within {} days of {}. Maybe adjust the lookbacks argument?'
1601 .format(missing_keys, lookbacks[-1], stop.date))

ValueError: did not find transitions for state key(s) {'simpos', 'grating', 'hetg', 'letg'} within 1000 days of 2000:001:00:00:00.000. Maybe adjust the lookbacks argument?

@taldcroft
Copy link
Member

@Gregg140 - the main issue is that prior to 2003 we do not have a definitive list of Chandra command events (aka non-load commands) and a definitive backstop history chain. There were many safing actions and complicated command histories from launch to 2003. If you can define those elements and validate their accuracy vs. telemetry then we can add those commands to the commands archive which will then make the states available.

@taldcroft
Copy link
Member

@Gregg140 - as part of the commands v2 promotion / migration process, I realized that some of our code (e.g. mica.starcheck) would be easier to migrate if the commands archive were complete. As expected including the early commanding isn't easy, I'm already about 1.5 days into this project and maybe half done. But with any luck it will converge and the v2 archive will be complete and reasonably accurate through the first available loads.

@Gregg140
Copy link
Author

Gregg140 commented Sep 6, 2022

That's good news. Thanks for the effort.

@Gregg140
Copy link
Author

Question:

Your comment above says:
" I realized that some of our code (e.g. mica.starcheck) would be easier to migrate if the commands archive were complete. "

Does this then translate into the states also being complete? My original issue was th the states did not go back to the first available loads

@taldcroft
Copy link
Member

Does this then translate into the states also being complete? My original issue was th the states did not go back to the first available loads

Yes. The kadi states are dynamically derived from commands, so if the commands are complete then states become complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants