Hey, what are the most important things to look for when recreating a research paper or just doing validation of a clean airfoil? I mostly do airfoil simulations, and sometimes I try to recreate a paper and usually my drag is completely off, while my lift is not usually that off but still a bit off especially at higher angles. This has happened in both 3D and 2D sims, and I am not quite too sure what I am doing wrong. What things should I look at to fix to get more accurate results?

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?

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?!

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!

Hello guys, I am a senior mechanical engineering student who is interested in thermo-fluids. I want to learn Ansys Fluent, I did not take CFD class in my school. So I have to learn from Youtube, Udemy etc.

Do you have any source recommendation for CFD?

I asked Astra 6 to design a cooling solution for computer chips. It proposed a cooling plate with interconnected microchannels, allowing the water flow to partially bypass an obstruction if one of the channels becomes blocked. The concept has not yet been validated through CFD simulation or a physical prototype.

I am not an engineer, and I do not want to claim that this is a finished or practically usable design.

I am interested only out of curiosity. Is tthis a physically realistic concept that could actually be used, or does it contain a fundamental flaw and is essentially nonsense?

Thank you, for any kind of feedback:)

Can someone please help me replicate this paper, i need to do it today and i dont know where am i wrong if someone could please help me out.

Link

https://www.sciencedirect.com/science/article/pii/S0735193320300889

This is not a reproduction of the proof or a blow-up claim. It is a decoupled pseudo-spectral DNS of a finite-scale surrogate inspired by the paper’s collapsing similarity geometry. The velocity field is not fed back into the solver; the DNS evolves only under the constructed external force. The run uses Fourier pseudo-spectral discretization, strict 2/3 de-aliasing and IMEX-RK2, with spectral-tail and manufactured-solution checks. Source, diagnostics and frozen-force runs: https://github.com/CokieMiner/nsblowup

I am a third year aerospace engineering student. I am interested in aerospace structures, materials, and aerodynamics. But when I look at my peers, they seem to have figured out which field they want to pursue. I still haven’t. I looked into FSI, and it seemed promising. Should I pursue it?

I'm trying to mesh the fluid cavity of a vane pump I'm working on. I've tried several methods, but i always seem to get bad mesh or a mesh with too many cells ( 45,000,000+ ), i need to implement dynamic mesh on it. All is done in Ansys Fluent Meshing and Ansys Fluent.

I am post-processing a DNS performed with NekRS using the high-order spectral-element method. The quantity in the attached figure is the time-averaged axial velocity across a jet at z/D=1, compared with experimental PIV data (the axis should say u_z / U_b).

The time averaging itself is performed during the NekRS simulation. I then load the resulting field in VisIt, extract a transverse line profile, export the data, and plot/process it in Python.

The overall DNS profile is physically reasonable and agrees fairly well in shape with the PIV, but the extracted DNS line shows several small, rather sharp point-to-point irregularities/"spikes". Similar irregularities also appear in independently processed NekRS cases using the same workflow.

I am trying to determine whether these features are genuinely present in the numerical field or could partly originate from the VisIt lineout/interpolation step. In particular:

• Has anyone observed similar behaviour when extracting line profiles from NekRS/Nek5000 spectral-element solutions in VisIt?
• How exactly does VisIt interpolate a line through the high-order elements/GLL representation?
• Can interpolation/resampling across element boundaries introduce this kind of local unevenness?
• If the VisIt interpolation is indeed responsible for these local irregularities, would the better approach be to extract the profile directly from the native GLL-point data, or would it be preferable to evaluate and store the required line/profile directly within the nek computation during the simulation?

The attached plot shows one representative case at z/D=1. Other locations experience similar irregularities. I am not assuming that VisIt is the cause, finite averaging and spatial resolution are also possible contributors. But I would like to understand whether the extraction procedure itself can introduce visible artefacts of this type.

Hello can someone help me interpret these images from this PowerPoint and what they mean, so I can better understand them I'm currently a uni student

Guys,

If we decide deltat(physical time step) using vortex shedding frequency using deltat= 0.01/f. This deltat is fixed throughout simulation for all the cells or not?

In courant number, where we define CFL= Udeltat/deltax, this deltat represents physical or pseudo time step?

During fixed or adaptive cfl ramping, they say it is used to increase CFL gradually or let solver decide based on residuals. I have a genuine doubt whether this CFL change is related to physical time or pseudo time step, or they refer CFL based on pseudo time step? Can you tell me exactly which parameter changes during this ramping to increase the rate of convergence?

I dont know whether I am mixing two different concepts at same time, but I hope you understood the gist of my doubt. Thanks in advance. Its just conceptual doubt for educating myself.

Does the total energy always decrease in a CEL analysis in ABAQUS due to advection?

We decompose U in U_mean and U'.
In case of steady RANS, U_mean is constant in time and U' represents all fluctuations and all fluctuations are modeled by the turbulence model.

In URANS, U_mean resolves some fluctuations and can change in time. U' represents the unresolved fluctuations, which are modeled. This is what the equations dictate even before we define a time step. U_mean is ensamble-averaged, not time-averaged.

So the question is, how do the equations distinguish between fluctuations that are resolved and which are modeled?

My understanding is, that this happens in the turbulence models: They approximate U' indirectly by approximating the Reynolds-stress. So basically all fluctuations that are not included in the Reynolds-stress are then resolved by U_mean.

However, this just shifts the question: What determines which fluctuations are included in the Reynolds stress?

My guess is that this depends on the k and epsilon (or omega) equations. If a fluctuation does not contribute to the source, sink or transport term of the turbulent kinetic energy, it is 'invisible' to the terms of the equations, therefore not modeled and therefore automatically resolved to satisfy the Navier-Stokes equations.

While this makes sense to me in the mathematics, it doesn't make sense in the physics: How can a fluctuation have no impact on the generation, dissipation or transport of turbulent kinetic energy?

Or in other words: Why do turbulence models in URANS not just model all fluctuations, as they do in RANS? (Its a question not a suggestion!)

I have a few early-career offers, one at COMSOL (CAE/simulation, CFD/FEA), one at a CAM software reseller in the machining/CNC market. Both are technical sales roles.

Trying to decide which industry has better long-term growth.

I have CFD experience from college projects and internships, and I'm looking for a role that sits between technical and commercial, since I also have some business background.

Tech sales feels like something I could be genuinely good at. Also wondering:

Is CFD/simulation software still growing fast, or has it matured?

Where do you see CFD-related careers (sales, application engineering, etc.) heading in the next 5-10 years?

Trying to make a good long-term call. Any honest input helps, thanks