I can't say for certain what you're like, but I know I'm very logical, methodical and structured in my thoughts but equally find myself falling into the abyss of philosophy and abstract thinking.

I guess, over my 18+ year professional career this has helped me more times than I care to think.

Being empathetic and human-aware has given many Engineers an edge throughout history.

We often start with a product specification.

Structured. Compartmentalised. Ordered.

We then address each part of the design, step-by-step, ticking off the boxes as we go.

Design. Tolerances, Fit. Finish.

We consider the failure modes, often only at obvious and predictable points.

Check. Check. And Check ✅ .

…

And it's no different when developing digital software products or any kind for that matter.

As intellectuals, we tend to lean on our structured, logical thinking and reason all that we can.

Yet, our products are being designed for humans.

Human nature is at play.

This is the intellectual trap we fall into, just like the Engineers of the past faced.

Being aware of this is the first step to addressing it.

One way of thinking that I've found to be practically useful is to consider yourself as a channel for new ideas, but with a complete openness to failure with a humble stance to learn more about what you're trying to release into the world.

In other words we should be passionate about what we're building but know we don't have all the answers to any given problem.

Some of it is held squarely in the mind of the end-user.

And they too won't always tell you what you should build or where it can be improved.

Welcome to human nature.

This is the ultimate responsibility we hold as Engineers today.

See you soon. 👋

Nasser

Title image source: “https://www.technologyreview.com/2007/03/01/226479/engineering-the-brain/amp/”

Most Engineers don’t share their specific workflow - I mean the little details that make all the difference.

Some go on to become really good at their job, but in my experience, only a few actually build repeatable frameworks and workflows for what they do.

Most absorb the skills from a mentor or go on autopilot.
That was me too…for years!

But I was following a workflow - I just hadn’t consciously and physically written it down!

In industry it makes all the difference to the output and quality of the work.

Here’s how every new CFD study should ideally be planned out:

Defining the [Engineering] objective

Building the physics concept

Planning the simulation itself

Checking available resources

Considering the risks

Documenting the plan

Together, these components of the workflow lead to a well-designed and orchestrated simulation study.

Here it is in one, clear and easy-to-reference info-graphic.

Something like this acts like a post-it note, reminding me what’s important and keeping me focused on the outcome.

And this is what really matters when it comes to Engineering work.

I’ve also hosted other frameworks on my “Resources” page of my website.
Take a look here: https://nasserm.com/resources/

I hope you study these and put it into practice.

See you soon. 👋
Nasser

This post is part of a series, demonstrating a practical investigation using OpenFOAM for CFD simulation and analyses.

If you missed the previous posts, take a look here:

We have a mock Air Inlet Manifold here with a single inlet and four outlets, symmetric in design.

I want to extract the pressure drop and mass flow rate across the runners.

Why? Well, these give us an indication on how well the flow is being distributed to the four outlets that would actually be feeding a 4-cylinder engine.

If we excuse the blocky design for now (I’ll do a more realistic one in the future), the goal is to get you to understand how to do things with OpenFOAM and, more importantly, why it’s done this way.

Taking a section through the 3D field.

You can look at these slices as 2D cuts within the larger 3D field.

This is also known as “spatial” data - specifically velocity in x, y and z.

The values at each cell face are calculated by the solver and is displayed at a given time step (smoothed if you selected the ‘cell-to-point filtered data’ option in ParaView).

And the time it take to cut this and manipulate it is incredibly fast thanks to the great tools, algorithms and modern computers.

Sometimes we forget how good we have it..!

I need to zone in on a single runner.

What we currently have is the field distribution.
And we can see:

• The pressure gradients

• The velocity magnitude and direction

• The non-uniformity in the flow

But we need to drill down into one outlet and extract the pressure values from that to get what we need in order calculate the mass flow rate.

To do this OpenFOAM provides Function Objects (Utilities that make your life easier!).
And there’s literally 100’s of them!

I created a bounded clipped plane using a function object (this is just a visual extraction of the mesh cells in vtp format).

To really isolate it, you need to define a ‘bounds’ value, restricting the cut plane to an X and Y extent of the runner surface…

Extracting the field values.

We need the average pressures and mass flow rates at each runner to ultimately calculate the percentage of flow running through each (the flow distribution).

