Parameters

KHARMA has a large number of runtime parameters, which configure everything about its operation from physical theory to problem setup to debugging output.

Parameters are divided into blocks of related options. An individual parameter on the command line is denoted block/parameter_name=value e.g. to change the simulation end time, parthenon/time/tlim=100000 or whatever. Nearly all blocks are optional, with the exception of the <parthenon/x> blocks, <GRMHD>, and <coordinates>. Defaults are listed only when they seem relevant. Most booleans default to false.

<parthenon/job>

Any block beginning parthenon/ consists of global options, generally implemented by Parthenon and not KHARMA. The full list of Parthenon parameters is in the Parthenon documentation.

• problem_id is the name of the physical problem KHARMA will set up. It is also prefixed to all output files.
• archive_parameters creates a parameter file with all known runtime parameters, for reproducibility -- this way, defaults, runtime-changed parameters, or additional command line parameters are all captured in one file, the idea being that with this parameter file, and using the same commit of KHARMA, one can reproduce the same simulation. Note that regardless of this setting, a copy of this file is also included in every dump file, as the File attribute of the Input group.

<parthenon/mesh>

• refinement: none, static, or adaptive. Details of static or adaptive mesh refinement are specified in later blocks.
• numlevel: maximum total number of refinement levels to use, with 1 being no refinement.
• nx1, nx2, nx3: Size of the (base-level, Eulerian, evenly-spaced) mesh. KHARMA uses transformed coordinate systems to compress these where they are useful, see the <coordinates> block.

<parthenon/meshblock>

• nx1, nx2, nx3: size of a meshblock. Must evenly divide into the mesh size.

<coordinates>

These parameters detail the coordinate transformation between "native" coordinates (where the code evenly spaces zones and generally does its calculations) and the "embedding" coordinates (whatever simpler coordinate system covers the desired spacetime, e.g. spherical Kerr-Schild coordinates or Cartesian coordinates in Minkowski space). Note that extra parameters for a different

• base: spherical_ks aka ks, spherical_bl aka bl, spherical_minkowski, cartesian_minkowski aka minkowski. Base or "embedding" coordinates describing the desired space-time. The ks and bl systems describe a Kerr metric -- set a to zero for a Schwarzchild black hole. Several KHARMA forks implement more exotic metrics with various coordinate systems.
• transform: null aka none, exponential aka exp aka eks, superexponential aka superexp, modified aka mks, funky aka fmks, widepole aka wks. Coordinate transformations. Most transformations take the radial coordinate $r \rightarrow \log(r)$, with different strengths and modes of compressing zones in $\theta$. See the wiki page or Wong et al. for details of "modified" and "funky" systems. "Superexponential" is as described in Tchekhovskoy et al. and implemented in HARMPI. "Wide-pole" coordinates widen only the last zone next to the pole, and are described in full in Cho et al. Appendix C.
• ext_g: Whether to include an external gravity term, for certain very large-scale simulations (see Cho et al. eqn. 12)
• a: black hole spin, in the range $(-1, 1)$ for Kerr spacetimes
• r_br, npow, cpow: parameters for superexp; these and following parameters are coefficients in transformation formulae; consult the documentation above for specific meanings.
• hslope: parameter for mks. Defined negatively, so hslope = 1 corresponds to uniform spacing in $\theta$.
• mks_smooth, poly_xt, poly_alpha, fmks_zero_point: parametes for fmks. fmks_zero_point corresponds to startx1 on the wiki page -- it is used to make FMKS systems at different spin and radius more consistent, and avoid weird coordinate crossover in ghost zones.
• lin_frac, smoothness: parameters for wks

<parthenon/time>

Time steps and limits. Note KHARMA does not support all of the time-stepping options listed in Parthenon's documentation, as most were added very recently. Instead, it supports:

• tlim: simulation time limit
• nlim: maximum number of steps. 0 is valid, -1 sets an unlimited number of steps.
• use_dt_light: Use the light-crossing time as the timestep for safety, rather than computing it from signal speeds. Leads to much shorter timesteps early in a simulation, slightly shorter timesteps throughout.
• start_dt_light: Use the light-crossing time as the first timestep, but the signal speed thereafter.
• use_dt_light_phase_speed: Use the phase speed, rather than $c$, when calculating the light-crossing time
• dt: default/first timestep. Default: dt_min
• dt_min: minimum timestep. Default: 1e-5
• max_dt_increase: maximum proportional increase in dt from a step to the subsequent step. Default: 2.0

<GRMHD>

• cfl: Portion of the Courant-Friedrichs-Lewy stability maximum to use when setting the GRMHD timestep.
• gamma: Fluid adiabatic index. KHARMA supports only ideal equations of state with constant $\gamma$
• implicit: Evolve GRMHD variables semi-implicitly, solving for the next state including any time-dependent source terms. Turned on automatically when necessary, e.g. for Extended GRMHD simulations
• refine_tol, derefine_tol: minimum difference between the extrema of prims.rho before triggering refinement on an AMR grid. Maximum difference between extrema before derefining.
• sync_utop_seed: synchronize primitive variables, even when treating conserved variables as fundamental. This uses some MPI bandwidth but no latency, in order to ensure that primitive variable recovery happens identically in physical and ghost zones. Default: true

<flux>

• type: llf or hlle. Use the Local Lax-Friedrichs (LLF) flux common to HARM codes, or the more accurate but less stable Harten, Lax, van Leer and Einfeldt (HLLE) flux. KHARMA lacks a check for whether the latter is imaginary, which is not uncommon, so llf is default & recommended.
• reconstruction: donor_cell, donor_cell_c, linear_vl, linear_mc, weno5, weno5_linear, ppm, ppmx, or mp5. Reconstruction scheme used to find the values of primitive variables at faces, given values at adjacent cell centers. linear_mc and linear_vl use the monotonized central and Van Leer slope limiters, respectively. donor_cell_c is just an alternate implementation of donor_cell for testing and behaves identically. weno5_linear is a WENO5Z implementation which falls back to linear reconstruction according to smoothness indicators (Similar to WENO5-AO but simpler. "WENO5-AO at home," if you will). ppmx is extremum-preserving PPM. If you suspect the reconstruction of causing instabilities, fall back to linear_mc. Default: weno5
• low_order_edges, low_order_poles: use weno5 reconstruction over the interior domain, but linear_mc reconstruction on the x1 and x2 boundaries of the domain, respectively.
• reconstruction_floors: apply geometric floors to the reconstructed values at faces. Set by default for non-TVD reconstructions.
• reconstruction_fallback: use results of a TVD reconstruction to replace any values which would fall below geometric floors. Overrides reconstruction_floors if both are set.
• consistent_face_b: When using Face-CT magnetic transport, use the existing values of corresponding magnetic field components already defined at faces, rather than reconstructed values. This is how constrained transport schemes generally work, and it is a bad idea to turn this option off. Default: true

TODO