The Basic Knowledge of AMRVAC – 4. Parameters

In this note, I will briefly introduce the amrvac.par file, another important file for all kinds of settings. This file is used to set all the parameters, and actually all these parameters have their default value. As a result, I will just introduce some parameters often used and kind of important.

&filelist

 

Parameter	Type	Default value	Other presets
base_filename	string	‘data’	–
AMRVAC will output some data files during the running. This parameter tells AMRVAC the prefix of your output data filename, by default you will get results like ‘dataXXXX.dat’, where XXXX is 4-digit numbers determined by AMRVAC.
convert_type	string	‘vtuBCCmpi’	‘tecplot’ ‘tecplotCC’ ‘tecline’ ‘tecplotmpi’ ‘tecplotCCmpi’ ‘teclinempi’ ‘vtu’ ‘vtuCC’ ‘vtumpi’ ‘vtuCCmpi’ ‘vtuB’ ‘vtuBCC’ ‘vtuBmpi’ ‘pvtumpi’ ‘pvtuCCmpi’ ‘pvtuBmpi’ ‘pvtuBCCmpi’ ‘vtimpi’ ‘vtiCCmpi’ ‘onegrid’ ‘onegridmpi’ ‘oneblock’ ‘oneblockB’ ‘user’ ‘uesrmpi’
It defines which format to use when converting. Basically, we have vtu and tecplot these two types used for visualization, while vtu is recommend if you use ParaView. Types with CC means output cell center values while without CC means corner valuse, types with B means output data will be binary files while others are ASCII files, types without mpi cannot be converted using multi processors so that types with mpi are recommended, types with a prefix p will result in a .vtu file for each processor (what’s the usage ?). Other types are onegird.
saveprim	logical	.false.	.true.
If true, AMRVAC will output primitive variables instead of conservative ones
autoconvert	logical	.false.	.true.
If true, AMRVAC will automatically convert to output format during the run. It will save time and would be convenient for small-scale runs, but for large-scale runs, according to my experience, it is not recommended. You’d better download the raw data and convert it locally instead of doing autoconvert on clusters. It will cost much time and occupy too much space.
nwauxio	integer	0	–
AMRVAC could output auxiliary variables in addition with basic variables like density, velocity or something else, for example, temperature. This could be done by setting subroutines usr_aux_output and usr_add_aux_names in the mod_usr.t file. I will give an introduce to it in later notes. Then, nwauxio = the number of additional variables, which should be the same with what you write in the mod_usr.t file.

&savelist

Parameter	Type	Default value	Other presets
dtsave_dat	double precision	bigdouble	–
AMRVAC will repeatedly save .dat files when ‘dtsave_dat’ simulation time has passed. However, the final output is always saved after the stop condition has been fulfilled.
dtsave_log	double precision	bigdouble	–
AMRVAC will repeatedly save information in a log file when ‘ditsave_log’ time steps have passed. However, the final output is always saved after the stop condition has been fulfilled.
itsave(SAVEINDEX,FILEINDEX)	integer	0	–
It tells AMRVAC to save data file with certain FILEINDEX and SAVEINDEX at the given iteration step. AMRVAC provides 5 types of output data which is corresponding to the parameter FILEINDEX here, 1 = Log output, 2 = Normal output, 3 == Slice output, 4 = Collapsed output, 5 = Call user custom analysis subroutine, e.g., subroutine usr_write_analysis in mod_usr.t file. 3-5 will be introduced in later note. Here, we suppose FILEINDEX = 2. While for the SAVEINDEX, it is simply the index of your output data. For example, you want to save snapshots more frequently at the beginning of the simulation. You can set ‘tsave(1,2)=0.1 tsave(2,2)=0.25 tsave(3,2)=0.5, dtsave_dat=0.5’ and then it will save snapshots at times 0.1, 0.25, 0.5, 1, 1.5, … etc. And usually, a itsave(1,2)=0 is used to save the initial state.

&stoplist

Parameter	Type	Default value	Other presets
time_max	double precision	bigdouble	–
AMRVAC will stop simulation when the physical time reaches ‘time_max’.

&methodlist

