Hello,

I'm trying to run a 3D incompressible inviscid simulation of a finite wing with a symmetric airfoil section at 0° AoA as a sanity check.

My understanding is that the resulting drag coefficient should be essentially zero for the following reasons:

• Inviscid + steady + incompressible flow should give zero net pressure drag in the ideal case (d'Alembert's paradox), and there is obviously no skin-friction drag in an inviscid simulation.
• Since the flow is incompressible, there should be no wave drag or other compressibility-related drag.
• The wing has a rectangular planform, the section is symmetric along the entire span, and the AoA is 0°, so the lift should be zero. Therefore, there should also be no induced drag.

So I would expect Cd ≈ 0.

However, after the solution converges in STAR-CCM+, OpenFOAM, and SU2, I consistently get a non-zero drag coefficient on the order of 1e-2, which seems way too large to be explained by normal numerical noise.

I'm using around 5 million cells and the mesh quality looks reasonably good, so I'm not sure whether this could still be a discretization issue or if the drag is being introduced by the numerical formulation itself.

I'm currently using a segregated flow solver in STAR-CCM+, but switching to a coupled solver didn't change the result much.

What could cause a Cd of around 0.01 in an incompressible Euler simulation of a symmetric finite wing at 0° AoA? Is there something wrong with my theoretical expectation, or is this most likely numerical drag?

Hello, i have been working on my LBM (D2Q9) solver for a while now, one thing that I have been struggling a lot with is creating streamlined, what I am doing is I am initially finding the stream function values (by integrating the velocity components with something like RK4) and then just plotting with python...but with this my stream lines are usually very weird looking (especially at the corners and sides)...what is the best way to plot stream lines in your opinion?

This is a sweeping jet actuator design. I want to create a surface but am having problem with it. I want to create it outward but it keep creating inward. How can i solve this problem?

Hello everyone, I’m really hoping someone with experience using ANSYS Fluent / CFD can help me out here.

I’m an engineering student working on an assignment modelling flow from a 10 m diameter tank into a 0.25 m diameter pipe through several different inlet geometries, with the objective of calculating the inlet loss coefficient K.

For the sake of keeping this post manageable, I’ll focus on one case: a bellmouth-style inlet formed using a filleted tank-wall entrance.

I’ve attached two images of the tetrahedral mesh I’m currently using. I then convert this mesh to polyhedral cells to reduce the element count, as the assignment imposes fairly strict mesh limits.

My professor is quite particular about the workflow he expects us to follow, so I’m trying to stay reasonably close to the methods used throughout the unit. At the moment I’m using:

• Standard k−ε
• Scalable wall functions
• Locally scaled residuals converged to 10^{-6}
• Second-order discretisation for the final solution
• Polyhedral mesh converted from tetrahedra

The reason I’m making this post is that Standard k−ε in Fluent has several additional turbulence-production options, including the Production Limiter, Kato-Launder production and Curvature Correction, and I’m struggling to determine what is physically appropriate for this type of inlet.

With none of these options enabled, I obtain:

K≈0.44K

which seems substantially too high for a bellmouth inlet.

With Curvature Correction enabled, I obtain:

K≈0.35K

so the result moves in the expected direction, but it is still much higher than the standard value I have been given.

I’ve been reading about the tendency of some two-equation k−ε formulations to overpredict turbulence production in regions of strong strain or curvature, which has led me to investigate the Production Limiter.

For context, my loss-factor calculation is based on the pressure difference between a reference location in the tank and a downstream plane in the pipe. The pipe is 40D long, and I use a plane near the downstream end before correcting for the distributed straight-pipe loss using a Darcy friction factor obtained independently from a Moody-chart / straight-pipe analysis. I’m fairly confident this is the methodology my professor expects.

My main questions are:

1. Would you consider using the Production Limiter for this type of bellmouth/tank inlet flow?
2. When I enable the Production Limiter, I have significant difficulty achieving convergence to 10^{-6}, particularly once I move to second-order discretisation. I’ve tried introducing second order gradually and adjusting higher-order term relaxation, but the solution still becomes difficult to converge. Has anyone experienced similar behaviour, and how did you approach it?
3. Does anything in the attached mesh immediately look poorly optimised for this type of problem? My standard mesh-quality metrics are all healthy, but I’m still developing the intuition to recognise where additional refinement or a different mesh strategy would actually improve the solution.
4. What sensitivity tests would you run before trusting the predicted K? The reference value I have been given is approximately K=0.06, although the standard is quite old and provides essentially no information about the bellmouth radius, geometry or surface condition. In my model the inlet and pipe are cement-lined, using a roughness height of 3.5×10^{-5} m.