I used the surfaceFieldValue functionObject to define a plane (see usage help in the docs for setup: https://doc.openfoam.com/2606/tools/post-processing/function-objects/field/surfaceFieldValue/).

The naming of each function object makes general sense and crawling the documentation becomes so much easier when you have this focus on what you want from it.

Remember, OpenFOAM is really a toolkit.
I like to think of it as generalised commercial software broken into pieces, so we can use only what we need at any given time.

That’s it for Part 1.
I’ll follow up on this soon and turn this raw data into useful calculated values.

If these posts save you time in trial and error, becoming a paid subscriber helps me spend more of my time running these investigations and sharing the results with you. I provide them with my insights and additional resources that help get you build your own skills faster with complete clarity.

Get access to the exact template with functionObjects I’ve setup to use on your own cases below and save time!

See you soon. 👋
Nasser

And of what you find, most isn’t that helpful…

• Some are showing their age

• Some are difficult to understand / decipher

• Some are simply AI-generated slop

I went out there to gather the best, a few less-known but helpful resources you can use in addition to the information I’ve been sharing in my newsletter.

Forums

CFDOnline

An active place for many users of OpenFOAM with no question too silly! Thousands of members and one of the earliest places for CFD discussions. A great place to hang out and ask questions, with boards organised by CFD workflow (pre, solve, post etc.).

Link: https://www.cfd-online.com/Forums/openfoam/

OpenFOAM subreddit

Lively place with over 6000 active members. Most people seem to be asking for help here and they quickly get answered. Definitely worth a look!

https://www.reddit.com/r/OpenFOAM/

Presentations

engsys slides on snappyHexMesh (for meshing)

Whilst it’s a little old, it’s definitely a great resource - often cited internet-wide for a reason. Lots of good detail on snappyHexMesh still very relevant to how the meshing utility works.

Link: https://openfoamwiki.net/images/f/f0/Final-AndrewJacksonSlidesOFW7.pdf

IAEA intro to OpenFOAM

An interesting read for beginners to OpenFOAM - general notes on modelling a problem, the structure of cases and getting started. Useful.

Link: https://indico.ictp.it/event/10199/session/1/contribution/4/material/slides/0.pdf

Books

Notes on Computational Fluid Dynamics

This is basically the official book from the creators of OpenFOAM (CFD Direct). It’s well detailed, explained but can get quite math-heavy for complete beginners. Great for solver developers and those curious on the inner workings though! Available as a free download or book on Amazon.

Link: https://doc.cfd.direct/notes/cfd-general-principles/introduction

Mathematics, Numerics, Derivations and OpenFOAM

An interesting book by a passionate community contributor. Again, can be a little math-heavy for beginners but great insights to be had! This guy has customised solvers and even has a utility or two for specific physics modelling.

Link: https://holzmann-cfd.com/community/publications/mathematics-numerics-derivations-and-openfoam

Videos

József Nagy

Great set of videos with great clarity for beginners. He even made a video explaining OpenFOAM through Pizza! Fun and enjoyable to watch.

Link: https://www.youtube.com/channel/UCjdgpuxuAxH9BqheyE82Vvw

Wolf Dynamics World

Great set of videos with a consistent quality, making watching a learning about OpenFOAM enjoyable. I learnt a great deal from here, but it did need some patience and clarifying at times.

Link: https://www.youtube.com/@wolfdynamicsCFD/videos

Websites

CFDEngine by Robin

A site with interesting posts, no longer active but useful as insights on some key OpenFOAM utilities and workings. Shame it stopped.

Link: https://cfdengine.com/newsletter/

CFD University by Tom-Robin Teschner

A great site with lots of detailed articles from a CFD solver developer! Definitely an understated resource to understanding how solvers work.

Link: https://cfd.university/blog

WolfDynamics

These guys have been around for a long time with a popular YouTube channel too. Very detailed information can be found in their resources. Just don’t get lost in all of it - use what you need depending on what you’re learning to do.

Link: https://www.wolfdynamics.com/tutorials.html

The OpenFOAM Journal

I only came across this one late last year and it features published papers that only use OpenFOAM as the tool for investigations! Pure gold if you ask me when it comes to validated results!

Link: https://journal.openfoam.com/index.php/ofj/index

The source code itself!

I wrote this a few months ago and it got very popular with over 700 hits in a weekend!

Weekly poll:

See you soon. 👋
Nasser

Mesmerising isn’t it?

It’s not the animation but the changes in the fields over the time steps…
It can almost put me in a trance!

Imagine what this would look like if the geometry was a lot smoother, refined and with a higher-density mesh…

And this is often the reason it’s so easy to get carried away with the simulation results.

I’ve learnt from experience that CFD solvers are great at producing plausible results if setup with a little effort.

And I thought I’d pause and write this up, highlighting the issues at this stage for other Engineers following along.

What was observed:

• A strong central jet forming and separating into the two immediate runners

The model used was Laminar with an Upwind scheme for increased stability.

This was expected, so to speak.

Features that are not so good (and not immediately visible):

• The flow is being spread artificially - the Upwind scheme is first-order (stable but not so accurate).

• The outer runners are starved from air - not great as an engine manifold (but good for an academic-style CFD investigation.

• The flow regime for the physics is actually turbulent (Re ~13000).

Over the next few weeks I’m planning to improve this particular study and share the details with you right here.

The reality of running simulations

This goes beyond OpenFOAM.

It’s about running simulations in general.

As mentioned, I’m an experienced Engineer and I’ve always been skeptical of taking things at face-value. I take cause and effect quite literally!

I can’t get myself to trust pretty pictures.

But I can increase the trust in the results by following specific, objective steps that removes the subjectivity from the investigation, naturally boosting my confidence in it.

Physics solvers and computers are capable - very capable, regardless of the inherent errors they display.

No one can dispute the utility in the valuable insights they provide, especially an Engineer that has used them to directly optimise products designed for the real world.

Engineering discipline with a verification and validation mindset needs to be top-of-mind if we want to continue using simulation tools as part of the modern development process.

I share this because I believe tools should be assistive to the Engineer and not used as crutches, casually or carelessly.

See you soon. 👋
Nasser

This is just WEIRD.

In simulation terms it’s known as result divergence - or the onset of a simulation “explosion”. In fact, the velocity readings went higher and higher as the iterations went on, confirming this!

It’s really frustrating.
And if you’ve ever spent time preparing the model, setting up the OpenFOAM solver and biting your nails waiting for the run to finish, you’ll know exactly what I mean.

Well, just know that It’s unlikely to be your computer misbehaving or you just having a bad day.

The very first thing you should do is double-check your boundary conditions - do they make physical sense?

I’ve written about this before so take a look at that post to set them up correctly in OpenFOAM:

Once you’ve made sure they’re realistic and plausible, keep reading on.

Trouble-shooting the issue

The case I’m simulating here is of an Air Intake Manifold.

In terms of the geometry, I have a single Inlet pipe going into a “plenum” chamber which then feeds into four, equally-positioned outlets.

The air is set to 5m/s going in to the main chamber and departing from each outlet.
We can investigate a number of metrics here.

An Air Intake Manifold typically feeds the individual cylinders of an Engine with air, in the required amount and at the right time of the combustion cycle.

I chose to look at air flow distribution to the outlets and whether it was equally distributed. Even without measuring the actual mass flow rate / percentage, you should be able to visually appreciate the results above are incorrect.

In other words, we should expect the fundamental (and intuitive) flow behaviour to be exhibited with such a symmetric and simple setup.

Struggling to setup a clean case in OpenFOAM? Check out my manual I wrote to guide you:

Improved, stable results

Having dug around the documentation, code and other resources, I’ve come to the following solver settings that allow you to get your simulation running correctly if you’re seeing a similar result in your case.

It’s just incredibly time-consuming and quite challenging to get right, especially if you’re starting out with this tool.

Let me save you time and frustration.

Access my stable solver settings and case files below:

Read more

That’s more than 3 times where I started a little over 13 years.

Now, depending on where you live in the world and the specific Engineering Design company you work for, this is either incredible or not so impressive (I’m betting unlikely the latter).

The reason I’m sharing this is because I want to highlight some key things I learnt that allowed me to make exponential gains in my compensation, but also in my technical and professional confidence as I progressed from Junior to Senior Design Engineer.

I found that most Engineers working in the Engineering industry settle for where they are and what they’ve been offered.

I’m living proof that your Engineering knowledge and technical skills can compound in your favour as well at the industry you’re part of.

Real information / data beats assumption

As Engineers, we think we’re super-smart.

In fact, we are when it comes to the specific “wedge” of the industry or tools we use day-to-day.

But it’s completely false when you zoom out (even a little).

Around 2013, a few years into my professional career, plastic parts I designed were made in low-volume.

When it was time to assemble it, they didn’t physically fit together.
And I had the mold guy on the phone…

“You didn’t take material shrinkage into account!”.

This was more than embarrassing - it was painful for me as I thought I was getting better and had started in a new role a few months prior.

Two years later something similar happened elsewhere at another company, this time with CNC-machined parts.

It wasn’t the CAD tools.
It wasn’t a poor simulation.

It was me working with data I assumed to be correct.

My framework to get it right first-time was born.
I started asking these 6 questions:

1. Who assembles this?

2. Who manufactures this?

3. Who services this?

4. Who tests it?

5. What don’t I know yet?

6. Can I contact the fabricator / machinist / molder (internal / external) to understand more about the process and get some hints?

Now I was humble in my approach, not ego-driven thinking I knew what I had to know.

Simulation is evidence, not proof

This is a big one.

I’ve used CFD to assess race car wing designs, fluid flows inside water pipes and cooling efficiency in of aluminum heat sink designs.

I’ve used FEA to assess whether CCTV brackets will withstand typical wind forces in the London Underground and whether a Taxi roof will withstand the load of a digital advertising box.

I’ve used DEM to assess how granular materials flow along chutes and tumble around in drums, analysing the wall material wear along the way.

The tools were incredible, but they were also easy to get carried away with.

I believed the results far too quickly and often took it as proof that the design is will perform detailed in my reports.

Big mistake.

The results were only indicative. In other words, it’s all theoretical and only as good as the model.

That’s not to say they aren’t useful, but it’s to highlight my approach needed to change.

Ever since I ran into issues downstream, I defaulted to the following process:

I had to reprogram my mind and default to being a problem-solver first.
That's when these tools actually enhanced me as an Engineer.

Build workflows

I touched on this in the past in my LinkedIn posts and here in the newsletter.

Take a look at an earlier post of mine (it’s referring to OpenFOAM software, but there’s a lot of general principles and details on workflows in there):

In short, a workflow is about repeatability, confidence and delivering quality at scale.

If I found something that felt cumbersome, disjointed or simply frustrating, I’d be taking notes to document the painful steps.

I’d then take this document and simplify the process before trying to automate it with code or otherwise.

Put yourself forward. Get better at communicating.

Looking back, I wasn’t promoted because I became better at CAD, CFD or any other specific tool.

Whilst this naturally improved overtime, especially having become an independent consultant a few years in, I became more valuable as an Engineer because I became better at making engineering decisions - and voicing them.

Communication is not just about standing up in a Design Review meeting and sharing your design innovations or simulation results with the rest of the team.

It’s about building a mindset that creates a reputation around the office, with your peers.

Some tips:

• Keep a physical journal - jot down any thoughts, design issues or questions you have as you work

• Setup regular meetings with colleagues and managers for informal chats

• Request feedback for any ideas once you have something to show

• Aim to build a reputation that gets people saying “He / She is a good Engineer - always opinionated, thoughtful, considerate and generates practical ideas. Oh and he / she is incredible with the tools”.

Let your reputation carry you forward into rooms you wouldn’t have thought you had previously belonged.

This is how Engineering companies grow at large - there’s always an Engineer which is called upon / truly earns the ‘Senior’ title (and gets paid for it too).

If you understand this and put it into practice, you’ll be ahead of most Engineers.

See you soon 👋
Nasser

You’ve got all the detail you could ever want but before you can simulate any kind of physics, it needs to be carefully reduced in complexity, regardless of whether you have integrated simulation capabilities or not.

There’s often a lot of friction here in many respects - I used to become really anxious at times as an Engineer responsible for this “clean-up” process.

You have colleagues waiting on you expecting it to be a clean, ready-to-use model, Managers expecting you to avoid delaying development and Customers / Clients wanting to make grounded decisions fast.

And I’ve had to think deep and hard about this workflow throughout my career as a Senior Mechanical Engineer - often without a good answer to the problem.

The issue is partly due to the discontinuity between the tools, file formats, technical capabilities and poor communication.

What a CAD model really is…

Years ago I was a young, budding Engineer without a clue. At University, I got introduced to the Engineering tool “stack” - CAD, CFD, FEA etc.

At that time I saw everything at face value - CAD was for modelling the design, FEA virtually tested the structural strength / loads and CFD was there to investigate how the fluid behaves through or around the design.

I was right…but mostly wrong.

After more than a decade in industry as a Senior Engineer, I’ve come to the conclusion that a CAD model is really a single source of truth for most Engineers and Teams. A CAD model:

• Is used to capture design intent

• Is used to describe the physical shape, size and dimensions

• Is used to describe manufacturing details needed

• Often contains META data for use by other Engineers, Clients and even Marketing

But a CAD model in itself is just geometry and practically useless when it comes to simulation after it meets all of the above.

CFD tools like OpenFOAM expect watertight, triangulated geometry with labelled face regions before you can apply the all important boundary conditions to them.

The frustrations of dealing with this humble you over the years.

“Nasser, how much detail do I need to keep?”

I got questions like this throughout my career and the truth is it’s not always straight-forward but there is a method and workflow that makes it far easier.

And it all depends on the complexity of the design and what you hope to extract from your CFD simulation results.

An understanding of the meshing and simulation process helps to build an intuition for these things too.

With that said, stripping away model details without a careful and diligent workflow with this in mind will risk large amounts of wasted time, errors, mistakes and frustrations, affecting the downstream simulation setup and solve processes.

A clear framework that stopped me guessing…

The most challenging environment for an Engineer is industry.

It’s messy, you’re up against tight deadlines, communication is poor and nothing quite works. Iterations become your teacher.

I’ve spent my working career (16+ years) modelling, editing and deleting all kinds of features from all kinds of CAD models destined for simulation internally or using external consultants.

I’ve built a personal framework to remove the guesswork from this process and can now confidently prepare any model, regardless of complexity, for CFD simulation.

It has served me consistently and now you can use it too to save you time and frustration!
Access down below:

Read more

Engineering is:
more than the 3D CAD model.
more than a pressure plot from CFD analysis.
more than the interim solutions, part failures and team squabbles.

I remember when I was a graduating from University with a Degree in Mechanical Engineering back in 2008, how naive my ideas of industry were.

And no, Academia didn’t prepare me for the industry - how an Engineering business works, the departmental / operational dependencies nor the workflows you need in place to get the most out of the tools.

Maybe that’s why I found myself gravitating towards the processes and workflows we tend to follow, over the last few years of consulting.

Since Engineering is full of software tools, it’s the obvious place to improve and create more workflow-focused tools that can actually improve the development experience and end-products you create as an Engineering business.

In the 9+ companies I was contracting and consulting at in the UK, I noticed flaws in communication, the systems around me and the workflows the team defaulted to.

“I was only an “Engineer” though - what did I know about the business of Engineering?” Or so I thought…

But then, I was an “outsider” to some degree - an external consultant / contractor, not part of the salaried payroll.

This allowed me to step back, mingle with different departments more freely and ask some of the bigger questions.

At the end of the day, the goal is to create a solution to solve the problem.
We should always be asking ourselves two questions:

1. How good is this solution?

2. Can we deliver better products with all that we have?

3. Do the development tools we use support us in the decisions we need to make?

If you’re an Engineer building products, commit to better communication.
If you own an Engineering business, commit to better workflows and processes.
If you’re human, have empathy for the user - that’s who you’re really building for.

After 13+ years working as a Senior Mechanical Engineer, I now improve and build the Engineering software tools (CAD, CAE) with the insights I had sitting in the design seat.

I enjoy sharing the frameworks that changed everything for me and have a mission to make processes and tools more conducive to the challenge of making decisions as an Engineer.

See you soon. 👋
Nasser

Title image from DHCAE tools

Why bother setting up a virtual / digital simulation in the first place?
Why spend so much time and struggle on generating a mesh?
Why wait for days on end for results that may only be an approximation at best?

I got started in the industry back in 2008 and I was always wondering why someone would pay me to think up design solutions (the term “knowledge” worker wasn’t really a thing then, or at least I never heard it said in industry).

The engineering design and simulation landscape was also a little different…

• Large assembly models crashed everything (including the project!)

• Forced to run steady-state physics simulations due to hardware limitations

• A clean 500k cell mesh was a real achievement!

• Simulation was still viewed as a “nice-to-have” rather than a necessity

• Cloud tools / scale was non-existent

Well, it’s 2026 and the tools have come a long, long way, mostly due to the compounding hardware developments.

Computational simulations provide the huge benefit of a virtual environment, without the absolute need for physical construction and testing (although, as you’ll see later I always recommend it).

Once you have a trustworthy simulation result as an Engineer, you can answer some questions about your design and in turn support the business in a real, meaningful way, impacting the bottom line.

This is where the true value of simulation lies.

Now we know the “why”, let me explain the how.

You need a process that is inherently diligent and progressive.

Honestly, if I’ve learnt anything around the real, messy engineering reality of designing physical products, it’s this.

It keeps you methodical, sane and tends to result in the best ROI for the business itself, in more than one way.

Here’s my 4-step framework I’ve used in client simulation work:

1. Develop a simple (first) model
   Test your assumptions, specific setup and solver choices.
   This is your physics validation step.
   

2. Setup the more complex model
   Test your mesh refinement, time step, residual behaviour.
   This is your numerical validation step.
   

3. Plan a production-grade model
   Check for expected physics, flow, forces.
   This is your engineering validation step.

4. Compare your results

   Check the results against previous prototypes, data, measurements.
   This is your strongest validation.

The bottom line (pun intended!)

The process is about building confidence in the results - to a point where you can trust where they came from, how you got them and consequently make supportive design and business decisions.

See you soon. 👋
Nasser

This way of thinking and problem solving drives everything I do.

If you’ve ever tried to generate layers consistently using snappyHexMesh (SHM), you’ll know why it’s a common challenge, especially getting good locality, thickness and distribution.

In general, you’re up against 50+ parameters across the three processing stages, a heap of potential errors and generally speaking, one stage leads to another, so success matters along the way.

I’ve been trying to make it easier to understand and work with SHM for a while now, through experiments and a variety of previous posts earlier this year. Take a look:

What’s the need for layers anyway?

I like to go back to the fundamentals and remind myself (and you) of them.

You see, most of the interesting physics happens close to surfaces.

You can use “wall functions” but they’re approximations of how the fluid behaves. I’ve written about this before.

Layers in a mesh increase the local resolution near walls and resolving the fluid behaviour, hence any form of heat transfer, turbulence and other wall-affected physics can be captured.

Predicting layer success

The layer generation algorithm is sensitive to cell sizing.
And this is a product of both the Base mesh cell size and cell refinements.

Let me explain.

When you refine cells you get something like this:

Next comes the snapping stage - the vertices (points) are pulled from the “stepped” mesh in or out in the direction to a smooth result:

This very action results in shrinking, stretching and skewing, particularly of the boundary cells, which can be seen at the boundary above.

In other words, the size (and area) of the cells change.
And the aspect ratio of the boundary cells is now distorted.

This makes perfect sense as two of the three stages of SHM are sequential in the algorithm, but it means that the layer algorithm has to deal with imperfect cell sizes, to try and grow the number of layers, at the sizes you’ve requested!

My results

They’re promising (still getting recession and collapse in typically-challenging regions) and I’m still testing it on other geometry, before sharing the full, specific steps I use to get consistent layers, regardless of the geometric complexity.

The screenshots of the resulting mesh is from a tool I’ve been building, that allows me to inspect the resulting mesh with more accuracy and intention.

Stay tuned and connected for updates on this.

If you like what I'm doing here, consider supporting me by upgrading your subscription and access more resources.

See you soon. 👋
Nasser

Impressive isn’t it?

It’s easy to click a few buttons and run some commands and “look” like you’re Engineering.

But technical software is a double-edged sword.

Most people consider it a productivity tool (like automation in general), but I see Engineering tools like CFD, CAD and FEA like design assistance tools.

Almost like an extension of your research, as we’re often concerned with innovation and optimisation.

We’re not really designing something that already exists in new-product development (NPD).

That’s why we as Engineers should be critical, even insistent, on knowing how our tools work and the answers they provide.

I was guessing for years

• Using CFD and other solvers without understanding how they work.

• Had no understanding of how it came to the answers it did.

• Trusted it gave the right answer as long as I set it up “correctly”.

• Tried to look important / knowledgeable with screenshots and reports.

• Glossing over questions about my design solutions shaped by simulation results.

The turning point came when I was asked to develop a product that needed to house a bunch of electronics in a small, thin form-factor for company based in London, UK.

Heat was the issue, with previous designs literally catching fire.

I needed to up my game and knowledge of the tools.

Self-learning is lonely but worth it

That experience led me down a self-guided learning path, years after graduating.

University simply doesn’t (and can’t) prepare you for every project you’ll work on in the real world.

I came to learn that most CFD tools use FVM - a numerical method to calculate the trajectory of fluids based on forces etc. as sources of input.

If you missed my popular introductory post, take a look here:

We owe a lot to Calculus (so I learnt about it without a Math teacher)

In fluid dynamics (or indeed any dynamic situation), we’re only concerned with two things:

1. How fast is the quantity (velocity, temperature, movement etc) changing?

2. How much in total (over a given period in time) has it changed?

In Calculus, the branch of math that deals with this, the first is answered by something called a “derivative”. The second is called a “integral“.

A derivative looks at a quantity over a given area of time / space and returns a “slope” that numerically indicates the rate of the change.

An integral accumulates many of these changes over the bigger area.

That’s it. That’s really the basis of all CFD tools.

Sure, there’s a few details I’m leaving out…but I don’t want to swamp you to with too much math, but I do know when it’s practically useful.

To that end, I’m planning to detail more about these concepts as they are directly relevant.

Thanks for tuning in this week!

PS. If you’re struggling to learn or make real progress with OpenFOAM for CFD simulation, my manual ‘The OpenFOAM Diet’ has been a resounding success with readers! Click here for details. (And send me an email if you’re a student and I’ll send you a unique discount code for it.)

See you soon. 👋
Nasser

And you’d think I’d get used to the process after using OpenFOAM for a while.

Wrong.

You see it still costs time - something far more valuable than anything else.

I realised I was doing the same thing over and over again. Something like this…

1. Load the OpenFOAM environment in a terminal

2. Write out .foam file

3. Launch ParaView

4. Load the .foam file

5. Slice data set in camera normal plane / XY

6. Switch view style to “surface-with-edges”

7. Crinkle slice / remove the triangulation

8. Switch camera to parallel projection view

After a while, all you really want to do is change the snappyHexMesh dict file, run the command to start meshing and look at the new result.

That’s it.

Sure, I could have written a batch file to take care of the snappyHexMesh process. Then a ParaView macro to execute the process within that at the click of a button.

But that still feels a little disjointed and impractical.

In comes Python

You’ve likely heard of this “programming” language (it’s more like a glorified scripting language with access to a bunch of libraries, but that’s neither here nor there!).

You can do some cool things with it, making things happen with your computer and the software tools that sit on it.

And that’s what matters here.

Whilst I’ve been a Software Engineer for a few years with a previous background in Mechanical Engineering, I don’t have the inclination to make this more complicated than it has to be or spend excessive time on it. I intentionally stayed away from low-level / “serious” languages like C++ here.

Oh, and I’m not contemplating using any kind of AI here (I grew up in the 90’s and engineering in the early 2000’s - a time when CFD tools crashed when trying to generate a mesh with over 100,000 elements!).

A little bit of planning goes a long way

I like splitting things up into parts just so I can “see” how it works as a whole.

The process of building a tool really is like building something out of physical Lego bricks - you build a parts and do a whole lot of testing, hope it breaks in front of you and repeat the cycle.

I mapped out the full process based on a simple flow as best as I can see it at the time...

Getting it to shake hands

A new process needs to be spawned in order to mimic the launch of a terminal / command prompt.

I’m running a Windows WSL-based installation of OpenFOAM so I needed to start the WSL environment before I could see any OpenFOAM commands.

There’s a library that let’s you access internal Windows OS processes, exposing this kind of thing.

From here it was a case of interrogating what I had available from the field data sets and associated case files.

What I’ve got so far…

This is only the start of what I think could be a useful tool if done with some thought.

You really don’t need a GUI to use snappyHexMesh so I don't plan on making this do any kind of setup in that way. I’ve been contemplating of having something more useful - a bit like a mesh debugging tool rather than just a 3D mesh visualiser.

If you’re a paid / premium subscriber of my newsletter you’ll get the chance to test-drive this tool and hear about it before anyone else.

I hope you’ve enjoyed this weeks post.

See you soon.
Nasser

And there’s good reason too…

A poor mesh can:

• introduce artificial diffusion

• ruin any turbulence modeling

• destroy numerical convergence

• de-stabilise linear, time-dependent solvers

• create non-physical pressure/velocity fields

• force you to use unnecessarily small time-steps, making the simulation take longer to complete

Therefore, experienced Engineers have realised this is where the time should be spent.

What a CFD mesh actually does in the computational world

The mesh is a representation of your CAD geometry in 3D space, made up of vertices, connecting edges and nodes.

It discretises the space / domain that you’re interested in - kind of like saying “this section of my green field is what I’m interested in. Now break it into small pieces so I can solve do a little mathematics across each one.”

Seriously, this is all it is.

And whilst this is what it is, many just stop there and proceed with auto “generating” a mesh with some mesh generation tool like snappyHexMesh without much in the way of critical analysis of the process and end result.

Representing your geometry digitally

Turning geometry into the finite, small pieces that the computer can work with is done by creating typical cell types:

Notice, all of these can be decomposed / built-up from triangles, yes a rectangle can have two triangles! - and computers (graphics and physics engines) absolutely love them.

Where the problems start

If you’re a regular reader of my newsletter, you’d know I like to reiterate a few of the physics regularly.

Remember, each cell approximates:

• gradients

• fluxes

• divergence

• diffusion

• convection

• pressure coupling

And the shape and arrangement of cells directly affects those approximations.

You might want to have a read of this article I wrote if you want to understand how the traditional method of modelling fluids works.

(I walked through this too on my YouTube channel, click here)

Mesh generation is an optimisation problem

You can have tiny cells everywhere and it’ll usually give you the most accurate results. Conversely, a mesh with large coarse cells will be quick and cheap, yet mostly useless.

So, like most things in Engineering, this is something that needs to be a compromise and iteratively optimised!

Orthogonality

Engineers gloss over this, yet it’s arguably the most important quality metric.

Why, you ask?

Here’s why: the physics terms like diffusion are calculated using the normal vectors of the shared faces between cells. If it’s not completely orthogonal (which is common), correction terms need to be applied to the calculated flux.

Remember this.

Skewness and the aspect ratio are the metrics next in line of importance and I’ll cover them in future posts.

I hope you learnt something from this post today.

See you soon. 👋

Nasser

It was excruciatingly painful but equally rewarding in a variety of ways…
(It definitely tested my resolve and commitment to learn!)

It led me down various rabbit holes (which I’ve not quite climbed out of years on!):

• Computational mechanics

• Geometry mathematics

• Graphics pipelines

• CPU and GPU architecture

• Software patterns

• Debugging code

• Performance tuning

• …

Honestly, it’s a lot to take on, especially when balancing a full-time job and family commitments.

But I did it anyway and I’m glad I did.

Here’s an earlier engine I built for granular physics in C++, (click to view the video):

I’ve always looked at the career change as more of an adaptation and augmentation of my Engineering design skills.

I can now develop useful digital tools, potentially improving the design and simulation tools out there!

This was and is still a huge plus for me.

A little coding experiment…

I keep pushing myself to keep learning and developing my skills as a professional Software Engineer in this space.

This week I wrote a small program, just to highlight the difference optimised code makes to a theoretical solver code.

Program 1 (Unoptimised memory layout)
Total time for 100 time steps: 636.793 ms
Sample Particle [0] Position: (5, 45.046)

Program 2 (Optimised memory layout)
Total time for 100 time steps: 136.881 ms
Sample Particle [0] Position: (5, 45.046)

That’s a 4.5x speed-up by considering how to layout particle data in RAM!

OpenFOAM code

It’s was released over 20 years ago and written in an C++ object-oriented.

For a variety of reasons It’s slow, but remember the fundamental physics don’t really change.

I love the code for what it is and it’s very good as a generalised system solving fluid dynamics problems in Research and Engineering.

It reminds us that the period of invention, state of technology and collaborative efforts push human community forward.

Here’s a shout-out to OpenFOAM and all those involved…Kudos for bringing a much-loved and respected code-base to the people that need it!

See you soon. 👋
Nasser

If you think about it, it generally follows the CFD / computational process that pretty much exists in most simulation workflows to this day…

CAD → Mesh → Solve → Results

It’s a structured, proven codebase that works for a wide range of physics problems.

I even developed a clear, concise, no-fluff manual to make it absolutely easy to use. Read more about it here if you missed that!

Common roadblocks

Whilst it can be easier to use with clarity and determination, some things stand in the way of beginners:

• It’s poorly documented

• It can crash without warning / error messages

• It doesn’t have a graphical user interface (GUI) and works in the command-line (CLI)

• There is no official support available

BUT it is free (at least money-wise) - there are no licence fees whatsoever.
And together with proven results, it’s usually what brings swathes of people back to it!

Will AI make tools like this any easier?

AI chatbots like chatGPT is only as good as the information you give it.
But it isn’t very good at setting up a non-trivial case from scratch. (Believe me, I know).

The real promise is in the form of “PINN’s” - AI that is physics-aware and doesn’t use a mesh!

Above source: https://www.mathworks.com/discovery/physics-informed-neural-networks.html

But it’s a current and relatively new research area, so….

For those interested, there are “agentic” automated workflow tools popping up, but it would be interesting to see how their capabilities develop.

Practical applications matter most

Here’s the thing - for Engineers like me and you, the practical application is what matters.

I’ve always had an Engineering-first / problem-first mindset.

Asking things like…

• “What is the design issue?”

• “What are we actually trying to solve here?”

• “Can we do without [insert specific tool]?”

It’s not the tools that are difficult - you can always learn how to use them at any stage of your career.

Focusing on the fundamentals of your discipline will be the key to keeping nimble, valuable and confident as we move into the future together.

At least this is what I firmly believe after 12+ years as a Senior Mechanical Engineer and software programmer of CAE tools.

This week on my YouTube channel:

I’m working on creating videos consistently and sharing my career / industry experiences with you, so keep an eye on the channel over the next few days and weeks.

See you soon. 👋

Nasser

So much so, they leave it for another, often commercial alternative.

But I haven’t given up on it.

You see, over the years I’ve been coming back to it, mostly because I like tinkering with tools. I always have!

I usually get a good mesh out of it, but lately I’ve been pushing it to its limits (and my 32GB machine memory!)

Next, I wanted to test further corner refinement, trying to get as close as possible to the corners.

Now, this was an interesting revelation…

The same 5 layers requested and generated but compressed in a smaller space, given the smaller cells.

SHM will scale the whole layer stack.

But, the transition cells / layers is quite abrupt here, so a stepped refinement would help.

I plan to continue my practical experiments, develop my SHM insight tool and write here and on LinkedIn about them, so do subscribe and follow.

Hope you’ve learnt something.

Have a great week!
Nasser

P.S. If you’re starting out with OpenFOAM take a look at The OpenFOAM Diet manual I made from scratch for you. It’s a no frills, no fluff guide to simulating with OpenFOAM (and previous buyers have raved about it!).
Click here to learn more and start reading it

Whilst frustrating to say the least, the results from snappyHexMesh improve when you start thinking about it a little more holistically…

I’ve found it’s best to stop thinking about it in stages (castellation | snapping | layering) and instead think of it like a waterfall process (castellation to snapping to layering).

In other words, generally, the success of each feeds into the next.

This means you stop thinking “I need a fine base mesh before anything”.
The truth it’s often more productive and beneficial to keep it relatively coarse and moderately refine the cells in snappyHexMesh from here.

A “Setup” tends to make you think of providing snappyHexMesh all the parameter numbers that need to go in (be completed).

Whereas a “Strategy” is an approach to meshing, providing snappyHexMesh with parameter values that work together.

Here’s my general strategy for a new geometry file:

Base mesh: Moderately coarse (not too fine)
Surface refinement: Moderate, resolveFeatureAngle: <20
Snap: tolerance 2, nRelaxIter 20
Layers: Thin and a few to start, nGrow: 1 or 2, featureAngle: 120 - 130

I let this guide my work.

Could this be the answer to all geometries? No, and it can get frustrating.
But it does provide a starting point from which you can hopefully refine later.

What I’m fast realising with snappyHexMesh…

Commercial meshing tools make it super-easy to generate a mesh using alternative algorithms and moderate / forgiving presets.

snappyHexMesh has a meshing algorithm with is based on recursive refinement and extruding layers after a mesh exists.

This is often the source of many of its “issues” - my quest is to focus in on these and tame them.

Watch this space as I share my progress and solutions with you.

See you soon 👋

But snappyHexMesh (SHM) has always been packaged with OpenFOAM from the beginning…and it was designed to bridge the gap between the messy, real-world of CAD design parts and CFD simulation.

Whilst I’ve used it in the past to good effect and I’ve recently been trying to clarify whether it can really generate better, more numerically-valid CFD meshes.

If you've been following the last few posts here, you would've seen me detailing the most influential snappyHexMesh parameters in any meshing project. Here’s a list for convenience:

The philosophy behind it

I may have mentioned this before - it works with a “background” mesh and your CAD geometry (STL / OBJ), cutting, refining and layering a final CFD mesh.

This makes logical and computational sense to me.

But in my experience, the results are dependent on your configuration / parameter settings (contained in system/snappyHexMeshDict).

It takes some time to get going

Once you get used to the interface and how to manipulate the parameters, it’s a matter of refining those.

But this is where most people give up as it typically takes an excessive amount of time to find them for your specific geometry.

For example, it took me a few hours to get a good snapping result with minimal mesh errors:

When things go wrong

Number of intersected edges : 0

Marked for refinement due to surface intersection : 0 cells.

***Concave cells (using face planes) found, number of cells: 82739

***Error in face tets: 16 faces with low quality or negative volume decomposition tets.

Blah, blah, blah, blah, blah, blah, blah, blah, blah.........
Blah, blah, blah, blah, blah, blah, blah, blah, blah, blah.........
...........
........
.....

These are some of the error log messages I came across when using it generate a mesh lately and it can be exhausting to say the least.

There are few things you can do here:

• Read and try to understand what the error log is saying.
  There are often clues in it, although not exactly pin-pointing to the problem

• Understand geometry a little - what is a hex cell? why does the spacing between the background mesh matter? what are the refinement levels?

• Run each stage (Castellation, Snapping, Layers) separately.
  You can also use “debug 1” within the configuration file to write and output the intermediate results of each.

What I’m doing to help you further…

• I’m writing my next precise and concise manual around Meshing for OpenFOAM (part of the OpenFOAM Diet series)

• I’m building out this SHM tool to help generate better meshes for better simulation results.

Help me to help you….

See you soon 👋

They’ve been in the trenches.
They’re up against the deadlines.
They’ve developed workflows to mitigate the risks.

I’ve noticed, even in my own Engineering journey, that I was forced to develop a better way of doing things if I was ever to “graduate” beyond the junior role.

If my work was ever to be taken seriously by others.

Previously, I’ve written on developing a simulation strategy, which this post is related to. If you missed it, take a look here:

Whenever you start a new simulation project for a new product or design, start with the right questions…

Here’s a list I put together for you:

1. Ask the engineering question, delay the physics

Ask: What do I actually need at the end?

Lift?
Pressure drop?
Temperature distribution?
Flow rate?
Noise?

Whatever that one thing is becomes your compass.

RESULT: Anything not needed to get that number is not part of version 1.

2. Classify the physics early using the simplest bins

These choices lock others into place.

Choose between:

• Flow type (Internal vs external)

• Mach regime (Incompressible vs compressible)

• Time nature (Steady vs transient)

• Turbulence (RANS first unless you truly need LES/DES)

• Phases (Single-phase unless the phenomenon demands more)

RESULT: This narrows the OpenFOAM solver list from ~50 to like 1–3 candidates.

3. Prioritise: what really changes the answer?

A simple rule of thumb:

Mesh quality > Turbulence model > Numerical schemes > Geometry details

Fancy chemical reactions mean nothing if your mesh looks like a crushed soda can.

RESULT: Start with clean geometry and low complexity. Add details only when the coarse model fails.

4. Develop your “Minimum Viable Simulation”

Like drawing a sketch before a masterpiece, develop:

• A coarse mesh to act as a base line

• Get it working with a steady RANS turbulence model

• Stick with default numerical solver settings

• Constrain to one operating condition

RESULT: Get your first / draft answer in hours, not weeks. Then test sensitivity.

5. Document assumptions like a detective

Write no more than one page:

What physics are included?
What physics are excluded?
Why is this acceptable theoretically?
When does the answer become invalid?

RESULT: If the assumptions don’t hold, the model doesn’t hold.

6. Apply progressive refinement to the case

You only add when you can justify:

• More mesh near walls
• A better turbulence model
• Conjugate heat transfer
• Transient flow behaviour
• Multi-phase or reacting flow problems

RESULT: Small steps and a single purpose for each upgrade.

This is what building a “minimum viable simulation” model looks like in practice.

I hope it helps you plan and develop your OpenFOAM simulations with clarity and intent.

See you next week 👋