Oscillating Cylinder in Laminar Crossflow – pimpleDyMFoam

In this post I am going to simulate an oscillating cylinder in a cross-flow… just for fun… and to provide an additional tutorial case for those wishing to use some of the dynamic meshing features of OpenFOAM.

The case I am going to simulate is a cylinder in a Reynolds number 200 cross-flow (U=2 m/s, D=1 m, nu = 0.01 m^2/s), oscillating at a rate of 0.2 hz.

Tutorial Files

The tutorial files for this case can be downloaded from here:

Download Tutorial Files

Please let me know if the download does not work or if there is a problem running the tutorial files. Note: I ran this case in parallel on a relatively fast 6-core computer. It will take a long time if you try to run it as single core.

Mesh Generation

For this simulation, I built a simple two dimensional O-grid around the cylinder which joined to a series of blocks making a rectangular domain. I built this using the native OpenFOAM meshing utility blockMesh (which I like a lot).

Fig: Grid

If you are wondering about the blockMesh set up… I intend to a blockMesh tutorial post… not that it’s all that necessary since the OpenFOAM manual covers it pretty well.

Case Set-up


When running a dynamic mesh case a solver runs as part of the solution and solves for the new grid at each timestep. Several are available in OpenFOAM and I am not really trying to do a full post on that right now. So I’ll just tell you that in this case I decided to use the displacementLaplacian solver.

Along with the solver one must define the coefficients that go with the solver. For most of the solvers this means setting the diffusivity for the Laplace solver. Since I am relatively new to these types of solutions I did what we all do… and turned to the great CFD online forum! A discussion in this post (http://www.cfd-online.com/Forums/openfoam-meshing/97299-diffusivity-dynamicmeshdict.htm) made me think that a good starting point would be the inverseDistance model for the mesh diffusivity.

In the end my dynamicMeshDict (which belongs in the constant folder) looked like:

dynamicFvMesh dynamicMotionSolverFvMesh;

motionSolverLibs ( "libfvMotionSolvers.so" );

solver displacementLaplacian;

      diffusivity inverseDistance 1(cylinder);

The solver produces the grid movements through time as the simulation is performed. Here is what the mesh looks like while it is moving! I added the stationary mesh and the moving mesh. Click on them to get a clearer picture 🙂

Boundary Conditions

The set up for this case is simple. An inlet boundary (on the far left) where I specified the incoming velocity and pressure (both are uniform fixedValue). The top and bottom boundaries are slip boundaries (but could also be freestream depending on your preferred set-up style).

The cylinder itself requires some special treatment because of the moving mesh. It must obey the no-slip condition right? So do we set it as uniform (0 0 0) ? No! The cylinder is moving! Luckily there is a handy boundary condition for this in the U file:

      type movingWallVelocity;
      value uniform (0 0 0);

For a typical simulation using pimpleFoam a p and U file would be all that are required. However, since we are doing a moving mesh simulation there is another parameter that must be solved for and requires boundary conditions… pointDisplacement.

For the pointDisplacement boundary conditions, we know that all of the outer edges should NOT move. Therefore they are all fixed with a type of fixedValue and  a value of uniform (0 0 0).

The cylinder however is moving and requires a definition. In this simulation we are simulating and oscillating cylinder. Since we are using the displacement solver the type is oscillatingDisplacement. We input and omega (rad/s) and an amplitude (m) in the following way:

 type oscillatingDisplacement;
 omega 1.256; 
 amplitude (0 0.5 0); // Max piston stroke
 value uniform (0 0 0);


Yay! Now its time to look at the results. Well since I am not doing this for any particular scientific study… let’s look at some pretty pictures!

Here is an animation of vorticity:

Wake of Oscillating Cylinder

Looks pretty nice! I personally have a big nerd love for vortex shedding…. I don’t know why.

Obviously if you intend to do any scientific or engineering work with this type of problem you would need to think very carefully about the grid resolution, diffusivity model, Reynolds number, oscillation frequency  etc. All of these were arbitrarily selected here to facilitate the blog post and to provide a nice tutorial example!


In this post I briefly covered the set-up of this type of dynamic meshing problem. The main difference for running a dynamic mesh case is that you require a dynamic mesh solver (you must specify in the dynamicMeshDict), and you also require boundary conditions for that solver.

Let me know if there are any problems with this blog post or with the tutorial files provided.

Shocktube – rhoCentralFoam TVD Schemes Test

Careful selection of TVD interpolation schemes is important for solving high speed compressible flows. In cases with discontinuities such as shockwaves and contact surfaces, these schemes help keep the simulations free of spurious oscillations. In this post I will use the shock tube tutorial case to test some of the available schemes in OpenFOAM (specifically rhoCentralFoam).

I am going to test the following schemes: vanLeer, vanAlbada, and Gamma (0, 0.5 and 1). To test them, I will first simulate the tutorial case without changing anything. I will then examine how each of the limiters respond to an increase in grid density and also a decrease in CFL (Courant-Freidrichs-Levy) number … also the amazing Canadian Football League :).

