Skip to content
This repository has been archived by the owner on Dec 24, 2023. It is now read-only.

Latest commit

 

History

History
102 lines (88 loc) · 5.45 KB

2021.11.28-requirements-2-of-n.md

File metadata and controls

102 lines (88 loc) · 5.45 KB

Requirement meeting 2

Date: 2021 NOV 28

Attendees:

  • Greg H (gregh)
  • Chris DC (pwnOrbitals)
  • Chris R (xionbox)

Action items for next meeting

  • Everyone:
    • Figure out which simple low-collision hashing algorithm we could use for the tables in version 0.1 (requirement 1.x)
  • Chris R:
    • Write meeting notes
    • Create Github issues to start the specs
    • Update requirements on language support tiers
    • Proof of concept of maps in specs
  • Greg:
    • Write 1.6 sub-requirements (Digital shape model data shall be storable for any arbitrary shape)
    • Find existing file shape format for our need, or define a new one, or find a solution for that

Action items of previous meeting

  • Everyone:
    • Populate the requirements list as per the process defined below. File is on Google Spreadsheets, here.
    • Populate the slides for the LSIC meeting. Keep it short, only 10 minutes and plus 5 of Q&A. File is on Google Slides, here.
  • Greg:
    • Start working on the Rust project with the specs repo as a submodule
    • Investigate whether Flatbuffers could be used to write tests, or if another framework can be used to write generic tests in several languages to avoid cloning the test suite for each supported language
  • Chris R:
    • Write meeting notes and requirement process
    • Create Google documents for requirements and for LSIC 18 Nov 2021 meeting
    • Send next meeting invite
    • Send LSIC meeting invite, and ask Sarah Whitee for Greg and Chris DC to join too

Discussion

  1. We've passed the mid-November deadline. However, in this long meeting (2.5 hours) we discussed in detail the requirements.
  2. Greg recalled that flatbuffer is for I/O, codebase will be in Rust for other language that will be wrapped around to benefit Rust's safety.

Programming language support

  1. It's clear that FORTRAN is still thoroughly used in the aerospace industry. Jacob Williams (lead software engineer extraordinaire of Copernicus) announced that he would be interested in ANISE if a FORTRAN interface was provided. Let's make it happen!
  2. Greg says that FORTRAN can call C code. Therefore, the first idea here is to use the Rust code to build the FORTRAN interface (we'll probably need to use no_mangle).

File structure, unique object identifiers

  1. An original requirement was to store the ephemeris and the orientations as trees. Although that would work, this tree structure adds lots of complexity in storing the unique ID of a body and orientation root in a way that is copiable. We discussed storing this as similar to IP addresses with different bits corresponding to different levels of the tree. We also discussed the extensability of this method, whether it would allow storing Hipparcos ESA star catalog, and what other issues we'd likely encounter.
  2. Moreover, a tree architecture is excellent for an O(k) access to the children of a given object (where k is the depth). However, in reference frame transformations, we can't typicalling looking for the children of a given object but for the parents. With the tree organization, this means we need to compare the starting blocks of the unique identifier of the object. This works, but we still have O(k) translations and O(k') rotations for k depth of translation and k' depth of rotation. Again, this works, but it probably isn't optimal.
  3. In addition to being copiable (i.e. made of primitives that the compiler can place on the stack), we want to allow users to store their own data in the kernels without overwriting some standard names. One way to handle that is to specify reserved numbers (similar to NAIF's reserved list for celestial objects (positive numbers) and spaceraft (negative numbers)). The difficulty here is that we'd need some "authority" to provide us with that list. This would be a lot of work.
  4. In conclusion, we've decided to simply store objects as an array and embed a lookup table in the file. This table associates a unique hash mapping the object name to a position in the object list. The hashing function will be provided with the specs. The hashing function, chosen to be computationally simple and also not create too many collisions, will be published with the specs.
  5. Finally, we also decided that the process of "building a reference frame" will require a user a provide both the name of the center object and the name of the orientation (instead of relying on error-prone tokens). The function could be my_anise_ctx.build_frame(ANISE_CONSTANT::Earth, ANISE_CONSTANT::J2000) where the constants are both directly the hashes as integers.
  6. When a user requests to add a new frame to the file, the mutuable function will trigger an error, unless using a specific function which will allow overwriting pre-existing frames.