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

SPICE BSP files should be usable without needing the ANISE file equivalent #30

Closed
ChristopherRabotin opened this issue Oct 17, 2022 · 2 comments · Fixed by #36
Closed
Assignees
Labels
API: rust Related to the Rust API Kind: spice-interop SPICE interoperability

Comments

@ChristopherRabotin
Copy link
Member

Use case

Although the ANISE file format provides a number of advantages compared to the BSP files, requiring users to convert their data into ANISE before using this library is a large overhead.

Effort

ANISE.rs already supports reading BSP files of some types. However, that implementation requires memory allocations. These should not be required.

Hence, the crux of this issue is to rewrite the SPK parser to not perform any memory allocations. This issue also includes providing a rewrite of some of the SPK related functions (exact list to be determined from this list). These functions must be behind a specific crate feature, e.g. spice-interop.

Verification

TDB: from the list of functions above, the tests should require rust-spice by @GregoireHENRY and make sure that the SPK functions selects return the same values. This will likely require #26 too.

@ChristopherRabotin ChristopherRabotin added API: rust Related to the Rust API Kind: spice-interop SPICE interoperability labels Oct 17, 2022
@GregoireHENRY
Copy link
Collaborator

I will make sure the list of SPK-related selected functions are supported in the wrapper.

@ChristopherRabotin
Copy link
Member Author

ChristopherRabotin commented Nov 12, 2022

The latest update can load SPK and BPC data using furnsh_spk and furnsh_bpc. I can't make those generic yet because the data is strongly typed at loading time (in order to correctly read the summary data) and they go into different variables.

Since the SPICE context only has pointers to the data, the size on the stack remains the same:

DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 1, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 641, end_idx: 310404 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 2, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 310405, end_idx: 423048 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 3, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 423049, end_idx: 567372 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 4, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 567373, end_idx: 628976 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 5, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 628977, end_idx: 674740 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 6, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 674741, end_idx: 715224 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 7, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 715225, end_idx: 750428 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 8, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 750429, end_idx: 785632 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 9, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 785633, end_idx: 820836 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 10, center_id: 0, frame_id: 1, data_type_i: 2, start_idx: 820837, end_idx: 944040 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 301, center_id: 3, frame_id: 1, data_type_i: 2, start_idx: 944041, end_idx: 1521324 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 399, center_id: 3, frame_id: 1, data_type_i: 2, start_idx: 1521325, end_idx: 2098608 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 199, center_id: 1, frame_id: 1, data_type_i: 2, start_idx: 2098609, end_idx: 2098620 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 299, center_id: 2, frame_id: 1, data_type_i: 2, start_idx: 2098621, end_idx: 2098632 }
DE-0421LE-0421                           -> SPKSummaryRecord { start_epoch_et_s: -3169195200.0, end_epoch_et_s: 1696852800.0, target_id: 499, center_id: 4, frame_id: 1, data_type_i: 2, start_idx: 2098633, end_idx: 2098644 }
start: 1899-07-29T00:00:00.000000074 ET length: 32 days rsize: 35       num_records: 1760       len data: 61600
[Some("de421"), None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None]
[Some("de421"), Some("de440"), Some("de438s"), None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None]
1536
[Some("de421"), None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None]
1536

Associated code:

    let spice = SpiceContext::default();
    let spice = spice.furnsh_spk("de421", &de421).unwrap();

    println!("{:?}", spice.spk_lut);

    // Now load another DE file
    // WARNING: Rust won't allow us to load this other file in a scope and then unload it!
    {
        let bytes = file_mmap!("data/de440.bsp").unwrap();
        let de440 = DAFBytes::<SPKSummaryRecord>::parse(&bytes).unwrap();
        // NOTE: We assign the output because `furnsh_*` will return a clone of (pointers) of the already loaded context.
        // This might sound counter intuitive but it allows the data to be loaded in a given scope and also dropped when that scope is gone.
        let spice = spice.furnsh_spk("de440", &de440).unwrap();

        // And another
        let bytes = file_mmap!("data/de438s.bsp").unwrap();
        let de440 = DAFBytes::<SPKSummaryRecord>::parse(&bytes).unwrap();
        let spice = spice.furnsh_spk("de438s", &de440).unwrap();

        println!("{:?}", spice.spk_lut);

        println!("{}", size_of_val(&spice));
    }

    println!("{:?}", spice.spk_lut);
    println!("{}", size_of_val(&spice));

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
API: rust Related to the Rust API Kind: spice-interop SPICE interoperability
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants