Couple a 1D pipe network to a 3D CFD model

CFD coupling in Fluid Network Studio exports the network you have built as a single self-contained STAR-CCM+ Java macro with the network solver embedded inside it. The macro runs as a live boundary condition on your CFD model. At an interval you set, counted in CFD iterations, it reads each coupling boundary, solves the whole one-dimensional network with those readings, and writes the matching pressure, mass flow and, when heat transfer is on, temperature back to the boundary, under-relaxed, until the two solvers settle on one operating point. The CFD solver drives, nothing else has to be running during the solve, and there is no inter-process link to keep alive.

This is the capability that shaped how the rest of the tool was built, and it comes directly from the founder's peer-reviewed research on coupled one-dimensional and three-dimensional CFD. The coupling export is on the Advanced plan, A$39 a month, and it is currently marked Beta in the Studio. What that means in practice is set out honestly in what it does not do below.

The problem it solves

Most real systems are one small piece of three-dimensional physics attached to a large one-dimensional piping system. A manifold that distributes badly, a plenum, a header, a tubesheet, a vessel with an awkward internal path. The 3D piece deserves CFD. The other two hundred metres of pipe, the fittings, the pump and the tank do not, and meshing them is a waste of cells and of your week.

The usual workaround is manual iteration. You guess a boundary condition for the CFD model, run it, read the flow or the pressure it produced, take that back to a spreadsheet or a network tool, work out what the system would actually deliver, then re-run the CFD with the corrected number. Repeat until the two stories agree, if you have the patience. Every loop is hand work, the intermediate states are undocumented, and it is very easy to stop one iteration early and call it converged.

The coupling replaces that loop with a boundary condition that solves the network itself. You draw the network once, mark where the CFD domain sits in it, and export. From then on the network is re-solved inside the CFD run, at the current boundary values, as often as you ask for it.

What the export produces

Pressing Export STAR-CCM+ macro in the Studio downloads one file, hns_coupling.java. It is self-contained Java. There is no runtime to install, no separate library, and no account or licence check inside it.

The file has four parts.

1. A setup checklist, generated for your network, as a comment block at the top. It names the exact boundaries and reports you have to create in your simulation, with the names you typed in the Studio, the report type each one needs, the pressure datum to set, and the coupling controls in use. It is the to-do list for the next section.
2. The embedded solver. A hand-written, dependency-free Java port of the app's incompressible network solver: the same Churchill friction factor, the same Darcy-Weisbach pipe response, the same fitting losses and pump curves, the same global gradient algorithm. These files are constant across every export. The numerics were written and validated once, deliberately, so what runs inside your CFD solve is a version-pinned core rather than something regenerated per download.
3. Your network as data. The compiled topology, geometry, loss coefficients, fluid properties, boundary conditions and the port wiring, emitted as a plain data block. This is the only part of the file that changes from one export to the next.
4. The coupling loop, including a read-only preflight that self-checks your simulation before anything is written to it.

How the two solvers exchange values

In the Studio you drop a CFD domain box into the network where the three-dimensional region sits, and wire your pipes to it. Each pipe you wire becomes a port on the box, and each port couples in one of two directions. You choose per port, and you can mix them.

The rhythm of the run is the same either way. The CFD advances N iterations. The macro reads every port's report, solves the embedded network once with those values, and imposes the conjugate value on each boundary, blended with the previous value by an under-relaxation factor. Then the CFD advances another N iterations. When the imposed values stop moving, the two solvers have agreed.

Two controls tune that. The under-relaxation factor (URF) blends each new boundary value with the last one, and defaults to 0.5. Lower it if the imposed values oscillate or overshoot. N, the CFD iterations between network solves, defaults to 20. It wants to be high enough that the CFD field has settled before it is read again, and low enough that the boundary is not stale. Both sit in the Model tab beside the export button, under the Expert toggle, and the defaults are a sensible starting point.

The macro never creates anything in your simulation. It binds by name to boundaries and reports that already exist, which is why the checklist matters and why a typo is caught rather than silently worked around.

Setting it up in STAR-CCM+

Step one, in the Studio. Turn on CFD coupling in the Model tab, drop the CFD domain in, wire your pipes to it, and for each pipe add an inlet or an outlet port. Give each port its type, the boundary name as STAR-CCM+ spells it, and the name of the report that reads it. Set the box elevation, which is the height the CFD domain sits at in your network. Give the network a fixed-head anchor, such as a reservoir, a pressure boundary or a mass-flow inlet port, so it is solvable on its own. Export.

Step two, in your simulation. Working through the generated checklist, set each boundary to the type its port expects with its value method set to constant, since the macro drives that constant. Create the matching report on each boundary with the exact name from the Studio, and give each report a monitor so it has samples to read during the run. Then set the case reference-pressure datum to the same box elevation you used in the Studio. The macro imposes gauge pressures relative to that datum, so a mismatch offsets every imposed pressure by the density-gravity-height product and quietly shifts the operating point.

