MFC: User’s guide

S. H. Bryngelson, K. Schmidmayer, T. Colonius

Division of Engineering and Applied Science,
California Institute of Technology,
1200 E California Blvd, Pasadena, CA 91125, USA
V. Coralic
Prime Air,
Amazon Inc.,
Seattle, WA 98108, USA
J. C. Meng
Bosch Research and Technology Center,
Sunnyvale, CA 94085, USA
K. Maeda
Department of Mechanical Engineering,
University of Washington,
Seattle, WA 98195, USA

1
Contents
1 Preliminary 2

2 Source code 2
2.1 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Installation 3
3.1 Step 1: Configure and ensure dependencies can be located . . . . . . . . . . . . . . . 3
3.1.1 Main dependencies: MPI and Python . . . . . . . . . . . . . . . . . . . . . . 3
3.1.2 Simulation code dependency: FFTW . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.3 Post process code dependency: Silo/HDF5 . . . . . . . . . . . . . . . . . . . 4
3.2 Step 2: Build and test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Configure Python master script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 How to run 9

5 Python input file 10

5.1 Dependencies and Logistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Input parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1 Job-scheduler parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.2 Computational domain parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.3 Patch parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.4 Fluid material’s parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.5 Simulation algorithm parameters . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2.6 Formatted database and structure parameters . . . . . . . . . . . . . . . . . . 18
5.2.7 (Optional) Acoustic source parameters . . . . . . . . . . . . . . . . . . . . . . 19
5.2.8 (Optional) Ensemble-averaged bubble model parameters . . . . . . . . . . . . 20

6 Flow visualization 21
6.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

A Boundary conditions 26

B Patch types 26

C Flux limiter 27

1
1 Preliminary
This document provides instructions for installation and configuration of MFC (Multi-component
flow code), a CFD-framework for simulation of compressible, multi-component fluid flows. The
reader is also pointed to a separate journal publication, Bryngelson et al. (2019) for a scientific
backgrounds and overview of MFC. MFC is licensed under the GNU GPLv3.

2 Source code
2.1 Documentation

The source code, located in the src/ directory, contains three components: pre process/,
simulation, and post process. These codes are all documented via Doxygen, which can be
located at https://mfc-caltech.github.io.

2.2 Naming conventions

The Fortran files ∗.f90 in the source code directories utilize the naming conventions found in
table 1.

2
 Variable Description
∗ sf Scalar field
∗ vf Vector field
∗ pp Physical parameters
∗[K,L,R] WENO-reconstructed cell averages
∗ avg Roe/arithmetic average
∗ cb Cell boundary
∗ cc Cell center
∗ cbc Characteristic boundary conditions
∗ cons ∗ Conservative
∗ prim ∗ Primitive
gm ∗ Gradient magnitude
∗ ndqp Normal direction Gaussian quadrature
points
∗ qp Cell-interior Gaussian quadrature points
un ∗ Unit-normal
dgm ∗ Curvature (derived gradient magnitude)
∗ icpp Initial condition patch parameters
∗ idx Indices of first and last (object)
cont ∗ Continuity equations
mom ∗ Momentum equations
E ∗ Total energy equation
adv ∗ Volume fraction equations
∗ id Identifier
dflt ∗ Default value
orig ∗ Original variable
q ∗ Cell-average conservative or primitive vari-
ables
q[L,R] ∗ Left[right] WENO-reconstructed cell-
boundary values
dq ∗ First-order spatial derivatives
∗ rs Riemann solver variables
∗ src Source terms
∗ gsrc Geometric source terms
[lo,hi] ∗ Related to TVD options
∗ IC Inter-cell
∗ ts Time-stage (for time-stepper algorithm)
wa ∗ WENO average
crv ∗ Geometrical curvature of the material in-
terfaces

Table 1: Code variables

3 Installation
The documents that describe how to configure and install the MFC are located in the source code
as CONFIGURE and INSTALL. They are also described here.

3.1 Step 1: Configure and ensure dependencies can be located

3.1.1 Main dependencies: MPI and Python

MacOS has Python pre-installed. If you do not have Python, it can be installed via Homebrew1 on
MacOS as:
1
Located at https://brew.sh

3
 # brew install python

or compiled via your favorite package manager on UNIX systems.

An MPI Fortran compiler is required for all systems. If you do not have one, Homebrew can take
care of this on MacOS:
# brew install open-mp

or compiled via another package manager on UNIX systems.

3.1.2 Simulation code dependency: FFTW

If you already have FFTW compiled, specify the location of your FFTW library and include files in
Makefile.user (fftw_lib_dir and fftw_include_dir)
If you do not have FFTW compiler, the library and installer are included in this package. Just:
# cd installers
# ./install_fftw.sh

3.1.3 Post process code dependency: Silo/HDF5

Post-processing of parallel data files is not required, but can indeed be handled with MFC. This is a
favorable option for parallel data visualization and analysis, which is described in section 6. For
this, HDF5 and Silo must be installed
On MacOS, a custom Homebrew tap for Silo is included in the installers/ directory. You can use
it via
# cd installers
# brew install silo.rb

This will install silo and its dependencies (including HDF5) in their usual locations (/usr/local/lib
and /usr/local/include)
On UNIX systems, you can install via a package manager or from source. On CentOS (also Windows
7), HDF5 binaries can be found online.2 To install them, open their archive in your intended location
via
# tar -zxf [your HDF5 archive]

Silo should be downloaded3 and installed via

# tar -zxf [your Silo archive]
# cd [your Silo archive]
# ./configure --prefix=[target installation directory] --enable-
pythonmodule --enable-optimization --disable-hzip --disable-fpzip
--enableportable-binary FC=mpif90 F77=mpif77 -with-hdf5=[your hdf5
directory]/include,/[your hdf5 directory]/lib --disable-silex
2
For example, https://support.hdfgroup.org/ftp/HDF5/current18/bin/
3
Located at: https://wci.llnl.gov/simulation/computer-codes/silo/downloads

4
 # make
# make install

Note that, depending on the environment and the version of Silo, a text file with a name of either
silo.inc (default) or silo_f9x.inc can be created in directly [your Silo directory]/include.
Once Silo is installed, the user is recommended to check the name of the text file, and specify the its
name of the file to include in the header of module /src/post_process_code/m_data_output.f90.
Add the following line to your ~/.bash_profile (creating this file if necessary):
# export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/[your silo directory]/
lib:/[your hdf5 directory]/lib

Finally:
# source ~/.bash_profile

You then need to modify silo lib dir and silo include dir in Makefile.user to point to
[your silo directory].

