# Arsenal Development Plan β€” Atomizer Multi-Solver Integration > **Status:** DRAFT β€” pending CEO approval > **Date:** 2026-06-25 > **Authors:** Technical Lead (architecture + feasibility), Auditor (risk + gates), Manager (orchestration) > **Source docs:** Arsenal V3 Final, Tool-Agnostic Architecture, Multi-Solver Roadmap, Arsenal Reference --- ## 1. Executive Summary **Goal:** Integrate the 80/20 highest-leverage open-source tools from the Atomizer Arsenal into V2, enabling fully scripted optimization without NX GUI dependency. **What this unlocks:** - Linux-headless optimization loops (no NX license bottleneck) - 100s–1000s of trials per campaign (vs. current NX-constrained budgets) - Multi-solver validation (CalculiX vs Nastran cross-checking) - Path to CFD and multi-physics (expansion sprints) **The 80/20 stack (6 sprints):** | Priority | Tool | Category | Why | |----------|------|----------|-----| | πŸ”΄ P1 | CalculiX | FEA solver | Free structural solver, covers 80% of use cases | | πŸ”΄ P1 | Gmsh | Meshing | Universal mesher, Python API, STEP import | | πŸ”΄ P1 | Build123d | CAD | Code-native geometry, LLM-perfect, headless | | πŸ”΄ P1 | meshio + pyNastran | Converters | Format glue between all tools | | πŸ”΄ P1 | PyVista + ParaView | Post-processing | Automated visualization pipeline | | 🟑 P2 | pymoo | Optimization | Multi-objective (NSGA-II/III) | | 🟑 P2 | OpenFOAM | CFD | Thermal/flow screening | | 🟒 P3 | preCICE | Coupling | Thermo-structural coupling | | 🟒 P3 | OpenMDAO | MDO | System-level optimization | **Antoine's time commitment:** ~2–3 hours per sprint for validation gates. **HQ autonomous work:** days of implementation per sprint. --- ## 2. Architecture Overview The Arsenal integrates through Atomizer's 3-layer tool-agnostic architecture: ``` β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ Layer 3: OPTIMIZATION INTELLIGENCE β”‚ β”‚ AtomizerSpec v3.0 β”‚ Optuna/pymoo β”‚ LAC β”‚ LLM Agents β”‚ β”‚ ── never touches tool-specific formats ── β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ Layer 2: TOOL PROCESSORS (deterministic Python) β”‚ β”‚ Geometry: nx_geometry β”‚ build123d_geometry β”‚ step_importβ”‚ β”‚ Meshing: gmsh_mesher β”‚ nx_mesher β”‚ β”‚ Solvers: nastran_solver β”‚ calculix_solver β”‚ openfoam β”‚ β”‚ Convert: meshio_converter β”‚ pynastran_bridge β”‚ β”‚ Post: pyvista_post β”‚ paraview_post β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ Layer 1: UNIVERSAL DATA CONTRACTS β”‚ β”‚ AtomizerGeometry β”‚ AtomizerMesh β”‚ AtomizerBCs β”‚ β”‚ AtomizerMaterial β”‚ AtomizerResults β”‚ β”‚ ── solver-agnostic dataclasses (the Rosetta Stone) ── β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ ``` **Key rule:** Adding a new tool = writing ONE processor file. Contracts never change per tool. ### 2.1 V2 Repository Target Layout ``` atomizer/ β”œβ”€β”€ contracts/ β”‚ β”œβ”€β”€ geometry.py # AtomizerGeometry β”‚ β”œβ”€β”€ mesh.py # AtomizerMesh β”‚ β”œβ”€β”€ boundary_conditions.py # AtomizerBCs β”‚ β”œβ”€β”€ material.py # AtomizerMaterial β”‚ β”œβ”€β”€ results.py # AtomizerResults β”‚ └── validators.py # Cross-contract sanity checks β”œβ”€β”€ processors/ β”‚ β”œβ”€β”€ base.py # Abstract base classes β”‚ β”œβ”€β”€ geometry/ β”‚ β”‚ β”œβ”€β”€ build123d_geometry.py β”‚ β”‚ β”œβ”€β”€ nx_geometry.py β”‚ β”‚ └── step_import.py β”‚ β”œβ”€β”€ meshing/ β”‚ β”‚ β”œβ”€β”€ gmsh_mesher.py β”‚ β”‚ └── nx_mesher.py β”‚ β”œβ”€β”€ solvers/ β”‚ β”‚ β”œβ”€β”€ nastran_solver.py β”‚ β”‚ β”œβ”€β”€ calculix_solver.py β”‚ β”‚ └── openfoam_solver.py # Sprint 4 β”‚ β”œβ”€β”€ converters/ β”‚ β”‚ β”œβ”€β”€ meshio_converter.py β”‚ β”‚ └── pynastran_bridge.py β”‚ └── postprocessing/ β”‚ β”œβ”€β”€ pyvista_post.py β”‚ └── paraview_post.py β”œβ”€β”€ orchestrator/ β”‚ β”œβ”€β”€ pipeline.py # Solver-agnostic run sequencing β”‚ β”œβ”€β”€ auto_select.py # Toolchain routing logic β”‚ └── coupling.py # Sprint 5: preCICE β”œβ”€β”€ optimization/ β”‚ β”œβ”€β”€ engine.py # Core optimization loop β”‚ β”œβ”€β”€ optuna_backend.py β”‚ └── pymoo_backend.py # Sprint 6 └── mcp_servers/ # Sprint 2-3 β”œβ”€β”€ calculix/ β”œβ”€β”€ gmsh/ β”œβ”€β”€ build123d/ └── pynastran/ ``` --- ## 3. Current Environment Assessment | Item | Status | Action Required | |------|--------|----------------| | V2 repo (`atomizer/` package) | ❌ Not yet created β€” still V1 flat layout | Sprint 0: scaffold package structure | | pyNastran | βœ… Installed | None | | CalculiX (ccx) | ❌ Not installed | `apt install calculix-ccx` or Docker | | Gmsh | ❌ Not installed | `pip install gmsh pygmsh` | | Build123d | ❌ Not installed | `pip install build123d` | | meshio | ❌ Not installed | `pip install meshio` | | PyVista | ❌ Not installed | `pip install pyvista` | | ParaView/pvpython | ❌ Not installed | `apt install paraview` | | pymoo | ❌ Not installed | `pip install pymoo` (Sprint 6) | | OpenFOAM | ❌ Not installed | Docker recommended (Sprint 4) | **First blocker:** Package installs on T420. Either direct install or Docker-based dev environment. --- ## 4. Sprint Plan ### Sprint 0: Environment + Scaffold (1–2 days) **Goal:** Working dev environment and V2 package skeleton. | Task | Owner | Autonomy | Deliverable | |------|-------|----------|-------------| | Install core Python packages (gmsh, build123d, meshio, pyvista) | Developer/IT | 🟒 Full | Working imports | | Install CalculiX (`apt install calculix-ccx`) | Developer/IT | 🟒 Full | `ccx` on PATH | | Scaffold `atomizer/` package with `__init__.py` stubs | Developer | 🟒 Full | Package importable | | Create `tests/benchmarks/` with 3 analytical reference cases | Tech Lead | 🟒 Full | JSON expected-value files | **Analytical benchmarks (known-answer problems):** 1. **Cantilever beam** β€” tip deflection = PLΒ³/3EI (linear static) 2. **Plate with hole** β€” SCF β‰ˆ 3.0 at hole edge (stress concentration) 3. **Simply supported beam** β€” first natural frequency = (π²/LΒ²)√(EI/ρA) (modal) **Antoine gate:** None β€” this is infrastructure. --- ### Sprint 1: Contracts + Structural Bridge Baseline (1 week) **Goal:** Contract-driven NX/Nastran baseline with format conversion verification. | Task | Owner | Autonomy | Deliverable | |------|-------|----------|-------------| | Implement 5 contract dataclasses | Developer | 🟒 95% | `contracts/*.py` with full type hints | | Implement `validators.py` | Developer | 🟒 95% | Unit-consistent checks, BC physics checks | | Implement `processors/base.py` abstract classes | Tech Lead β†’ Developer | 🟒 95% | `GeometryProcessor`, `MeshProcessor`, `SolverProcessor` ABCs | | Wrap existing NX/Nastran into `nastran_solver.py` | NX Expert β†’ Developer | 🟑 70% | Existing workflow through new interface | | Implement `meshio_converter.py` | Developer | 🟒 95% | BDF ↔ INP ↔ MSH ↔ VTK round-trip | | Implement `pynastran_bridge.py` | Developer | 🟒 95% | BDF read/modify, OP2 parse β†’ AtomizerResults | | Implement `pipeline.py` skeleton | Tech Lead β†’ Developer | 🟒 90% | Sequential pipeline runner | | Unit tests for all contracts + converters | Developer | 🟒 95% | pytest suite passing | **Success criterion:** Existing NX/Nastran workflow passes through new architecture with zero regression. **Antoine gate:** Provide 3 trusted benchmark studies with known expected outputs for parity check. **Risk:** Hidden assumptions in legacy NX/Nastran parsing may break when abstracted. **Mitigation:** Run full diff on old vs new output before declaring parity. --- ### Sprint 2: Open Structural Lane β€” CalculiX + Gmsh + Build123d (1–2 weeks) **Goal:** Full Linux-headless structural optimization loop with zero NX dependency. | Task | Owner | Autonomy | Deliverable | |------|-------|----------|-------------| | Implement `build123d_geometry.py` | Developer | 🟒 90% | DV dict β†’ Build123d β†’ STEP | | Implement `step_import.py` | Developer | 🟒 95% | STEP β†’ AtomizerGeometry | | Implement `gmsh_mesher.py` | Developer | 🟒 90% | STEP β†’ Gmsh β†’ AtomizerMesh (with quality metrics) | | Implement `calculix_solver.py` | Tech Lead β†’ Developer | 🟑 80% | .inp generation + ccx exec + .frd parsing β†’ AtomizerResults | | Implement `pyvista_post.py` | Developer | 🟒 95% | AtomizerResults β†’ contour plots (PNG/VTK) | | Implement `optuna_backend.py` (adapted) | Optimizer β†’ Developer | 🟒 90% | Contract-aware Optuna loop | | Run 3 analytical benchmarks through full pipeline | Tech Lead | 🟒 90% | Pass/fail report vs known answers | | CalculiX vs Nastran parity comparison | Tech Lead | 🟑 70% | Delta report on shared benchmark | **Demo scenario:** ``` Parametric bracket (thickness, fillet_radius, rib_width) β†’ Build123d generates STEP β†’ Gmsh meshes β†’ CalculiX solves (SOL 101 equivalent) β†’ PyVista renders stress contour β†’ Optuna optimizes for min mass @ stress constraint β†’ Full loop on Linux, no NX ``` **Success criteria:** - [ ] 3 analytical benchmarks pass within 2% of theory - [ ] CalculiX vs Nastran delta < 5% on stress/displacement for shared benchmark - [ ] Full optimization loop completes 50+ trials unattended **Antoine gate:** 1. Approve CalculiX vs Nastran parity tolerance (proposed: 5% on stress, 3% on displacement) 2. Validate one benchmark result manually 3. Review Build123d geometry quality for representative model **Risks:** - Gmsh mesh quality on sharp fillets β†’ **Mitigation:** define mesh size presets, add Jacobian quality check - CalculiX .frd parsing edge cases β†’ **Mitigation:** test against multiple element types (CQUAD4 equivalent, CHEXA equivalent) - Build123d geometry failures on complex shapes β†’ **Mitigation:** start with simple parametric bracket, escalate complexity gradually --- ### Sprint 3: MVP Hardening + Client-Grade Post-Processing (1 week) **Goal:** Production-quality outputs from both solver lanes, side-by-side comparison capability. | Task | Owner | Autonomy | Deliverable | |------|-------|----------|-------------| | Implement `paraview_post.py` | Developer | 🟒 90% | Publication-quality figures (headless pvpython) | | Implement `auto_select.py` | Tech Lead β†’ Developer | 🟑 75% | Toolchain routing rules (NX lane vs open lane) | | Implement `spec/validator.py` | Developer | 🟒 95% | AtomizerSpec v3.0 schema validation | | Dual-lane comparison report | Post-Processor β†’ Developer | 🟒 85% | Side-by-side Nastran vs CalculiX with pass/fail | | Regression test suite | Auditor β†’ Developer | 🟒 90% | Automated benchmark + parity checks | | MCP-CalculiX server | MCP Engineer β†’ Developer | 🟑 70% | Tool-call interface for CalculiX | | MCP-Gmsh server | MCP Engineer β†’ Developer | 🟑 70% | Tool-call interface for Gmsh | | Documentation: Integration Guide | Secretary | 🟒 95% | `docs/DEV/INTEGRATION-GUIDE.md` | **Success criteria:** - [ ] Dual-lane comparison passes on all 3 benchmarks - [ ] Automated regression suite runs in CI - [ ] MCP servers pass basic smoke tests **Antoine gate:** 1. Approve report template and required figure list 2. Define auto-select routing rules (when NX vs when open-source) 3. Sign off MVP as "usable for real studies" **🏁 MVP EXIT β€” after Sprint 3, Atomizer can run full structural optimization on Linux without NX.** --- ### Sprint 4: CFD Lane β€” OpenFOAM (1–2 weeks) **Goal:** Automated CFD/thermal screening within the same orchestration framework. | Task | Owner | Autonomy | Deliverable | |------|-------|----------|-------------| | Install OpenFOAM (Docker recommended) | IT | 🟒 Full | Working `simpleFoam` / `buoyantSimpleFoam` | | Implement `openfoam_solver.py` | Tech Lead β†’ Developer | 🟑 65% | Case generation + execution + result parsing | | Extend `gmsh_mesher.py` with CFD presets | Developer | 🟑 75% | Boundary layer meshing, inflation layers | | Extend contracts for CFD quantities | Tech Lead β†’ Developer | 🟑 70% | Pressure, velocity, temperature fields in AtomizerResults | | 2 CFD validation cases | Tech Lead | 🟑 60% | Lid-driven cavity + pipe flow (known analytical/reference) | **Demo scenario:** ``` Electronics enclosure airflow β†’ STEP β†’ Gmsh CFD mesh β†’ OpenFOAM (buoyantSimpleFoam) β†’ PyVista thermal map + pressure drop β†’ Variant ranking by max temperature ``` **Antoine gate:** 1. Lock one validated starter case template before generalization 2. Define screening-fidelity defaults (mesh size, turbulence model) 3. Validate thermal results against engineering judgment **Risk:** OpenFOAM setup complexity is high. Dictionary validation is error-prone. **Mitigation:** Start with one locked template, generalize only after it works. --- ### Sprint 5: Coupled Thermo-Structural β€” preCICE (1–2 weeks) **Goal:** Two-way coupled OpenFOAM ↔ CalculiX simulations. | Task | Owner | Autonomy | Deliverable | |------|-------|----------|-------------| | Install preCICE + adapters | IT | 🟒 Full | preCICE + CalculiX adapter + OpenFOAM adapter | | Implement `coupling.py` | Tech Lead β†’ Developer | 🟑 60% | Coupled orchestration with convergence monitoring | | 1 coupled benchmark | Tech Lead | πŸ”΄ 50% | Heated plate with thermal expansion | **Antoine gate:** Approve coupling parameters and convergence criteria. **Risk:** Coupling divergence, debugging complexity. **Mitigation:** Conservative time-step, explicit convergence checks, one golden benchmark. --- ### Sprint 6: Multi-Objective + MDO β€” pymoo + OpenMDAO (1–2 weeks) **Goal:** Pareto optimization across multiple objectives and disciplines. | Task | Owner | Autonomy | Deliverable | |------|-------|----------|-------------| | Implement `pymoo_backend.py` | Optimizer β†’ Developer | 🟒 85% | NSGA-II/III alongside Optuna | | Pareto front visualization | Post-Processor β†’ Developer | 🟒 90% | Interactive Pareto plots | | OpenMDAO integration (if scope allows) | Tech Lead β†’ Developer | 🟑 60% | MDO wiring for multi-discipline | | 1 multi-objective demo | Optimizer + Tech Lead | 🟑 70% | Mass vs stress vs temperature Pareto | **Antoine gate:** Define objective scaling and hard constraints. --- ## 5. Semi-Autonomous Workflow ``` β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ PER-SPRINT LOOP β”‚ β”‚ β”‚ β”‚ 1. Antoine picks sprint / approves scope [YOU] β”‚ β”‚ 2. HQ researches + designs architecture [AUTO] β”‚ β”‚ 3. Auditor reviews design for risks [AUTO] β”‚ β”‚ 4. Antoine approves architecture (15 min) [YOU] β”‚ β”‚ 5. Developer implements + writes tests [AUTO] β”‚ β”‚ 6. Auditor reviews code against protocols [AUTO] β”‚ β”‚ 7. Antoine validates one benchmark (2-3 hrs) [YOU] β”‚ β”‚ 8. Merge β†’ next sprint [AUTO] β”‚ β”‚ β”‚ β”‚ Your time: ~2-3 hours/sprint β”‚ β”‚ HQ time: days of implementation/sprint β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ ``` **What runs fully autonomously (steps 2-3, 5-6):** - Research tool capabilities, formats, Python bindings - Design processor architecture and contract extensions - Implement Python adapters, parsers, converters - Write and run unit tests against analytical benchmarks - Audit code against Atomizer protocols - Generate regression reports **What needs your engineering judgment (steps 1, 4, 7):** - Tool priority sequencing (strategic call) - Architecture approval (15-min review) - Cross-solver parity acceptance (is 5% delta OK?) - Benchmark validation (does this match physics?) - Geometry quality assessment (does Build123d output look right?) --- ## 6. Quality Gates (Auditor-Defined) ### Per-Processor Gate - [ ] Processor implements abstract base class correctly - [ ] Round-trip test: contract β†’ native format β†’ solve β†’ parse β†’ contract - [ ] At least 1 analytical benchmark passes within tolerance - [ ] Unit test coverage β‰₯ 80% for parser logic - [ ] Error handling for: missing files, solver crash, malformed output - [ ] Documentation: input/output formats, known limitations ### Per-Sprint Gate - [ ] All processor gates pass - [ ] Integration test: full pipeline from AtomizerSpec β†’ results - [ ] Regression: no existing tests broken - [ ] Parity check (if applicable): new solver vs reference solver - [ ] Tech Lead sign-off on physics validity - [ ] Auditor sign-off on code quality + protocol compliance ### MVP Gate (Sprint 3 Exit) - [ ] 3 analytical benchmarks pass (cantilever, plate-hole, modal) - [ ] CalculiX vs Nastran parity < 5% stress, < 3% displacement - [ ] 50-trial optimization completes unattended - [ ] Dual-lane comparison report generates automatically - [ ] Antoine validates one real-world study through the new pipeline - [ ] All regression tests pass in CI --- ## 7. Risk Register | # | Risk | Impact | Likelihood | Mitigation | Owner | |---|------|--------|------------|------------|-------| | R1 | CalculiX vs Nastran parity exceeds tolerance | High | Medium | Start with simple geometries, document element type mapping, investigate mesh sensitivity | Tech Lead | | R2 | Gmsh mesh quality on complex geometry | Medium | Medium | Define quality thresholds, add Jacobian/aspect-ratio checks, fallback presets | Tech Lead | | R3 | Build123d limitations on complex parametric models | Medium | Low | Start simple, escalate complexity, keep NX lane as fallback | Developer | | R4 | Contract design locks in wrong abstractions | High | Low | Freeze contracts only after Sprint 1 validation, allow minor evolution in Sprint 2 | Tech Lead + Auditor | | R5 | Package dependency conflicts on T420 | Low | Medium | Use venv or Docker dev environment | IT | | R6 | OpenFOAM setup complexity delays Sprint 4 | Medium | High | Docker-first approach, one locked template | IT + Tech Lead | | R7 | Scope creep into expansion tools before MVP stable | High | Medium | Hard gate: no Sprint 4+ work until Sprint 3 exit criteria met | Manager + Auditor | | R8 | MCP server maintenance burden | Low | Medium | MVP cap at 4 MCP servers, thin wrappers only | MCP Engineer | --- ## 8. Tool Installation Reference ### Sprint 0-2 (Core) ```bash # Python packages pip install gmsh pygmsh build123d meshio pyvista # CalculiX solver sudo apt install calculix-ccx # ParaView (Sprint 3) sudo apt install paraview ``` ### Sprint 4+ (Expansion) ```bash # OpenFOAM via Docker docker pull openfoam/openfoam-dev # preCICE sudo apt install libprecice-dev python3-precice # pymoo pip install pymoo # OpenMDAO pip install openmdao ``` --- ## 9. Success Metrics | Metric | Sprint 3 Target | Sprint 6 Target | |--------|----------------|----------------| | Solver lanes operational | 2 (Nastran + CalculiX) | 4 (+OpenFOAM + coupled) | | Optimization trials/hr (bracket-class) | 50+ | 100+ | | Analytical benchmarks passing | 3 | 8+ | | Cross-solver parity verified | Nastran ↔ CalculiX | + OpenFOAM thermal | | Automation level (no human in loop) | 70% | 85% | | MCP servers | 2 (CalculiX, Gmsh) | 4 | --- ## 10. Immediate Next Steps 1. **Antoine:** Approve this plan and Sprint 0-1 scope 2. **IT/Developer:** Run Sprint 0 package installs (est. 1-2 hours) 3. **Tech Lead:** Finalize contract dataclass specs with field-level detail 4. **Developer:** Scaffold `atomizer/` package structure 5. **Auditor:** Prepare benchmark expected-value files for 3 analytical cases 6. **Manager:** Create Mission Dashboard tasks for Sprint 0 + Sprint 1 --- *This plan is a living document. Update after each sprint retrospective.*