Step three, play the macro. It runs a read-only preflight first. For every port it checks the boundary exists, is the right type, has a constant value method it can drive, and has a report it can read, and it runs one embedded network solve as a seed. It prints a pass or fail line per port. On a failure it lists what is missing and stops without changing any boundary, so a half-configured simulation is never left in a strange state. On a pass it starts coupling and prints the imposed values as it goes, so convergence is something you watch rather than assume.

There is also a validate-only switch near the top of the file. Set it and the macro runs the preflight and stops, which is the fastest way to check a simulation is wired correctly without advancing the solution.

Temperature, when heat transfer is on

If heat transfer is on in the Studio, the export carries the network's thermal model too, and each port exchanges temperature alongside pressure and mass flow. A pressure-outlet port reads its boundary temperature from an area-averaged temperature report and feeds it into the network as the supply temperature at that point. A mass-flow inlet has the network's own computed temperature imposed on it, so the fluid entering the CFD domain carries the temperature the network says it should, under a separate temperature under-relaxation factor. Each embedded solve becomes a coupled thermal-hydraulic solve rather than a hydraulic one, so the run converges on a consistent thermal and hydraulic operating point together.

Two things to know. Temperature is absolute kelvin throughout, with no datum or gauge correction of the kind pressure needs, so the temperature report has to read absolute kelvin. And the exported thermal model uses constant fluid properties, sampled once at the Studio's fluid temperature: specific heat, conductivity, density and viscosity are held constant for the solve. For the two solvers to agree, set your CFD material to matching constant properties rather than strongly temperature-dependent ones. Temperature-dependent properties are a later extension, not a current capability.

The method behind it

Coupling a one-dimensional network to a three-dimensional CFD model, and getting the heat and the flow distribution to agree across the interface, was the subject of the founder's master's research at the University of Pretoria. It developed a coupled one-dimensional and three-dimensional CFD method for thermal analysis with flow maldistribution, applied to a feedwater heater tubesheet, and it was published and peer reviewed in the ASME Journal of Thermal Science and Engineering Applications.

Jordaan, H. et al. (2021), "Numerical Development of a Coupled One-Dimensional/Three-Dimensional Computational Fluid Dynamics Method for Thermal Analysis With Flow Maldistribution", ASME Journal of Thermal Science and Engineering Applications, Vol. 13, No. 4, Article 041017. ASME Digital Collection - full text in the University of Pretoria repository.

That is the lineage of this feature rather than a coincidence of interests. The coupling export is not a plugin bolted onto a network tool after the fact. It is the reason the network solver was built the way it was: as a pure, self-contained, auditable module with no framework around it, so that it could be ported into a CFD solver's own process and trusted there. More on the engineer behind it is on the about page.

How the embedded solver is verified

Trust with a CFD audience is mostly about provenance, so here is the actual chain.

• The Java kernel reproduces the app's own solver. It is validated against the pinned verification problem set the app itself is tested on, plus extra pump-curve fixtures, with the expected values generated by the app's solver and read as data by the Java side, never re-derived. Twenty cases at the time of writing. The agreement is at the level of floating-point noise: maximum flow error of order 1e-14, maximum head error of order 1e-13 m, and the friction factor identical.
• It cannot silently drift. The reference file is committed, and a test in the build fails if it no longer matches a fresh solve from the current app solver. If the solver changes and the kernel is not regenerated, the build goes red.
• The thermal side is validated the same way, against its own generated reference, including the recirculating and near-adiabatic cases that are the usual places a thermal transport implementation goes quietly wrong.
• The generated macro is checked end to end. A macro built by the real export pipeline from a fixture network is compiled every time, so the export produces real, compilable Java rather than plausible-looking text.
• The coupling loop is exercised as a fixed point. It is run in-process against a CFD surrogate with the real kernel behind it, and converges to a consistent operating point from both port directions.

The wider solver verification, including the published references each case is checked against, is on the verification page, and the numerical formulation is described in how it works.

What it does not do

This is a young feature with a deliberately narrow fence, and the honest version is more useful to you than the flattering one.

• Incompressible liquids only. The export refuses a gas network rather than approximating one. Compressible coupling is not in this version.
• No fans or compressors in the coupled network, for the same reason. Pumps are supported.
• One CFD domain per network. A box can carry many ports, but the export supports exactly one box. Two separate CFD regions in one network is not supported.
• STAR-CCM+ only. A Fluent C UDF is planned and not shipped. If Fluent is what you run, that is a real gap today, and worth telling us about.
• Steady coupling. The embedded solve is the steady network solve. The Studio's time-simulation mode does not export to CFD.
• Constant fluid properties in the thermal path, as described above.
• No wall-only or porous-zone thermal coupling. The current coupling connects at named inlet and outlet boundaries where the two fluids share a flow boundary. Coupling that exchanges only heat, across a wall or through a tube bundle as a porous zone, is a concept we are exploring and not something you can buy today.
• No claimed certification against any STAR-CCM+ version. The macro is written against the STAR-CCM+ Java macro API and cross-checked call by call against a recorded-macro reference. Where a name could not be confirmed from that reference it is isolated in one place and resolved live by the preflight, before anything is written. If your version spells something differently, the preflight reports it and stops rather than guessing.
• Two things are confirmed on your first real run, not by us: the boundary sign convention on your specific case, and that the reference-pressure datum matches the box elevation. The macro guards both. A diverging imposed value stops the run with a message pointing at the sign convention, and the preflight prints the datum as a reminder. Neither can be settled headlessly, which is exactly why the feature is marked Beta.

