Next release focus: should 0.7.5 / 0.8 be a CFD release?

[jyviko]

@bluecmd I'd love your view on where the next release should go, since you've driven most of the fluid side.

Where we are. 0.7.0 was the meshing release. Since then the fluid work has moved fast: the GPU lattice Boltzmann backend, in-place streaming, flow results in the viewport (slices, surfaces, streamlines), heat carried by the flow with buoyancy and wall heat, and the start-up clip in the gallery. On the structural side, the plan I'd sketched for 0.7.5 was a GPU solver for linear and nonlinear statics (PCG + AMG on the CPU first as the reference, then wgpu), and #579 (units stored in SI) is now in progress underneath everything.

The question. Should the next release (0.7.5 or 0.8) be a CFD release instead, or as well? For example:

• what a CFD release would need to be genuinely useful to someone running a real case (your AIO cooler study is a good yardstick): turbulence/LES at higher Re (A collision operator that stays stable at τ⁺ near ½: bluff-body flows above Re ≈ 100 blow up with TRT on gallery-sized grids #557), inlet/outlet and porous/fan conditions, conjugate heat transfer into solids (Thermal lattice Boltzmann and conjugate heat transfer with solids #157), the remote/async runs from docs/remote: design proposal for FieldCraft Remote, an asynchronous simulation backend #568, validation cases;
• what you'd cut as not needed yet;
• how it would interact with the structural GPU work (shared wgpu plumbing, one solver backend pattern).

No decision yet on my side; I want to hear what you think matters most before we pick.

And a request: could you contribute some example runs with their inputs and outputs? A small set of real cases (the model or script that sets it up, the solve settings, and the results: numbers, a picture or a short clip) would help everyone: new users get something to start from, we get regression material beyond the unit tests, and it shows what FieldCraft can actually do. The gallery in docs/examples.md and tools/flow-clip are a natural home; whatever format suits you.

Thanks, as always!

[bluecmd]

Thanks @jyviko, happy to weigh in. My own interest is designing and simulating electronics: boards, heat sinks, enclosures, coolers. So my vote is a CFD release, but a narrow one: an electronics-cooling release. The test it should pass: can I find out whether every component on a board stays under its limit before I build it?

What it needs, in order:

1. Conjugate heat transfer into solids (Thermal lattice Boltzmann and conjugate heat transfer with solids #157). Heat has to conduct through heat sinks, spreaders and the PCB itself, not only reach the faces. This also needs component power as a heat source (W per part), anisotropic PCB conductivity (in-plane vs through), and a thin-layer resistance for pastes and pads.
2. Fast steady temperatures. Electronics users want final junction temperatures, not a transient. With LBM, the solids' thermal time constants are many orders of magnitude longer than a flow step. So the solid side needs its own accelerated or steady solve, coupled to the flow periodically, plus a convergence stop rule. Without this, CHT is too slow to be practical.
3. Fans, vents and grilles. A fan as a pressure–flow curve, a resistance for perforated panels and filters, and inlet and outlet conditions. That covers forced-air enclosures and coolers like the AIO case.
4. Natural convection, and radiation as a later step. Buoyancy is already there. In sealed or passive enclosures, radiation carries a large share of the heat, so simple surface-to-surface radiation is worth planning for after 1–3.
5. Results in the user's terms. Max/junction temperature per component against its limit, the fan's operating point, flow through each vent, and the heat path.
6. Validation that electronics people recognise. The de Vahl Davis differentially heated cavity (natural convection), a heated block or cube in a channel (forced convection), and heat sinks against published correlations, all in the oracle.

What I'd cut for now: shedding at Re 300–600 and general turbulence/LES (#557 can wait, since electronics airflow is mostly modest Re), multiphase, and Remote (below).

How it fits the structural GPU work. It connects rather than competes. A computed temperature field pushed into a static step as a nodal temperature load gives board warpage and thermal stress. That is the same load NAFEMS LE11 is waiting for in the oracle. Shared wgpu plumbing and one solver-backend pattern make sense too: the LBM backend already shows the shape.

One more link: pcbcraft. Importing a board (outline, copper layers, footprints, per-part power) from pcbcraft or KiCad into a FieldCraft thermal model would give one family of open tools covering board design through thermal checks. Nothing open does that today.

On example runs: gladly. I'd start with three cases that double as the release's acceptance cases: a heat sink with a fan (forced convection), a sealed enclosure with a PCB (natural convection), and the AIO cooler study. Each would come with its model or script, solve settings, numbers and a picture or clip, in docs/examples.md alongside the flow-past clip.

On Remote (#568): let's leave it out of this release. It's important and we want to get it right, so I'd rather let the design marinate a bit than rush it. For 0.8, solving locally on your own GPU is enough.

[jyviko]

Thank you @bluecmd, this is exactly the kind of answer I hoped for: a narrow release with one clear test (does every component stay under its limit before I build it?), an ordered list, a cut list, and acceptance cases that double as examples. The link back to structures through a nodal temperature load (and LE11) is a great point. Let me go through it properly and come back here with a decision on scope.

[bluecmd]

A correction to my list above, from building the first examples (#587). I said #557 could wait because electronics airflow is mostly modest Re. That's wrong in practice. In the heat-sink example the inlet had to stay gentle because the TRT is close to its stability limit at that resolution, and the buoyant plume in the enclosure example runs into the same limit. Real fan speeds are higher still. So I'd move a collision operator that stays stable near τ⁺ ≈ ½ (#557: the regularised results there survived where TRT failed) from the cut list into the must-haves, next to #157.

On #157: the examples currently stand in for conduction with isothermal or fixed-flux faces and say so. Conjugate heat transfer is the single biggest gap for every one of them, so if the plan in #157 suits you, we're ready to start it.

[bluecmd]

The three electronics-cooling examples from this thread landed in develop with #587. They're samples now (cooling-heat-sink, cooling-enclosure, cooling-aio) and are written up in docs/examples.md:

• Heat sink in forced air: a six-fin sink held at 50 °C in 25 °C air at 0.1 m/s, buoyancy on (mixed convection, Ri ≈ 3). It sheds 1.93 W, a sink-to-inlet resistance of 13.0 K/W, with an effectiveness of 0.48 of what the duct's air could carry.
• Sealed enclosure with a PCB: a chip held at 40 °C in a box with 25 °C walls, natural convection only, solved to steady state with the steady stop rule (lbm, engine: run a fluid step to steady state with a stop rule #595). It sheds 62.7 mW, h ≈ 7.9 W/m²K, a resistance of 239 K/W.
• AIO cooler radiator (air side only): fan air at 0.1 m/s through the radiator held at a 45 °C coolant temperature. 61 W to 163 L/min of air, an effectiveness of 0.93. The water loop isn't simulated yet.

Trunk tests cover short runs of the heat sink and the enclosure. Heavy tests cover the AIO's short run, the heat sink's published numbers and the enclosure's steady state.

Every approximation these cases had to make (no conduction inside solids, the 0.1 m/s cap from #557, uniform inlet instead of a fan curve, no radiation, no component power, no coolant loop, and so on) is listed with its evidence in the Gaps table in #587's description.

[jyviko]

Thank you @bluecmd for the write-up, and for the three cases themselves! The numbers line up with hand estimates, and the Gaps table is a ready-made backlog. Several of those gaps are closing already: conduction inside solids with component power (#609), a collision that stays stable at higher speeds (#627, now in develop), a convective outlet (#626) and the de Vahl Davis validation (#628).