Here is a summary of what I’ve found… then you can read through all the plots after!

  1. In all cases the results at a cell count of 100 showed oscillatory and therefore unsatisfactory results. As you should already know, grid resolution is important.
  2. At a CFL of 0.2, vanLeer in rhoCentralFoam was inconsistent. What I mean by this is when using vanLeer, as you refine your grid the results actually get worse! This is not desirable in a numerical scheme for obvious reasons.
  3. At a CFL of 0.1 vanLeer showed good results. This indicates that one should probably avoid using vanLeer unless you are committed to using small timesteps (more computing time).
  4. vanAlbada is consistent at both CFL numbers tested. This indicates that by using vanAlbada, it is possible that a larger CFL could be tolerated (assuming sufficient grid density is used).
  5. Gamma 0 – Corresponds to central differencing and therefore we expect it to be the least stable (and not total variation diminishing). This is confirmed by the results which are poor in all cases! Decreasing the CFL number helps but it is clear that different schemes should be used.
  6. Gamma 0.5 – Corresponds to hybrid central and upwind (TVD) differencing. The results are much better than Gamma 0.  In fact, the results are very similar to the results of vanLeer.
  7. Gamma 1 – Corresponds to fully TVD linear upwind interpolation. This scheme should be the most stable.  However, because it is only first order, higher grid resolution is required to get the best results. This is the compromise that must be made between stability and accuracy when using TVD schemes.

In my opinion, the two best options are vanAlbada and Gamma 1. vanAlbada most likely provides the best mix between accuracy and stability (at least for the case examined here). Gamma 1 provides the best option if stability is the most important thing to you. However, because it is first order you will need more cells to get the most accurate solution.

Details of the test case and all of the results are listed below! Hopefully somebody finds this useful. If I have anything wrong please let me know! If you want me to try more schemes or anything different let me know as well!



Shock-tube Case

If you aren’t familiar with the shock tube case, it is the simple one dimensional problem where one side (the driver side) begins at a high pressure. The other side (the driven side) is at a lower pressure. When the simulation begins, the discontinuous initial conditions send a shock wave down the tube. Following the shock wave is a contact surface. Here is an animation of the simulation:





  • 100, 1000, 10000 cells


  • 100, 1000, 10000 cell



  • 100, 1000, 10000 cells


  • 100, 1000, 10000 cells


Gamma 0

  • CFL=0.2

    • 100, 1000, 10000 cells
  •  CFL=0.1

    • 100, 1000, 10000 cells

Gamma 0.5

  • CFL=0.2

    • 100, 1000, 10000 cells
  •  CFL=0.1

    • 100, 1000, 10000 cells

Gamma 1

  • CFL=0.2

    • 100, 1000, 10000 cells
  •  CFL=0.1

    • 100, 1000, 10000 cells


Converging-Diverging Nozzle v2- rhoCentralFoam

Recently I read a CFD Online forum post where the accuracy of rhoCentralFoam was called into question.

The test case was the simple example of a converging diverging nozzle flow. In fact, I have already done a blog post regarding this. However, I tackled the problem using a large reservoir. In fact, it would have been more prudent to just simulate the nozzle and attempt to match the example from the NASA cfd benchmarking website:


So this is what I’ve done!

The case file can be found here:

Case File Download

The geometry in the case is an axi-symmetric converging diverging nozzle defined by a cosine function. I built the geometry and mesh in PointWise (just for the sake of time… I mean, I already did a detailed nozzle post). The result is here:

Fig: Geometry (generated using pointwise)

Three cases are calculated for comparison on the nasa site given above:

  1. Subsonic flow at exit (Pe/Po=0.89)
  2. Supersonic flow with shock wave in expanding section (Pe/Po=0.75)
  3. Supersonic flow at the exit (Pe/Po=0.16)

Case 1- Subsonic

For the subsonic case, it is important to remember that the outlet pressure MUST be set. Why? Because for a given nozzle geometry and stagnation pressure there is more than one possible solution since the flow is not choked!

The two most important boundary conditions here are the inlet and outlet. The inlet is specified using the totalPressure boundary condition (in my set-up P0=10000 Pa). You can also specify the total temperature. However, this will not affect the mach number or pressure profiles, only the velocity, density and temperature profiles. I set the temperature to be fixed at 298 K. The nozzle itself is an adiabatic, slip wall. The front and back are wedge types. The outlet is set to zeroGradient for velocity and temperature and the pressure is fixed to 8900 Pa (P/Po=0.89)

The results for pressure distribution and Mach number are shown here. Remember that since we are comparing P/Po and Mach number, it didn’t matter that I used a different pressure and temperature than the test case. I also included gifs showing the unsteady part of the simulation at the start.


Clearly the results match! Woohoo! One down, two to go!

Case 2- Supersonic with shock in diverging section

Tip for supersonic flow solution: Initialize the problem as a shock tube! Then the throat is choked right away in the simulation and convergence to the solution is faster!

In this case we must also specify the outlet pressure. Why? Because there are multiple solutions possible! Changing the back pressure changes the strength and location of the shock in the diverging section! So the setup is identical to the subsonic case for the inlet and nozzle. The only difference is that the outlet is set to 7500 Pa (P/Po=0.75).  In order to speed convergence, we can use the setFields utility to set the LHS of the nozzle to the stagnation pressure, and the RHS of the nozzle to the outlet pressure.

The results for pressure distribution and Mach number are shown here:


Hurray! Two for two!

Case 3- Supersonic Flow

The fully supersonic case is in fact the most simple. Recall that a supersonic nozzle is actually an initial value problem! This is in contrast to the subsonic cases, or cases with shocks, where they are boundary value problems (the outlet pressure controls the solution). But in order to achieve the supersonic flow solution we just set the outlet pressure to be zeroGradient. Additionally, we again start the solution as a shock tube.

So you might ask, but we were given a specified outlet pressure! Well, we CAN set this outlet pressure. But this unnecissarily restricts our solution. Having a back pressure very close to, but not exactly the same as the actual supersonic outlet pressure could make things difficult. It is much easier to let the solution converge to where IT THINKS the right answer is. Then, how closely we match the outlet pressure is in fact an indicator of the quality of our solution!

Here are the results:

Three for three! rhoCentralFoam has passed the test.

As always comment and correct me where my mouth (or keyboard) has made error.