NINI
72 lines
2.5 KiB
Markdown
72 lines
2.5 KiB
Markdown
# Step 13: linear-static-analysis-path
|
|
|
|
## Sprint Contract
|
|
|
|
### Objective
|
|
Implement the `LinearStaticAnalysis` Template Method path from parsed Domain to solved state and written `U`/`RF` results.
|
|
|
|
### Required Reading
|
|
- /AGENTS.md
|
|
- /PROGRESS.md
|
|
- /PLAN.md
|
|
- /docs/README.md
|
|
- /docs/HARNESS_ENGINEERING.md
|
|
- /docs/PRD.md
|
|
- /docs/ARCHITECTURE.md
|
|
- /docs/ADR.md
|
|
- /docs/NUMERICAL_CONVENTIONS.md
|
|
- /docs/RESULTS_SCHEMA.md
|
|
- /docs/VERIFICATION_PLAN.md
|
|
- /phases/1-linear-static-mitc4/step8.md
|
|
- /phases/1-linear-static-mitc4/step12.md
|
|
|
|
### Scope
|
|
- Implement the linear static analysis strategy using the documented common flow: validate, build model, number DOFs, assemble, constrain, solve, reconstruct, recover RF, update state, write results.
|
|
- Store mutable physical quantities and iteration/result state in `AnalysisState`.
|
|
- Route solving through the linear solver interface.
|
|
- Emit minimum Phase 1 result fields `U` and `RF`.
|
|
|
|
### Allowed Files
|
|
- `include/**`
|
|
- `src/**`
|
|
- `tests/**`
|
|
- `PLAN.md`
|
|
- `PROGRESS.md`
|
|
- `phases/1-linear-static-mitc4/index.json`
|
|
|
|
### Explicit Non-Goals
|
|
- Do not implement nonlinear, dynamic, thermal, composite, or contact workflows.
|
|
- Do not bypass `DofManager`, assembler, solver interface, or result writer boundaries.
|
|
- Do not compare against stored Abaqus references in this step; that is Step 14.
|
|
|
|
### Tests To Write First
|
|
- End-to-end small-model test using a deterministic element or minimal fixture where expected `U` and `RF` are known.
|
|
- Singular-system failure test through the analysis path.
|
|
- Result-emission test for `U` and `RF` fields and component order.
|
|
|
|
### Reference Artifacts
|
|
- None required for this orchestration step.
|
|
|
|
### Acceptance Commands
|
|
```bash
|
|
python scripts/validate_workspace.py
|
|
```
|
|
|
|
### Evaluator Checklist
|
|
- Strategy + Template Method architecture is visible and not hardwired to only one future analysis type.
|
|
- `AnalysisState` owns mutable solve/result data.
|
|
- `RF` uses full-vector recovery.
|
|
- Results match the documented step/frame/field layout.
|
|
|
|
### Handoff Requirements
|
|
- Record analysis behavior, tests, and validation in `PROGRESS.md`.
|
|
- Update `PLAN.md` if Phase 1 end-to-end risks remain.
|
|
- Update the matching phase index entry: use `completed` with a one-line `summary`, or `blocked` with `blocked_reason`, or `error` with `error_message`.
|
|
|
|
## Verification
|
|
1. Run the acceptance command.
|
|
2. Inspect the analysis path for architecture-boundary shortcuts.
|
|
|
|
## Do Not
|
|
- Do not make the first end-to-end path depend on local Abaqus execution.
|