3.2 Step 2: Build and test

Once all dependencies have been installed, MFC can be built via
# make

from the MFC directory. This will build all MFC components. Individual components can be built
via
# make [component]

where [component] is one of pre process, simulation, or post process.

Once this is completed, you can ensure that the software is working as intended by
# make test

3.3 Configure Python master script

MFC uses a python-based interface. Python master script, /master_script/m_python_proxy.py,

contains a dictionary of input parameters and scripting function that interconnect procedures’
execution. Low-level access to the portable batch system (PBS) and Slurm Workload Manager
(Slurm) is also included through additional dictionary definitions and provides the MFC with parallel
run capabilities.
The user must prepare a separate python input file (input.py) for each case. The master script
receives the MFC component name (pre_process/simulation/post_process), the case dictionary,
the MFC location, and the engine configuration from the input file. The scripting function (located
in m_python_proxy.py) compiles the source code for the selected component (if not completed
already) and writes the component’s Fortran input file. A batch file will also be generated if the
parallel engine is used. If this is the case, the component’s executable will be executed via the

5
submitted PBS/Slurm batch file. Otherwise, it runs the executes the component directly in the
command-line.
Configurations of the job scheduler are often enviornment-dependent, and thus should be specified
in the scripting function f_create_batch_file.py in by the user when the MFC is installed in
a new environment. Examples are shown below, although configurations can vary and should be
modified as needed.
PBS example:

def f_create_batch_file(comp_name, case_dict, mfc_dir): # ----------------------

# Enabling access to the PBS dictionary

global pbs_dict

# Setting the location of the batch file

file_loc = comp_name + ’.sh’

# Opening and obtaining a handle for it

file_id = open(file_loc, ’w’)

# Populating Batch File ===================================================

file_id.write( \
\
# Script interpreter
’#!/bin/sh’ + ’\n’ \
\
# Account to be charged for the job:
’#PBS -A [account name]’ + ’\n’ \
\
# Name of the queue to which the job should be submitted:
’#PBS -q ’ + str(pbs_dict[’queue’]) + ’\n’ \
\
# Name of the job to be submitted to the scheduler:
’#PBS -N ’ + comp_name + ’\n’ \
\
# Node(s) and processor(s) per node (ppn) for job:
’#PBS -l nodes=’ + str(pbs_dict[’nodes’]) \
+ ’:ppn=’ + str(pbs_dict[ ’ppn’ ]) + ’\n’ \
\
# Maximum amount of time to commit to the execution of the job:
’#PBS -l walltime=’ + str(pbs_dict[’walltime’]) + ’\n’ \
\
# Declare the job rerunable (y) or non-rerunable (n)
’#PBS -r n’ + ’\n’ \
\
# Output standard output and error in a single file
’#PBS -j oe’
\
# Notify by email when job begins (b), aborts (a), and/or ends (e):

6
 ’#PBS -m bae’ + ’\n’ \
’#PBS -M ’ + str(pbs_dict[’mail_list’]) + ’\n’ \
\
# Total number of processor(s) allocated for job execution
’num_procs=$(cat $PBS_NODEFILE | wc -l)’ + ’\n’ \
\
# Moving to the case directory
’cd $PBS_O_WORKDIR’ + ’\n’ \
\
# Setting up the output file’s header information:
’echo MFC ’ + basename(getcwd()) \
+ ’: $PBS_JOBNAME.o${PBS_JOBID:0:7}’ + ’\n’ \
’echo Description: $PBS_JOBID executed on $num_procs ’ \
+ ’processor\’(s)\’. The’ + ’\n’ + ’echo ’ \
+ ’\’ \’ command-line output ’ \
+ ’information may be found below.’ + ’\n’ \
’echo Start-date: ‘date +%D‘’ + ’\n’ \
’echo Start-time: ‘date +%T‘’ + ’\n’ \
’echo’ + ’\n’ + ’echo’ + ’\n’ \
’echo \’================================ Terminal Output ’ \
+ ’===============================\’’ + ’\n’ + ’echo’ + ’\n’ \
\
# Starting the timer for the job execution
’t_start=$(date +%s)’ + ’\n’ \
\
# Executing job:
’mpirun ’ \
+ mfc_dir + ’/’ + comp_name \
+ ’_code’ + ’/’ + comp_name + ’\n’ \
# Stopping the timer for the job
’t_stop=$(date +%s)’ + ’\n’ + ’echo’ + ’\n’ \
\
# Setting up the PBS output file’s footer information
’echo \’=================================================’ \
+ ’===============================\’’ + ’\n’ \
’echo’ + ’\n’ + ’echo’ + ’\n’ \
’echo End-date: ‘date +%D‘’ + ’\n’ \
’echo End-time: ‘date +%T‘’ + ’\n’ + ’echo’ + ’\n’ \
’echo Total-time: $(expr $t_stop - $t_start)s’ + ’\n’ \
\
# Removing the input file
’rm -f ’ + comp_name + ’.inp’ + ’\n’ \
\
# Removing the batch file
’rm -f ’ + comp_name + ’.sh’ )
# END: Populating Batch File ===============================================

# Closing the batch file

file_id.close()

# Giving the batch file the permission to be executed

cmd_status = Popen(’chmod +x ’ + comp_name + ’.sh’, shell=True, stdout=PIPE)

7
 output, errors = cmd_status.communicate()
# END: def f_create_batch_file -------------------------------------------------

Slurm example:

def f_create_batch_file(comp_name, case_dict, mfc_dir): # ----------------------

# Enabling access to the PBS dictionary

global pbs_dict

# Setting the location of the batch file

file_loc = comp_name + ’.sh’

# Opening and obtaining a handle for it

file_id = open(file_loc, ’w’)

# Populating Batch File ===================================================

