Skip to content

Flags

Jump to bottom
Alyssa Hayes edited this page Jun 7, 2025 · 32 revisions

Flag-Groupings.png

Operators

USE_IONIZATION = 0;

Value options:

  • 0: Ionization and recombination off
  • 1: Ionization and recombination on

If ionization and recombination are turned on, GITR expects reaction coefficients in gitrInput.cfg. The most common input file for this is a NetCDF file containing coefficients from ADAS, typically called ADAS_Rates.nc or something similar. Here is an example segment to achieve this in your gitrInput.cfg file. This segment should fall into the impurityParticleSource section.

    ionization =
    {
        fileString = "ADAS_Rates.nc";
        TempGridString = "n_Temperatures_Ionize";
        DensGridString = "n_Densities_Ionize";
        nChargeStateString = "n_ChargeStates_Ionize";
        TempGridVarName = "gridTemperature_Ionization";
        DensGridVarName = "gridDensity_Ionization";
        CoeffVarName = "IonizationRateCoeff";
    };

    recombination =
    {
        fileString = "ADAS_Rates.nc";
        TempGridString = "n_Temperatures_Recombine";
        DensGridString = "n_Densities_Recombine";
        nChargeStateString = "n_ChargeStates_Recombine";
        TempGridVarName = "gridTemperature_Recombination";
        DensGridVarName = "gridDensity_Recombination";
        CoeffVarName = "RecombinationRateCoeff";
    };

USEPERPDIFFUSION = 0;

Units: m^2/s

Value options:

  • 0: Anomalous perpendicular diffusion off
  • 1: Anomalous perpendicular diffusion on
  • 2: Anomalous perpendicular diffusion on and takes care of magnetic field curvature

If anomalous perpendicular diffusion is turned on, GITR expects Dperp, an anomalous perpendicular diffusion coefficient in gitrInput.cfg. The Diffusion segment belongs inside the backgroundPlasmaProfiles section and utilizes the profiles.nc file.

    Diffusion = 
        {    
        Dperp = 0.3;
        fileString = "profiles.nc";
        gridNrString = "nR";
        gridNzString = "nZ";
        gridRString = "r";
        gridZString = "z";
        variableString = "ni";
        };

USECOULOMBCOLLISIONS = 0;

Value options:

  • 0: Fokker-Planck Coulomb collisions off
  • 1: Fokker-Planck Coulomb collisions on

USETHERMALFORCE = 0;

Value options:

  • 0: Thermal gradient force correction off
  • 1: Thermal gradient force correction off

USESHEATHEFIELD = 0;

Value options:

  • 0: Brooks model of the sheath electric field used internally by GITR off
  • 1: Brooks model of the sheath electric field used internally by GITR on

USESURFACEMODEL = 0;

Value options:

  • 0: Self-sputtering and reflection off
  • 1: Self-sputtering and reflection on

If self-sputtering and reflection are turned on, GITR expects self-sputtering and reflection yields in gitrInput.cfg. This is inclusive to multi-species simulations. The most common input file for this is a NetCDF file containing coefficients from Fractal TRIDYN or RustBCA, typically called ftridynSelf.nc. Here is an example section to achieve this in your gitrInput.cfg file. This section is standalone.

surfaceModel = 
{
    fileString = "ftridynSelf.nc";
    nEsputtRefCoeffString = "nE";
    nAsputtRefCoeffString = "nA";
    nEsputtRefDistInString = "nE";
    nAsputtRefDistInString = "nA";
    nEsputtRefDistOutString = "nEdistBins";
    nEsputtRefDistOutStringRef = "nEdistBinsRef";
    nAsputtRefDistOutString = "nAdistBins";
    E_sputtRefCoeff = "E";
    A_sputtRefCoeff = "A";
    E_sputtRefDistIn = "E";
    A_sputtRefDistIn = "A";
    E_sputtRefDistOut = "eDistEgrid";
    E_sputtRefDistOutRef = "eDistEgridRef";
    Aphi_sputtRefDistOut = "phiGrid";
    Atheta_sputtRefDistOut = "thetaGrid";
    sputtYldString = "spyld";
    reflYldString = "rfyld";
    EDist_Y = "energyDist";
    AphiDist_Y = "cosXDist";
    AthetaDist_Y = "cosYDist";
    EDist_R = "energyDistRef";
    AphiDist_R = "cosXDistRef";
    AthetaDist_R = "cosYDistRef";
}

USE_SURFACE_POTENTIAL = 0;

Value options:

  • 0: Uses inbuilt Debye Sheath model in GITR
  • 1: Uses specified surface potentials (specified in gitrGeometryPointPlane3d.cfg)

If USE_SURFACE_POTENTIAL = 0, it uses the Debye sheath model built in GITR and overrides any other specified surface potentials. However, in some cases where surface potentials are specified externally (e.g. RF rectified sheath potentials) in gitrGeometryPointPlane3d.cfg as an input preprocessing, this flag is set to 1.

Geometry

USECYLSYMM = 0;

Value options:

  • 0: Extrude into a 3D (r,z,y) rectangular cartesian space
  • 1: Extrude into a 3D (r,z,t) toroidal space with cylindrical symmetry in the toroidal direction

Given a 2D geometry and 2D plasma profiles, USECYLSYMM will extrude both into 3D space, depending on whether a 0 or a 1 is assigned. If a 3D geometry is defined, USECYLSYMM will not override it. If 3D plasma profiles are defined, USECYLSYMM will not override them.

Vector Field Interpolators

BFIELD_INTERP = 0;

Units: T

Value options:

  • 0: Use dummy B-field values defined in gitrInput.cfg
  • 2: Interpolate 2D values for Br, Bt, and Bz in the (r,z) dimensions from bfield.nc
  • 3: Interpolate 3D values for Br, Bt, and Bz in the (r,z,y) or (r,z,t) dimensions from bfield.nc

GITR always expects B-field values in gitrInput.cfg.

The first section consists of 3 lines that define B-field dummy constants r, z, and y, which correspond to Br, Bz, and By and default to 0. If BFIELD_INTERP is set to 0, this will activate these constants to be applied across either the (r,z,y) or (r,z,t) dimensions, depending on the value of USECYLSYMM. The second section defines expected variable names for GITR to interpolate B-field values from bfield.nc. This section should not be changed. Here is an example segment to achieve this in your gitrInput.cfg file. This segment belongs inside the backgroundPlasmaProfiles section and utilizes the bfield.nc file.

    Bfield =
        {
        r = 0.0;
        z = 0.0;
        y = 0.0;
        fileString = "bField.nc";
        gridNrString = "nR";
        gridNzString = "nZ";
        gridRString = "r";
        gridZString = "z";
        rString = "br";
        zString = "bz";
        yString = "bt";
        interpolation = 2;
        filename = "Bfield_output";
        value = 1.0;
        variable_name = "Bfield_output";
        };

EFIELD_INTERP = 0;

Units: V

Value options:

  • 0: Use dummy E-field values defined in gitrInput.cfg
  • 2: Interpolate 2D values for Er, Et, and Ez in the (r,z) dimensions from profiles.nc
  • 3: Interpolate 3D values for Er, Et, and Ez in the (r,z,y) or (r,z,t) dimensions from profiles.nc

The first section consists of 3 lines that define E-field dummy constants Er, Ez, and Ey, which default to 0. If EFIELD_INTERP is set to 0, this will activate these constants to be applied across either the (r,z,y) or (r,z,t) dimensions, depending on the value of USECYLSYMM. The second section defines expected variable names for GITR to interpolate E-field values from profiles.nc. This section should not be changed. Here is an example segment to achieve this in your gitrInput.cfg file. This segment belongs inside the backgroundPlasmaProfiles section and utilizes the profiles.nc file.

    Efield = 
        {
        Er = 0.0;
        Ez = 0.0;
        Et = 0.0;
        fileString = "profiles.nc";
        gridNrString = "nR";
        gridNzString = "nZ";
        gridRString = "r";
        gridZString = "z";
        radialComponentString = "Er";
        axialComponentString = "Ez";
        toroidalComponentString = "Et";
        }

PRESHEATH_INTERP = 0;

Units: V

Value options:

  • 0: Use dummy presheath E-field values defined in gitrInput.cfg
  • 2: Interpolate 2D presheath E-field values in the (r,z) dimensions
  • 3: Interpolate 3D presheath E-field values in the (r,z,y) or (r,z,t) dimensions

DENSITY_INTERP = 0;

Units: m-3

