r/CFD

I’m working on an early prototype around Ansys Fluent/Workbench, but the main reason I’m posting is not to showcase it.

I’m trying to understand what Fluent users would actually want something like this for.

The current demo is very limited and controlled, but this is what it does:

1. I press Ctrl+Shift+L and the assistant opens.

2. It has Ask mode and Execute mode.

3. I connect it to an already-open Workbench project using the StartServer() port.

4. In Ask mode, I can ask:

   - “What is the current CFD state of this project?”

   - “List the current boundary conditions and zone names.”

   - “What values do I need to set for the velocity inlets and pressure outlet?”

5. It reads the project/Fluent state through APIs and gives a CFD-oriented answer instead of just raw Workbench cell states.

6. In Execute mode, I can give a controlled one-shot prompt for a mixing elbow case:

   - set both velocity inlets

   - set the pressure outlet

   - run hybrid initialization

   - run 100 iterations

   - display a velocity magnitude contour on the symmetry plane

I’m using Workbench/Fluent APIs where possible, not trying to do everything through GUI automation.

My current hypothesis is that a lot of Fluent work is not always “hard physics” — sometimes it is knowing where to click, remembering the setup sequence, checking what state the case is in, repeating the same setup actions, cleaning/preparing geometry for meshing, and making sure the right zones/BCs are actually being used.

But I may be wrong about which part matters most.

So my question for Fluent users is:

What part of your Fluent/Workbench workflow feels most painful, repetitive, or unnecessarily manual?

For example, is it:

- cleaning CAD/geometry before meshing?

- setting up the mesh?

- figuring out zones/named selections?

- setting boundary conditions?

- checking whether the case is solve-ready?

- convergence/debugging?

- creating the right contours/reports after solving?

- something else entirely?

Also: what would you trust an assistant to do, and what would you absolutely not trust it to touch?

I’m trying to decide what the first real problem should be before I keep building.

Blunt feedback is welcome.

El campo de vorticidad en 2 interfaces con un perturbación senosoidal. No se como subir el código XD

3 weeks series free course on openFOAM!

This series gives the possibility of getting a more detailed understanding of the basics of OpenFOAM.

It can be completed in about three weeks.

▶ Week - 1
openFOAM Installation
Introduction to openFOAM
Theory & Fun simulations

▶ Week - 2
Geometry preparation & Meshing
Turbulence Modeling
Multiphase Modeling
Parallelization in openFOAM

▶ Week - 3
Programming in openFOAM

Just google, "3 weeks series openfoam" you can find it easily.

Check out this amazing series. It's free!

At the top, we have DNS, the most expensive one. It is not a turbulence model at all.

In the DNS, we solve instantaneous Navier-Stokes equations numerically without any turbulence model.

Then we have LES, which is less expensive than DNS but very often still too expensive for practical application.

In LES, large eddies are directly resolved, and smaller ones are modeled.

We put a filter that comes from a mesh resolution, above which turbulence eddies are resolved.

In RANS, we use Reynolds averaging, through which we average out all the information on turbulence.

We have to use the Turbulence Model along with the RANS equation to close the system, and it accounts for the effect of turbulence in the average flow.

That is the challenge and the art of turbulence, then.

We have the Reynolds Stress Model, which is a bit expensive but gives a more realistic picture of turbulence.

In RSM, we solve the transport equation for each of the Reynolds stress components, allowing us to capture the effect of anisotropy.

2 Equation Eddy viscosity models, the running horse of industries, are the least expensive ones where we apply the Boussinesq hypothesis.

Reynolds Stress is related to the mean velocity gradient; there is a linear relationship between stress and strain.

The wall function uses an empirical formula formulated based on experimental measurements and documented as the "Law of the Wall"

That empirical formula satisfies the log-region velocity profile.

So, you have to put the first cell centroid in the log layer.

In the second-order finite volume method, the variation across the cell for any flow variable is linear.

You are not resolving the velocity gradient as first cell placed in the log layer, but the wall shear stress must be correct.

The wall function modifies the viscosity in the cell adjacent to wall such that the product of velocity gradient and viscosity, shear stress, remains correct.

We will have wall functions computed near the wall for other flow quantities.

The thickness of the log layer plays a critical role in the selection of the wall function.

Wall Function should not be used for the flows prone to separation.

In resolved boundary layer approach, mesh up-to the viscous sub layer is resolved such that the first cell centroid lies within the viscous sublayer.

This allows direct resolution of the velocity and turbulence gradients in this thin layer, instead of relying on wall functions.

In resolved boundary layer approach, Low-Re models are often used.

Low-Re turbulence models is a modified version of a traditional turbulence model (like k-ε or k-ω).

There are additional source terms in the turbulence equations to control how turbulence is suppressed near the wall.

These extra terms or functions account the effects of viscosity near the wall.

Different models use different damping functions​ which are dependent on local Reynolds numbers and vanish near the wall to suppress turbulence there.

Convergence of "resolved boundary layer approach" can be very slow because of high aspect ratio cells near the wall and very high overall mesh count.