file_id.write( \
\
# Script interpreter
’#!/bin/sh’ + ’\n’ \
\
# Account to be charged for the job:
’#SBATCH -A [account name]’ + ’\n’ \
\
# Name of the queue to which the job should be submitted:
’#SBATCH -p ’ + str(pbs_dict[’queue’]) + ’\n’ \
\
# Name of the job to be submitted to the scheduler:
’#SBATCH -J ’ + comp_name + ’\n’ \
\
# Node(s) and processor(s) per node (ppn) for job:
’#SBATCH --nodes=’ + str(pbs_dict[’nodes’]) + ’\n’ \
’#SBATCH --ntasks-per-node=’ + str(pbs_dict[’ppn’]) + ’\n’ \
\
# Constrain allocated nodes to single rack for best code efficiency:
’#SBATCH --switches=1’ + ’\n’ \
\
# Maximum amount of time to commit to the execution of the job:
’#SBATCH -t ’ + str(pbs_dict[’walltime’]) + ’\n’ \
\
# Output standard output and error in a single file
’#SBATCH -o ’ + comp_name + ’.o%j’ + ’\n’ \
’#SBATCH -e ’ + comp_name + ’.o%j’ + ’\n’ \
\
# Notify by email when job begins (b), aborts (a), and/or ends (e):
’#SBATCH --mail-type=all’ + ’\n’ \
’#SBATCH --mail-user=’ + str(pbs_dict[’mail_list’]) + ’\n’ \
\

8
 # Setting up the output file’s header information:
’echo MFC ’ + basename(getcwd()) \
+ ’: $SLURM_JOB_NAME.o$SLURM_JOB_ID’ + ’\n’ \
’echo Description: $SLURM_JOB_ID executed on $SLURM_NTASKS ’ \

+ ’processor\’(s)\’. The’ + ’\n’ + ’echo ’ \

+ ’\’ \’ command-line output ’ \
+ ’information may be found below.’ + ’\n’ \
’echo Start-date: ‘date +%D‘’ + ’\n’ \
’echo Start-time: ‘date +%T‘’ + ’\n’ \
’echo’ + ’\n’ + ’echo’ + ’\n’ \
’echo \’================================ Terminal Output ’ \
+ ’===============================\’’ + ’\n’ + ’echo’ + ’\n’ \
\
# Starting the timer for the job execution
’t_start=$(date +%s)’ + ’\n’ \
\
# Executing job:
’mpirun ’ \
+ mfc_dir + ’/’ + comp_name \
+ ’_code’ + ’/’ + comp_name + ’\n’ \
# Stopping the timer for the job
’t_stop=$(date +%s)’ + ’\n’ + ’echo’ + ’\n’ \
\
# Setting up the PBS output file’s footer information
’echo \’=================================================’ \
+ ’===============================\’’ + ’\n’ \
’echo’ + ’\n’ + ’echo’ + ’\n’ \
’echo End-date: ‘date +%D‘’ + ’\n’ \
’echo End-time: ‘date +%T‘’ + ’\n’ + ’echo’ + ’\n’ \
’echo Total-time: $(expr $t_stop - $t_start)s’ + ’\n’ \
\
# Removing the input file
’rm -f ’ + comp_name + ’.inp’ + ’\n’ \
\
# Removing the batch file
’rm -f ’ + comp_name + ’.sh’ )
# END: Populating Batch File ===============================================

# Closing the batch file

file_id.close()

# Giving the batch file the permission to be executed

cmd_status = Popen(’chmod +x ’ + comp_name + ’.sh’, shell=True, stdout=PIPE)
output, errors = cmd_status.communicate()
# END: def f_create_batch_file -------------------------------------------------

4 How to run
MFC can be run by navigating to a case directory and executing the appropriate Python input file.
Example Python input files can be found in the example cases case directories and they are called

9
input.py. Their contents, and a guide to filling them out, are the subject of section 5. The MFC
can be executed as
# input.py pre_process

This will generate the restart_data directory that contains initial flow field and grid data files in
a binary data format. Then
# input.py simulation

will read the data files and execute the flow solver. The last (optional) step is to post treat the
binary data files and output Silo-HDF5 database for the flow variables via
# input.py post_process

This will generate silo_hdf5 that contains the database. This requires installation of Silo and
HDF5, as described in section 3.1.3.

5 Python input file

Python input file input.py defines dependencies and logistics, and input parameters for each
simulation case. In this section, details of the input file and how to edit it are described. The user
can also leverage the example input files as necessary.

5.1 Dependencies and Logistics

To specify dependencies and logistics, users are required to specify the directory of MFC and
computational engine. If the parallel engine is chosen, the python input file automatically generates
a batch job-script file and submits it to a job-schedule in the given environment.
Example of the Dependencies and Logistics:

#!/usr/bin/python

# Dependencies and Logistics ===========================

# Command to navigate between directories

from os import chdir

# Command to acquire directory path

from os.path import dirname

# Command to acquire script name and module search path

from sys import argv, path

# Navigating to script directory

if len(dirname(argv[0])) != 0: chdir(dirname(argv[0]))

# Adding master_scripts directory to module search path

mfc_dir = ’[MFC directory]’; path[:0] = [mfc_dir + ’/master_scripts’]

10
 # Command to execute the MFC components
from m_python_proxy import f_execute_mfc_component

# Serial or parallel computational engine

engine = ’parallel’
#engine = ’serial’
# =======================================================

MFC is optimized to work with a parallel engine. Nevertheless, if serial engine is specified, MFC
can be executed without using a job scheduler.

5.2 Input parameters

There are multiple sets of parameters that must be specified in the python input file:
1. Job scheduler parameters (see table 2).
2. Computational domain parameters (see table 3).
3. Patch parameters (see table 4).
4. Fluid material’s parameters (see table 5)
5. Simulation algorithm parameters (see table 6).
6. Formatted database and structure parameters (see table 7).
7. (Optional) Acoustic source parameters (see table 8).
8. (Optional) Ensemble-averaged bubble model parameters (see table 9).
Items 7 and 8 are optional sets of parameters that activate the acoustic source model and ensemble-
averaged bubble model, respectively. Definition of the parameters is described in the following
subsections.

5.2.1 Job-scheduler parameters

Parameter Type Description

case dir String Case script directory
run time info Logical Output run-time information
nodes Integer Number of nodes
ppn Integer Number of cores
queue String Queue name
walltime Time Maximum run time
mail list String Information sent to this email

Table 2: Job-scheduler parameters

Table 2 lists the job-scheduler parameters. The parameters are used to configure the batch file that
is submitted to a parallel job scheduler.
case dir specifies the directory where the python input file is located.
run time info generates a text file that includes run-time information including the CFL number(s)
at each time-step.

11
nodes and ppn specify the number of node and the number of cores per node used in parallel run.
The total number of processors used is thus given as nodes × ppn.
queue and walltime define the queue name and the maximum run time of the job. They must
be consistent with specific queue rules that are defined in a computer cluster/environment in that
MFC is installed.

5.2.2 Computational domain parameters

Parameter Type Description

