As I lack the discipline required to keep my desktop uncluttered, I am aiming for a simple bash script, that moves old files and folders into a designated folder on my desktop. Installing a separate software to achieve that seemed to be a little bit redundant, so I tried to come up with a fancy call to GNU find, that uses – amongst other things – regular expressions to match folder and filenames. Unfortunately, the version of find that comes with OS X 10.7 does not support the parameters I needed. I therefore had to combine the find command with some grepping.The final script looks like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#!/bin/bash
 
TIDYUP=$HOME/Desktop
TIME="4w"
 
TARGET_FOLDER="old"
TARGET=$HOME/Desktop/$TARGET_FOLDER
 
# At first, move all toplevel folders to the TARGET folder
FOLDERS=`find $TIDYUP -type d -maxdepth 1 -mindepth 1 -mtime +$TIME| grep -v $TARGET`
for fI in $FOLDERS
do
    mv $fI $TARGET
done
 
# Now do the same with the files
find $TIDYUP \
    -type f \
    -maxdepth 1 \
    -mindepth 1 \
    -mtime +$TIME \
    -exec mv {} $TARGET \;

The script does the following:

The first line specifies the interpreter, which is – of course – the bash. Line 3 defines the folder, that should be tidied up and the period in that files and folders may remain in the above specified folder is defined in line 4. I used four weeks, but this choice depends on your personal preferences. For alternative formulations, have a look at the find manpages.

As I needed to define a folder into that the older files and folder are moved, I did so in line 6 and 7. I now have a folder on my desktop that is called “old”, where all the old stuff is moved to.

Moving the folders that are directly stored on the desktop is the first real step of the cleaning process. I use find to find all directories on the desktop, that were not modified within the specified period of time. From that output, I remove the target folder and store all that in a variable. Each folder is moved using a for loop.

Getting rid of the outdated files is easier, as I don’t have to check whether the target folder is part of the things GNU find has found on the desktop. Using the exec statement, the particular files are moved immediately.

Making the Script available

In order to make the script globally available, I stored it in my personal bin folder ($HOME/bin) and set the appropriate file permissions:

chmod +x tidyUpDesktop.sh

In my case, this path is already one of the paths, the system look for executable files. If this is not the case with your system, you will have to add it manually:

export PATH=/path/to/your/file:$PATH

If you don’t want to execute the above line every time you open a new shell, then simply put it into your .bashrc.

Series PyFoam

1. Parameter variation in OpenFOAM using PyFoam

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.

1. Preparation

The first step is to choose a case to do a parameter variation on. For the sake of simplicity, I chose the lid driven cavity as an example. This can be found in the OpenFOAM tutorial folder:

$FOAM_TUTORIALS/incompressible/icoFoam/cavity

To keep the original tutorial unaltered, we need to create a parent folder and copy the cavity tutorial case folder to that directory. Now we need to change to that directory. I chose my OpenFOAM user folder for that

run
mkdir cavityParameterStudy
cd cavityParameterStudy
cp -r $FOAM_TUTORIALS/incompressible/icoFoam/cavity cavity-template
cd cavity-template

The current structure looks like this:

   |-cavityParameterStudy
   |---cavity-template

In the following, I will call the cavityParameterStudy folder “parent folder” and the cavity-template folder “template folder”.

2. Getting Started

The basic idea behind doing a parameter variation using PyFoam is to create a template case, clone that via a script and alter the respective parameters in that cloned case. We need to create the python script, that will do all the exhausting work for us (I am a vim fanboy, but please feel free to use whatever editor suites your needs).

vim parameterVariation.py

Before doing anything serious, I do perform organisational steps inside the python script:

from PyFoam.RunDictionary.SolutionDirectory import SolutionDirectory
from PyFoam.RunDictionary.ParsedParameterFile import ParsedParameterFile
from PyFoam.Basics.DataStructures import Vector
 
templateCase = SolutionDirectory("cavity-template", archive=None, paraviewLink=False)

Very brief explanation of the above lines:

• Line one imports a class that can handle an OpenFOAM case folder with all it’s essential directories. It provides easy access to these folders and the particular dictionaries, as well as a method to clone that case to an other – not yet existing – OpenFOAM case.
• The PyFoam class, dealing with accessing and altering OpenFOAM dictionaries is imported in line two.
• As I am a lazy person, when it comes to tasks that can be simplified significantly by some piece of software, I import the Vector class of PyFoam as well. We will use it, when we alter the velocity boundary condition of the cavity.
• An instance of the imported SolutionDirectory is instantiated for the template folder, that contains the case we want to alter systematically.

3. Deciding which Parameters to vary

