Atomizer/projects/hydrotech-beam/BREAKDOWN.md

Technical Breakdown — Hydrotech Beam Structural Optimization

Project: Hydrotech Beam
Protocol: OP_10 (Project Intake), Step 2 — Technical Breakdown
Author: Technical Lead 🔧
Date: 2025-02-09
Status: Ready for review

---

1. Geometry Description & Structural Behavior

1.1 Structural Configuration

The component is a sandwich I-beam serving as the primary load-bearing member in a test fixture assembly. Key geometric features:

• Cross-section: Sandwich construction — a core layer flanked by face sheets on top and bottom flanges
• Web: Contains a pattern of lightening holes (circular cutouts) to reduce mass
• Loading: Static structural — likely a cantilever or simply-supported configuration with transverse loading (evidenced by "tip displacement" as a key output)
• Material: Steel (AISI) — conservatively strong for this application, which is consistent with the "overbuilt" assessment

1.2 Structural Behavior Analysis

The beam behaves as a bending-dominated structure. Key physics:

Behavior	Governing Parameters	Notes
Bending stiffness (EI)	Face thickness, core thickness	Sandwich theory: faces carry bending stress, core carries shear. Stiffness scales roughly with the square of the distance from the neutral axis
Mass	All four variables	Core thickness and face thickness add material directly; holes remove material from the web
Stress concentrations	Hole diameter, hole spacing	Larger holes → higher stress concentration factors at hole edges. Closely spaced holes can have interacting stress fields
Shear capacity	Core thickness, hole count, hole diameter	Web lightening holes reduce shear area. More holes or larger holes = less shear-carrying web
Local buckling	Face thickness, hole geometry	Thin faces or large unsupported spans between holes may introduce local instability, though at steel gauges this is less likely

1.3 Baseline Assessment

The current design (~974 kg, ~22 mm tip displacement) is significantly overbuilt in mass but under-stiff relative to the 10 mm displacement target. This is an important observation:

⚠️ The baseline FAILS the displacement constraint. Tip displacement is 22 mm vs. a 10 mm limit. This means the optimizer must simultaneously increase stiffness (reduce displacement by >50%) while reducing mass. These objectives are naturally conflicting — stiffer generally means heavier.

This will drive the optimizer toward a specific region: thicker faces (increased bending stiffness) but thinner core and/or more/larger holes (reduced mass). The feasible region may be narrow.

---

2. Design Variable Assessment

2.1 Individual Variable Analysis

Variable	ID	Range	Type	Sensitivity Expectation	Primary Effect
beam_half_core_thickness	DV1	10–40 mm	Continuous	High on mass, Medium on stiffness	Increases distance between face sheets → stiffness scales ~quadratically. Also adds core mass.
beam_face_thickness	DV2	10–40 mm	Continuous	High on both mass and stiffness	Thicker faces = more bending stiffness AND more mass. Key trade-off variable.
holes_diameter	DV3	150–450 mm	Continuous	High on mass, High on stress	Larger holes remove more web material (mass ∝ d²). But stress concentrations scale with hole size.
hole_count	DV4	5–15	Integer	Medium on mass, Medium on stress	More holes = less web mass, but also less shear-carrying area and potential hole interaction effects

2.2 Interaction Effects (Expected)

These variables are not independent — significant interactions are expected:

1. DV1 × DV2 (core × face): Classic sandwich interaction. Optimal bending stiffness comes from balancing core depth (lever arm) vs. face material (bending resistance). Increasing core thickness makes face thickness more effective for stiffness.

2. DV3 × DV4 (hole diameter × hole count): Strong interaction. Both control how much web material is removed. Large holes + many holes could create a web that's more hole than steel — stress will spike. There may be a feasibility boundary where the holes start to overlap or leave insufficient ligament width between them.

3. DV2 × DV3 (face × hole diameter): Stress at hole edges depends on the overall stress field, which is influenced by face sheet proportioning. Thicker faces reduce nominal stress → allowing larger holes.

4. DV1 × DV3 (core × hole diameter): Core thickness determines beam depth → determines web height → constrains maximum feasible hole diameter. If holes_diameter can approach the web height, we need a geometric feasibility check.

2.3 Discrete Variable Handling — hole_count

hole_count is an integer variable (5–15, 11 levels). Options:

Approach	Pros	Cons
Treat as continuous, round at end	Simple, works with any algorithm	Rounding may violate constraints; NX may not accept non-integer
Treat as truly integer	Correct physics per evaluation	Limits algorithm choices; some optimizers handle poorly
Relaxed continuous + periodic integer check	Best of both worlds	More complex implementation

