R3XA_API

Tutorials

  • Tutorial — Interactive DIC notebook (Marimo)
    • 1) Local test (interactive editor)
      • Install notebook dependencies
      • Graphviz requirement
      • Start Marimo
      • What to validate
    • 2) MyBinder (public interactive run)
  • Tutorial — Qi Hu case study (IR Lagrangian thermography)
    • Context
    • Data flow (conceptual)
    • Graph (Qi Hu example)
    • How to generate the graph
    • Graph semantics (colors & shapes)
      • Data sources (ellipses)
      • Data sets (rectangles)
      • Edges
    • Files used

How-to guides

  • Examples and recipes — from scratch vs registry
    • Example index
      • Python scripts (examples/python/)
      • MATLAB scripts (examples/matlab/)
      • Data files
    • 1) From scratch
    • 2) Registry‑based
    • Outputs
    • 3) Creating a new registry item
    • 4) Loading an existing file and saving it again
    • 5) Discovering and merging registry items
    • 6) Typed DIC pipeline
    • 7) Qi Hu from a literal JSON reconstruction
    • DIC pipeline graph (from scratch example)
  • Registry Web Editor
    • Why a dedicated page
    • Route
    • Validation API
    • Local workflow
    • Relation to existing web docs
  • Deploy on Railway
    • 1) Create the Railway project
    • 2) Environment variables
    • 3) Health check
    • 4) Local run
    • Notes

Explanation

  • R3XA_API — Overview and rationale
    • Why R3XA
    • Core idea
    • JSON structure (high level)
      • Structure diagram
    • Header (minimal)
    • Settings
    • Data sources
      • Flow diagram
    • Data sets
    • Using the SDK
    • Validation (why it matters)
      • Full file validation
      • Item validation (registry)
    • Registry (reusable components)
      • How to load registry items
      • How to create a new registry item
      • How to reuse and override a registry item
      • How it maps to the schema
      • Why sub-validation works
  • Engineering Contract — user and developer requirements
    • 1. Project goals
    • 2. User perspective — what matters in practice
      • 2.1. There is a recommended public API surface
      • 2.2. The recommended full-file workflow is load -> edit -> validate/save
      • 2.3. The registry is used in two different ways
      • 2.4. Why RegistryItem was introduced
      • 2.5. Guided helpers exist to speed up file creation
      • 2.6. Compatibility helpers still exist, but they are no longer the recommended path
      • 2.7. Validation is not optional in the project philosophy
      • 2.8. Typing and IDE autocompletion are optional, but useful
    • 3. Developer perspective — what must be respected
      • 3.1. The source of truth is not this repository
      • 3.2. Why the API does not depend on the spec repository at runtime
      • 3.3. When the schema changes, several derived artifacts must change too
      • 3.4. Why the .pyi file exists
      • 3.5. Why guided helpers are not yet implemented as static Python methods
      • 3.6. Why the top-level API surface was reduced
      • 3.7. Stability policy for the 1.x series
      • 3.8. What developers must do before a release
    • 4. Common misunderstandings
      • “Why keep a dict-based API if Pydantic exists?”
      • “Why is the helper called unit() if the object contains more than a unit?”
      • “Why keep some helpers if they are no longer recommended?”
    • 5. Structural decisions to keep in mind
      • For users
      • For developers
    • 6. Operational summary
      • User perspective
      • Developer perspective

Reference

  • R3XA_API — API Reference
    • Recommended imports
    • Stability policy
    • Core class
      • R3XAFile
    • Helper functions
      • unit(...)
      • data_set_file(...)
    • Registry utilities
      • load_item(path) -> dict
      • save_item(path, item, validate=True, kind=None) -> Path
      • Registry
      • RegistryItem
      • validate_item(item, kind=None, schema=None) -> None
      • Advanced
      • load_registry(root) -> dict
      • merge_item(base, **overrides) -> dict
    • Schema utilities
      • load_schema(path: str | None = None) -> dict
      • schema_version(path: str | None = None) -> str | None
      • validate(instance: dict, schema: dict | None = None) -> None
    • Related pages
  • R3XA Specification
    • General Structure
    • Header
    • Settings
      • Generic experimental setup (settings/generic)
      • Specimen (settings/specimen)
      • Stereo rig (settings/stereorig)
      • Testing machine (settings/testing_machine)
    • Data Sources
      • Generic data source (data_sources/generic)
      • Visible Camera (data_sources/camera)
      • Infrared Camera (data_sources/infrared)
      • Tomograph X-Ray (data_sources/tomograph)
      • Load Cell (data_sources/load_cell)
      • Strain Gauge (data_sources/strain_gauge)
      • Point Temperature (data_sources/point_temperature)
      • Digital Image Correlation measurement (data_sources/dic_measurement)
      • Mechanical analysis (data_sources/mechanical_analysis)
      • Parameter identification (data_sources/identification)
      • Computing strains from displacement field (data_sources/strain_computation)
    • Data Sets
      • Generic data set (data_sets/generic)
      • Data set (single file) (data_sets/file)
      • Data set (list of files) (data_sets/list)
    • Appendix — Common Types
      • Setting id
      • Data set id
      • Data source id
      • Data set file
      • Unit
      • unsigned integer
  • Typed models (optional) — dic_pipeline example
    • Goal
    • Why Pydantic helps in the workflow
    • Install
    • Public typed entry points
    • dic_pipeline in typed mode
    • Important compatibility note
    • Ready-to-run example script
  • MATLAB binding reference (minimal)
    • Install (MATLAB path)
    • Quick start
    • MATLAB vs Python helper signatures
    • unit() signature difference
    • What is implemented
    • Legacy aliases
    • What is intentionally omitted
  • Validation — concepts and best practices
    • Why validation matters
    • Two levels of validation
      • 1) Full file validation
      • 2) Item (registry) validation
    • Best practices
    • Common pitfalls
  • Web UI (R3XA_API)
    • Architecture choices
    • Install & run
      • Graphviz requirement
    • What you can do
    • Links
    • API endpoints
  • Developer workflow
    • Runtime model for graphs
    • Optional dependency sets
    • Bootstrap a contributor environment
    • Test matrix
    • Common developer commands
      • Schema-driven stubs
      • Test commands
      • Graph generation checks
    • Clean source archive
R3XA_API
  • Search

© Copyright .

Built with Sphinx using a theme provided by Read the Docs.