Within the scope of this tutorial, we will vary the tangential velocity at the top boundary of the cavity. To reduce the amount of typing, we let python calculate the respective velocities and to do so, an extra line must be added to the header:

from PyFoam.RunDictionary.SolutionDirectory import SolutionDirectory
from PyFoam.RunDictionary.ParsedParameterFile import ParsedParameterFile
from PyFoam.Basics.DataStructures import Vector
 
# Add the following line
from numpy import linspace

This imports the linspace function from numpy, which divides an interval into an arbitrary amount of steps. This function is used as such:

uTangential = linspace(0.1,0.8,8)
print uTangential
>>> array([ 0.1,  0.2,  0.3,  0.4,  0.5,  0.6,  0.7,  0.8])

4. Accessing the Boundary Conditions

What we’ve learned so far is to import some packages from PyFoam and to create a numpy array with some velocities in it. The next major step is to access the boundary condition file for the velocity and to modify it according to our specifications. Before we do any modifications, we should clone the template into a new case:

case = templateCase.cloneCase("testCase")

What does this do?

• Create a new folder on your disk, that is named “testCase”.
• Copy all basic files and folders from “cavity-template” over to “testCase”. This does not include log files, time-step folder and so on. Just 0/ constant/ and system/. Any other files and folders must be specified explicitly.
• Return a new SolutionDirectory object, that points to “testCase” and store it in case

The reason why to handle the path operations by means of PyFoam and not by manually access all required paths is simply because it is much less error prone, requires less typing and is much faster.

The next step is to access the velocity boundary condition and alter the “movingWall” patch:

velBC = ParsedParameterFile(path.join(case.name,"0", "U"))
velBC["boundaryField"]["movingWall"]["value"].setUniform(uTangential[0],0,0)
velBC.writeFile()

What it does, line by line:

1. Create a ParsedParameterFile object for the velocity boundary condition file. This can be done for any other file as well, including constant/ and system/ files, if you would like to change some other parameters.
2. Access the movingWall subdictionary in the boundaryField dictionary of the velocity boundary condition and set the value of the Dirichlet boundary condition to be uniform for all faces on the patch and use the first tangential velocity, that was defined previously using the linspace expression.
3. Write all changes to the boundary condition.

5. Using a loop

As the above lines do not account for changing the velocity multiple times, we employ a for loop around the ParsedParameterFile lines, so that the entire script should look like:

1
2
3
4
5
6
7
8
9
10
11
12
13

from PyFoam.RunDictionary.SolutionDirectory import SolutionDirectory
from PyFoam.RunDictionary.ParsedParameterFile import ParsedParameterFile
from PyFoam.Basics.DataStructures import Vector
from numpy import linspace
 
uTangential = linspace(0.1,0.8,8)
 
templateCase = SolutionDirectory("cavity-template", archive=None, paraviewLink=False)
for uI in uTangential:
    case = templateCase.cloneCase("cavity-u%.1f" %uI)
    velBC = ParsedParameterFile(path.join(case.name,"0", "U"))
    velBC["boundaryField"]["movingWall"]["value"].setUniform(uI,0,0)
    velBC.writeFile()

This script loops over all defined velocities, clones the template case and stores the correct velocity in the velocity boundary condition. At the current state of the tutorial, the cases must be started manually, though this can be automated fairly easy with PyFoam.BasicRunner. But this will be covered by an extra tutorial.

1. Prerequisities

I should note that I used the latest version of the git repository and not the tarball. The reason for this was that I would like to be able to update the installation more easily in the future.

• Grab cmake. I used the binary version 2.8.3 and install the command line version as well!
• Install git for mac.

2. Clone the git repository

The next step is to clone the git repository. Before doing that, I created a parent folder to organize the source and binary files.

mkdir $HOME/Applications/src/VTK
cd $HOME/Applications/src/VTK

In that folder we clone the git repository and checkout the release branch by performing

git clone git://vtk.org/VTK.git VTK
cd VTK
git checkout release

3. Cmake

The cmake configuration differs in some parts from the Unix cmake configuration. Since I’ve several different versions of gcc installed on my machine, I have to link to the one I’d like to use. If no backward compatibility to 10.5 is required, the best CMAKE_OSX_ARCHITECTURES is x86_64 and the usage of i386 caused errors after the compilation finished successfully.

 ccmake ../VTK -G "UNIX Makefiles"        \
	 	-DCMAKE_CXX_COMPILER:PATH=/usr/bin/c++-4.2 \
		-DCMAKE_C_COMPILER:PATH=/usr/bin/gcc-4.2 \
		-DVTK_USE_QVTK:BOOL=ON            \
		-DVTK_USE_COCOA:BOOL=ON          \
		-DVTK_USE_CARBON:BOOL=OFF          \
		-DCMAKE_BUILD_TYPE:STRING=Release \
		-DCMAKE_OSX_ARCHITECTURES:STRING=x86_64 \
		-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.6 \
		-DBUILD_SHARED_LIBS:BOOL=ON \
		-DPYTHON_EXECUTABLE:PATH=/usr/bin/python \
		-DCMAKE_INSTALL_PREFIX:PATH= \
		-DVTK_WRAP_PYTHON:BOOL=ON \
		-DVTK_USE_GUISUPPORT:BOOL=ON

After building the makefiles using this cmake configuration, I had to create a symbolic link to my python site-packages. The installation pointed to a wrong directory and I didn’t figure out which parameter I had to set to avoid this. Therefore:

sudo mkdir /lib/python2.6
sudo ln -s /Library/Python/2.6/site-packages /lib/python2.6/site-packages

Now I just compiled on 4 cores

make -j 4
sudo make install

4. Postinstallation

After the installation, some environmental variables in my $HOME/.bash_profile:

export LD_LIBRARY_PATH=/lib/vtk-5.6:$LD_LIBRARY_PATH
export PYTHONPATH=/Library/Python/2.6/site-packages:$PYTHONPATH
export DYLD_LIBRARY_PATH=/lib/vtk-5.6:$DYLD_LIBRARY_PATH

Done! Now python 2.6 runs with VTK.

slogin -X $user@$server

The plotting is done on that cluster and only the output is forwarded to my machine. For the plotting itself, I love to use gnuplot and its extensive functionality. As a output terminal for gnuplot, I use X11. It allows you to zoom into the data and customize the origin of the visual plot, without having to adjust the plotting parameters inside your gnuplot script.

Assume, that I would like to plot the second column over the first column of a file called forces.dat, the gnuplot file plot.gnp would look like:

reset
set xlabel 'Iterations'
set ylabel 'Force [N]'
plot 'forces.dat' using 1:2 with lines title 'not working plot'

Unfortunately, OpenFOAM stores the forces in a list of vectors. This means, that there are plenty of brackets inside that forces.dat file and gnuplot is not capable of ignoring these brackes. They need to be removed for the plotting, which can be done in several ways and I am using sed. But one question comes up to mind: What if I do not want to execute a load 'plot.gnp' each time, I want to update my plot, since new data is available?

For this purpose I am piping the output of this script directly into the plot and I do not need to store the ouput of  the small sed script (shown in a previous post) in an additional file:

plot "<./removeBrackets.sh" using 1:2 with lines

If you would want to visualize e.g. the residuals of a run, which are stored in the logfile of the solver, you are running, you can do the same with a grep, intead of a sed. Or you can use Bernhard’s pyFoam extension, which I highly recommend.

sed -e "s/[(,)]//g" $file > output

This comes in handy, if you need to plot data, that is located on a cluster or server and you do not want to transfer a 50MB file over the net just for plotting purposes.

Series snappyHexMesh

1. snappyHexMesh Tutorial
2. snappyHexMesh Tutorial Part 2
3. Snap edges with snappyHexMesh

Making use of snappyHexMesh for the mesh generation polarizes, some love it and some hate it. I personally switch between love and hate, depending on the efforts that need to be taken, to get a proper mesh. The major drawback of snappyHexMesh is that it does not respect sharp edges, but creates these jagged edges as shown in the picture above.

Up until today’s morning, I was pretty much convinced that there is no OpenSource tool for OpenFOAM, that enables snappyHexMesh to snap vertices to sharp edges. But then I’ve found this on the forum.

Niklas Nordin has written a tool called snapEdge, that provides exactly this missing functionality. He introduced his code with only a one sentence post.

I’ve written a little program that might help, I call it snapEdge.Niklas Nordin

Unfortunately, I’ve not had the time to try it, but from what I’ve read on the forum so far it looks pretty promising. As soon as I find the time to try it out, I’ll update this post.

1. Why?

NerdTree in action

This is an easy one. As you might know or at least guess, I am editing files on a HPC over the internet and this was a hassle with Textmate. Why? Because I had to mount the HPC‘s filesystem via my internet connection and edit the remote files with my local Textmate, which is a really bad idea. It just felt like sedated and still trying to get things done. I was in need of a proper alternative for doing such things, something that could be run in an ssh terminal window. I remembered vim from some administrative jobs on a server, I did some time ago and so I gave vim a try.

2. Textmate functionality in vim?

After having played around for a day or two with vim, I wondered if there is a replacement for my beloved Textmate functions, such as:

