← Journal

Before a CFD result approves a change, read how the run ended

· 7 min read · Written with an AI assistant

A pressure drop on a change request says nothing about how the solver reached it. Four checks for a SOLIDWORKS Flow Simulation result: converged goals, the right stopping reason, a new calculation and a mesh-independent answer.

A revised manifold goes onto a change request with one number beside it: the new pressure drop from a SOLIDWORKS Flow Simulation run. Nobody asks how the solver reached that number, and two failures hide well behind a clean figure: a run that stopped on a limit rather than converging, and a run that continued from the old setup so the change was never applied.

Now that design engineers run CFD themselves, this is a review problem, not a specialist one. Before a CFD result approves a change, check four things: the goals converged, the solver stopped for the right reason, the run was a new calculation, and the answer does not depend on the mesh.

The number needs its provenance

Take a familiar case. A hydraulic manifold has one inlet and several outlets. The change widens one cross-drilling and adds a blend where two passages meet, to cut losses at the design flow. The change request says the pressure drop has fallen and quotes the new figure.

A reviewer looking at that figure should also see:

None of this is exotic. It is the CFD equivalent of asking which load case an FEA stress came from. Without it, the figure is an assertion.

Make the acceptance value a goal

In Flow Simulation, goals do three jobs at once: they set the design objectives, they control convergence, and they finish the calculation, as the SOLIDWORKS blog on goals puts it. That makes them the natural acceptance criteria for a change. If the number on the change request is not a goal, the solver was never told it mattered.

There are five goal types: Global, Point, Surface, Volume and Equation. A Global goal is calculated across the whole computational domain, which is rarely what a port-to-port pressure drop needs. For the manifold, you want Surface goals on the inlet and outlet faces, and an Equation goal that combines them. The blog’s own example is outlet pressure minus inlet pressure to get pressure drop; the same mechanism can calculate valve Cv, heat-exchange efficiency, pump efficiency and drag coefficient.

In outline, the manifold goal set looks like this:

SG Inlet   : Surface goal, Average total pressure, inlet face
SG Outlet  : Surface goal, Average total pressure, outlet face
EG dP      : Equation goal = SG Outlet - SG Inlet

Two details matter. First, the Surface Goal dialog lets you request Min, Average, Max or Bulk Average for a parameter. Which one you pick is an engineering decision, and it should be stated beside the result, because the before and after runs must use the same one. Second, the “Use for Conv” column is ticked by default. Check that it is still ticked on the goals the change will be judged on. The blog post dates from 2015 with a later page update, so confirm dialog names against your installed version.

In steady problems, goals can end the run well before the solver’s own conservative convergence criteria would. Transient runs are different: goal values keep changing over time, so they may never converge and are normally stopped at a set physical time. For a transient study, the stopping time is the thing to review.

Read why the solver stopped

The next points come from practitioner guidance on Engineers Rule, a site sponsored by Dassault Systèmes. Treat them as an experienced user’s advice, not official documentation, and check them against your own help files.

Once goals exist, Flow Simulation adds automatic stopping criteria that end the run when the goals converge within a tolerance, which you can set by hand. The author still recommends checking convergence after the run. The tell-tale sign of a bad stop is simple: if the monitored values were still rising when the solver stopped, a secondary criterion such as an iteration limit or travel limit probably ended the run.

For the manifold, open the goal plot for EG dP. A flat tail means the number is settled. A line still climbing at the last iteration means the figure on the change request is a snapshot of a run in progress.

You do not normally need residuals for this. The same source says Flow Simulation does not need residual monitoring for typical steady or transient problems on default settings; in transient studies with nested iterations, normalised mass, momentum and energy residuals are available as extra goal plots.

The second trap is quieter. If you changed the simulation setup, you usually need a New calculation. Picking Continue calculation by mistake can mean the changes never appear in the results. Geometry changes mark the mesh as out of date, but changing only simulation parameters does not, so nothing warns you. Suppose the change also raised the design flow rate at the inlet boundary condition. Continue the old run and you may report a pressure drop at the old flow, against the new geometry, with nothing on screen to say so.

Show the answer does not depend on the mesh

Flow Simulation combines a Cartesian (octree) mesh with the immersed boundary method. The most common meshing problem the Engineers Rule author sees is cells many orders of magnitude larger than the features they must resolve. A Mesh Plot shows whether cell sizes match feature sizes. For the manifold, cut a plot through the widened drilling and the new blend. If a passage is spanned by a handful of cells, the blend you added barely exists to the solver.

The author’s rule of thumb is 10 to 15 cells across a narrow channel, with the caveat that rules like this do not replace a mesh-independence study. In a change workflow, that study can be short: run the same goals at two or three refinement levels and see whether EG dP stops moving. Solution-adaptive meshing helps here. You can set a maximum cell count and a wait time between refinements, and if goals are tracked, the run records the converged goal values at each refinement level. That record is exactly what a reviewer wants to see.

Then keep the limit in view. A mesh-independent result is not necessarily accurate. It only removes one source of error.

Converged is not validated

ASME V&V 20-2009 (reaffirmed 2021) is the ASME standard for verification and validation in CFD and heat transfer. It quantifies how accurate a solution is by comparing it with test data for a specified variable at a specified validation point, using experimental uncertainty methods for errors in both the simulation and the data.

It is just as useful for what it leaves out. V&V 20 does not cover accuracy away from the validation points, such as interpolating or extrapolating across a validation domain; ASME calls that engineering judgement. So the three claims are separate:

  1. Converged: the goals settled for the right reason.
  2. Mesh-independent: refining the mesh no longer moves the goals.
  3. Validated: the result agrees with test data at a defined point, within quantified uncertainty.

Most design-change runs reach the second claim at best. That is often enough to compare before and after, but an engineer should say so, and judge whether the new flow regime is close to anything that has been tested.

A checklist to sign before the change moves on:

What this means for CAD and engineering tooling

The lesson for tooling is that analysis output should travel with its provenance. A pressure drop pasted into a change request loses the goal definition, the stopping reason, the calculation mode and the mesh history. Each of those is available at the moment the run ends, and almost none survives the copy.

In the workflow AI-CAD is being built around, analysis is one stage between verification and drawing, and an engineer approves each decision before the change moves on. Our view is that what passes between stages should be the figure plus the evidence above, so the reviewer signs a result they can interrogate. AI-CAD is a prototype, so treat this as a design principle we are working to, not a feature to rely on.

CFD in the hands of design engineers is a good thing. It just needs the same discipline we already apply to FEA: ask how the run ended before trusting what it says. If this kind of working note is useful, follow the journal, or get in touch to tell us how your team reviews CFD results.

Sources