x[y,z] domain%beg[end] Real Beginning [ending] of the x[y,z]-direction domain
stretch x[y,z] Logical Stretching of the mesh in the x[y,z]-direction
a x[y,z] Real Rate at which the grid is stretched in the x[y,z]-direction
x[y,z] a Real Beginning of the stretching in the negative x[y,z]-direction
x[y,z] b Real Beginning of the stretching in the positive x[y,z]-direction
cyl coord Logical Cylindrical coordinates (2D: Axisymmetric, 3D: Cylindrical)
m Integer Number of grid cells in the x-coordinate direction
n Integer Number of grid cells in the y-coordinate direction
p Integer Number of grid cells in the z-coordinate direction
dt Real Time step size
t step start Integer Simulation starting time step
t step stop Integer Simulation stopping time step
t step save Integer Frequency to output data

Table 3: Computational domain parameters

Table 3 lists the computational domain parameters. The parameters define the boundaries of the
spatial and temporal domains, and their discritization that are used in simulation.
x[y,z] domain%beg[end] define the spatial domain in x − y − z Cartesian coordinates:
x ∈[x domain%beg, x domain%end]; y ∈[y domain%beg, y domain%end]; z ∈[z domain%beg,
z domain%end].
m, n, and p define the number of finite volume cells that uniformly discritize the domain along the x,
y, and z axes, respectively. Note that the actual number of cells in each coordinate axis is given as
m[n, p] + 1. For example, m=n=p= 499 discretizes the domain into 5003 cells. When the simulation
is 2D/axi-symmetric or 1D, it requires that p= 0 or p=n= 0, respectively.
stretch x[y,z] activates grid stretching in the x[y, z] directions. The grid is gradually stretched
such that the domain boundaries are pushed away from the origin along a specified axis.
a x[y,z], x[y,z] a, and x[y,z] b are parameters that define the grid stretching function. When
grid stretching along the x axis is considered, the stretching function is given as:


xcb a x(xcb − x a) a x(xcb − x b)
xcb,stretch = xcb + log[cosh( )] + log[cosh( )]
ax L L

a x(x b − x a)
− 2log[cosh( )] , (1)
2L
where xcb and xcb,stretch are the coordinates of a cell boundary at the original and stretched domains,
respectively. L is the domain length along the x axis: L =x domain%end−x domain%beg. Crudely
speaking, x a and x b define the coordinates at which the grid begins to get stretched in the

12
negative and positive directions along the x axis, respectively. a x defines the smoothness of the
stretching. Stretching along the y and z axes follows the same logistics. Optimal choice of the
parameters for grid stretching is case-dependent and left to the user.
cyl coord activates cylindrical coordinates. The domain is defined in x-y-z cylindrical coordinates,
instead of Cartesian coordinates. Domain discritization is accordingly conducted along the axes
of cylindrical coordinates. Wnen p= 0, the domain is defined on x-y axi-symmetric coordinates.
In both Coordinates, mesh stretching can be defined along the x- and y-axes. MPI topology is
automatically optimized to maximize the parallel efficiency for given choice of coordinate systems.
Meng (2016)
dt specifies the constant time step size that is used in simulation. The value of dt needs to be
sufficiently small such that the Courant-Friedrichs-Lewy (CFL) condition is satisfied.
t step start and t step end define the time steps at which simulation starts and ends, respec-
tively. t step save is the time step interval for data output during simulation. To newly start
simulation, set t step start= 0. To restart simulation from k-th time step, set t step start= k.

5.2.3 Patch parameters

Parameter Type Description

num patches Integer Number of initial condition geometric patches
num fluids Integer Number of fluids/components present in the flow
geometry∗ Integer Geometry configuration of the patch (see table 11)
alter patch(i)∗ Logical Alter the i-th patch
x[y,z] centroid∗ Real Centroid of the applied geometry in the x[y,z]-direction
length x[y,z]∗ Real Length, if applicable, in the x[y,z]-direction
radius∗ Real Radius, if applicable, of the applied geometry
smoothen∗ Logical Smoothen the applied patch
smooth patch id∗ Integer A patch with which the applied patch is smoothened
smooth coeff∗ Real Smoothen coefficient
alpha(i)∗ Real Volume fraction of fluid i
alpha rho(i)∗ Real Partial density of fluid i
pres∗ Real Pressure
vel(i)∗ Real Velocity in direction i

Table 4: Patch parameters.

∗
These parameters should be prepended with patch icpp(j)% where j is the patch index.

Table 4 lists the patch parameters. The parameters define the geometries and physical parameters
of fluid components (patch) in the domain at initial condition. Note that the domain must be fully
filled with patche(s). The code outputs error messages when an empty region is left in the domain.
num patches defines the total number of patches defined in the domain. The number has to be a
positive integer.
num fluids defines the total number of fluids defined in each of the patches. The number has to
be a positive integer.
patch icpp(j)%geometry defines the type of geometry of j-th patch by using an integer from 1 to
13. Definition of the patch type for each integer is listed in table 11).
x[y,z] centroid, length x[y,z], and/or radius are used to uniquely define the geometry of the

13
patch with given type. Requisite combinations of the parameters for each type can be found in is
listed in table 11).
patch icpp(j)%alter patch(i) activates alternation of patch(i) with patch(j). For instance, in
a 2D simulation, when a cylindrical patch(2) is immersed in a rectangular patch(1),
patch icpp(1)%geometry= 3;
patch icpp(2)%geometry= 2;
patch icpp(2)%alter patch(1)=TRUE.
smoothen activates smoothening of the boundary of the patch that alters the existing patch. When
smoothening occurs, fluids of the two patches are mixed in the region of the boundary. For instance,
in the aforementioned case of the cylindrical patch immersed in the rectangular patch, smoothening
occurs when patch icpp(2)smoothen=TRUE. smooth coeff controls the thickness of the region
of smoothening (sharpness of the mixture region). The default value of smooth coeff is unity.
The region of smoothening is thickened with decreasing the value. Optimal choice of the value of
smooth coeff is case-dependent and left to the user.
patch icpp(j)alpha(i), patch icpp(j)alpha rho(i), patch icpp(j)pres, and
patch icpp(j)vel(i) define for j-th patch the void fraction of fluid(i), partial density of fluid(i),
the pressure, and the velocity in the i-th coordinate direction. These physical parameters must be
consistent with fluid material’s parameters defined in the next subsection. See also adv alphan in
table 6.

5.2.4 Fluid material’s parameters

Parameter Type Description

gamma Real Stiffened-gas parameter Γ of fluid
pi inf Real Stiffened-gas parameter Π∞ of fluid
Re(1)∗ Real Shear viscosity of fluid
Re(2)∗ Real Volume viscosity of fluid

Table 5: Fluid material’s parameters. All parameters should be prepended with fluid pp(i)% where i is the fluid
index.

