Issue 035 – February 27, 2021

Problem cells

Hey there,

It’s Robin from CFD Engine, back with another dose of “OpenFOAM esoterica” (shout-out to Julian for coining that phrase).

This week I’m chasing problem cells & giving a couple of pointers that might be useful when a few pesky cells are spoiling your simulations.

I’m sure you’ve been there – your boundary conditions are all in order, your schemes are on point, and you’ve picked the right solvers, but your case still won’t run. A few iterations and then it diverges – what do you do?

J’accuse the mesh, it’s almost always the mesh.

Check Yo’ Mesh

The ultimate check for a mesh is to run it, but we’ve established that it doesn’t run, so we need a different check – enter checkMesh.

Amongst other things, checkMesh flags any cells it thinks are suspect. So, if we’re having problems and checkMesh says our mesh has issues, then we should probably fix them first. But where are they?

By default checkMesh creates sets for our dodgy cells. Adding the -writeSets VTK option will prompt checkMesh to write out those flagged cells in VTK format, ready to go straight into ParaView.

checkMesh -writeSets VTK

Then we can read our case (& input geometry) into ParaView, grab the “dodgy cells” VTK file and start investigating where & what the problem is.

Pro Tip: Display your checkMesh VTK files as Point Gaussian to make them easier to spot from a distance. You could even apply the Cell Centers filter to display just a single point for each dodgy cell.

Once you know where the problem cells are, take a look at the surrounding mesh & you’ll probably spot a way to get rid of them. Maybe a little extra refinement, a change to an expansion rate, a reduction in edge length or perhaps a little mod to the input geometry (if it’s an unimportant area).

Then it’s time to go again – re-mesh, re-check & re-run 🤞

Bin the dodgy cells

You didn’t get this one from me, but you could just delete the dodgy cells & carry on 🤫

I’m not going to tell you how to do it, ‘cos it feels (to me) like a kludge. I’d recommend fixing your mesh, so that the problem cells aren’t generated in the first place.

But, if it turns out that you only have a couple of problem cells and they’re somewhere you don’t care about, then this could be a quick fix – especially when you’re in a pinch.

Fast Cells & Sticky Cells

Sometimes checkMesh doesn’t flag any cells of interest, where do we look then, especially if the case blows up before it writes any data?

My next stop is to use the fieldMinMax function to report min/max values on some properties of interest. It’s often p & U in my cases, but you may be having problems with turbulence or something else.

It’s so useful that I have this function activated on all simulations, logging the min/max values for U & p (& their locations) at each iteration. If a case ever diverges I can check the log to see if either field (& it’s usually both) has gone haywire.

I can then scroll back through the log & find when they started to go wrong, along with the locations in the mesh. These locations are the first places I look for problem cells.

Here are a few simple steps to add this function to your case:

  • Use foamGetDict fieldMinMax to copy a sample min/max dictionary to your system directory;
  • Edit system/fieldMinMax to include the fields you’re interested in, e.g. fields (p U);
  • Activate the function by adding #includeFunc "fieldMinMax" to the functions section at the bottom of system/controlDict
  • Solve your case as normal
  • By default the function will log its results to the solver output & also to a data file – postProcessing/fieldMinMax/0/fieldMinMax.dat
  • If you want to turn off the solver output (but keep writing to the data file) you can add log false; to your function in system/fieldMinMax.

Now whenever a case diverges, you’ll have a great resource to help you zero in on the place in the mesh where it all started going wrong.

Alternatives

There are other things you can do that don’t involve chasing cells around. You could change your solver settings to be more lenient in the early iterations and hope that you can converge things enough that the “difficult” cells don’t cause a problem. You could maybe even limit some fields for the same reason.

Over the course of a project, I think the time spent chasing out problem cells is time well spent. They have a habit of hiding until you’re in a time crunch and then they pop up & cause havoc. Fix ’em in the mesh & be done with it.

Do you have any other tips for finding & fixing problem cells? I’m always keen to learn from you. What have I missed &/or what do I need to know? Drop me a note – my inbox is always open.

Until next week, stay safe,

Robin