High Precision Kernels

[gwbres]

Hello,

for some reason, I'm able to manually download the BPC from JPL (URL is therefore vaild), but it always fails anytime I try to automate it (using the Meta infra). Is the Meta infra solely intended for files that are hosted in the nyx cloud?

My objective is to propose an infaillible method (so we can always deploy), that prefers and targets the ITRF93 frame (if we can), otherwise, relies on the IAU ECEF. In this current form, it always succeeds in attaching the BSP, the PCA and always fails to attach the JPL Daily file. Caching works fine 👍 .
To my understaning, this is the minimum requirement I need to obtain the ITRF93 correctly.
In otherwords, I removed the Moon file that MetaAlmanac::latest() always integrates. This one being "easier" to deal with than doing everything myself. But that one I cannot seem to get to work either, because it always fails to attach the Moon file (similarly)

[gwbres]

Sorry.. my bad, I had a typo in the code which misled PCK11 to JPL to not being downloaded.
And I actually had an error in the PCK11 url.
Which leads to my next question: some of these files are tied to an ANISE release.
But for the BSP and PCA, I would not expect those to change in near future.
What is the release policy, does every single release of the ANISE lib mean a new PCK11 file that we should update to ?

[ChristopherRabotin]

Sorry for the delay in my answer. The JPL cloud should work all the time, and the meta load works for any URL or even a local path (which is how I use it in a professional context for project specific ephemeris files).

You're right that the data in the PCA file does not change. However, I changed the encoding method between version 0.3 and 0.4, so the PCA files were not longer compatible between both versions. I hope (and think) that there will not be changes to the file format in a long time because the format in version 0.4 has all of the features of 0.3, but it's over 100 times faster.

You can build your own PCA files by using the ANISE cli and the "convert tpc" action. The inputs needed there are the JPL provided text data, which you can modify by hand. Here is how these are built for each release:

anise/anise/src/naif/kpl/tpc.rs

Line 180 in 8310be5

let pck08 = convert_tpc("../data/pck00008.tpc", "../data/gm_de431.tpc").unwrap();

.

You can also use the get_by_id and set_by_id methods of the planetary dataset to modify a loaded planetary dataset, and then call the save_as function to save it to disk. I'm working on an example of this at the moment where I estimate the state of the lunar reconnaissance orbiter using the public ephemeris.

[gwbres]

or even a local path (which is how I use it in a professional context for project specific ephemeris files)

good to know as well

You're right that the data in the PCA file does not change. However, I changed the encoding method between version 0.3 and 0.4, so the PCA files were not longer compatible between both versions.

👍

I hope (and think) that there will not be changes to the file format in a long time because the format in version 0.4 has all of the features of 0.3, but it's over 100 times faster.

👍

I'm working on an example of this at the moment where I estimate the state of the lunar reconnaissance orbiter using the public ephemeris.

I'm not sure I will ever need to modify the planetary datasets, but since I'm a very beginner I cannot be 100% sure.
thank you for your answer

[ChristopherRabotin]

The main advantage of defining your own planetary datasets is that you can rerun a specific set of analysis with an updated model. I'll come around to your PR for the WGS84 Ellipsoid model later this evening, but typically, that would be defined in the PCA file and you would query the Almanac to get a copy of that. This provides flexibility to any user regardless of the version of ANISE, similar to how SPICE works.