-
-
Notifications
You must be signed in to change notification settings - Fork 14
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
Context should include gravity fields #89
Comments
C_nm
and S_nm
separate from each other, a flag specifying whether the coefficients are normalized, and (tbd) the uncertainty around these coefficients (which will allow tools to generate gravity clones, and provide lossless info from PDS)
Note that this cannot be done using a clever heapless structure because there are too many items (it's a triangular number). Instead, this new format should follow a packed array approach, similar to what's in the DAF format. It may be worth making up a new such format, e.g. |
I'm not convinced that a DAF is a reasonable approach here. DAF has a summary with a validity domain, unique ID, etc. But gravity fields are essentially always valid, and one chooses a degree and order. The more I think of this, the more I think it should be separate from ANISE and work only in Nyx. |
I'm re-opening this to consider storing the coefficients as a flattened matrix and using the indexing for O(1) access to any coefficients. For platform compatibility, these doubles should be stored in ASN1 using the |
These should be stored with
C_nm
andS_nm
separate from each other, a flag specifying whether the coefficients are normalized, and (tbd) the uncertainty around these coefficients (which will allow tools to generate gravity clones, and provide lossless info from PDS)The text was updated successfully, but these errors were encountered: