The 2.2 version of OpenFOAM was released on 6. March 2013 and after reading the changelog, I was keen to try it out. Especially due to the promised changes to snappyHexMesh. I tried to build the new version that is distributed via github using the well known way of just changing into the $WM_PROJECT_DIR, executing ./Allwmake and hoping for the best. Unfortunatly this didn’t work out well, because the libOpenFOAM didn’t compile properly:

primitives/triad/triad.C:36: error: expected initializer before '<' token
    primitives/triad/triad.C:39: error: expected initializer before '<' token

After discussing this with my good friend Tomislav, he came up with a simple fix for this: Just remove the lines in $FOAM_SRC/OpenFOAM/Make/files that contain something with triad in it. You can either download the bugfix from github or generate it from scratch by commenting all lines that contain something with triad.

Executing Allwmake in $WM_PROJECT_DIR should now compile the current version without any errors.

Performing parameter variations can be stressful, especially if some parameters have to be altered in various places in an OpenFOAM case. This is where the python modules of PyFoam come in quite handy. I assume, that you have a basic knowledge on how an OpenFOAM case is structured and that you are familiar with programming in python. If you need a brief refreshment of your python skills, you can pick one of these tutorials.

I usually use matplotlib during post-processing for plotting x-y data, as the plots look nice and I can use my other python classes to generate and parse the data, which is quite nice. This works perfectly when the original data doesn’t change, while a plot window is open, which is not the case for e.g. the forces on a patch that are sampled during a simulation, by a function object. For this purpose I use good old gnuplot, which can be updated easily.

The forces are stored in forces/0/forces.dat inside the particular case directory. One problem arises, though: The forces are not stored in a gnuplot friendly format but as nested vectors with round brackets, which gnuplot cannot process. These brackets must hence get removed somehow and if possible in an automatic fashion. The removing itself can be done using sed:

sed -e "s/[(,)]//g" forces/0/forces.dat

This replaces any round brackets by nothing and prints the output to stdout. We can either pipe this output into a file and plot this file or use the output of sed directly in gnuplot. As the first way is not as elegant as the second, we’ll just use the latter.

plot '<sed -e "s/[(,)]//g" forces/0/forces.dat' using 1:2 with lines

Whenever the plot is updated, the sed command is executed which in turn reads the latest forces data, removes the brackets and hands it back to gnuplot.