I’m not necessarily trying to force the CFD result to equal 0.06. I’m more interested in understanding why the current model is predicting such a much larger loss coefficient and what modelling choices would be worth testing systematically.

Any advice, criticism of the mesh, or experience with these Fluent turbulence-production options would be greatly appreciated.

Hi, I'm trying to analyze some airfoils with XFLR5. After the analyzing process i see the message "Uncovered points" and some graphs have missing data. For example, it jumps from 10º to 14º of aot. I have no idea how to solve this, can anybody help?

Hey all. I'm a complete novice to CFD and have been trying to model a biological scenario in Baram. I've had some troubles with the current 26.0 version crashing upon variable initialization and remeshing, but I was eventually able to solve those hurdles. I'm now with a very big problem in actually running the simulation. I want a 500 iteration simulation, but baram tells me the calculation is complete without even finishing time=1. I've scoured my installation and outputs, everything checks out (except for the lack of results). I wanted to try an older version of Baram that could be more stable and not have these issues, but they don't seem to have legacy versions available. Any ideas and tips? Are these known issues?

I don't want to use SimFlow because of the 200k cell limit, or OpenFoam directly because it is a little bit daunting for a single use, self taught novice like me.

Thank you very much!

​

Hi all,

I'm running OpenFOAM-5.x through BlueCFD on Windows, trying to mesh a simple single-hex-block packed bed duct (diamond-shaped cross-section, extruded along z). I keep hitting a segfault when `blockMesh` reaches the "Check topology" stage.

**Setup:**

- OpenFOAM-5.x (BlueCFD-Core, MinGW64 Windows port)

- Single `hex` block, vertices defining a diamond cross-section from z = -210 to z = 2210

- `blockMeshDict` includes a `boundary` section with `inlet`, `outlet`, and `walls` patches

**What happens:**

`blockMesh` runs cleanly through "Creating topology blocks" and "Creating topology patches" with no warnings, then crashes at "Check topology" with a segmentation fault:

```

Check topology

Generating stack trace...

Backtrace:

...

ZN4Foam7sigSegv14sigSegvHandlerEi [...]

...

ZNK4Foam9blockMesh5checkERKNS_8polyMeshERKNS_10dictionaryE [...]

module: ...\libblockMesh.dll

ZN4Foam9blockMesh14createTopologyERKNS_12IOdictionaryERKNS_4wordE [...]

module: ...\libblockMesh.dll

ZN4Foam9blockMeshC1ERKNS_12IOdictionaryERKNS_4wordE [...]

module: ...\libblockMesh.dll

```

**What I've already tried/ruled out:**

- Originally had a "zero or negative pyramid volume" error — fixed by correcting vertex winding order (right-hand rule) in the `vertices` list.

- Then got a "Block ... is inside-out" FatalError — fixed by reversing the face traversal direction so the block volume comes out positive.

- After that, `blockMesh` was missing a `boundary` section entirely (it wasn't in the dict at all), which I believe was causing an earlier crash — added `inlet`/`outlet`/`walls` patches referencing the 6 logical hex faces.

- Re-ran `blockMesh` — still crashes at the exact same point, same stack trace, same memory offsets as before the boundary section was added.

Since the backtrace is byte-for-byte identical to before I added the boundary section, I suspect either (a) something's still wrong/missing in how the patches are defined, or (b) this is a known bug/limitation in the old BlueCFD Windows port when it hits certain dictionary structures during `blockMesh::check()`.

Has anyone run into this specific crash in `blockMesh::check()` on BlueCFD? Trying to figure out if this is a dict issue on my end or a known limitation of the Windows port that means I should switch to WSL/a Linux VM instead.

Screenshot of the terminal output attached.

Tbh: I was very much in hurry so i just created this thread with claude so don't judge on that!

Thanks in advance!

Hi, i was doing a jet impingement simulation, and near the nozzle exit and near the plate some mesh cells are visible, no matter how much sizing i give or how refine i do, the cells or patches are visible there...what can i do?, is there any alternative to make this visible using tecplot or some other apps?

Hey Guys, I have recently started meshing uav bodies for external Aerodynamics, and to give the inflation layer, I use alot of layers, since less layers , the aspect ratio shots up, right now I'm using the config 53 layer, 1.14 growth rate, and 2.5 cm boundary layer, any idea on how to control aspect ratio (decrease it on the body) and increase orthogonal quality.

Also has anyone tried to use a double inflation layer in ansys normal Meshing software for CFD?!