arxiv: 2605.12443 · v1 · submitted 2026-05-12 · 📡 eess.SY · astro-ph.IM· cs.MS· cs.SE· cs.SY

Recognition: 2 theorem links

· Lean Theorem

Basilisk and Docker for Reproducible GN&C Simulation: A Workflow Reference

Anubhav Gupta

Pith reviewed 2026-05-13 03:48 UTC · model grok-4.3

classification 📡 eess.SY astro-ph.IMcs.MScs.SEcs.SY

keywords BasiliskDockerreproducible simulationGN&Cspacecraft dynamicscontainerizationastrodynamicsMonte Carlo analysis

0 comments

The pith

Docker containerization makes Basilisk GN&C simulations reproducible across different machines and operating systems.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper establishes that packaging the full Basilisk astrodynamics framework inside a Docker container resolves setup inconsistencies caused by dependencies and platform differences. It demonstrates this through a sequence of examples that start with simple orbital dynamics scripts and advance to BSKSim attitude control simulations that include Monte Carlo statistical analysis. A sympathetic reader cares because mismatched environments have long produced non-reproducible results in collaborative spacecraft guidance and control work. The workflow supplies a self-contained reference that also describes the underlying class hierarchy, dynamics models, flight software implementation, and scenario execution steps.

Core claim

The central claim is that a Docker-based containerization workflow encapsulates Basilisk's complete build environment, dependencies, and simulation infrastructure in a portable image, enabling reproducible GN&C simulations as shown by progressive demonstration cases from basic orbital scripts to full attitude dynamics with Monte Carlo analysis.

What carries the argument

The Docker container image that holds the complete Basilisk build environment, dependencies, and simulation infrastructure.

If this is right

The same Basilisk scripts produce matching results on any machine that can run the container.
GN&C researchers can advance from standalone orbital dynamics to BSKSim-based attitude control and Monte Carlo studies without reconfiguring local systems.
Detailed descriptions of the class hierarchy and execution patterns allow direct reuse or modification of the flight software examples.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Other open-source simulation tools in aerospace could adopt similar container packaging to reduce setup friction for new users.
Widespread use of the workflow might make it easier to verify published GN&C results by allowing reviewers to execute the exact same environment.

Load-bearing premise

The assumption that a single Docker image can fully encapsulate and resolve all practical challenges related to dependency management, operating system compatibility, and software configuration for Basilisk across heterogeneous environments.

What would settle it

Running the supplied Docker image on a new operating system or hardware configuration and obtaining different numerical outputs or failed builds compared with the paper's reported results would falsify the reproducibility claim.

Figures

Figures reproduced from arXiv: 2605.12443 by Anubhav Gupta.

**Figure 1.** Figure 1: Simplified Basilisk execution hierarchy and module-message architecture. 2.2 Vizard Vizard is a Unity-based three-dimensional visualization application developed alongside Basilisk for interactive rendering of simulation environments and spacecraft states [2]. The visualization framework interfaces directly with Basilisk simulations and supports both live streaming and offline playback workflows. A key ch… view at source ↗

**Figure 2.** Figure 2: Example spacecraft visualization rendered using Vizard during an Earth-orbit Basilisk simulation. 2.3 Docker and Docker Compose Docker is an open-source containerization platform that enables applications and their dependencies to be packaged into portable execution environments [3]. In scientific and engineering workflows, containerization simplifies dependency management, reduces platform-specific config… view at source ↗

