Embed some planetary ephemerides and constants
ChristopherRabotin opened this issue · comments
High level description
As per rtk-rs/gnss-rtk#16 (comment) and georust/rinex#252 (comment), air gaped systems can't use the MetaAlmanac feature and tracking their own version of the ephemerides is not evident since that's a pretty specific feature for astrodynamics.
Requirements
Using rust-embed, and behind a feature, ANISE should provide a subset (10 years?) of planetary ephemerides including only the Sun, Earth, and Moon, along with the latest PCK file.
Requires #262 .
Test plans
- Ensure that the data can be loaded correctly when using the embedded files.
Design
This would be a new initializer to Almanac called until_2030 to make the end epoch of the loaded data very clear.
That sounds pretty cool. Could the embedded file serve as a backup when download is in failure ?
The way I currently see this, is the download API is mandatory for people who target the finest (heaviest) models, which is a specific case and may not apply to all applications ?
You're entirely right, and I only had the highest fidelity models in mind, and the use case of matching the éphémérides with other software used commercially. The embedded file will be just fine for almost all other use cases, I was just too focused on my own use case.
Oh I totally understand what your initial target is and make no mistake, we will definitely use it 😆
From our current perspective, the final precision is only dictated by the user input files, so it's really up to what they bring to the table.
In the next release, and if we manage to design this behavior, we simply have to specify in the docs that, if they 're in position to garantee access to ANISE or NASA databases - at least once (thank's to your pretty cool built-in behavior), we are in position to garantee ultimate performance.
I see that you did the modification and a test exists, but is it really being tested ?
On my side, the AstroData setup does not work at all.
sidenote : It's more important to fix the other topics than this one...
I'm quite surprised because the test works for me on the 0.4.0 tag and it is executed successfully as part of the coverage tests
╭─chris at tumblerust in ~/Workspace/nyx-space/anise/anise on 0.4.0✔ 24-07-06 - 21:40:38
╰─⠠⠵ cargo test ut_embed --features embed_ephem
Compiling anise v0.4.0 (/home/chris/Workspace/nyx-space/anise/anise)
Finished test [unoptimized + debuginfo] target(s) in 11.13s
Running unittests src/lib.rs (/home/chris/Workspace/nyx-space/anise/target/debug/deps/anise-c6211fbe8f462001)
running 2 tests
test almanac::embed::ut_embed::test_limited_set ... ok
test almanac::embed::ut_embed::test_embedded_load ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 88 filtered out; finished in 1.50s
Running tests/lib.rs (/home/chris/Workspace/nyx-space/anise/target/debug/deps/lib-086f94cfc2363c11)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 37 filtered out; finished in 0.00s
Running tests/naif.rs (/home/chris/Workspace/nyx-space/anise/target/debug/deps/naif-3a6fcb83dc45b37a)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 5 filtered out; finished in 0.00s
╭─chris at tumblerust in ~/Workspace/nyx-space/anise/anise on 0.4.0✔ 24-07-06 - 21:40:53you can try on either gnss-rtk latest or your fork, to activate anise 0.4.0 features = embed_ephem, and see that the build fails
the priority is to fix the newly anise based ephemeris calculations
Thanks for the patience. I finally understood the issue, and know how to prevent it in the future. Rust Embed will embed the files at build time. This works on my machine and in CI because the data folder is present. Issue is that in the Cargo.toml, I specifically exclude the data folder of ANISE because it's way larger than the crates.io size limit. But this causes the build process to fail to find the embedded files:
error: #[derive(RustEmbed)] folder '/home/crabotin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anise-0.4.0/../data/' does not exist. cwd: '/home/crabotin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anise-0.4.0'
--> /home/crabotin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/anise-0.4.0/src/almanac/embed.rs:11:1
|
11 | / #[folder = "$CARGO_MANIFEST_DIR/../data/"]
12 | | #[include = "de440s.bsp"]
13 | | #[include = "pck11.pca"]
14 | | struct AstroData;
| |_________________^
In the best of all worlds, the files would be downloaded at build time and embedded into the crate then, so that they aren't stored on crates.io either.
I'm quite focused on Nyx 2.0.0 between now and September. But your use case is important to me: would you like me to fix this embed feature in the next few days? I can work to release version, e.g. 0.4.1-alpha with only the rust_embed fixed.
Let me know. You're one of the key users of my work, so I want to make sure that you can use it!
Hello, thank you very much for the follow up
You're one of the key users of my work, so I want to make sure that you can use it!
But your use case is important to me: would you like me to fix this embed feature in the next few days?
the ANISE upgrade cannot be neglicted for us, it really reduces the calculations and what we are responsible for (verification process). Like i said, fixing the calculation is the highest priority, until then, the position solver is broken and fails to resolve solutions. The problem for us, is that it kind of is the only option, because nyx-2 + hifitime-3 combination does not exist. So we need to fix the new ephemeris calculations. The way we download and access data is secondary to that, it can be fixed later.
Issue is that in the Cargo.toml, I specifically exclude the data folder of ANISE
that's kind of unfortunate. We have two options
- either propose a secondary data set, like
embed_datathat is not excluded and we make sure they fit in the crates.io policy - or we introduce a build script, that does the downloading for us. It could simply use your existing downloading infrastructure