Value options:

  • 0: Use dummy ni and ne density values defined in gitrInput.cfg
  • 2: Interpolate 2D values for ni and ne in the (r,z) dimensions from profiles.nc
  • 3: Interpolate 3D values for ni and ne in the (r,z,y) or (r,z,t) dimensions from profiles.nc

The first section consists of 2 lines that define dummy constants ni and ne, which default to 1.0E+19 m-3. If DENSITY_INTERP is set to 0, this will activate these constants to be applied across either the (r,z,y) or (r,z,t) dimensions, depending on the value of USECYLSYMM. The second section defines expected variable names for GITR to interpolate density values from profiles.nc. This section should not be changed. Here is an example segment to achieve this in your gitrInput.cfg file. This segment belongs inside the backgroundPlasmaProfiles section and utilizes the profiles.nc file.

    Density = 
        {    
        ni = 1.0E+19;
        ne = 1.0E+19;
        fileString = "profiles.nc";
        gridNrString = "nR";
        gridNzString = "nZ";
        gridRString = "r";
        gridZString = "z";
        IonDensityString = "ni";
        ElectronDensityString = "ne";
        };

TEMP_INTERP = 0;

Units: eV

Value options:

  • 0: Use dummy Ti and Te density values defined in gitrInput.cfg
  • 2: Interpolate 2D values for Ti and Te in the (r,z) dimensions from profiles.nc
  • 3: Interpolate 3D values for Ti and Te in the (r,z,y) or (r,z,t) dimensions from profiles.nc

The first section consists of 2 lines that define dummy constants Ti and Te, which default to 10 eV. If TEMP_INTERP is set to 0, this will activate these constants to be applied across either the (r,z,y) or (r,z,t) dimensions, depending on the value of USECYLSYMM. The second section defines expected variable names for GITR to interpolate temperature values from profiles.nc. This section should not be changed. Here is an example segment to achieve this in your gitrInput.cfg file. This segment belongs inside the backgroundPlasmaProfiles section and utilizes the profiles.nc file.

    Temperature = 
        {    
        ti = 10.0;
        te = 10.0;
        fileString = "profiles.nc";
        gridNrString = "nR";
        gridNzString = "nZ";
        gridRString = "r";
        gridZString = "z";
        IonTempString = "ti";
        ElectronTempString = "te";
        };

FLOWV_INTERP = 0;

Units: m/s

Value options:

  • 0: Use dummy flow velocity values defined in gitrInput.cfg
  • 2: Interpolate 2D values for flowVr, flowVy, and flowVz in the (r,z) dimensions from profiles.nc
  • 3: Interpolate 3D values for flowVr, flowVy, and flowVz in the (r,z,y) or (r,z,t) dimensions from profiles.nc

The first section consists of 3 lines that define dummy constants flowVr, flowVy, and flowVz, which default to 0. If FLOWV_INTERP is set to 0, this will activate these constants to be applied across either the (r,z,y) or (r,z,t) dimensions, depending on the value of USECYLSYMM. The second section defines expected variable names for GITR to interpolate flow velocity values from profiles.nc. This section should not be changed. Here is an example segment to achieve this in your gitrInput.cfg file. This segment belongs inside the backgroundPlasmaProfiles section and utilizes the profiles.nc file.

    FlowVelocity = 
        {    
        interpolatorNumber = 0;
        flowVr = 0.0;
        flowVy = 0.0;
        flowVz = 0.0;
        fileString = "profiles.nc";
        gridNrString = "nR";
        gridNzString = "nZ";
        gridRString = "r";
        gridZString = "z";
        flowVrString = "vr";
        flowVzString = "vz";
        flowVtString = "vp";
        };

GRADT_INTERP = 0;

Units: eV/m

Value options:

  • 0: Use dummy temperature gradient values defined in gitrInput.cfg
  • 2: Interpolate 2D values for temperature gradient values in the (r,z) dimensions from profiles.nc
  • 3: Interpolate 3D values for temperature gradient values in the (r,z,y) or (r,z,t) dimensions from profiles.nc

