Three Tiny Tips: Part 02

Hey there,

It’s Robin from CFD Engine & I’m back with second edition of the “Three Tiny Tips” series that I started back in December.

No deep dives or tutorials, just three little nuggets of “OpenFOAM esoterica” that you might not know. This week it’s one function object & two keywords – let’s get it…

executeControl

This is the second time executeControl has been in an email, so perhaps this is more about confusion control 🤔

I’d totally missed this function object keyword until reader Tom pointed it out, prompted by something I’d written in the first edition of “Tiny Tips”.

I had wrongly assumed that, when using forceCoefs it was the writeControl keyword that determined when the force history was written. Turns out, it’s not. It’s the “new-to-me” exectuteControl keyword that does the trick. You could in fact set writeControl none; and still get your force history.

executeControl determines when the function object is executed (or updated), it’s optional & defaults to timeStep. Which I think is why I’d never noticed it. Perhaps you missed it too?

Taking the example I used in the previous tiny tips email – writing force fields from forceCoeffs – you can safely set writeControl endTime; and get your force fields at the end of your run and still get a force history at every timestep. Nice.

You can find more info on the various function object control keywords and their defaults here along with a little worked example using the Courant number function object.

runTimeControl

Whilst we’re in a controlling mood, let’s switch to a nifty function object that we can use to end a simulation early if it meets certain criteria – runTimeControl

I’ve never been a big fan of using residuals as convergence criteria. In my day-to-day CFD the residuals drop to an acceptable level way before the forces have converged. As such I tend to run long, usually to a fixed number of iterations, where I can be pretty sure that the forces will have converged.

runTimeControl could’ve saved me some iterations & a whole bag o’ cash over the years 💸💰

Using this function object we can chain together several convergence criteria to create more complex conditions. We can also pull data from other function objects and use them as convergence criteria. They can even be averaged & windowed for yet more flexibility.

Want to end your simulation if your residuals are peaking (rather than converging) instead of just waiting for it to blow up? This function object has several options for that. Plus, it always writes out when triggered, so you can inspect your flowfield before it blows up & triage it – bonus.

Want to end your simulation when your forces are steady within a certain range, for a certain amount of time? runTimeControl has you covered.

Want to add a caveat to the above so that your residuals must be below a certain level as well? Certainly, no problem.

Want all of the above in one function? You’re in luck.

Check out the documentation for more information, plus an example like the one I just outlined, all ready to cut & paste.

result

This is exactly the thing that these Tiny Tips emails were built for.

Did you know you can change the name of the fields written by post-processing function objects? Me neither. But then, it’s only been around for 6 years, so you can see how we might’ve missed it 😳

But why would you want to do this? A few reasons…

It’s really useful for (re)naming the result of a calculation.

It’s great if you want to match a particular naming convention that you (or your clients) are used to.

Or if you just want to rename those fields with parentheses in their name, e.g. mag(U), static(p), total(p)_coeff etc, to make them easier to use on the command-line, or in scripts.

For example, adding result cpT; to the end of your total pressure coefficient function will give you a field called cpT rather than total(p)_coeff.

A tiny tip, not a huge deal, but nice to know.

Over to you

I told you they were little – renaming fields, stopping your simulation & a hidden default that you may never need to change.

Were they all super-obvious? Anything of interest here? Did I get something wrong? Let me know, it really helps when I’m writing future emails.

There’ll be more editions of “Three Tiny Tips” so, if you’ve recently (or if you ever) come across something you think I should share with the class, then drop me a note & I’ll add it to the list.

Sim you later,