airfRANS-model-exploration/PROJECT_PLAN.md

AirfRANS Scaling Frontier Project

This document is a scope anchor, not a specification. It should help a human or agent understand what this repository is for without forcing a particular architecture, experiment grid, or implementation shape.

What we are doing

We are exploring the scaling frontier for AirfRANS-based CFD surrogate simulations.

The project is about understanding how far useful surrogate simulation can be pushed with open AirfRANS-style data, and what factors appear to control that frontier. The goal is not to preselect a model family, reproduce every baseline, or build a large simulation platform. The goal is to produce grounded evidence about what improves surrogate quality and where returns begin to flatten.

Use careful language: this is an empirical scaling/frontier study, not a claim of universal scaling laws unless the evidence later supports that.

Core questions

The work should stay centered on questions like:

1. What quality frontier is reachable using open AirfRANS-based simulation data?
2. How does performance change as available data, compute, and model capacity change?
3. Which bottleneck is most visible at a given stage: data, compute, representation, model capacity, optimization, or evaluation target?
4. When does additional simulation data appear more valuable than better training, representation, or model choice?
5. What is the simplest experiment that can move our understanding of the frontier forward?

These questions matter more than any specific architecture list or dataset-shape detail.

Working principles

• Start from open AirfRANS data and existing public context.
• Keep experiments small enough that results can be inspected, repeated, and compared.
• Change one major scaling axis at a time when possible.
• Track compute and wall-clock cost alongside quality metrics.
• Prefer evidence that informs the next decision over exhaustive sweeps.
• Avoid committing early to a specific model family, pipeline abstraction, or benchmark layout.
• Treat additional generated simulations as a later decision, justified only by measured need.

Scaling axes to keep in mind

The project should distinguish between several sources of scale:

• number of independent simulations available;
• number of sampled/query points used from those simulations;
• model capacity;
• training compute;
• inference cost;
• evaluation target, such as field quality versus engineering quantities.

Not every experiment needs to cover every axis. The important part is to avoid confusing them when interpreting results.

What counts as progress

A useful step should do at least one of the following:

• establish a trustworthy baseline;
• reveal a bottleneck;
• compare two choices under a controlled constraint;
• improve measurement or logging so future comparisons are reliable;
• show that a proposed direction is not worth pursuing yet;
• produce a plot, table, or saved artifact that clarifies the frontier.

A larger run is not automatically better. A small run that changes the next decision is more valuable than a broad sweep with unclear interpretation.

Non-goals for now

• Do not turn this into a general CFD framework.
• Do not make model selection the center of the project before the measurement loop is solid.
• Do not overfit the plan to AirfRANS implementation details that are not needed for the current decision.
• Do not generate additional CFD simulations before the open-data frontier has been measured.
• Do not treat a large experiment grid as inherently more credible than a focused frontier measurement.

Expected final shape

The eventual artifact should explain, with measured evidence:

• what frontier was explored;
• what axes were varied;
• what improved quality or efficiency;
• what bottleneck seems most important;
• whether additional generated simulation data appears justified;
• what the next most rational experiment would be.

The final output should be legible to someone evaluating the project as evidence of experimental judgment, simulation awareness, and resource-aware ML engineering.