Recommendation: Treat hole_count as integer throughout. With only 11 levels and NX-in-the-loop (where the model must be rebuilt with integer hole count), there's no benefit to continuous relaxation. The algorithms recommended below (CMA-ES, TPE) both handle mixed integer/continuous natively.

---

3. Objective Formulation

3.1 Single-Objective vs. Multi-Objective

The handoff mentions three goals: minimize mass, minimize displacement, keep stress safe. Let's decompose:

Goal	Type	Rationale
Minimize mass	Primary objective	Antoine's explicit priority
Tip displacement < 10 mm	Constraint	Hard limit, not a competing objective
Von Mises stress < 130 MPa	Constraint	Hard limit (safety)

Recommendation: Single-objective optimization.

\min_{x} \quad f(x) = \text{mass}(x) \text{s.t.} \quad g_1(x) = \delta_{\text{tip}}(x) \leq 10 \text{ mm} \quad\quad g_2(x) = \sigma_{\text{VM,max}}(x) \leq 130 \text{ MPa}

Rationale:

• Mass is the clear primary objective
• Displacement and stress are hard constraints, not competing objectives to trade off
• Single-objective is simpler, converges faster, and is appropriate for 4 design variables
• If Antoine later wants to explore the Pareto front (mass vs. displacement), we can reformulate

3.2 Constraint Margins

Given that the baseline already violates the displacement constraint, we should consider:

• Running the optimizer without constraint penalties initially to map the landscape
• Using a penalty-based approach with gradually increasing penalty weight
• Or using feasibility-first ranking (preferred for population-based methods)

Recommendation: Use a constraint-handling approach where feasible solutions always rank above infeasible ones (Deb's feasibility rules), with infeasible solutions ranked by constraint violation magnitude.

---

4. Constraint Formulation — Extraction from NX

4.1 Mass (Objective)

• Source: NX expression p173
• Extraction: Read directly from the NX expression system after model update
• Units: kg
• Validation: Cross-check with manual volume × density at baseline

4.2 Tip Displacement (Constraint g₁)

• Source: NX Nastran SOL 101 results — nodal displacement
• Extraction method options:
  1. DRESP1 in the .sim: Define a displacement response at the tip node(s). Extract max magnitude from the .f06 or .op2 results file
  2. Post-processing script: Parse the Nastran output (.f06 or .op2) for the displacement at the tip node ID
  3. NX expression/sensor: If a result sensor is defined in the sim, it can be queried as an expression
• Recommended: Define a displacement result sensor in Beam_sim1.sim at the beam tip. This gives us a clean NX expression we can extract alongside p173
• Component: We need to clarify whether the constraint is on total magnitude (RSS of X, Y, Z) or a single component (likely vertical/Z displacement). Assume magnitude for now.

4.3 Von Mises Stress (Constraint g₂)

• Source: NX Nastran SOL 101 elemental/nodal stress results
• Extraction method options:
  1. DRESP1: Maximum von Mises stress across the model or a specific group
  2. Result sensor: Max stress sensor in the sim
  3. Post-processing: Parse peak stress from .f06
• Recommended: Define a stress result sensor for max von Mises. Critical: identify the stress reporting location — element centroid vs. corner nodes can differ by 10–20%
• Concern: Stress at hole edges will be mesh-sensitive. Need to ensure mesh convergence at holes (see Section 5)

4.4 Extractor Requirements

The Atomizer framework will need extractors for:

1. mass ← NX expression p173
2. tip_displacement ← displacement sensor or Nastran output parse
3. max_von_mises ← stress sensor or Nastran output parse

⚠️ Action needed: Confirm whether result sensors already exist in Beam_sim1.sim, or whether we need to create them. This determines extractor complexity.

---

5. Solver Requirements

5.1 Solution Type

• SOL 101 (Linear Static) — appropriate for this problem
• Steel under moderate loading → linear elastic behavior expected
• Small displacement assumption: 22 mm tip displacement on a beam that's likely 2+ meters long → probably OK, but should verify L/δ ratio
• If L/δ < 50, consider SOL 106 (geometric nonlinearity) — unlikely to be needed

5.2 Mesh Considerations

Concern	Requirement	Priority
Hole edge refinement	Stress accuracy at lightening holes requires adequate mesh density. At minimum 4–6 elements around each hole quarter-circumference	Critical
Mesh morphing vs. remeshing	When holes_diameter or hole_count changes, does the mesh adapt? Parametric NX models typically remesh on update — need to confirm	High
Mesh convergence	Must verify that the baseline mesh gives converged stress results. If not, results will be noisy and optimization will struggle	Critical
Element type	Confirm element type: CQUAD4/CQUAD8 for shell? CTETRA/CHEXA for solid? Shell elements for thin faces are more efficient	Medium
Mesh size consistency	If mesh density varies with design variable changes, the noise in the objective/constraints could mislead the optimizer	High

5.3 Solver Runtime

• Need to benchmark: how long does one SOL 101 run take? This directly determines feasible trial budget
• Estimated: for a single beam with ~10K–100K DOF → probably seconds to low minutes per evaluation
• If < 2 minutes per run → budget of 100–200 trials is very feasible

---

6. Algorithm Recommendation

6.1 Problem Characterization

Dimension	Value
Design variables	4 (3 continuous + 1 integer)
Objectives	1 (mass)
Constraints	2 (displacement, stress)
Evaluation cost	Medium (NX model update + SOL 101 solve)
Landscape	Expected smooth with possible local features near constraint boundaries
Variable interactions	Significant (sandwich theory, hole interaction)

6.2 Algorithm Comparison

Algorithm	Handles Integer?	Handles Constraints?	Trial Efficiency	Exploration	Notes
CMA-ES	Yes (with rounding)	Via penalty/repair	Good for 4D	Excellent	Strong for low-dimensional continuous; integer handling is approximate
TPE (Bayesian)	Yes (natively)	Via constraint observations	Excellent	Good	Optuna's default; handles mixed types well; sample-efficient
NSGA-II	Yes	Yes (Pareto-based)	Moderate	Excellent	Overkill for single-objective; better for multi-obj
Nelder-Mead	No	Via penalty	Moderate	Poor	Too simple for mixed-integer
SOL 200 (Nastran)	Limited	Yes (native)	Excellent (gradient)	Poor	Nastran-native; no integer support; gradient-based so fast convergence but may miss global optimum
Latin Hypercube + Surrogate	Yes	Yes	High (via surrogate)	Excellent	Build surrogate from DoE, optimize on surrogate. Very efficient for expensive sims

6.3 Recommended Approach: Two-Phase Strategy

Phase 1: Design of Experiments (DoE) — Landscape Mapping

• Method: Latin Hypercube Sampling (LHS)
• Budget: 40–50 evaluations
• Purpose:
  • Map the design space
  • Identify feasible region
  • Understand variable sensitivities and interactions
  • Build intuition before optimization
  • Catch any model failures or numerical issues early
• Output: Sensitivity plots, interaction plots, feasible region visualization

Phase 2: Directed Optimization — TPE (Tree-structured Parzen Estimator)

• Method: TPE via Optuna
• Budget: 60–100 evaluations
• Purpose:
  • Exploit the landscape knowledge from Phase 1
  • Converge to the optimum
• Why TPE over CMA-ES:
  • Native mixed-integer support (no rounding hacks for hole_count)
  • Built-in constraint handling via Optuna's constraint interface
  • Sample-efficient — important if NX solve time is non-trivial
  • Handles non-smooth constraint boundaries well (stress around holes can have sharp gradients)
  • Well-supported in Python/Optuna ecosystem

Total Budget: ~100–150 NX evaluations

At 1–2 minutes per evaluation → 2–5 hours total compute time. Very manageable.

6.4 Alternative: SOL 200 for Continuous Subproblem

If we fix hole_count at a few integer values (e.g., 7, 10, 13), we could run Nastran SOL 200 for the remaining 3 continuous variables at each fixed hole count. SOL 200 uses gradient-based optimization with analytical sensitivities — extremely efficient. Then pick the best across the integer levels.

Pros: Fastest convergence for continuous variables, leverages Nastran's native sensitivity analysis
Cons: Requires DESVAR/DRESP setup in the .sim, more NX expertise, less framework-portable

Verdict: Keep as a backup option. TPE is more aligned with the Atomizer framework approach and handles the full mixed-integer problem in one pass.

---

7. Gap Analysis

7.1 Must-Clarify Before Proceeding

#	Item	Why It Matters	Risk if Unresolved
G1	Beam length and support conditions	Need to understand L/δ ratio; affects whether linear analysis is sufficient; affects sensitivity expectations	Could invalidate SOL 101 assumption
G2	Loading definition	What loads are applied? Point load at tip? Distributed? Self-weight? This affects stress distribution and which variables matter most	Incorrect optimization direction
G3	Displacement measurement location	"Tip displacement" — which node exactly? Max of a set? Single point? Which DOF component?	Wrong constraint extraction
G4	Stress constraint location	Max VM stress where? Entire model? Exclude supports/load application points? Stress at hole edges specifically?	Over-constraining or missing real failures
G5	Geometric feasibility of hole patterns	When hole_count = 15 and holes_diameter = 450 mm, do holes overlap? What's the beam web length?	Infeasible geometries will crash NX
G6	Result sensors in the sim	Do Beam_sim1.sim already have displacement/stress sensors defined?	Determines extractor development effort
G7	NX model parametric update method	How are design variables linked to NX expressions? Does the model reliably rebuild across the full range?	Model rebuild failures during optimization
G8	Mesh type and density	Shell or solid elements? Current mesh size? Has convergence been checked?	Noisy results → poor optimization
G9	Stress allowable basis	130 MPa — is this yield with a safety factor? What factor? Is it a project spec?	Constraint may be wrong

7.2 Nice-to-Know

#	Item	Value
N1	Any previous optimization attempts on this beam?	Avoids repeating failed approaches
N2	Are there manufacturing constraints (min face thickness, standard hole sizes)?	May restrict feasible designs
N3	Is fatigue a concern?	Static optimization alone may not be sufficient
N4	Any other load cases (dynamic, thermal, handling)?	Current scope is single static case
N5	Target mass? Antoine says "lighter" — is there a specific mass goal?	Helps gauge success criteria

---

8. Risk Assessment

8.1 Risk Register

#	Risk	Likelihood	Impact	Mitigation
R1	Narrow feasible region — displacement constraint is already violated at baseline. The feasible region (displacement < 10 mm AND low mass) may be very small or empty	High	Critical	Run DoE first to map feasibility. If no feasible point found, discuss relaxing constraints with Antoine
R2	NX model rebuild failures — parametric models can fail at extreme variable combinations (geometry boolean failures, mesh errors)	Medium	High	Test all 4 corners of the design space manually before optimization. Implement robust error handling
R3	Mesh-dependent stress results — stress at hole edges is mesh-sensitive. If the mesh changes character across the design space, stress results may be inconsistent	Medium	High	Conduct mesh convergence study at baseline. Verify mesh quality at 2–3 points in the design space
R4	Conflicting objectives — reducing mass while halving displacement requires finding a very specific structural configuration	High	Medium	The sandwich effect is our ally: increasing core depth increases stiffness faster than mass. But the feasible region may demand thick faces
R5	Hole overlap at extreme parameters — high hole count + large diameter could create infeasible geometry	Medium	Medium	Add a geometric feasibility pre-check before NX evaluation. Calculate minimum ligament width
R6	Linear analysis limitation — if optimal design has very thin members, local buckling or geometric nonlinearity could invalidate results	Low	Medium	Post-optimization validation: run SOL 105 (buckling) and/or SOL 106 on final design
R7	Single load case optimization — optimizing for one load case may create a design that fails under other real-world conditions	Medium	High	Flag to Antoine: are there other load cases? Plan verification runs post-optimization

8.2 Overall Risk Rating: MEDIUM-HIGH

The primary risk driver is R1 — the feasible region may be very constrained (or empty). The baseline design already violates the displacement constraint. The optimization isn't just about making it lighter — it must first make it stiffer, then lighter within the stiffness constraint. This is achievable with sandwich theory (the core thickness lever arm is powerful), but we need the DoE phase to confirm.

---

9. Recommended Next Steps

1. Clarify gaps G1–G9 with Antoine (via Manager)
2. Baseline model validation:
   • Open NX model and document geometry, mesh, BCs, loading
   • Run baseline and verify reported mass/displacement/stress values
   • Conduct mesh convergence check
3. Test parametric rebuild at design space corners
4. Set up extractors for mass, displacement, stress
5. Execute Phase 1 DoE (40–50 LHS samples)
6. Analyze DoE results — sensitivity, feasibility, interactions
7. Execute Phase 2 TPE optimization (60–100 trials)
8. Validate optimum — confirm NX results, check buckling, review physics

---

10. Summary

Aspect	Recommendation
Formulation	Single-objective: minimize mass, constrain displacement (≤10mm) and stress (≤130 MPa)
Algorithm	Two-phase: LHS DoE (40–50 trials) → TPE optimization (60–100 trials)
Total budget	~100–150 NX evaluations
Integer handling	hole_count treated as true integer (TPE native support)
Key risk	Baseline violates displacement constraint — feasible region may be tight
Key gap	Need to confirm loading, BCs, and geometric feasibility limits
Confidence	Medium — solid approach, but dependent on gap resolution

---

Technical Lead 🔧 — The physics is the boss.