∗
Parameters that work only with model eqns=2.

Table 5 lists the fluid material’s parameters. The parameters define material’s property of compress-
ible fluids that are used in simulation.
fluid pp(i)%gamma and fluid pp(i)%pi inf define Γ and Π as parameters of i-th fluid that are
used in stiffened gas equation of state.
fluid pp(i)%Re(1) and fluid pp(i)%Re(2) define the shear and volume viscosities of i-th fluid,
respectively. When these parameters are undefined, fluids are treated as inviscid. Details of
implementation of viscosity in MFC can be found in Coralic (2015).

14
5.2.5 Simulation algorithm parameters

Parameter Type Description

bc x[y,z]%beg[end] Integer Beginning [ending] boundary condition in the x[y,z]-direction
(negative integer, see table 10)
model eqns Integer Multicomponent model: [1] Γ/Π∞ ; [2] 5-equation; [3]
6-equation
alt soundspeed∗ Logical Alternate sound speed and K∇ · u for 5-equation model
adv alphan Logical Equations for all N volume fractions (instead of N − 1)
mpp lim Logical Mixture physical parameters limits
mixture err Logical Mixture properties correction
time stepper Integer Runge–Kutta order [1–5]
weno vars Integer WENO reconstruction on [1] Conservative; [2] Primitive
variables
weno order Integer WENO order [1,3,5]
weno eps Real WENO perturbation (avoid division by zero)
char decomp Logical Characteristic decomposition
mapped weno Logical WENO with mapping of nonlinear weights
null weights Logical Null WENO weights at boundaries
mp weno Logical Monotonicity preserving WENO
riemann solver Integer Riemann solver algorithm: [1] HLL∗ ; [2] HLLC; [3] Exact∗
avg state Integer Averaged state evaluation method: [1] Roe averagen∗ ; [2]
Arithmetic mean
wave speeds Integer Wave-speed estimation: [1] Direct (Batten et al. 1997); [2]
Pressure-velocity∗ (Toro 1999)
commute err†∗ Logical Commutative error correction via cell-interior quadrature
split err†∗ Logical Dimensional splitting error correction via cell-boundary
reg eps∗ Real Interface thickness parameter for regularization terms
flux lim∗ Integer Choice of flux limiter: [1] Minmod; [2] MC; [3] Ospre; [4]
Superbee; [5] Sweby; [6] van Albada; [7] van Leer.
tvd rhs flux∗ Logical Apply TVD flux limiter to intercell fluxes outside Riemann
solver
tvd riemann flux∗ Logical Apply TVD flux limiter to cell edges inside Riemann solver
tvd wave speeds∗ Logical TVD wave-speeds for flux computation inside Riemann solver

Table 6: Simulation algorithm parameters.

∗
Options that work only with model eqns= 2.
†
Options that work only with cyl coord=FALSE.

Table 6 lists simulation algorithm parameters. The parameters are used to specify options in
algorithms that are used to integrate the governing equations of the multi-component flow based
on the initial condition. Models and assumptions that are used to formulate and discritize the
governing equations are described in Bryngelson et al. (2019). Details of the simulation algorithms
and implementation of the WENO scheme can be found in Coralic (2015).
bc x[y,z]%beg[end] specifies the boundary conditions at the beginning and the end of domain
boundaries in each coordinate direction by a negative integer from -1 through -12. See table 10 for
details.
model eqns specifies the choice of the multi-component model that is used to formulate the dynamics
of the flow using integers from 1 through 3. model eqns=1, 2, and 3 correspond to Γ-Π∞ model
(Johnsen, 2008), 5-equation model (Allaire et al., 2002), and 6-equation model (Saurel et al., 2009),
respectively. The difference of the two models is assessed by (Schmidmayer et al., 2019). Note that
some code parameters are only compatible with 5-equation model.

15
alt soundspeed activates the source term in the advection equations for the volume fractions,
K∇ · u, that regularizes the speed of sound in the mixture region when the 5-equation model is
¯
used. The effect and use of the source term are assessed by Schmidmayer et al. (2019).
adv alphan activates the advection equations of all the components of fluid. If this parameter is
set false, the void fraction of N -th component is computed as the residual of the void fraction of
the other components at each cell:
N
X −1
αN = 1 − αi , (2)
i=1

where αi is the void fraction of i-th component. When a single-component flow is simulated, it
requires that adv alphan=TRUE.
mpp lim activates correction of solutions to avoid a negative void fraction of each component in
each grid cell, such that αi > ε is satisfied at each time step.
mixture err activates correction of solutions to avoid imaginary speed of sound at each grid cell.
time stepper specifies the order of the Runge-Kutta (RK) time integration scheme that is used for
temporal integration in simulation, from the 1st to 5th order by corresponding integer. Note that
time stepper=3 specifies the total variation diminishing (TVD), third order RK scheme (Gottlieb
and Shu, 1998).
weno vars specifies the choice of state variables that are reconstructed using a WENO scheme
by an integer of 1 or 2. weno vars=1 and 2 correspond to conservative variables and primitive
variables, respectively.
weno order specifies the order of WENO scheme that is used for spatial reconstruction of variables
by an integer of 1, 3, and 5, that correspond to the 1st, 3rd, and 5th order, respectively.
weno eps specifies the lower bound of the WENO nonlinear weights. Practically, weno eps< 10−6
is used.
char decomp activates projection of the state variables onto characteristic fields prior to WENO
reconstruction.
mapped weno activates mapping of the nonlinear WENO weights to the more accurate nonlinear
weights in order to reinstate the optimal order of accuracy of the reconstruction in the proximity of
critical points (Henrick et al., 2005).
null_weights activates nullification of the nonlinear WENO weights at the buffer regions out-
side the domain boundaries when the Riemann extrapolation boundary condition is specified
(bc x[y,z]%beg[end]= −4).
mp weno activates monotonicity preservation in the WENO reconstruction (MPWENO) such that
the values of reconstructed variables do not reside outside the range spanned by WENO stencil
(Balsara and Shu, 2000; Suresh and Huynh, 1997).
riemann solver specifies the choice of the Riemann solver that is used in simulation by an integer
from 1 through 3. riemann solver=1,2, and 3 correspond to HLL, HLLC, and Exact Riemann
solver, respectively (Toro, 2013).
avg state specifies the choice of the method to compute averaged variables at the cell-boundaries
from the left and the right states in the Riemann solver by an integer of 1 or 2. avg state=1 and