As with everything else in the tool, the coupling supports your engineering judgement rather than replacing it, and results should be reviewed by a qualified engineer before they are relied upon.

Who this is for

Engineers who already run STAR-CCM+ and already have a system around the model. Thermal-hydraulic analysts sizing headers and manifolds where the distribution is the answer. People doing conjugate work on heat exchangers, coolers and jackets, where the coolant circuit outside the CFD domain sets what the CFD domain sees. Anyone who has run the guess-run-correct-repeat loop by hand and did not enjoy it.

If your network never touches a 3D model, ignore this page. The rest of the tool is a complete network solver in its own right, and the free tier covers liquid analysis without any of this.

Frequently asked questions

What is 1D-3D CFD coupling?

It is the practice of solving a one-dimensional pipe network and a three-dimensional CFD model together, so that each one supplies the other's boundary conditions instead of both being guessed. The 3D model resolves the piece that needs resolving, the 1D network carries the rest of the system, and the two are iterated until the flows, pressures and temperatures they exchange are consistent.

What does Fluid Network Studio actually export?

One self-contained STAR-CCM+ Java macro file, hns_coupling.java. It contains a setup checklist written for your network, a validated Java port of the app's incompressible network solver, your network as a data block, and the coupling loop with its read-only preflight. There is nothing else to install.

Does Fluid Network Studio have to be running during the CFD solve?

No. The macro is self-contained. The solver is compiled into it, so there is no live link between applications, no seat consumed and no process to keep alive. This is the main difference from coupling approaches where a system-simulation tool must run alongside the CFD solver.

Does it work in parallel or on a cluster?

It is safe by construction for parallel runs. The only values crossing a partition boundary are reports, which the CFD solver reduces globally before the macro reads them, and boundary values, which it distributes globally. The network kernel runs once on the controller, with no partition-local field access and no threads of its own.

Can it exchange temperature as well as flow?

Yes, when heat transfer is on in the Studio. A pressure-outlet port reads its boundary temperature as the network supply temperature, a mass-flow inlet has the network's computed temperature imposed on it, and each embedded solve becomes a coupled thermal-hydraulic solve. Temperature is absolute kelvin, and the exported thermal model uses constant fluid properties.

What happens if my simulation is not set up correctly?

The macro runs a read-only preflight before it couples anything. It checks each boundary exists, is the right type and can be driven, that each named report is present and readable, and that the embedded network solves. On a failure it prints exactly what is missing and stops without changing a single boundary. Fix the items and play it again.

Which CFD codes are supported?

STAR-CCM+ today. A Fluent C UDF is planned and not released. No other code is supported.

What does it cost?

The CFD coupling export is part of the Advanced plan, A$39 a month or A$390 a year. Building the network, drawing the CFD domain and solving liquids are free, so you can lay out the whole coupling and see what it would export before paying anything.

References

• Jordaan, H. et al. (2021), "Numerical Development of a Coupled One-Dimensional/Three-Dimensional Computational Fluid Dynamics Method for Thermal Analysis With Flow Maldistribution", ASME Journal of Thermal Science and Engineering Applications, Vol. 13, No. 4, Article 041017. The peer-reviewed method behind this feature. ASME, full text
• Todini, E. and Pilati, S. (1988), "A gradient algorithm for the analysis of pipe networks", in Computer Applications in Water Supply, Volume 1: Systems Analysis and Simulation, John Wiley and Sons. The global gradient formulation the embedded kernel solves with.
• Churchill, S. W. (1977), "Friction-factor equation spans all fluid-flow regimes", Chemical Engineering. The friction correlation used across laminar and turbulent flow, in the app and in the exported kernel alike.
• Crane Co., Technical Paper No. 410: Flow of Fluids Through Valves, Fittings and Pipe, for the fitting loss coefficients carried into the export. tp410.com

Try the coupling on your own model

Open the Studio, build the network around your CFD region, turn on CFD coupling in the Model tab, and drop in a CFD domain. Wire your pipes to it, name the boundaries and reports the way your simulation spells them, and export. The checklist at the top of the file tells you what to build next, and the preflight tells you whether you built it correctly.

Open the Studio and set up a coupling. The export is part of the Advanced plan, A$39 a month or A$390 a year, and everything up to the export is free.