Skip to content

Design: Graph DataLevels

Jump to bottom
Dehann Fourie edited this page Jul 11, 2024 · 8 revisions

Copyright (c) 2024 NavAbility(TM) all rights reserved.

Background

Also see the data design: https://github.com/JuliaRobotics/Caesar.jl/wiki/Data-Design-for-Caesar-RoME-IIF

Four DataLevels:

  • Skeleton Variable/Factor old design wiki
  • Summary Variable/Factor
  • DFG Variable/Factor (Legacy PackedVariable or PackedFactor)
  • Compute Variable/Factor -- fully derivable from DFG{Variable/Factor} with preference for JuliaLang.

Note, only ComputeVariable / ComputeFactor is fully hydrated for computations, and is totally derived from DFG Variable/Factor -- with preference for JuliaLang compute. Reverse engineering Compute DataLevel in other languages is not supported by NavAbility at this time; not impossible but also not worth it.

Execptions within Standardized DataLevels across programming languages

IMPORTANT DataLevels Skeleton, Summary, DFG are 99% consistent across all languages and serializations, but there are exceptions:

Lang-Minor-Performance-Majors (LMPM)

  • E.g. JuliaLang uses label::Symbol everywhere, vs. Python uses label: string everywhere

Satellites (Dict vs. Vector/List)

For performance per technology, GQL queries return vectors yet DFG internally use Dicts. Special dispatches are needed to converge to dicts in the DFGs (aka SDKs) to dicts keyed by label for known satellites:

  • BlobEntries
  • PPEs
  • SolverData

Clone this wiki locally