16
2 correspond to Roe- and arithmetic averages, respectively.
wave speeds specifies the choice of the method to compute the left, right, and middle wave speeds
in the Riemann solver by an integer of 1 and 2. wave speeds=1 and 2 correspond to the direct
method (Batten et al., 1997), and indirect method that approximates the pressures and velocity
(Toro, 2013), respectively.
commute err activates WENO reconstruction of the cell-averaged variables at the cell-interior
Gaussian quadrature points, following the two-point, fourth order Gaussian quadrature rule (Titarev
and Toro, 2004).
split err activates numerical approximation of the left or right cell-boundary integral-average
of the given variables by getting the arithmetic mean of their WENO-reconstructed values at the
cell-boundary Gaussian quadrature points, following the two-point, fourth order Gaussian quadrature
rule (Titarev and Toro, 2004). When commute err and split err are set TRUE and the 5th-order
WENO is used, the global order of accuracy of the spatial integration of the governing equations
becomes fourth order (Coralic and Colonius, 2014).
reg eps specifies the magnitude of interface regularization for two-component flows that prevents
diffusion of the phase interface (Tiwari et al., 2013). The default value of reg eps is unity. When
reg eps is undefined, interface regularization is not used. Details of implementation and assessment
are addressed in Meng (2016); Schmidmayer et al. (2019).
flux lim specifies the choice of flux limiter that is used in simulation by an integer from 1 through
7 as listed in table 12. When flux lim is undefined, flux limiter is not applied. Details of the
limiters and their implementations in MFC can be found in Meng (2016).
tvd_rhs_flux activates a specified flux limiter to inte-rcell fluxes outside Riemann solver.
tvd_riemann_flux activate a specified flux limiter to cell edges inside the Riemann solver.
tvd_rhs_flux and tvd_riemann_flux are mutually exclusive.
tvd_wave_speeds activates the use of the TVD wave speeds for flux computation inside the Riemann
solver when tvd_riemann_flux is set TRUE.

17
5.2.6 Formatted database and structure parameters

Parameter Type Description

format Integer Output format. [1]: Silo-HDF5; [2] Binary
precision Integer [1] Single; [2] Double
parallel io Logical Parallel I/O
cons vars wrt Logical Write conservative variables
prim vars wrt Logical Write primitive variables
fourier decomp Logical Apply a spatial Fourier decomposition to the output variables
alpha rho wrt(i) Logical Add the partial density of the fluid i to the database
rho wrt Logical Add the mixture density to the database
mom wrt(i) Logical Add the i-direction momentum to the database
vel wrt(i) Logical Add the i-direction velocity to the database
E wrt Logical Add the total energy to the database
pres wrt Logical Add the pressure to the database
alpha wrt(i) Logical Add the volume fraction of fluid i to the database
gamma wrt Logical Add the specific heat ratio function to the database
heat ratio wrt Logical Add the specific heat ratio to the database
pi inf wrt Logical Add the liquid stiffness function to the database
pres inf wrt Logical Add the liquid stiffness to the formatted database
c wrt Logical Add the sound speed to the database
omega wrt(i) Logical Add the i-direction vorticity to the database
schlieren wrt Logical Add the numerical schlieren to the database
fd order Integer Order of finite differences for computing the vorticity and the
numerical Schlieren function [1,2,4]
schlieren alpha(i) Real Intensity of the numerical Schlieren computed via alpha(i)
probe wrt Logical Write the flow chosen probes data files for each time step
num probes Integer Number of probes
probe(i)%x[y,z] Real Coordinates of probe i
com wrt(i) Logical Add the center of mass of fluid i to the database
cb wrt(i) Logical Add coherent body data of fluid i to the database

Table 7: Formatted database and structure parameters

Table 7 lists formatted database output parameters. The parameters define variables that are
outputted from simulation and file types and formats of data as well as options for post-processing.
format specifies the choice of the file format of data file outputted by MFC by an integer of 1 and
2. format=1 and 2 correspond to Silo-HDF5 format and binary format, respectively.
precision specifies the choice of the floating-point format of the data file outputted by MFC by an
integer of 1 and 2. precision=1 and 2 correspond to single-precision and double-precision formats,
respectively.
parallel_io activates parallel input/output (I/O) of data files. It is highly recommended to
activate this option in a parallel environment. With parallel I/O, MFC inputs and outputs a single
file throughout pre-process, simulation, and post-process, regardless of the number of processors
used. Parallel I/O enables the use of different number of processors in each of the processes (i.e.
simulation data generated using 1000 processors can be post-processed using a single processor).
cons vars wrt and prim vars wrt activate output of conservative and primitive state variables
into the database, respectively.
[variable’s name] wrt activates output of the each specified variable into the database.
schlieren_alpha(i) specifies the intensity of the numerical Schlieren of i-th component.

18
fd order specifies the order of finite difference scheme that is used to compute the vorticity from
the velocity field and the numerical schlieren from the density field by an integer of 1, 2, and 4.
fd order=1, 2, and 4 correspond to the first, second, and fourth order finite difference schemes,
respectively.
probe_wrt activates output of state variables at coordinates specified by probe(i)%x[y,z].
com_wrt(i) activates output of the center of mass of i-th fluid component into the database.
cb_wrt(i) activates output of the coherent body mass of i-th fluid component in the domain into
the database.

5.2.7 (Optional) Acoustic source parameters

Parameter Type Description

Monopole Logical Acoustic source
num mono Integer Number of acoustic sources
Mono(i)%pulse Integer Acoustic wave form: [1] Sine [2] Gaussian [3] Square
Mono(i)%npulse Integer Number of pulse cycles
Mono(i)%support Integer Type of the spatial support of the acoustic source : [1] 1D [2]
Finite width (2D) [3] Support for finite line/patch
Mono(i)%loc(j) Real j-th coordinate of the point that consists of i-th source plane
Mono(i)%dir Real Direction of acoustic propagation
Mono(i)%mag Real Pulse magnitude
Mono(i)%length Real Spatial pulse length

Table 8: Acoustic source parameters.

Table 8 lists acoustic source parameters. The parameters are optionally used to define a source
plane in the domain that generates an acoustic wave that propagates in a specified direction normal
to the source plane (one-way acoustic source). Details of the acoustic source model can be found in
Maeda and Colonius (2017).
Monopole activates the acoustic source.
num mono defines the total number of source planes by an integer.
Mono(i)%pulse specifies the choice of the acoustic wave form generated from i-th source plane by
an integer. Mono(i)%pulse=1, 2, and 3 correspond to sinusoidal wave, Gaussian wave, and square
wave, respectively.
Mono(i)%npulse defines the number of cycles of the acoustic wave generated from i-th source plane
by an integer.
Mono(i)%mag defines the peak amplitude of the acoustic wave generated from i-th source plane with
a given wave form.
Mono(i)%length defines the characteristic wavelength of the acoustic wave generated from i-th
source plane.
Mono(i)%support specifies the choice of the geometry of acoustic source distribution of i-th source
plane by an integer from 1 through 3:
Mono(i)%support= 1 specifies an infinite source plane that is normal to the x-axis and intersects
with the axis at x =Mono(i)%loc(1) in 1-D simulation.

19
Mono(i)%support= 2 specifies a semi-infinite source plane in 2-D simulation. The i-th source
plane is determined by the point at [Mono(i)%loc(1), Mono(i)%loc(2)] and the normal vector
[cos(Mono(i)%dir), sin(Mono(i)%dir)] that consists of this point. The source plane is defined in
the finite region of the domain: x ∈ [−∞, ∞] and y ∈[-mymono length/2, mymono length/2].
Mono(i)%support= 3 specifies a semi-infinite source plane in 3-D simulation. The i-th source
plane is determined by the point at [Mono(i)%loc(1), Mono(i)%loc(2), Mono(i)%loc(3)] and the
normal vector [cos(Mono(i)%dir), sin(Mono(i)%dir), 1] that consists of this point. The source
plane is defined in the finite region of the domain: x ∈ [−∞, ∞] and y, z ∈[-mymono length/2,
mymono length/2].

5.2.8 (Optional) Ensemble-averaged bubble model parameters

Parameter Type Description

bubbles Logical Ensemble-averaged bubble modeling
bubble model Integer [1] Gilmore; [2] Keller–Miksis
polytropic Logical Polytropic gas compression
thermal Integer Thermal model: [1] Adiabatic; [2] Isothermal; [3] Transfer
R0ref Real Reference bubble radius
nb Integer Number of bins: [1] Monodisperse; [> 1] Polydisperse
Ca Real Cavitation number
Web Real Weber number
Re inv Real Inverse Reynolds number
mu l0∗ Real Liquid viscosity (only specify in liquid phase)
ss∗ Real Surface tension (only specify in liquid phase)
pv∗ Real Vapor pressure (only specify in liquid phase)
gamma v† Real Specific heat ratio
M v† Real Molecular weight
mu v† Real Viscosity
k v† Real Thermal conductivity

Table 9: Ensemble-averaged bubble model parameters. These options work only for gas-liquid two component flows.
Component indexes are required to be 1 for liquid and 2 for gas.

∗
These parameters should be pretended with patch index 1 that is filled with liquid: fluid_pp(1)%.
†
These parameters should be pretended with patch indexes that are respectively filled with liquid and gas:
fluid_pp(1)% and fluid_pp(2)%.

Table 9 lists the ensemble-averaged bubble model parameters.’

bubbles activates the ensemble-averaged bubble model.
bubble model specified a model for spherical bubble dynamics by an integer of 1 and 2.
bubble model=1 and 2 correspond to the Gilmore and the Keller-Miksis equations, respectively.
polytropic activates polytropic gas compression in the bubble. When polytropic is set FALSE,
the gas compression is modeled as non-polytropic due to heat and mass transfer across the bubble
wall with constant heat and mass transfer coefficients based on (Preston et al., 2007).
thermal specifies a model for heat transfer across the bubble interface by an integer from 1 through
3. thermal=1, 2, and 3 correspond to no heat transfer (adiabatic gas compression), isothermal heat
transfer, and heat transfer with a constant heat transfer coefficient based on Preston et al. (2007),
respectively.
R0ref specifies the reference bubble radius.

20
nb specifies the number of discrete bins that define the probability density function (PDF) of the
bubble radius.
Ca, Web, and Re inv respectively specify the Cavitation number, Weber number, and the inverse
Reynolds number that characterize the offset of the gas pressure from the vapor pressure, surface
tension, and liquid viscosity when the polytropic gas compression model is used.
mu l0, ss, and pv, gamma v, M v, mu v, and k v specify simulation parameters for the non-
polytropic gas compression model. mu l0, ss, and pv correspond to the liquid viscosity, surface
tension, and vapor pressure, respectively. gamma v, M v, mu v, and k v specify the specific heat
ratio, molecular weight, viscosity, and thermal conductivity of a chosen component. Implementation
of the parameterse into the model follow Ando (2010).

6 Flow visualization
Post-processed database in Silo-HDF5 format can be visualized and analyzed using VisIt (Childs
et al., 2012). VisIt is an open-source interactive parallel visualization and graphical analysis tool for
viewing scientific data. Versions of VisIt after 2.6.0 have been confirmed to work with the MFC
databases for some parallel environments. Nevertheless, installation and configuration of VisIt can
be environment-dependent and are left to the user. Further remarks on parallel flow visualization,
analysis and processing of MFC database using VisIt can also be found in Coralic (2015); Meng
(2016).

6.1 Procedure

After post-process of simulation data (see section 4), a folder that contains a silo-HDF5 database is
created, named silo_hdf5. silo_hdf5 includes directory named root, that contains index files for
flow field data at each saved time step. The user can launch VisIt and open the index files under
/silo_hdf5/root. Once the database is loaded, flow field variables contained in the database (see
section 5.2.6) can be added to plot.
As an example, figure 1 shows the iso-contour of the liquid void fraction (alpha1) in the database
generated by example case 3D_sphbubcollapse. For analysis and processing of the database using
VisIt’s capability, the user is encouraged to address VisIt user manual4 .

4
https://wci.llnl.gov/simulation/computer-codes/visit/manuals

21
Figure 1: Iso-contour of the liquid void fraction (alpha1) in the database generated by example case
3D_sphbubcollapse.

22
Acknowledgements
This work was supported in part by multiple past grants from the US National Institute of
Health (NIH), the US Office of Naval Research (ONR), and the US National Science Foundation
(NSF), as well as current NIH grant number P01-DK043881 and ONR grant numbers N0014-17-
1-2676 and N0014-18-1-2625. The computations presented here utilized the Extreme Science and
Engineering Discovery Environment, which is supported under NSF grant number CTS120005. K.M.
acknowledges support from the Funai Foundation for Information Technology via the Overseas
Scholarship.