• Snippets
• command-t
• Projectdrawer
• bibtex completion
• reference completion for latex documents

There are so many plugins for vim, most likely you can find one for everything, you need to do. The Textmate snippet function can be replaced by vim’s snippets plugin, which provides a bunch of ready to use snippets for all my beloved languages (c++, python, tex).

An other awesome feature of Textmate is the so called command-t file navigation. This functionality is adopted to vim by the command-t plugin. In my honest opinion, this plugin is way better than the Textmate function, since it supports tabs and splits.

The projectdrawer in Textmate can be replaced in vim, using the NerdTree plugin, it even supports opening files in new splits, which is not supported in Textmate.

As Textmate offers a nice integration of bibtex bibliographies and latex typesetting and I use this for all my writing, I was anxious to find a way to use this in vim as well. I am currently using vim -latex, which is working quite well. Unfortunately I’ve found no way to display inline parsed equations in vim, like it is possible with emacs. If you know a way, please let me know (and no, switching to emacs is no option for me).

3. Conclusion after 10 months of usage

I don’t want to go back. I love the splits in vim, the fast editing and that there is no need to take the hands of the keyboard. Just pressing keys, lots of keys. By cloning the .vim folder and .vimrc file in my home directory to a git repository, I have the same vim configuration available on all machines I am using. Regardless of the architecture.

Series snappyHexMesh

1. snappyHexMesh Tutorial
2. snappyHexMesh Tutorial Part 2
3. Snap edges with snappyHexMesh

The first snappyHexMesh tutorial is more or less a little extended listing of the information gained from the OpenFOAM User’s Guide. This tutorial gives a brief view on how to setup the background mesh and how refinement regions should be configured. As an example, a container vessel is meshed within this tutorial. No prismatic boundary layer will be used for this tutorial.

Update 26.01.2012:
You can download the geometry of the KRISO Container Vessel (KCS) as STL from here. Thanks to Abe for reminding me to make the download available.

0. Prerequisities

Before we start, we need to take some prerequisities

1. Check the quality of the STL file. The surface needs to be as smooth as possible, without any humps.
2. Check the orientation of the STL file. Are the coordinate axes aligned correctly?
3. Check the position of the STL file. Is the origin of the STL file located, where it is supposed to be?
4. Check the scaling of the STL file. Guess…
5. Check the format of the STL file. It should be ASCII and not binary. You can have multiple surface groups in your STL file, but the naming should be without whitespaces, such as

    solid OBJECT
       facet normal 1 -0 0
       [...]

Not all features of snappyHexMesh are described within this article. Either have a look into the tutorials, that come with OpenFOAM, or read the first snappyHexMesh tutorial.

1. Background mesh

Since the entire mesh depends on the background mesh, some thoughts should be spent on the its design. As stated in [1]

The cell aspect ratio should be approximately 1, at least near surfaces at which the subsequent snapping procedure is applied [...]OpenFOAM User’s Guide [1]

Even though one can achieve convergence during the meshing process, if the backgroundmesh does not fullfill this requirement, maintaining the aspect ratio gives notable speedup to the meshing process. Depending on the layout of the computational domain, the number of final cells can be easily adjusted by tweaking the number of cells in the background mesh. Using the levels inside snappyHexMesh often leads to a massive increase of cells, even if the level is increased by only one. But more on this later.

Closup of the background mesh

The layout of the background mesh for the container vessel has been choosen as such, that there is no special refinement region and no grading. The last three cells (upstream of the outlet boundary) have a small grading and a different aspect ratio in x-direction, than all other cells, in order to damp wave before they may be reflected at the outlet. Unfortunately, this cannot be seen easily at this stage of the meshing process. Due to the spatial limits in vertical direction, the ascpect ratio of 1 could not be maintained.

2. snappyHexMeshDict

The next step is to adjust the snappyHexMeshDict, where multiple subdictionaries need to be edited and extended.

2.1 Geometry definition

As the first step, the geometry dictionary need to be updated. Since our ship is stored in a file called kcs.stl, we need to specify this.

kcs.stl
{
     type triSurfaceMesh;
     name hull;
}

Line 3 tells snappyHexMesh, that the STL file contains a triangulated surface mesh and a proper name for that geometry is assigned in line 4, which is used from now on to assign properties to that geometry.

If you need to take multiple phases into account, which is the case for a ship, the area where the free surface is expected needs an additional refinement, in order to resolve the free surface properly. A refinement region is used for this purpose. Several of the so called searchableObjects are implemented in snappyHexMesh, such as

• searchableSphere
• searchableBox
• searchableCylinder
• searchablePlate

