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

Predictive Ephemeris Data Missing on 2000:071 #32

Open
aarvai opened this issue Apr 9, 2012 · 2 comments
Open

Predictive Ephemeris Data Missing on 2000:071 #32

aarvai opened this issue Apr 9, 2012 · 2 comments

Comments

@aarvai
Copy link

aarvai commented Apr 9, 2012

Predictive ephemeris data are missing from 2000:071:00:00:00 - 2000:071:12:03:56:00 UTC. This affects orbitephem0, lunarephem0, and solarephem0, as well as their associated MSIDs (_x, _y, _z, _vx, _vy, and _vz). Also, because of their dependence on ephemeris data, PCAD derived parameters DP_PITCH, DP_ROLL, DP_XZ_ANGLE are also affected. I believe this is the only time period in the current TLM archive with this issue (missing data for > 301 seconds). Definitive ephemeris is not affected.

For example:

In [57]: x=fetch.Msid('orbitephem0_x','2000:001')

In [58]: dt = diff(x.times)

In [59]: i = dt > 301

In [60]: Chandra.Time.DateTime(x.times[i]).date
Out[60]:
array(['2000:071:00:00:00.000'],
  dtype='|S21')

In [61]: Chandra.Time.DateTime(x.times[1:][i]).date
Out[61]: 
array(['2000:071:12:03:56.000'],
  dtype='|S21')

@taldcroft

@taldcroft
Copy link
Member

I've confirmed this occurs in both the GRETA and HEAD versions. I tried re-ingesting the ephem0 data from the CXC archive and the same data gap appeared. Resolving this issue may not be easy, so it might be best to just set this as a bad time. Thoughts @aarvai?

@aarvai
Copy link
Author

aarvai commented Dec 10, 2012

Since I believe that predictive ephemeris == definitive ephemeris for past data, an alternative approach would be to set the missing predictive values in the archive equal to the definitive values. I'd be comfortable with that from a data-fidelity standpoint. However, if that's too much trouble, setting it as a bad time is also fine. I don't believe there's anything historically significant about 2000:071, so I doubt the data will be substantially missed.

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

No branches or pull requests

2 participants