OpenFOAM Expressions

Hey there,

It’s Robin from CFD Engine & this week is a continuation of something I started back in November. In that issue I discussed using include files, environment variables & expressions to minimise the number of dictionaries you need to edit to run your next simulation.

I suggested then that expressions warranted their own email – so here it is.

What are expressions?

I previously described expressions as a whole host of native functionality for doing calculations & manipulating variables inside your OpenFOAM dictionaries. There’s a bit more to it, but that’s general gist.

There is a catch though – they’re only available in ESI-OpenCFD releases (since v1912). But don’t tune out if you’re currently on the Foundation version, expressions might be enough for you to consider switching 🤔

What can you do with them?

Pretty much anything you can think of…as long as you’re thinking about manipulating variables or setting boundary values & initial conditions.

You’ll find most (if not all) of the mathematical functions you’ll ever need (especially if you’re replacing a spreadsheet) plus vector & tensor operations, and some logical/boolean tests.

There are a selection of mesh-related functions, that allow you to find locations, normals, areas etc and to do weighted averages & sums.

They even include some random number generators, for when your results aren’t quite random enough 😉

You can find the full list here – there’s a lot to check out.

My use case

I use them to replace the process of calculating variables in a spreadsheet & then copy-&-pasting them into the relevant dictionaries.

It’s pretty simple boundary condition stuff such as, combining the windspeed with a tyre’s rolling-radius to calculate its omega. Or calculating engine intake values from a handful of engine parameters. Through to figuring out an inlet vector from the windspeed & a yaw angle (I could do more on this, like grabbing the inlet normal from the mesh & incorporating it into this calculation – one step at a time 🤯).

In the old “copy-&-pasting” days, there was no simple/automatic way to keep the the spreadsheet & the boundary conditions in sync (or ensure I hadn’t made a fat-finger typo along the way).

But, by replacing the spreadsheet with a handful of expressions:

1. everything lives in the OpenFOAM case files. No need to refer to an external source to find/calculate any values;
2. the calculations are evaluated every time the case is run, meaning they should always be up-to-date 🤞
3. they’re easy to work with over a remote connection, they’re just another text file;

It’s no more accurate than any other method, but I like the above benefits and it’s native OF functionality, so why not?

Gotchas & Tips

I’ve found expressions pretty straightforward for my simple use case. Parameter expansion has me puzzled from time to time, plus casting strings to other data types had me stumped for a bit – hey, I’m not a developer 🤷‍♂️

On that, a vector written in a text file looks like a vector, but it’s actually just a string. They look the same, but they aren’t, hence the trouble. It’s easy to fix (there’s a function for it) but it had me scratching my head for a bit. It looked like it should work, but thankfully the error messages are pretty helpful.

Top Tip: Use foamDictionary -expand to see what your dictionaries look like after OpenFOAM has parsed them & compare it to what you really intended.

Other than that:

• start small & build up – you don’t need to go crazy straight out of the gate;
• Don’t use an expression when a constant will do;
• Comment as you go – you can use the usual dictionary commenting style – // or /* */ – you’ll thank yourself later.
• If in doubt, throw in a few more quotation marks to clarify what you actually mean & help avoid ambiguity.

Alternatives

There are other ways to do this kind of thing. For example, #calc or #codeStream (available in Foundation & ESI-OpenCFD releases) uses dynamically-compiled C++ code to provide essentially the same functionality as expressions. They come with a small overhead, related to generating & compiling the new code, but unless you’re using them heavily you probably won’t notice much more than a short delay when you first run the tool/solver. You do need to be running in an environment that has compilation tools though, otherwise they’ll throw an error.

There are also third-party options, such as swak4foam (the inspiration for expressions). But they involve downloading, compiling & updating additional codes. They may be worth investigating if expressions are missing something you really need.

Express yourself

If you’re using spreadsheets to calculate boundary conditions then I reckon you should at least take a look at expressions. They run quickly, they have the functionality to cover most situations & they bring your boundary condition calcs into your OpenFOAM dictionaries.

If you’re already doing tricksy things with #calc, #codeStream or swak4foam then you’re sorted. But for the rest of us, expressions are well worth a look.

Do you already make use of expressions (or #calc / #codeStream) for calculating/manipulating variables inside your dictionaries? Are there any better options that I’ve missed? Or is it just “a bit too much” for your particular use case? I’m always keen to hear your experiences – drop me a note, any time.

I’ll be back next week,

Until then, stay safe,