PaperlayerView exact revision on arXiv

Source-linked AI summary

Introducing a new generation Adaptive Optics simulation framework: from PASSATA to SPECULA

Fabio Rossi, Alfio Puglisi, Guido Agapito

arXiv:2602.06688v1astro-ph.IM

TL;DR

Adaptive-optics development needs numerical end-to-end simulation, but PASSATA’s implementation limits laboratory use, GPU access, and HPC scaling. SPECULA replaces it with a Python, object-oriented framework configured through descriptions and supporting CPU, GPU, distributed, and hybrid operation. It achieves strong validation against PASSATA across tested systems while remaining subject to stated DAG and future-extension boundaries.

  • Problem

    PASSATA’s IDL implementation complicates laboratory use, GPU programming, HPC scaling, scripting, and maintainability, motivating a more accessible simulation framework.

  • Method

    SPECULA models simulations as connected processing and data objects configured from YAML, using Python with platform-agnostic CPU/GPU execution and distributed process placement.

  • Results

    SPECULA’s results agree excellently with PASSATA under identical SOUL conditions, with negligible numerical-precision differences; similar agreement held across all tested systems.

  • Takeaways & Limitations

    SPECULA is presented as mature for Adaptive Optics use, combining performance, extensibility, and simulation correctness verified across a wide set of systems.

  • Takeaways & Limitations

    The framework requires the graph remaining after delayed connections are removed to be a directed acyclic graph, and future work includes broader hardware-in-the-loop support.

Abstract

from arXiv · show

Numerical end-to-end simulation in Adaptive Optics (AO) is a key tool in the development of complex systems, from the initial design to the commissioning phase. Based on our previous experience with PASSATA, we decided to develop a new AO simulation framework in Python language, naming it SPECULA (short for: Scalable Parallel Execution of Computations Upscaling Large Adaptive optics simulations). Following an object-oriented approach, the physical entities are modeled as processing objects connected to each other to exchange data objects. A simulation is run by providing its description instead of writing and executing a specific script. The Python language and its library flexibility allowed us to write one single code that can be run on CPU and GPU platforms. We put a strong focus on computational efficiency, relying on CuPy and its interface to access the CUDA-stream mechanism. Moreover, SPECULA is capable of distributed computations over multiple processing nodes, making it suitable to run in an HPC environment, as tested on the Italian supercomputer Leonardo. SPECULA can also be used in laboratory environment to implement a hybrid simulation, allowing us to interface simulated and concrete objects: this feature was demonstrated in the Adaptive Optics laboratories at Arcetri Observatory. In this paper, we describe the main characteristics of SPECULA, show some relevant examples of its use, and finally draw our goals for the future.

1 Introduction

SPECULA addresses PASSATA’s adoption, usability, and scalability limitations with a Python-based, extensible framework for CPU, GPU, and HPC execution.

  • 1 Introduction: PASSATA’s IDL implementation complicates laboratory use, GPU programming, HPC scaling, scripting, and long-term maintainability.The paper also argues that the implementation language limited wider adoption.
  • 1 Introduction: Python was chosen to improve usability, inspectability, extensibility, and access to optimized numerical libraries without requiring hard real-time performance.The authors prioritize a framework that contributors can understand and extend while retaining computational efficiency.
  • 1 Introduction: SPECULA automates object construction from YAML descriptions and avoids GPU-specific code through platform-agnostic NumPy/CuPy support.Its processing objects can be allocated to CPUs, selected GPUs, or specific processes for distributed execution.
  • 1 Introduction: SPECULA is positioned among many AO simulators, while cross-checking results against those libraries remains outside this paper’s scope.The project is open source and invites feedback and contributions from other framework users.
  • 1 Introduction: The paper covers framework structure, configuration, data storage, visualization, multiprocessing, physical-device interaction, PASSATA comparison, and future work.The organization reflects both implementation details and validation of simulation results.

2 The framework

