Skip to content

docs(rfc): RFC 0000 — CFD solver strategy (SU2, OpenFOAM, PyFluent) - #45

Closed
aligatoralex wants to merge 1 commit into
mainfrom
docs/rfc-cfd-solver-strategy
Closed

aligatoralex wants to merge 1 commit into
mainfrom
docs/rfc-cfd-solver-strategy

Conversation

@aligatoralex

@aligatoralex aligatoralex commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Description of Changes:

Adds docs/rfcs/0000-cfd-solver-strategy.md — an RFC on CFD solver strategy for YAADO_Core (SU2, OpenFOAM, PyFluent/Fluent). No code changes.

⚠️ Filing-convention note (flagged, not resolved, in the RFC itself §7.1): requested as docs/rfcs/0000-template.md-formatted, but that template and the docs/rfcs/ directory do not exist on main — verified directly this session. Four prior RFCs (0001–0004) live in docs/rfc/ (singular), each still on its own unmerged branch. This RFC uses docs/rfcs/0000-... exactly as requested and flags the directory/numbering inconsistency as an open question for whoever owns repo conventions, rather than silently picking one.

Key recommendations:

  • SU2 → first-class public solver. LGPL-2.1 (clean for a public Apache-2.0 repo), purpose-built for compressible/aerospace flow. New finding: SU2 already ships continuous_adjoint.py/discrete_adjoint.py/shape_optimization.py and a pysu2 Python-wrapper build — adjoint shape-optimization infrastructure YAADO doesn't use yet, directly relevant to RFC 0004's optimization-loop question.
  • OpenFOAM → optional second choice. rhoCentralFoam/sonicFoam cover compressible/shock-capturing flow. New finding: DAFoam (discrete adjoint + native OpenMDAO interface) is the concrete adoption path if OpenFOAM-based MDO is ever pursued — adopt as a vendored submodule, don't hand-roll an adjoint wrapper.
  • PyFluent/Fluent → explicitly excluded from the public repo. Academic Ansys licensing (no redistribution/competitive-analysis, Teaching tier bars research/publication) creates real exposure for a public Apache-2.0 repo. May only live in a private, appropriately-licensed companion repo — never in YAADO_Core, and the RFC does not clear even that without a human reading the actual license (§7.4, deliberately unresolved).
  • 3D boundary-layer meshing gap is a structural limitation of the free tool stack (independently corroborated: free meshers show the same prism-layer failure in third-party comparisons), not a bug — requires an explicit mesh-quality flag in generic mesh output regardless of the eventual fix.
  • RANS/GCI split: generic config machinery stays in YAADO_Core; a vehicle's actual mesh files/study results move to Hangar/<vehicle>/analyses_private/.

Verified directly this session (not assumed): su2_config_template.py's real current state — stale module-path header (analyses.cfd.su2_config_template), "ramjet rocket" language mixed with post-refactor "Generic Vehicle" wording, a dead Any-typed config read sharing issue #34's pattern, and a dangling reference to a docs/AGENT_CONTEXT.md that does not exist on main. Scoped as required cleanup, folded into #34 where it overlaps rather than duplicated.

Deliberately left unresolved rather than assumed favorable: the actual Ansys license tier/terms (§7.4 — needs a human with the signed agreement), whether to resurrect vs. redesign the CFD scaffolding removed in the August 2026 reset (§7.2), and the RFC filing-convention question above (§7.1).

Checklist:

  • I have run uv run pytest YAADO_Core/tests/ and all tests pass. (Docs-only; 102 passed, unaffected baseline on this branch.)
  • My code includes type hints and docstrings. (N/A — Markdown RFC.)
  • I added all vital READMEs. (Adds docs/rfcs/.)

Verification method:
Every YAADO-repo claim (file contents, missing directories/templates, issue cross-references) was checked directly against the current checkout this session, not assumed from the task brief. External tool/license claims are cited to the sources supplied in the research brief; §4 explicitly tables which claims are independently re-verified here vs. carried forward from that brief without re-verification.


Generated by Claude Code

Recommends SU2 as YAADO_Core's first-class public CFD solver (LGPL-2.1,
aerospace/compressible-flow fit, already ships adjoint shape-optimization
infra the repo doesn't use yet), OpenFOAM as an optional second choice
(DAFoam as the concrete OpenMDAO-integration path if pursued, rather than
hand-writing an adjoint wrapper), and explicitly excludes PyFluent/Ansys
Fluent from the public repo on academic-license grounds -- it may only live
in a private, appropriately-licensed companion repo, never in YAADO_Core.

Verifies su2_config_template.py's real, current state directly (stale
module-path header, vehicle-specific "ramjet rocket" language mixed with
generic "Generic Vehicle" wording post-refactor, a dead Any-typed config
read sharing #34's pattern, a dangling reference to a non-existent
docs/AGENT_CONTEXT.md) and scopes its cleanup as part of this RFC's
acceptance. Recommends generic RANS/GCI config machinery stay in
YAADO_Core while vehicle-specific mesh/study results move to
Hangar/<vehicle>/analyses_private/, per the project's Core-stays-generic
rule. Names the 3D boundary-layer meshing gap in the free tool stack as a
structural limitation (corroborated by independent third-party sources),
not a bug, and requires an explicit mesh-quality flag in generic mesh
output regardless of which fix is eventually chosen.

Flags several things this RFC could not resolve on its own authority and
lists them as open questions rather than assuming a favorable answer:
the actual Ansys license terms (Teaching vs Research vs other), the
missing docs/rfcs/0000-template.md and docs/AGENT_CONTEXT.md this request
and the SU2 module respectively reference but do not exist on main, and
whether to resurrect vs redesign the CFD scaffolding removed in the
August 2026 ComponentStore reset.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NPJaUV26PzaRdYKr3Q7z1d

Copy link
Copy Markdown
Contributor Author

Superseded by #47 — this RFC moves to docs/rfcs/0005-cfd-solver-strategy.md (renumbered from 0000, for sequential continuity with 0001-0004) as part of a consolidation of all docs-only RFC/notes PRs into one PR, which also resolves this RFC's own §7.1 open question about the docs/rfc/ vs docs/rfcs/ naming split — docs/rfcs/ (plural) is now the adopted convention, documented in docs/rfcs/README.md. Discussion stays on issue #46. Closing this PR; its branch will be deleted.


Generated by Claude Code

@aligatoralex
aligatoralex deleted the docs/rfc-cfd-solver-strategy branch September 1, 2026 00:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants