80 lines
4 KiB
Markdown
80 lines
4 KiB
Markdown
# 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.
|