CCAPS : Cell Centred Approximate Projection Solver

Overview

CCAPS (Cell Centered Approximate Projection Solver) solves the incompressible flow equations

with the incompressible constraint

using a " projection method".

Currently can handle a uniform viscosity in the case of a homogenous fluid (where density is arbitrarily uniform and mass continuity is not actually solved), or an inviscid variable-density fluid.

In short, it consists of (1) an explicit treatment of the advection using a dimensionally-unspilt, second-order accurate finite volume method (higher order Godunov) and (2) simultaneous projection of the resulting velocities onto the constraint manifold and pressure update by the solution of a Poisson equation (at both the half-and full time levels).

Viscosity and variable density are built on top of this core idea.

Other separate versions of CCAPS exist for more specialised models, see also:

• CCAPS_atm_const a version of the code for time-independent background atmospheres in hydrostatic equilibrium in the Low Mach regime (which has a different divergence constraint / is not fully incompressible, but still sound-proof).

• CCAPS_vardens a slimmed-down version of CCAPS which always runs in variable-density mode.

Building the code

Currently uses cmake to produce a makefile with the proper linking etc.

• Make a directory to keep cmakes junk in
  • mkdir build
  • cd build
• Use cmake to produce a makefile (dont have to repeat this often, just if change compiler flags or add files to source), then run the makefile (do this every time you edit the source).
  • cmake ..
  • make
• You can also use cmake options for debugging here, e.g. instead of the above do
  • cmake -DCMAKE_BUILD_TYPE=Debug ..
  • make
• Move back up to the main directory and execute CCAPS
  • cd ..
  • ./bin/CCAPS
• There is a script to cleanup the output and the compiled binary
  • ./clean.sh
• And also scripts to automate some common build tasks
  • build.sh complete clean build with all compiler optimisations , deletes standard outputs.
  • debug.sh is as build.sh but with compiler debugging options.
  • make.sh which just cleans binaries, output and rebuilds (does not rerun cmake)

Editing the code setup and output

• No post-compile input decks - user setup required before compilation (don't worry, its lightweight and compiles fast).
• User should principally edit two files to configure a simulation:
• initial_conditions.f90 - set your conditions on the velocity field and other simulation data in a simple loop.
• control.f90 - user control variables and options (e.g., end time, max number of steps, grid and domain size, boundary conditions, slope limiters ...)
• subroutine setup_mg in setup.f90 can be edited to pass alternative boundaries to the multigrid solver for the projection and diffusion.
• user initial condiitons and control variables can be overwritten with pre-configured test cases by setting the appropriate logical in control.f90
• IO is basic at the moment - typical simple python image plots dumped at end of run. See diagnostics.f90 and the files in python_plotting for ideas if you need to modify.

Caution

• The code will let you set dx \neq dy in control.f90 but some of the equations have used them, so it isn't robust for an irregular grid (yet, and likely never).

The Algorithm

Currently, the core algorithm is more-or-less as described in Chapter 14 of Zingale's book.

The projections are handled via the SimpleCFD/multigrid module, details (including testing) are here

Viscosity is implemented as discussed in Bell, Coella and Howell 1991 except for using an approximate projection and different limiters. The viscous diffusion is accounted for implicitly, also using the multigrid method.

Density variation is incorporated in a sort-of-similar way to Bell and Marcus 1992 (different facings on variables are used, and viscosity is neglected). (https://doi.org/10.1016/0021-9991(92)90011-M).

Test Cases

These tests are built in and can be configured in initial_conditions.f90 and control.f90 in an obvious fashion (Minions test is the default setup).

Inviscid tests

Minions' Convergence Test

A simple doubly-periodic velocity field that has an analytical solution (simple translation in time). Allows computation of an error norm relative to the analytical solution, to act as a convergence test.

The following plot shows the L2 norm of CCAPS running with no gradient limiters:

which confirms the code has second-order convergence (the slope shown is the expected second order slope based on the error in the lowest resolution case).

Double-periodic shear layer

Write something insightful about this test here.

The output at t_end=1 with cfl=0.8 and nx=128 nx=ny

Note I haven't took care to make sure the divergent colour bars have the white set on zero, so there is an impression of lots of 'positive divergence/vorticity' outside of the shear layer concentrations - this isn't the case, its just that zero has been automatically assigned a pinkish colour instead of white. It actually does very well.

The above can also be compared to the pyro code's results for the same problem at http://python-hydro.github.io/pyro2/incompressible_basics.html

Viscous Tests

Lid-driven cavity

This is apparently a bit of a standard test for viscous incompressible flow. Ghia+82 is considered trustworthy and provides tabulated data as a point of comparison, which I use here.

The problem considers the case of no-slip (u=v=0, ZG pressure) boundaries on 3 faces and a constant driving of velocity 1 tangent to the other (which is impermeable to the normal coordinate). It should evolve towards a steady-state given the constant driving.

Lid-driven cavity: Velocity along central vertical cut

We compare velocity in the central vertical line (obtained by averaging the two cell centred data points to the left and right) to Table 1 of Ghai+82. Their table tabulates values of u on this cut at select points (i.e. not their whole discretisation, which is fairly-high resolution) for various Re. These selected data points are shown as blue, and all of the CCAPS actual data points for a given run are shown in red.

Re = 1e2, nx=ny=32

We get a steady state pretty quick and get good agreement with Table 1 of Ghia+ despite using significantly lower resolution (this is likely a clue that Re=1e2 is not hard to model). It seems to do just as well as the commercial code FLUENT

NB Ghia give edge centred values. I only show the cell centred in the domain, so there isn't a point u=1 at y=1 shown on the plot (but u=1 is indeed true at the boundary, its just the IO routines don't output the face vars / ghost vars)

Re = 1e3, nx=ny=32

Increasingly high Re is more challenging, but for 1000 it still does well in both the qualitative (compare the vortex / streamline structure to Ghia) and quantitative sense (the tabulated data). It even copes in the upper boundary layer (albeit its somewhat under-sampled, but the points appear to be where they should compared to Ghias points) which I was surprised at given the 32x32 resolution. It is however starting to deviate near the y_min boundary. Doubling the resolution to 64x64 gives good agreement however.

As the Re gets higher, this trend continues - the boundary layers require increasing resolution, but once this is achieved it does show agreement with the published results.

Overall, the no-slip boundaries on x_min, x_max, and y_min seem to work well, as does the driving on y_max. However, I really should run this test with different faces being the driven one. (i.e. the test gives me some confidence in the handling of viscous diffusion and the implementation of that particular combination of boundaries)

Variable density tests

Rayleigh Taylor instability