SPECULA models adaptive-optics simulations as connected processing and data objects managed by scheduling, device, communication, and persistence infrastructure.

  • 2.1 Basic Concepts: SPECULA represents simulations as networks of processing objects exchanging self-contained data objects, with management objects building and running the simulation.Processing objects model devices, physical entities, or processes, while data objects wrap physical quantities.
  • 2.1 Basic Concepts: Processing objects execute through input gathering, computation, and output updates, while generation times allow unnecessary computations to be skipped.A scheduler respects the network’s partial-order relation at each discrete time step.
  • 2.1 Basic Concepts: Delayed feedback connections are removed for scheduling, after which SPECULA requires a directed acyclic graph to assign a valid trigger order.This restriction prevents simultaneous circular dependencies between distinct processing objects.
  • 2.2 Data Classes: Data exchange across devices and nodes is handled automatically through references, memory copies, or message passing, with persistence provided through standardized FITS save and read methods.These mechanisms support heterogeneous execution and archiving or replaying complete simulation states.
  • 2.3 Processing Objects: Processing objects share a defined lifecycle and use unified CPU/GPU interfaces, with optional CUDA-stream execution for computationally intensive triggers.The framework separates setup, core computation, and post-trigger synchronization.
  • 2.3 Processing Objects: SPECULA had implemented more than 50 processing objects while targeting computational efficiency on both GPUs and standard CPUs.The design also provides guidelines for implementing additional processing objects.

3 Configuration files structure

SPECULA simulations are declared through compatible YAML files that define existing objects and parameters, with composition mechanisms for controlled configuration changes.

  • 3 Configuration files structure: A simulation is uniquely described by one or more YAML files whose conventions must match SPECULA’s existing code.YAML alone cannot define new classes or alter a processing object’s parameter list.
  • 3 Configuration files structure: All processing objects share target_device_idx and target_rank parameters for selecting CPU/GPU placement and MPI execution rank.Both parameters may be omitted when default values are sufficient.
  • 3 Configuration files structure: Multiple YAML files can be combined to modify a base simulation incrementally without proliferating configuration files.This supports reusing a system structure while changing selected simulation settings.

4 Data Storage and Simulation Replay

SPECULA stores simulation outputs explicitly through DataStore objects and supports later replay or analysis without repeating the original computations.

  • Data Storage: DataStore saves simulation inputs as temporal series in FITS or pickled-object formats.The stored output includes the data and time axis.
  • Data Storage: Each run records its complete combined simulation structure in params.yml for future reproducibility.The configuration includes overrides from multiple YAML inputs.
  • Simulation Replay: replay_params.yml enables reloading saved data through DataSource objects instead of recomputing saved outputs.Replay files can be modified to add displays or other processing objects.
  • Post-processing: Stored outputs can later support PSF computation, phase cubes, and modal analysis at different wavelengths or lines of sight.

5 Visualization Tools

SPECULA provides concurrent local and networked visualization tools for inspecting data exchanged during simulations, including displays for several AO-specific data types.

  • Display Objects: Display Objects provide live visualization for scalar or vector time series, 2D images, pixels, slopes, and electric fields.They can prepare input data before rendering.
  • Display Server: The display server publishes processing-object outputs through a Flask web server and interactive JavaScript clients.Users can request subsets of generated data through the web interface.
  • Display Objects: Fig 5 shows outputs from PhaseDisplay, ModesDisplay, PixelsDisplay, SlopecDisplay, PlotDisplay, and PsfDisplay.
  • Display Server: Fig 6 shows a generated web page exposing outputs from two processing objects through the “out_layer” and “out_sr” links.
  • Display Server: The web display is non-interactive with fixed ranges for most elements, but remains useful for quick simulation checks.

6 Multiprocessing and HPC enviroment

SPECULA distributes processing objects across GPUs, processes, and HPC nodes using MPI, and its MORFEO tests demonstrate useful but non-proportional scaling constrained by parallelizability and communication overhead.

  • Multiprocessing Support: SPECULA supports MPI-based distribution across computing nodes, with processing objects assigned to specific processes and GPU indices.Process and GPU assignments can also be represented in diagrams through color coding.
  • HPC Evaluation: The full MORFEO simulation was tested on four Leonardo HPC nodes, each equipped with four Nvidia A100 GPUs.
  • HPC Evaluation: MORFEO’s 12 WFS pipelines can execute in parallel on different GPUs, although their computational demands vary with WFS geometry.
  • Performance Results: SPECULA benefits from GPU allocation for demanding objects, while MORFEO scaling from one to two nodes is fairly good but not proportional.The authors attribute the non-proportional scaling to heterogeneous WFS workloads and communication overhead.
  • Performance Results: Scaling from two to four nodes reaches a limit imposed by the parallelizability of this specific MORFEO case.The best reported performance required distributing computations within a single process.

7 Hardware in the loop