Parameter	Type	Default value	Other presets
time_integrator	nlevelshi strings	‘twostep’	‘onestep’ ‘threestep’ ‘rk4’ ‘fourstep’ ‘ssprk43’ ‘ssprk54’
Choose the temporal discretization method used in AMRVAC, it will be discussed in later notes.
flux_scheme	nlevelshi strings	‘hll’	‘hllc’ ‘hlld’ ‘hllcd’ ‘tvdlf’ ‘tvdmu’ ‘tvd’ ‘cd’ ‘fd’ ‘source’ ‘nul’
Choose a scheme to calculate the flux at cell interfaces used for each “level” of grids in AMRVAC. Concepts related to “level” will be introduced in the next part. While details of the methods will be discussed in the later notes.
limiter	nlevelshi strings	‘minmod’	‘woodward’ ‘superbee’ ‘vanleer’ ‘albada’ ‘ppm’ ‘mcbeta’ ‘koren’ ‘cada’ ‘cada3’ ‘mp5’ ‘ppm’ ‘source’ ‘nul’
Limiter here refers to the so-called flux limiter here. They are chosen here for different level of grids. However, this term is based on some certain spatial discretization method, and actually I don’t think they are proper to all the methods here. The details will be discussed in later notes.

Before we going on the the &boundlist and &meshlist, we have to give a short discussion about the concept of blocks in AMRVAC. We take 2D simulation box for example. Suppose we have a 32 x 32 grids simulations box. We can divide it into four 16 x 16 grids per part, each of them is a single block. Then AMRVAC will distribute these blocks to different processors to realize parallel computing.

However, the blocks in different processors is not irrelevant, there should be some communication during every single step near the boundary of each block. These boundary cells are called “ghostcells”, whose value depend on the scheme you use, which is usually 2, which means you have to transport the value in the 2 cells nearest to the boundary to the adjacent block.

Here follows the concept of Adaptive mesh refinement (AMR). It is a method adapting the accuracy of a solution within certain sensitive or turbulent regions of simulation, dynamically and during the time the solution is being calculated. In AMRVAC, it is realized simply by for example, in 2D case, divide a square into four squares or combine them back to a single one.

&boundlist

Parameter	Type	Default value	Other presets
typeboundary_min^D typeboundary_min^D	nw strings	‘cont’	‘symm’ ‘asymm’ ‘periodic’ ‘noinflow’ ‘special’
You can set different types of boundary conditions for different variables. ‘cont’ refers to continuous, means simply copy the value of the inner block to the outer block. ‘symm’ and ‘asymm’ mean symmetric and asymmetric boundary conditions, ‘periodic’ is obviously periodic condition, ‘noinflow’ is basically ‘cont’ but the velocity component would be set to zero if it is an positive value for minimum boundaries or vice verse. When it is set to ‘special’, remember that principally you show set all the variables in this boudary to be ‘special’, do not write write kind of ‘cont’, 7*’special’, which is not recommended. When using ‘special’ conditions, you should write a subroutine usr_special_bc in the mod_usr.t file. The details will be talked about in the later note.

&meshlist

Parameter	Type	Default value	Other presets
refine_max_level	integer	1	–
It indicates the maximum number of grid refine levels that can be used during the simulation. If it is set to 1, no refinement or no AMR will be done. Usually it will be 2 or 3, and sometimes 4 or 5, but 6 or larger is not recommended unless in the future we have much more powerful computers.
domain_nx^D	integer	32	–
This parameter is the number of total grids in the ^D direction, so that it defines the base grid resolution (i.e. on the coarsest level 1).
block_nx^D	integer	16	–
This parameter is the number of grids in one block in the ^D direction. Obviously, domain_nx^D should be divide exactly by its corresponding block_nx.
xprobmin^D xprobmax^D	integer	–	–
The physical scale of the full computational domainin each direction.
refine_criterion	integer	3	0 1 2
0: all refinement solely based on user routine usr_refine_grid；1：simply compare w_n-1 with w_n and trigger refinement on relative differences；2：Error estimation is based on Lohner’s original scheme；3：Error estimation is based on Lohner’s scheme.