Image Source: "Computational Modelling of Non-Equilibrium Condensing Steam Flows In Low-Pressure Steam Turbines 0.1016/j.rineng.2019.100065 Ahmed M. Nagib Elmekawy, Mohey Eldeen H.H. Ali"

I noticed something strange from a CFD simulation that I've been trying to find an answer for and nothing seems to fully explain it.

In the picture is the Mach contour for an aerospike nozzle, which has its central plug slightly off-center, which produces a deviation in the jet (simulation is made with cold air at 4 bar at the inlet, in atmospheric conditions, gravity off).

If I measure this deviation through the forces acting on all its surfaces (using the Ansys Post force calculation tool; angle = arctan(Fy/Fx)), I get an angle of 2.1 degrees. If I measure the jet visually, as pictured, I get 5.2 degrees. A colleague measured it more "correctly" by averaging the angle of velocity for all the cells of the jet and he got a similar answer.

Where is this difference coming from? Shouldn't a momentum change in the velocity cause an opposite force at the same angle on the nozzle?

Hi everyone,

I’m working on a computer graphics course project and would really appreciate feedback from people with experience in computer graphics, CFD, SPH, adaptive meshing, adaptive mesh refinement, computational grid, irregular (organic) unstructured quadrilateral/hexagonal grid generation, or scientific visualization.

The project started from two separate interests:

1. A GPU particle-based (Lagrangian grid-free) fluid simulation in Unity, inspired by Sebastian Lague’s fluid simulation work (https://www.youtube.com/watch?v=rSKMYc1CQHE).
2. A custom organic irregular quadrilateral/hexagonal grid that I had previously built in Unity, inspired by Oskar Stålberg's Townscaper game. I'm a bit concerned about using this grid, since Oskar used it more for creativity/artistic reasons in his game, to get that organic European look for his town assets (https://x.com/OskSta/status/1147881669350891521).

More recently, I came across the paper (is it okay that it's 20+ years old?) “A Solution-Adaptive Grid Generation Scheme for Atmospheric Flow Simulations” (https://www.researchgate.net/publication/2379446_A_Solution-Adaptive_Grid_Generation_Scheme_for_Atmospheric_Flow_Simulations), which gave me the idea to combine these two directions. I am not trying to reproduce the full atmospheric solver from the paper. Instead, I’m trying to reinterpret the solution-adaptive grid-generation idea in a real-time graphics context.

My current implementation is roughly:

• A GPU particle-fluid simulation, where particles carry position, velocity, density, etc.
• A custom organic irregular quadrilateral grid.
• A regular uniform quad grid as a comparison baseline (or maybe something else?).
• A bridge that samples the fluid state and assigns an importance value to each adaptive grid cell.
• Cells are dynamically refined/coarsened based on particle count, density, velocity, or combined importance.
• The grid itself is CPU-side topology, while the fluid simulation and importance sampling are GPU-side in Unity.
• The organic grid boundary can also be used as the physical fluid collision boundary.

The part I am unsure about is the scientific meaning framing.

Since the fluid simulation is particle-based/Lagrangian, the adaptive grid is not actually solving the fluid equations directly. Instead, the grid adapts to the particle solution field. So the project is more of a hybrid particle-grid / scientific visualization / adaptive representation prototype than a traditional grid-based CFD solver.

My tentative research question is something like:

How effectively can a particle-based fluid simulation drive solution-adaptive refinement of an organic irregular quadrilateral grid in real time, and how does this compare to a regular uniform adaptive grid?

To make this project idea scientifically meaningfull I need to make the evaluation look like a research investigation, not only a demo. So basically, I need to ground this exploratory investigation idea into state-of-the-art evaluation methods for my approach. I struggle with this part as well.

I might be considering evaluating (do correct me if this seems incorrect or too much or too unnecessary):

• FPS / frame time
• adaptation time
• active cell count
• base cell count
• max refinement level
• particle count scalability
• percentage of particles covered by refined cells
• percentage of refined cells that are empty/wasted
• organic grid vs uniform grid performance and adaptive behavior
• possibly mesh-quality metrics such as aspect ratio, angle quality, or cell area variation

My doubts are:

1. Is this hybrid approach scientifically meaningful, even though the adaptive grid is not the main fluid solver?
2. Is comparing an organic irregular adaptive grid against a uniform adaptive grid a valid research-style comparison?
3. Would it be more correct to frame this as adaptive scientific visualization / adaptive spatial representation rather than CFD accuracy?
4. What evaluation metrics would make this feel like a serious graphics/scientific computing project rather than just a creative Unity demo?
5. Are there related methods or papers I should reference, especially around particle-grid coupling, adaptive mesh refinement, scientific visualization, or fluid-driven level of detail?

I would be grateful for any critique, suggestions, or warnings. I especially want to make sure I am not overclaiming what the project does. My goal is to present it honestly as a research-inspired real-time graphics prototype with a meaningful evaluation, not as a fully validated CFD solver. My interests lie more in the computational grid, spatial discretisation, computational geometry, implicit representation, shape representation, uncovering shapes, geometries, patterns, and structures in a space, and the spatial intelligence side of research, rather than physics itself.

Any help would be appreciated! Let me know if you need more info regarding this.

Thanks in advance!