SPECULA supports hybrid laboratory simulations by wrapping physical hardware as processing objects that exchange standard data objects with simulated components.

  • Hardware Interface: Specialized processing objects connect SPECULA to laboratory hardware while preserving standard simulation data exchanges.The interface is designed to support laboratory activity and hybrid simulations.
  • Hardware Interface: SPECULA uses PLICO to access supported hardware through simple server configuration and method calls for reading or commanding devices.Examples include camera reads and deformable-mirror shape commands.
  • Hardware Objects: Available hardware wrappers include PlicoDM, PlicoInterferometer, PlicoMotor, and PysilicoCamera.
  • Hardware Objects: Each hardware object performs one operation per simulation step, and the initial implementations are maintained in a separate SpecuLab repository.
  • Laboratory Demonstration: An influence-function calibration example drove an ALPAO deformable mirror, read interferometer wavefronts, and saved commands and wavefronts.The setup used a Baumer camera and a 4D PhaseCam interferometer.

8 Simulation results validation

SPECULA was validated through internal software testing and external comparison with PASSATA, showing excellent agreement across the tested Adaptive Optics systems.

  • Internal verification used more than 500 unit, integration, and validation tests distributed across approximately 100 files.Validation tests compared selected component outputs against reference data pre-computed with PASSATA.
  • PASSATA served as the scientific benchmark because its results had been verified across instrument design, on-sky commissioning, other simulators, and astronomical data.
  • SPECULA and PASSATA showed excellent agreement in an 11-second SOUL simulation under identical conditions, with only negligible numerical-precision differences.The comparison used guide star magnitude 8 and 0.8 arcsec seeing, with H-band Strehl Ratio and turbulence and residual modes RMS reported.
  • The external validation covered the entire set of Adaptive Optics systems listed in Table 1, with similar agreement found across all tested systems.

9 Conclusions and Future Work

The authors conclude that SPECULA is mature enough for the Adaptive Optics community, based especially on validated simulation correctness, while planning broader hardware, usability, visualization, and hybrid-simulation support.

  • SPECULA is presented as mature enough for community introduction after more than a year of development.The assessment is based on performance, ease of extension, and simulation correctness.
  • Simulation correctness was verified against PASSATA across a wide set of Adaptive Optics systems.
  • Future work includes broader hardware-in-the-loop and hybrid-simulation support, more devices, improved visualization, and tools for producing simulation definitions.A design GUI for generating YAML files and additional real-time feedback interfaces are among the planned extensions.
  • The modular framework is intended to support continued community contributions and simulation of state-of-the-art Adaptive Optics systems.

Disclosures

The paper reports no financial, commercial, or other potential conflicts of interest and acknowledges AI-assisted language refinement and laboratory equipment.

  • The authors declare no financial interests, commercial affiliations, or other potential conflicts influencing the research or manuscript.
  • The manuscript acknowledges Overleaf AI Assist powered by Writefull for language refinement and formatting.
  • The laboratory setup used an ALPAO 820 deformable mirror, a 4D PhaseCam 6110 interferometer, and a Baumer VCXG.2-124M camera.

10 Appendix A - Data and Processing classes

The appendix catalogs the data and processing object classes implemented in SPECULA.

  • Table 3 provides an overview of the data objects defined so far in SPECULA.
  • Table 4 provides an overview of the processing objects implemented so far in SPECULA.

11 Appendix B - Configuration files details, syntax and examples

SPECULA simulations are configured declaratively in YAML by defining parameters, data objects, processing objects, and their connections. The appendix also describes incremental overrides and removal, data-store inputs, and Slurm-based multi-node GPU execution.

  • Configuration examples: Simulation files begin with a SimulParams main section containing global settings such as storage location, pupil sampling, total duration, and time step.The SOUL example also defines wave-generator parameters and optical components such as a modulated pyramid.
  • Configuration syntax: YAML processing-object sections specify an object name, class, constructor parameters, inputs, and outputs, with non-default values overriding class defaults.Raw arrays can be loaded from disk using parameter names with the _data postfix.
  • Data connections: Processing objects exchange data through named outputs and inputs, while data-object connections must match the relevant data-object class or initialization fails.Inputs can reference another object's output, and outputs are listed by name; some processing objects may have no inputs.
  • Incremental modifications: Incremental configuration files can add sections, override selected parameters, remove objects, and specify DataStore inputs or named data files.Overrides use an object-name key with parameter-value mappings, while removals list object names explicitly.
  • HPC execution: A Slurm configuration runs SPECULA across four computing nodes with four GPUs per node, using CUDA, OpenMPI, and the NVIDIA HPC compiler environment.The example requests four MPI tasks per node and launches SPECULA with srun.
Loading 2602.06688v1…