You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug reports will lead to a stakeholder need report, and will need to be linked to this issue
Describe the bug
The lower half of de440s_transform_verif_venus2emb in tests/ephemerides/transform.rs is disabled. The SPICE data shows that both queries should be strictly opposite. ANISE shows that it isn't the case, and it only matches SPICE when transforming from IAU VENUS to EARTH ITRF93, but not the other way around.
I wonder if somehow the rotations need to be applied in a given order? I'm really confused about this one.
Note that this only applies if there are rotations involved. If the frame is J2000, there is no issue.
Expected behavior
ANISE return computation should be the exact opposite of the original computation.
Code to reproduce the issue
Uncomment the lower part of the code of that test in release 0.1 of ANISE.
Platform
Rust, Linux
The text was updated successfully, but these errors were encountered:
This bug also happens when rotating a spacecraft expressed in an inertial frame into a body fixed frame. My hunch is that if the frames differ, the intermediate states need to be rotated into an inertial frame immediately instead of performing one large rotation. I'll need to dive into the spkezr function to see where the rotations are performed.
The validation should include rotations of the Hermite BSP into the Earth body fixed frame and confirm that it matches SPICE.
Bug report
Bug reports will lead to a stakeholder need report, and will need to be linked to this issue
Describe the bug
The lower half of
de440s_transform_verif_venus2emb
in tests/ephemerides/transform.rs is disabled. The SPICE data shows that both queries should be strictly opposite. ANISE shows that it isn't the case, and it only matches SPICE when transforming from IAU VENUS to EARTH ITRF93, but not the other way around.I wonder if somehow the rotations need to be applied in a given order? I'm really confused about this one.
Note that this only applies if there are rotations involved. If the frame is J2000, there is no issue.
Expected behavior
ANISE return computation should be the exact opposite of the original computation.
Code to reproduce the issue
Uncomment the lower part of the code of that test in release 0.1 of ANISE.
Platform
Rust, Linux
The text was updated successfully, but these errors were encountered: