Creating a SaltProc input file¶

The SaltProc input file passes three categories of information to the program:

Paths to files that describe the reprocessing system
Paths to template files for the transport code.
Depletion settings

In the following sections, we will create an example SaltProc input file, and explain the purpose for each input variable. For a more detailed breakdown of the inputs, check the Input Files page.

Creating a JSON file¶

JSON files themselves are not that complicated. They consist of key-value pairs, much like a dictionary in Python. The entire JSON files needs to be wrapped with curly brackets, so we start our file like so:

{

}

Base paremters¶

There are two required base parameters: proc_input_file, a path to the file that defines processes, and dot_input_file, a path to the file that defines the process graph. We will learn how to create these files in the next chapter, but for now we just need to specify a path. We recommend storing all the input files in the same directory, but this is not requried.

Let’s name our process file processes.json and the process graph file graph.dot:

{
    "proc_input_file": "processes.json",
    "dot_input_file": "graph.dot"
}

Transport code parameters¶

As explained in methods_coupling, SaltProc uses template files provided by the user to create runtime files that are used as inputs to the transport code for each depletion step. The depcode setting in the SaltProc input file store paths to these template files, as well as other settings. The only two input parameters that have the same format for different transport codes are codename and geo_file_paths. codename is a string that indicates the transport code you are using. Accepted values are lowercased versions of the supported transport code (e.g. “serpent”, “openmc”). geo_file_paths is a list of paths to geometry files 1. At least one path to a geometry file must be given, and for the purposes of this guide this is sufficient.

Let’s briefly break down the minimum requirements for each supported transport code.

Serpent2¶

Only two additional parameters are needed for Serpent2 coupling:

template_input_file_path: A path to a template input file. We describe the structure of this file in Serpent 2 Template Files.
zaid_convention: A string that tells SaltProc what convention to use for the ZAIDs of metastable isotopes. By default, SaltProc uses the mcnp convention.

Let’s assume that we name our template input file template.serpent. If we have verified that we are okay to use the default value for zaid_convention, then we have:

{
    "proc_input_file": "processes.json",
    "dot_input_file": "graph.dot",
    "depcode": {
        "codename": "serpent":
        "geo_file_paths": ["geometry.ini"],
        "template_input_file_path": "template.serpent"
    }
}

OpenMC¶

The OpenMC inputs are more complicated. There are two reasons for this:

OpenMC uses separate input files for material, geometry, settings, and tally parameters, and uses strict naming for these input files.
Configuring OpenMC’s depletion capabilities must be done via the Python API, so what normally would be handled in the template input file must be handled directly in the SaltProc input file.

Fortunately, SaltProc doesn’t require users to touch these setting at all if they want to use the default options. Users interested in configuring their OpenMC depletion settings should advise the deplete module API as well as the user guide section on depletion to familiarize themselves with the various options, then look at the options in depletion_settings.

The depcode paramter for OpenMC also has the template_input_file_path parameter, except it is an object that in turn requires two file paths: materials for the materials file, and settings for the settings file. There is an additonal required parameter, chain_file_path which is a path to an OpenMC depletion chain file. Suppose we prepend template_ to the names of our OpenMC input files:

{
    "proc_input_file": "processes.json",
    "dot_input_file": "graph.dot",
    "depcode": {
        "codename": "openmc":
        "geo_file_paths": ["geometry.xml"],
        "template_input_file_path": {
            "materials": "template_materials.xml",
            "settings": "template_settings.xml"
        },
        "chain_file_path": "chain_simple.xml"
    }
}

Simulation parameters¶

Most users will only need to set the sim_name parameter. In this case, we can just pick "saltproc_example":

{
    "proc_input_file": "processes.json",
    "dot_input_file": "graph.dot",
    "depcode": {},
    "simulation": {
        "sim_name": "saltproc_example"
    }
}

There are two optional parameters that are important to make note of:

restart_flag: If a simulation fails before all the depletion steps have been calculated, the users can set restart_flag to true to run the simulation staring the last completed depletion step
adjust_geo: Setting adjut_geo to true will instruct SaltProc to switch to the next geometry file in geo_file_paths when \(k_\text{eff}\) drops below 1.

Depletion step parameters¶

In general, depletion parameters other than the defualts (e.g. timestepper method, solver used for the Bateman equations, normalization, etc.) should be set in the template input file when possible. The rationale for this is that these settings have more to do with the internal depletion calculations of the transport code than they do with SaltProc execution. The obvious exception to this are the delpletion step settings.

The reactor parameter provides four parameters to specify depletion settings:

power_levels: This property describes the power level at each depletion timestep. If a user wants to use the same power level for each depletion timestep, they can pass a singleton list instead and set n_depletion_steps.
depletion_timesteps: This property described the length of each depletion step.
timestep_type: The value of this property (cumulative or stepwise) tells SaltProc how to interpret depletion_timesteps. If cumulative, each value in depletion timesteps is assumed to be an absolute time, so the depletion step lengths are the differences between consecutive entries. If stepwise, each value in depletion_stimesetps is assumed to be the length of each depletion step. stepwise is the default value for this parameter.
timestep_units: This parameter specifies the units for depletion_timesteps

Let’s assume we want to run a depletion simultion for 36 days using 3-day timesteps at 1000MW:

{
    "proc_input_file": "processes.json",
    "dot_input_file": "graph.dot",
    "n_depletion_steps": 12,
    "depcode": {},
    "simulation": {
        "sim_name": "saltproc_example"
    },
    "reactor": {
        "depletion_timesteps": [3],
        "power_levels": [1000],
        "timestep_units": "d"
    }
}

With this, our input file is finished!

Footnotes

1: As explained in methods_geometry_switching, SaltProc allows a user to provide multiple geometry configurations that are switched to sequentially if that option is enabled and \(k_\text{eff}\) drops below 1