The first section consists of 6 lines that define dummy constants gradTeR, gradTeY, gradTeZ, gradTiR, gradTiY, and gradTiZ, which default to 0. If GRADT_INTERP is set to 0, this will activate these constants to be applied across either the (r,z,y) or (r,z,t) dimensions, depending on the value of USECYLSYMM. The second section defines expected variable names for GITR to interpolate flow velocity values from profiles.nc. This section should not be changed. Here is an example segment to achieve this in your gitrInput.cfg file. This segment belongs inside the backgroundPlasmaProfiles section and utilizes the profiles.nc file.

    gradT = 
        {    
        gradTeR = 0;
        gradTeY = 0;
        gradTeZ = 0;
        gradTiR = 0;
        gradTiY = 0;
        gradTiZ = 0;
        fileString = "profiles.nc";
        gridNrString = "nR";
        gridNzString = "nZ";
        gridRString = "r";
        gridZString = "z";
        gradTiRString = "gradTiR";
        gradTiYString = "gradTiY";
        gradTiZString = "gradTiZ";
        gradTeRString = "gradTeR";
        gradTeYString = "gradTeY";
        gradTeZString = "gradTeZ";
        }

File IO

FLUX_EA = 1;

Value options:

  • 0: Does not record or produce erosion and deposition data where surface=1 in the geometry input config file
  • 1: Records and produces erosion and deposition data in output/surface.nc for line segments where surface=1 in the geometry input config file

If FLUX_EA is turned on, GITR expects a flux section in gitrInput.cfg that contains the energy and angle bins, so that surface.nc can include the outgoing energy, sputtering, and reflection distributions. Here is an example segment to achieve this in your gitrInput.cfg file. This segment belongs inside the surfaces section.

    surfaces =
    {
        useMaterialSurfaces=1;
        flux =
        {
            nE=1000;
            E0 = 0.0;
            E = 10000.0;
            nA = 90;
            A0 = 0.0;
            A = 90.0;
        }
    }

Monte Carlo

FIXED_SEEDS = 1;

Value options:

  • 0: Uses random seeds
  • 1: Uses fixed seeds

Deprecated

  • USEPRESHEATHEFIELD
  • USEHEATING
  • USEANGLESCATTERING
  • BIASED_SURFACE
  • GENERATE_LC
  • LC_INTERP
  • OCEINT
  • FIELD_ALIGNED_VALUES
  • CHECK_COMPATIBILITY
  • FIXEDSEEDS
  • PARTICLE_SOURCE = 0
  • PARTICLE_SOURCE_SPACE = 0
  • PARTICLE_SOURCE_ENERGY = 0
  • PARTICLE_SOURCE_ANGLE = 0

Format for copypasting:

Value options:

  • 0:
  • 1:

If ##### is turned on, GITR expects ##### in gitrInput.cfg. The most common input file for this is a NetCDF file containing ##### from #####, typically called #####.nc. Here is an example segment to achieve this in your gitrInput.cfg file. This segment belongs inside the ##### section and utilizes the #####.nc file.

Developer Guide for Configuration Flags

relevant files:

these files:

include/config_interfaace.h src/config_interface.cpp

define these classes:

libconfig_string_query flags

for parsing the "flags" section of gitrInput.cfg

Description of functionality:

The file include/config_interface.h and src/config_interface.cpp contain the classes used to parse configuration flags. The input file gitrInput.cfg is in libconfig format, which is intended to be parsed by a software packaged called libconfig. The class called "libconfig_string_query" defines member functions that retrieve the value from a key/value pair found in a libconfig file. A libconfig_string_query class object is attached to a single libconfig file. The "flags" class defined in the include/config_interface.h uses a libconfig_string_query class in its constructor to fetch configuration flags from the "flags" section of the gitrInput.cfg input file. The "flags" class only contains integers as member variables. These integers represent the values of the corresponding flags in the gitrInput.cfg file. The value of each integer flag defined in the class as a member variable is set in the class constructor by querying the libconfig file using the libconfig_string_query class described above. A flags class object is defined at the beginning of src/gitr.cpp and is passed by value to any thrust functors that need to consult configuration options for control flow.

How to add or remove GITR configuration flags:

Adding a new flag requires modifying the flags class to add a new integer member variable to represent the value of the new configuration flag, and then modifying the class constructor to set the value of that member variable to the value that is given for it in the input file. The value in the input file can be obtained by using the libconfig_string_query class similarly to the other flags in the constructor. Non-integral data types such as strings cannot be member variables in the flags class. This is because the flags object is intended to be passed by value on the stack to thrust functions, which transfer their parameters to the device. Thrust does not support passing non-integral data types in classes to the device.

Clone this wiki locally