23
References
Allaire, G., Clerc, S., and Kokh, S. (2002). A five-equation model for the simulation of interfaces
between compressible fluids. Journal of Computational Physics, 181(2):577–616.
Ando, K. (2010). Effects of polydispersity in bubbly flows. PhD thesis, California Institute of
Technology.
Balsara, D. S. and Shu, C.-W. (2000). Monotonicity preserving weighted essentially non-oscillatory
schemes with increasingly high order of accuracy. Journal of Computational Physics, 160(2):405–
452.
Batten, P., Clarke, N., Lambert, C., and Causon, D. M. (1997). On the choice of wavespeeds for
the hllc riemann solver. SIAM Journal on Scientific Computing, 18(6):1553–1570.
Bryngelson, S. H., Schmidmayer, K., Coralic, V., Meng, J. C., Maeda, K., and Colonius, T. (2019).
Mfc: An open-source high-order multi-component, multi-phase, and multi-scale compressible flow
solver. arXiv preprint arXiv:1907.10512.
Childs, H., Brugger, E., Whitlock, B., Meredith, J., Ahern, S., Pugmire, D., Biagas, K., Miller, M.,
Harrison, C., Weber, G. H., Krishnan, H., Fogal, T., Sanderson, A., Garth, C., Bethel, E. W.,
Camp, D., Rübel, O., Durant, M., Favre, J. M., and Navrátil, P. (2012). VisIt: An End-User Tool
For Visualizing and Analyzing Very Large Data. In High Performance Visualization–Enabling
Extreme-Scale Scientific Insight, pages 357–372.
Coralic, V. (2015). Simulation of shock-induced bubble collapse with application to vascular injury
in shockwave lithotripsy. PhD thesis, California Institute of Technology.
Coralic, V. and Colonius, T. (2014). Finite-volume weno scheme for viscous compressible multicom-
ponent flows. Journal of computational physics, 274:95–121.
Gottlieb, S. and Shu, C.-W. (1998). Total variation diminishing runge-kutta schemes. Mathematics
of computation of the American Mathematical Society, 67(221):73–85.
Henrick, A. K., Aslam, T. D., and Powers, J. M. (2005). Mapped weighted essentially non-
oscillatory schemes: achieving optimal order near critical points. Journal of Computational
Physics, 207(2):542–567.
Johnsen, E. (2008). Numerical simulations of non-spherical bubble collapse: With applications to
shockwave lithotripsy. PhD thesis, California Institute of Technology.
Maeda, K. and Colonius, T. (2017). A source term approach for generation of one-way acoustic
waves in the euler and navier–stokes equations. Wave Motion, 75:36–49.
Meng, J. C. C. (2016). Numerical simulations of droplet aerobreakup. PhD thesis, California Institute
of Technology.
Preston, A., Colonius, T., and Brennen, C. (2007). A reduced-order model of diffusive effects on the
dynamics of bubbles. Physics of Fluids, 19(12):123302.
Saurel, R., Petitpas, F., and Berry, R. A. (2009). Simple and efficient relaxation methods for
interfaces separating compressible fluids, cavitating flows and shocks in multiphase mixtures.
journal of Computational Physics, 228(5):1678–1712.

24
Schmidmayer, K., Bryngelson, S. H., and Colonius, T. (2019). An assessment of multicomponent
flow models and interface capturing schemes for spherical bubble dynamics. arXiv preprint
arXiv:1903.08242.
Suresh, A. and Huynh, H. (1997). Accurate monotonicity-preserving schemes with runge–kutta
time stepping. Journal of Computational Physics, 136(1):83–99.
Thompson, K. W. (1987). Time dependent boundary conditions for hyperbolic systems. Journal of
computational physics, 68(1):1–24.
Thompson, K. W. (1990). Time-dependent boundary conditions for hyperbolic systems, ii. Journal
of computational physics, 89(2):439–461.
Titarev, V. A. and Toro, E. F. (2004). Finite-volume weno schemes for three-dimensional conservation
laws. Journal of Computational Physics, 201(1):238–260.
Tiwari, A., Freund, J. B., and Pantano, C. (2013). A diffuse interface model with immiscibility
preservation. Journal of computational physics, 252:290–309.
Toro, E. F. (2013). Riemann solvers and numerical methods for fluid dynamics: a practical
introduction. Springer Science & Business Media.

25
A Boundary conditions

# Description
−1 Periodic
−2

Normal
Reflective
−3 Ghost cell extrapolation
−4 Riemann extrapolation
−5 Slip wall
−6 Non-reflecting subsonic buffer

Characteristic.
−7 Non-reflecting subsonic inflow
−8 Non-reflecting subsonic outflow
−9 Force-free subsonic outflow
−10 Constant pressure subsonic outflow
−11 Supersonic inflow
−12 Supersonic outflow

Table 10: Boundary conditions.

The boundary condition supported by the MFC are listed in table 10. Their number (#) corresponds
to the input value in input.py labeled bc x[y,z]%beg[end] (see table 6). The entries labeled
“Characteristic.” are characteristic boundary conditions based on Thompson (1987) and Thompson
(1990).

B Patch types

# Name Dim. Smooth Description and required parameters

1 Line segment 1 N Requires x centroid and x length.
2 Circle 2 Y Requires x[y] centroid and radius.
3 Rectangle 2 N Coordinate-aligned. Requires x[y] centroid and x[y] length.
4 Sweep line 2 Y Not coordinate aligned. Requires x[y] centroid and normal(i).
5 Ellipse 2 Y Requires x[y] centroid and radii(i).
6 Vortex 2 N Isentropic flow disturbance. Requires x[y] centroid and radius.
7 2D analytical 2 N Assigns the primitive variables as analytical functions.
8 Sphere 3 Y Requires x[y,z] centroid and radius.
9 Cuboid 3 N Coordinate-aligned. Requires x[y,z] centroid and x[y,z] length.
10 Cylinder 3 Y Requires x[y,z] centroid, radius, and x[y,z] length.
11 Sweep plane 3 Y Not coordinate-aligned. Requires x[y,z] centroid and normal(i).
12 Ellipsoid 3 Y Requires x[y,z] centroid and radii(i).
13 3D analytical 3 N Assigns the primitive variables as analytical functions.

Table 11: Patch geometries

The patch types supported by the MFC are listed in table 11. This includes types exclusive to one-,
two-, and three-dimensional problems. The patch type number (#) corresponds to the input value
in input.py labeled patch icpp(j)%geometry where j is the patch index. Each patch requires a
different set of parameters, which are also listed in this table.

26
C Flux limiter
# Description
1 Minmod
2 MC
3 Ospre
4 Superbee
5 Sweby
6 van Albada
7 van Leer

Table 12: Flux limiter

The flux limiters supported by the MFC are listed in table 12. Each limiter can be specified by
specifying the value of flux_lim. Details of their implementations can be found in Meng (2016).

27