**Figure 3.** Figure 3: Simplified containerized Basilisk workflow using Docker and Docker Compose. 4 [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

**Figure 4.** Figure 4: Representative Basilisk module-message architecture. 4.2 Process and Task Hierarchy Module execution in Basilisk is organized through a two-level hierarchy of processes and tasks [1]. A task is a named execution group with a fixed update rate, specified in nanoseconds, to which one or more modules are assigned. A process is a named collection of related tasks. The simulation container, created from Simulat… view at source ↗

**Figure 5.** Figure 5: Representative Basilisk execution hierarchy consisting of processes, tasks, and simulation modules. by InitializeSimulation() and synchronizes module state to desired defaults, making it the appropriate location for repeatable initialization logic. Update() is called at every task time step and performs the module’s primary computation. C++ modules override Reset() and UpdateState() inherited from the SysM… view at source ↗

**Figure 6.** Figure 6: Standalone Basilisk scenario execution workflow. 10 [PITH_FULL_IMAGE:figures/full_fig_p010_6.png] view at source ↗

**Figure 7.** Figure 7: Spacecraft in low-Earth orbit rendered in Vizard from the Earth-orbit scenario. 11 [PITH_FULL_IMAGE:figures/full_fig_p011_7.png] view at source ↗

**Figure 8.** Figure 8: Sun-Earth-spacecraft simulation rendered in Vizard using SPICE ephemerides. 1 sampling_time = unitTestSupport.samplingTime( 2 simulation_time, simulation_time_step, 3 num_data_points) 4 5 sc_log = spacecraft_obj.scStateOutMsg.recorder(sampling_time) 6 simulation_obj.AddModelToTask("simulation_task", sc_log) 7 8 simulation_obj.InitializeSimulation() 9 simulation_obj.ConfigureStopTime(simulation_time) 10 sim… view at source ↗

read the original abstract

Basilisk is an open-source astrodynamics simulation framework widely used for spacecraft guidance, navigation, and control (GN&C) research and development. Despite its flexibility and computational capabilities, configuring Basilisk consistently across heterogeneous development environments presents practical challenges due to dependency management, operating system compatibility, and software configuration requirements. This paper presents a Docker-based containerization workflow for Basilisk that encapsulates the complete build environment, dependencies, and simulation infrastructure within a portable container image. The workflow is demonstrated through a progression of simulation scenarios of increasing complexity, from standalone orbital dynamics scripts to BSKSim-based attitude dynamics and control simulations with Monte Carlo analysis. The BSKSim class hierarchy, dynamics model architecture, flight software implementation, and scenario execution patterns are described in detail. The presented workflow provides a self-contained implementation reference for GN&C engineers and researchers seeking reproducible and portable Basilisk simulation environments. This work expands upon a workshop presentation delivered at the 46th Rocky Mountain AAS GN&C Conference, February 2024, available at https://doi.org/10.5281/zenodo.15008785.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

This is a practical Docker workflow reference for Basilisk that fills a real gap for GN&C users but stays incremental.

read the letter

The core contribution here is a documented, self-contained Docker image and workflow that wraps Basilisk's build environment, dependencies, and simulation stack so that GN&C teams can get identical results across machines without the usual dependency headaches. The paper walks through BSKSim architecture, flight software patterns, and a clear progression of examples from basic orbital scripts up to Monte Carlo attitude control runs. That progression is useful because it shows how the container handles increasing complexity without breaking reproducibility. The descriptions of scenario execution and class hierarchy give enough detail that someone already familiar with Basilisk could follow and adapt the setup. It also properly notes the prior workshop version and adds the fuller architecture and Monte Carlo material, so the expansion is honest rather than padded. The main limitation is scope: the work is tied to one framework and one containerization approach, and while Docker reduces many cross-platform issues it does not eliminate every edge case in heterogeneous environments. The demonstrations are convincing for the scenarios shown, but they do not include broad cross-OS testing or performance benchmarks against native installs. No circular reasoning or unsupported claims appear. This paper is aimed at Basilisk users in aerospace simulation who need a reliable starting point rather than at theorists looking for new methods. It is the kind of tools paper that can save other groups time, so it is worth a serious referee who can check the container files and example scripts for completeness. I would send it to review with the expectation that minor clarifications on limitations and setup instructions would strengthen it.

Referee Report

0 major / 2 minor

Summary. The paper presents a Docker-based containerization workflow for the Basilisk open-source astrodynamics simulation framework to address challenges in dependency management, OS compatibility, and configuration for GN&C research. It describes the BSKSim class hierarchy, dynamics model architecture, and flight software implementation, then demonstrates the workflow via a progression of simulation scenarios of increasing complexity, from standalone orbital dynamics scripts to attitude dynamics/control simulations with Monte Carlo analysis. The work positions itself as a self-contained implementation reference and expands on a prior workshop presentation.

Significance. If the workflow and examples are correctly documented and functional, this manuscript provides a useful practical contribution to the GN&C community by supplying a portable, reproducible Basilisk environment. The emphasis on containerization directly tackles a recurring barrier to consistent simulation setups across heterogeneous platforms, which can reduce setup time and improve research reproducibility. The detailed description of BSKSim architecture combined with concrete scenario examples strengthens its value as a reference implementation; the reproducible-code aspect via Docker is a clear strength that aligns with best practices in computational engineering.

minor comments (2)

[Abstract] Abstract: the DOI link to the workshop presentation is provided but could be accompanied by a one-sentence statement of the specific extensions (e.g., additional scenarios or BSKSim details) added in the current manuscript.
The manuscript would benefit from a short table or enumerated list summarizing the simulation scenarios by complexity level, key Basilisk modules used, and Docker-specific commands, to improve quick reference usability.

Simulated Author's Rebuttal

0 responses · 0 unresolved

We thank the referee for the positive review and recommendation to accept the manuscript. The comments confirm that the Docker-based workflow and BSKSim examples address a practical need in the GN&C community for reproducible simulation environments.

Circularity Check

0 steps flagged

No significant circularity

full rationale

The manuscript is a descriptive workflow reference for Docker-based containerization of Basilisk GN&C simulations. It presents no equations, derivations, fitted parameters, predictions, or uniqueness theorems. All content consists of architectural descriptions, code patterns, and example scenarios that stand independently as implementation guidance. The single self-reference to a prior workshop presentation is non-load-bearing and does not underpin any claimed result. The paper is therefore self-contained with no reduction of outputs to inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This paper is a software engineering workflow description and does not introduce or rely on free parameters, mathematical axioms, or invented entities. It builds on existing Basilisk and Docker technologies.

pith-pipeline@v0.9.0 · 5499 in / 1051 out tokens · 138213 ms · 2026-05-13T03:48:10.068529+00:00 · methodology

discussion (0)

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

IndisputableMonolith/Foundation/RealityFromDistinction.lean reality_from_one_distinction unclear
The presented workflow provides a self-contained implementation reference for GN&C engineers and researchers seeking reproducible and portable Basilisk simulation environments.
IndisputableMonolith/Cost/FunctionalEquation.lean washburn_uniqueness_aczel unclear
Docker-based containerization workflow for Basilisk that encapsulates the complete build environment, dependencies, and simulation infrastructure within a portable container image.

Reference graph

Works this paper leans on

16 extracted references · 16 canonical work pages

[1]

Basilisk:AFlexible,ScalableandModularAstrodynam- ics Simulation Framework

P.W.Kenneally,S.Piggott,andH.Schaub.“Basilisk:AFlexible,ScalableandModularAstrodynam- ics Simulation Framework”.Journal of Aerospace Information Systems17.9 (2020), pp. 496–507. doi:https://doi.org/10.2514/1.I010762

work page doi:10.2514/1.i010762 2020
[2]

Flexible Basilisk astrodynamics visualizationsoftwareusingtheUnityrenderingengine

J. Wood, M. C. Margenet, P. Kenneally, H. Schaub, and S. Piggott. “Flexible Basilisk astrodynamics visualizationsoftwareusingtheUnityrenderingengine”.In:AASGuidanceandControlConference, Breckenridge, CO. 2018

work page 2018
[3]

Docker: Lightweight Linux Containers for Consistent Development and Deployment

D. Merkel. “Docker: Lightweight Linux Containers for Consistent Development and Deployment”. Linux j239.2 (2014), p. 2

work page 2014
[4]

AnIntroductiontoDockerandAnalysisofitsPerformance

B.B.Rad,H.J.Bhatti,andM.Ahmadi.“AnIntroductiontoDockerandAnalysisofitsPerformance”. International Journal of Computer Science and Network Security (IJCSNS)17.3 (2017), p. 228

work page 2017
[5]

Gupta.Basilisk and Docker for Streamlined GN&C Simulation

A. Gupta.Basilisk and Docker for Streamlined GN&C Simulation. Presentation at the 46th Rocky MountainAASGN&CConference.Breckenridge,CO,USA,2024.doi:10.5281/zenodo.15008785

work page doi:10.5281/zenodo.15008785 2024
[6]

An Introduction to Docker for Reproducible Research

C. Boettiger. “An Introduction to Docker for Reproducible Research”.ACM SIGOPS Operating Systems Review49.1 (2015), pp. 71–79.doi:https://doi.org/10.1145/2723872.2723882

work page doi:10.1145/2723872.2723882 2015
[7]

A Study of How Docker Compose is used to Compose Multi-component Systems

I. M. Hasan, S. Mohammed, and A. E. Hassan. “A Study of How Docker Compose is used to Compose Multi-component Systems”.Empirical Software Engineering26.6 (2021).doi:https : //doi.org/10.1007/s10664-021-10025-1

work page doi:10.1007/s10664-021-10025-1 2021
[8]

Gupta.Basilisk and Docker for Reproducible GN&C Simulation

A. Gupta.Basilisk and Docker for Reproducible GN&C Simulation. Zenodo. 2026.doi:10.5281/ zenodo.20132421

work page 2026
[9]

TheGGM03mean earth gravity model from GRACE

B.Tapley,J.Ries,S.Bettadpur,D.Chambers,M.Cheng,F.Condi,andS.Poole.“TheGGM03mean earth gravity model from GRACE”. In:AGU Fall Meeting Abstracts. Vol. 2007. 2007, G42A–03

work page 2007
[10]

R. H. Battin.An Introduction to the Mathematics and Methods of Astrodynamics. AIAA, 1999.doi: https://doi.org/10.2514/4.861543

work page doi:10.2514/4.861543 1999
[11]

R. R. Bate, D. D. Mueller, J. E. White, and W. W. Saylor.Fundamentals of Astrodynamics. 2nd ed. Mineola, NY: Dover Publications, 2020

work page 2020
[12]

C. H. Acton.An Overview of SPICE.https://naif.jpl.nasa.gov/pub/naif/toolkit _docs/ Tutorials/pdf/individual_docs/03_spice_overview.pdf. 1998

work page 1998
[13]

Spice:AMeans for Determining Observation Geometry

C.Acton,N.Bachman,J.DiazDelRio,B.Semenov,E.Wright,andY.Yamamoto.“Spice:AMeans for Determining Observation Geometry”. In:EPSC–DPS Joint Meeting. Vol. 553. 2011. 20

work page 2011
[14]

SPICE for ESA Planetary Missions: Geometry and Visualization Support to Studies, Operations and Data Analysis within Your Reach

M. Costa. “SPICE for ESA Planetary Missions: Geometry and Visualization Support to Studies, Operations and Data Analysis within Your Reach”. In:2018 SpaceOps Conference. 2018, p. 2553. doi:https://doi.org/10.2514/6.2018-2553

work page doi:10.2514/6.2018-2553 2018
[15]

The Planetary and Lunar EphemeridesDE430andDE431

W. M. Folkner, J. G. Williams, D. H. Boggs, R. S. Park, and P. Kuchynka. “The Planetary and Lunar EphemeridesDE430andDE431”.InterplanetaryNetworkProgressReport196.1(2014),pp.42–196

work page 2014
[16]

Schaub and J

H. Schaub and J. L. Junkins.Analytical Mechanics of Space Systems. 3rd ed. Reston, VA: AIAA, 2014. 21

work page 2014