For this tutorial, a searchableBox is used exclusively and defined reading

waterlineBox
{
    type searchableBox;
    min (-50 -20 -0.1);
    max (50 20 0.1);
}

2.2 castellatedMeshControls

Up to now, snappyHexMesh does only know the location and dimensions of some surface and volume objects. For the meshing process, the level of refinement and the direction relative to the surfaces/volumes need to be specified, which is done in the castellatedMeshControls subdictionary.

The refinement levels for the STL surfaces need to be specified. There is no theoretical nessecity to specify two different levels. But since the container vessel has lots of areas where the curvature does not change, larger cells can be applied there. SnappyHexMesh does this automatically. For this example, refinement levels for the ship between 4 and 5 have been choosen.

 refinementSurfaces
{
    hull
    {
         level (4 5);
    }
}
resolveFeatureAngle 60;

By tweaking the resolveFeatureAngle parameter, the areas between the surface refinement levels can be changed indirectly.

Cells that ‘see’ multiple intersections where the intersections make an angle > resolveFeatureAngle get refined up to the maximum level. snappyHexMeshDict from motorBike tutorial

Things to keep in mind:

• The refinement level of the surface should be as high as the highes refinement of the adjoining volume mesh.
• The surface mesh should be as homogeneous as possible. Large face size gradiens need to be avoided.

Since we are trying to obtain a volume mesh, we need to specify the refinement for the in section 1 defined volume regions. For our setup, we can specify multiple types of refinements:

1. Refinement normal to the surface of the geometry. Using this refinement, the mesh resolution near the geometry can be fine. Unfortunately this type of refinement may result in lots of fine cells in areas where we are not interested in, such as above the deck of the ship.
2. Refinement inside or outside of searchable objects. This type of refinement can be adjusted quite precisely to the special needs.

For this example the volume around the hull is refined using the distance method and the waterlineBox, which has been defined previously, is refined inside that box. Regardless of the method or mode, the refinement levels are specified in the same manner. The first number is the distance from the particular surface and the second number specifies the level, that the enclosed volume is refined up to. It is possible and sometimes practical to define multiple steps of refinement, say a high refinement (level 5) up to one meter away from the hull and a coarser refinement (level 4)  up to 2 meters way from the hull. To achieve this, you have to nest the levels sorted from low distances to high distances.

The inside mode needs a distance as well, but since we want to refine the entire box, a quite high value for this distance can be choosen.

 refinementVolumes
{
    hull
    {
        mode distance;
        levels ((4.5 4));
        //levels ((1 5)(2 4));   // Nested refinement
    }
    waterlineBox
    {
        mode inside;
        levels ((1e4 4));
    }
}

The usage of the locationInMesh parameter is pretty much self-explanatory, but that point must not be placed on a cell face of the background mesh and – of course – inside the mesh.

If snappyHexMesh has finished this meshing step, the refinements are more or less in place and all cells, that are inside the geometry and not inside the desired volume mesh, are removed. But not a single face has been snapped to the surface of the STL file. This happens in the next step

2.3 snapControls

Again, the snap controls are pretty much self explanatory, if you’ve read the tutorial provided by OpenFOAM

3. Survey the result

After having executed snappyHexMesh on a proper background mesh, you obtain up to three time step folders in your case. If you have three, snappyHexMesh has created a prismatic boundary layer on some of the surfaces. This will be covered by an additional tutorial. Since you need to examine your mesh, you should run checkMesh. If you are tweaking some parameters, you should send the output of checkMesh through a pipe into a file. After that run, change the parameters and run snappyHexMesh + checkMesh again, but save the checkMesh output into a different file. Now you can do a diff to figure out the differences.

snappyHexMesh
checkMesh -latestTime > run1
 
snappyHexMesh
checkMesh -latestTime > run2
diff run1 run2

Furtheron the mesh needs to be analyzed in paraFoam, especially the surface of the hull and the region close to that surface.

[1] OpenFOAM User’s Guide v.1.5

Völlig ausgehungert haben wir dann einen mexikanisches Restaurant überfallen und vorzüglich gespeist. Den krönenden Abschluss haben wir uns bei sternenklarem Himmel mit einer dicken Portion Schoko-Mint-Eis im Jacuzzi gegeben – ja, es könnte uns schlechter gehen… oder: geiler Tag!!

Da in der letzten Woche zweimal genau an unserem Parkplatz ein Auto aufgebrochen wurde, nehmen wir die Kamera nicht mit zum Strand. Deshalb gibt es leider noch keine Surfbilder

So sieht’s bei uns einen Tag vor dem ersten Advent aus: