Setting up and using OpenFOAM might just kill you.

This might keep you sane!

OpenFOAM is not for the faint-hearted.

When you first encounter OpenFOAM, it’s a minefield from the beginning.

And if you’ve come from the comfort of commercial CFD / CAE tools, then this can initially appear to be a joke!

You probably throw in the keyword ‘download openfoam’ into Google and smash Enter, landing on either the “Foundation” (.org) or “ESI” (.com) version.

A slice of OpenFOAM results taken in ParaView

If by luck you already know which to use, you still need to wrestle with a whole host of things as a new user, including:

• what Ubuntu is

• why you need Linux

• what WSL is

• how WSL differs from Windows

• which Ubuntu distribution to install

• whether you have WSL1 or WSL2

• how to launch Ubuntu

• what sudo means

• what apt does

• what a repository is

• what a GPG key is

• why OpenFOAM isn’t simply an .exe

• where /opt is

• what .bashrc is

• what source means

• what environment variables are

• why $WM_PROJECT_DIR matters

• whether the correct MPI implementation is active

• where your cases should live

• whether your simulation actually runs

It’s generally a nightmare.

Here’s a previous post I wrote with installation guidelines if you missed that:

#5: A practical introduction to OpenFOAM for Researchers & Engineers

Over the years I’ve had to install OpenFOAM on a variety of machines and can tell you it’s definitely less painful, but still not so trivial.

I still get trip over on occasion!

So I’ve been thinking of making this process simpler.
But how?

Understanding the OpenFOAM build process.

OpenFOAM is native to Linux.

This is why you need to have a compatible Linux environment available before you can install and run it on your system.

Newer versions of Windows (10+) allow you to run an optimised virtual version of Linux. And this means you don’t need to setup a dual-boot system or drop Windows altogether just for OpenFOAM!

There are many moving parts to and steps to the build / installation process which can many out.

Here’s an overview:

1. Install dependencies

2. Download the source

3. Extract

4. Setup a directory

5. Set the environment

6. Verify the tools

7. Build OpenFOAM

8. Do a test

9. Try the utilities

10. …..

That’s quite a list before you even run a tutorial!

Let's inspect OpenFOAM with a “read-only” operation.

In other words, what does the current installation environment look like?

After a little investigation and digging into the code, I discovered OpenFOAM actually attempts to load a set of variables into the local environment via a specific bash script.

I read this in and created a simple but useful validation using a small python script I wrote from scratch:

We’re not doing anything amazing here really, but it does set the stage for a potential diagnostic / trouble-shooting utility.

I’m exploring this because I believe tools, open-source or not, should be accessible by the average user without having to wrestle the code or toolkit provided.

Commercial tools give you neat installed that abstract and hide these build operations and steps by running background processes whilst you’re shown a nice splash image with a “progress bar”.

Stick around for updates on this. 😁

New video uploaded on the YouTube channel this week!

Have an amazing week!
Nasser