User Manual

Introduction

As of 6/10/2025, the user manual is valid only for the 'devel' branch of MIDAS

Settings provided as strings are automatically converted to lowercase and whitespaces will be changed to
underscores by the MIDAS input parser. For example, if the optimizer setting is set to "Genetic Algorithm",
MIDAS will interpret it as 'genetic_algorithm'. This behavior is designed to enhance user flexibility
when constructing YAML input files. In this manual, setting options will be given in the format MIDAS
interprets for clarity and to avoid confusion.

General Block

The 'General' block provides information regarding the type of optimization to be conducted, file handling,
and data post processing.

optimizer

The optimizer option specifies the optimization method.

-Options-

genetic_algorithm
bayesian_optimization
simulated_annealing

-Default-

genetic_algorithm

-Notes-

Different optimizers require specific input settings in the "optimization" block.

-Input Example-

general:
optimizer: genetic_algorithm

code_type

The code type option specifies which code MIDAS will interface with during an optimization.

-Options-

parcs342
parcs343
ipwr_database
ipwr_database_legacy
trace50p5
polaris624

-Default-

parcs343

-Notes-

The code type determines the nature of the optimization problem based on the capabilities of the code
selected. For example, parcs343 can only handle loading patterns, so the problem must a be loading
pattern optimization.

-Input Example-

general:
code_type: parcs343

calc_type

The calc type option specifies the type of optimization problem to be conducted by MIDAS.

-Options-

single_cycle
eq_cycle
lattice_physics

-Default-

single_cycle

-Notes-

N/A

-Input Example-

general:
calc_type: single_cycle

input_template

This option is only available for PARCS343 calculations and currently only supports single cycle
optimizations.

This option allows the user to provide a template input file for PARCS343 optimizations. This gives the
users the ability to run any PARCS343 related optimization they wish even if MIDAS is unable to handle
the specific calculation type. Minimal edits are made to the template file except for when writing the
core configuration or when updating the th_fdbk option. The th_fdbk option should be provided in the
YAML file regardless if a template is used. All other information regarding the problem being solved that
has been provided in the YAML file is ignored. IT IS UP TO THE USER TO ENSURE THAT THE TEMPLATE HAS
BEEN SET UP CORRECTLY.

To set up the template file for an optimization the core map which is usually provided under the
'RAD_CONF' flag in PARCS should be left blank. At least one line should be left between the 'RAD_CONF'
flag and the next flag in the input. An example is shown below:

"""
GEOM
...
RAD_CONF

assy_type ...
"""

-Options-

apply:
True
False
loc:
strings

-Default-

apply:
False
loc:
''

-Notes-

MIDAS checks for basic PARCS input rewuirements but does not check the accuracy of the PARCS input.

-Input Example-

general:
input_template:
apply: False

or

general:
input_template:
apply: True
loc: ./directory/template.inp

results_directory_name

This setting specifies the directory for storing output files created by external softwares during the optimization.
Within the results directory, secondary directories will be created which correspond to specific individuals.
The secondary directories will store the input and output files as specified by the clear_results setting.

-Options-

strings

-Default-

output_files

-Notes-

N/A

-Input Example-

general:
results_directory_name: output_files

clear_results

This setting specifies how files and sub-directories created during the optimization will be handled.
'all' will delete all sub-directories and their contents that are created during the optimization process.
'all_but_best' deletes all sub-directories and their contents except for the sub-directory which pertains
to the best performing individual in each generation. The settings 'none', 'keep', and 'keep_all' will inform
MIDAS to not delete any output files or sub-directories.

-Options-

all
all_but_best
none
keep
keep_all

-Default-

all_but_best

-Notes-

sub-directories created during a particular generation will only be deleted after that generation has completed.

-Input Example-

general:
clear_results: all_but_best

statistics_plots

This setting instructs MIDAS to create 2D statistics plots.
Three plots are created showing the optimization performance including the best fitness per generation, the average
fitness per generation, and the fitness standard deviation per generation.

-Options-

True
False

-Default-

True

-Notes-

N/A

-Input Example-

general:
statistics_plots: True

convergence_plots

This setting instructs MIDAS to create a 2D convergence plot.
The convergence plot shows the fitness of the best performing individual up to a certain generation over the full
optimization.

If the best fitness value per generation up to generation 4 is 1, 4, 2, 12, 15 then the the convergence plot will
show 1, 4, 4, 12, 15.

-Options-

True
False

-Default-

True

-Notes-

N/A

-Input Example-

general:
convergence_plots: True

set_seed

This setting provides MIDAS with a seed for the internal random number generator. If a seed is not provided,
a seed is created by the internal python libraries. Due to the multiprocessing environment required for PSA
optimizations, repeatable optimizations are not possible with PSA. Running other algorithms in parallel will
not be affected by this.

-Options-

integers
None

-Default-

None

-Notes-

MIDAS internally sets the seed for the random and numpy python libraries. If future developments warrant using
random processes from other libraries then the seed will not work properly. The seed for any libraries that are
added can be specified in midasmain.py.

-Input Example-

general:
set_seed: 2025

initial_population

This setting allows the user to provide MIDAS with an initial population of inidividuals as a starting point
in the optimization. The user provides all of the solutions in a csv file which contains MIDAS interpretable
chromosomes. If the user provides fewer solutions than the population_size the rest of the initial population
will be randomly generated.

The easiest way for a user to provide MIDAS with interpretable chromosomes is to use chromosomes created by
MIDAS in previous optimizations and printed in the optimizer_results.csv. Users can also use the
solution_to_chromosome tool to convert solutions into MIDAS interpretable chromsomes (coming in a future
update).

When providing chromosomes in a csv file, users should have one chromosme per row starting on the first row
and the chromsome should start in the left most cell. No other information should be given in the csv other
than the chromosomes themselves. The format of the chromosomes is exactly as they appear in the
optimizer_results.csv, and the label for each gene in the chromosome must be defined in the yaml input file.

-Options-

path to csv

-Default-

None

-Notes-

The easiest way for errors to occur when using the functionality is when the user provided chromsomes are
not the correct length for the problem being optimzed.

-Input Example-

general:
initial_population: ./provided_chromosomes.csv

debug_mode

Allows MIDAS to run in debug mode. Debug mode will... TODO

-Options-

True
False

-Default-

False

-Notes-

N/A

-Input Example-

general:
debug_mode: False

Optimization Block

The 'Optimization' block provides settings which are universally required by all of the available optimizers
and the form of the objective function to be utilized during the optimization.

Within MIDAS, the genetic algorithm metaphor is used universally across all of the available optimizers.
When different optimization algorithms use distinct terminology for equivalent concepts, the genetic
algorithm nomenclature is adopted for clarity and consistency. Key examples are:

individual - a unique solution to the optimization problem which has been generated through the
optimization process
gene - an attribute of an individual (e.g. a single fuel assembly and its location)
chromosome - the unique set of genes which together define an individual (e.g. a loading pattern)
generation - an iteration in the main loop of the optimizer where a population in created
population - all of the individuals created in a given generation
fitness - the value of the objective function used to evaluate the performance of an individual

In order for MIDAS to evaluate the performance of an individual, a objective function (commonly referred to
as a fitness function or cost function) must be defined by the user. The objective function typically involves
maximizing/minimizing some quantity while meeting specified constraints. Objective functions can have any
functional form, however MIDAS opts to employ a linear combination of the objectives with weights for each
objective. Because minimization problems can easily be transformed into maximization problems MIDAS is only
capable of handling maximization problems. A form of the objective function can be represented as

$$ \quad f(\bar{x}) = w_0 f_0(\bar{x}) - \sum^{m}_i w_i , \mathrm{max}(0, f_i(\bar{x})-a_i) $$

In this equation, $\bar{x}$ is the generated solution (individual) where $\bar{x} \in \mathcal{X}^g$ and $\bar{x}=[x_1, \dots x_g]$ where $g$ is the
number of genes in the individual. The $f$ values represent the objectives of the solution which are typically
evaluated using and external solver (e.g. a loading pattern would be evaluated by PARCS). $f_0$ represents
the target objective which is to be maximized and $f_i$ are design constraints which are to be met during the
optimization. $a_i$ are the constraint targets and the $w$ values are weights both of which are provided by the user.

For a typical four-loop PWR, $g=193$ if no symmetry is assumed. If an octant symmetry is assumed then it
can be reduced to $g=31$. Each loading pattern can take values from the discrete set $\mathcal{X}^g$ that depends
on the available inventory of fuel assemblies. A typical target variable for this case would be the cycle length
and examples of design constraints would be power peaking factors and maximum boron concentration.

population_size

This setting allows the user to define the number of individuals generated in a given generation. When running
a simulatted annealing optimization, the population_size is overridden and set to 1.

-Options-

integers

-Default-

1

-Notes-

N/A

-Input Example-

optimization:
population_size: 50

number_of_generations

This setting allows the user to define the number of generations in the optimization. The number of generations
informs the number of iterations for all of the optimization algorithms including SA and BO.

The 'calculate_from_genes' option allows MIDAS to... TODO

-Options-

integers
calculate_from_genes

-Default-

1

-Notes-

N/A

-Input Example-

optimization:
number_of_generations: 50

or

optimization:
number_of_generations: calculate_from_genes

solution_symmetry

This setting tells MIDAS which symmetry to use when generating individuals. Introducing symmetries into the
optimization will reduce the number of genes carried by a chromosome which drastically reduces the size of
the design space. The reduction in design space decreases the strain on the optimizer and is generally a
beneficial practice as asymmetric individuals tend to have poor performance.

The effect of symmetry on the size and shape of a chromosome is dependent on the problem being solved. For
instance a quarter of a PWR core has a different shape than a quarter of a BWR core. In these cases the
chromosome shape is defined within MIDAS and is informed by common modeling practices.

-Options-

full
quarter
octant

-Default-

octant

-Notes-

octant core symmetry is currently not available for equilibrium cycle calculations.

-Input Example-

optimization:
solution_symmetry: octant

termination_criteria

This setting allows the user to define the termination criteria to be used by MIDAS during the optimization.
When specifying the termination criteria the user must also provide the number of termination generations.
The number of termination generations determines the number of consecutive generations where the condition
for termination must be consecutively satisfied before the optimization is cancelled. MIDAS will prioritize
the condition for termination that appears first during the optimization. For example, if the user specifies
the 'number_of_generations' to be 10 and 10 generations have been completed but the termination criteria
has not been met then the optimization will cancel. If the user specifically wants the termination criteria
to be the final condition for termination then 'number_of_generations' should be set to a very large number.

There are three termination criteria available in MIDAS. 'none' allows MIDAS to optimize for the entire number
of generations given by the user. 'consecutive' tells MIDAS to cancel the optimization if the best fitness value
found during the optimization does not improve over a set number of termination generations. 'spearman' takes
the assembly average burnup values across the core and averages each assembly value across the entire population.
A Spearman rank coefficient is then calculated by comparing the current generation's burnup set against the
previous generation's. If the Spearman rank coefficient does not improve over a set number of termination
generations then the optimization will be canceled.

-Options-

method:
none
consecutive
spearman
termination_generations:
integers

-Default-

method: none
termination_generations: 0

-Notes-

The spearman termination criteria is only available for the ipwr_database and is generally not
recommended by the developers.

-Input Example-

optimization:
termination_criteria:
method: consecutive
termination_generations: 5

objectives

This setting allows the user to define the optimization objectives as well as their weights and objective targets.
When specifying the objective, MIDAS requires 5 inputs, the constraint itself, the goal, the target,and the weight.
All of the available objectives are listed below however some constraints are code specific. The handling of the
objective in the objective function depends on the specified goal. The 'greater_than_target' and 'less_than_target'
options will only apply a penalty to the fitness of an individual if the objective value violates the goal relative
to the target while the 'maximize' or 'minimize' options will always apply a penalty to the fitness. Most commonly,
target objectives us the 'maximize' or 'minimize' options while design constraints typically use the
'greater_than_target' or 'less_than_target' options. The weight inputs are problem specific and are up to the
discretion of the user but standard practice is to set the weight so that each objective contributes equally towards
the fitness value. The settings ... TODO

The contribution of the objective goals on the fitness value is shown below.
maximize:

$$ f(\bar{x}) += \mathrm{value} * w_i $$

minimize:

$$ f(\bar{x}) -= \mathrm{value} * w_i $$

meet_target:

$$ f(\bar{x}) -= \mathrm{abs}(\mathrm{target} - \mathrm{value} ) * w_i $$

greater_than_target:

$$ f(\bar{x}) -= (\mathrm{target} - \mathrm{value}) * w_i \ \ \mathrm{if} \ \ (\mathrm{target} - \mathrm{value}) > 0.0 \ \ \mathrm{else} \ \ 0.0 $$

less_than_target:

$$ f(\bar{x}) -= (\mathrm{value} - \mathrm{target}) * w_i \ \ \mathrm{if} \ \ (\mathrm{value} - \mathrm{target}) > 0.0 \ \ \mathrm{else} \ \ 0.0 $$

-Options-

max_boron (parcs343, parcs342, ipwr_database)
pinpowerpeaking (parcs343, parcs342, polaris624, ipwr_database)
fdeltah (parcs343, parcs342, ipwr_database)
cycle_length (parcs343, parcs342, ipwr_database)
assembly_burnup (ipwr_database)
cost_fuelcycle (parcs343, parcs342)
av_fuelenrichment (parcs343, parcs342)
maxcladtemp (trace50p5)
maxfueltemp (trace50p5)
maxgapq (trace50p5)
peak_reactivity (polaris624)
max_critical_exposure (polaris624)
goal:
maximize
minimize
meet_target
greater_than_target
less_than_target
target:
floats
weight:
floats
settings:
scope:
full_core
feed_batch_only

-Default-

None

-Notes-

N/A

-Input Example-

optimization:
objectives:
cycle_length:
goal: maximize
weight: 1.0
max_boron:
goal: less_than_target
target: 1300
weight: 1.0

Algorithm Block

The 'Algorithm' block provides algorithm specific settings which are required by the specified optimizer.

Settings specific to certain algorithms will be designated by parenthesis next to the setting name.

selection (GA)

This setting allows the user to define the parent selection method used in the genetic algorithm optimizer.
When selecting parents to mate, MIDAS will pick two parents from the previous generation using one of the
predefined methods. The mating pair will then be used to create the necessary number of children accounting for
population size and elitism.

More information on the parent selection methods can be found in:
Jebari, Khalid. (2013). Selection Methods for Genetic Algorithms. International Journal of Emerging Sciences.

-Options-

tournament
roulette
random
ktournament
truncation
sus (stochastic universal sampling)

-Default-

tournament

-Notes-

N/A

-Input Example-

algorithm:
selection:
method: tournament

or

algorithm:
selection:
method: ktournament
k: 8

reproducer (GA)

TODO...

-Options-

-Default-

-Notes-

N/A

-Input Example-

crossover (GA)

This setting allows the user to define the crossover method used when generating children in the genetic algorithm
optimizer. After parents have been selected to mate, children will be generated by MIDAS using one of the predefined
crossover methods. This is made possible as internally MIDAS represents the chromosome of individuals using lists
rather than 2D arrays. Each of the crossover methods take advantage of this by iterating over the elements of the list
to perform the crossover. Uniform crossover iterates over each element of the two parents' chromosomes and will swap
the gene at a particular index with a probability set by the user using the "crossover_rate". Random element crossover
is a method unique to MIDAS which selects a gene from each parent at random and swaps them. The Number of swaps can
be set by the user using "num_swaps".

In situations where unique geometric considerations must be accounted for (e.g. assembly multiplicity in LWRs) MIDAS will
continuously attempt to create solutions until a valid child is created. If a valid child is not created after a large
number of attempts, the MIDAS job will cancel and an message describing the issue will be given to the user. Both
contraceptive and abortive restrictions are utilized in MIDAS, but the use of contraceptive restrictions are avoided in
the MIDAS source code unless necessary.

More information on the parent crossover methods can be found in... TODO

-Options-

uniform
random_element
one_point
two_point

-Default-

one_point

-Notes-

N/A

-Input Example-

algorithm:
crossover:
method: one_point

or

algorithm:
crossover:
method: uniform
crossover_rate: 0.5

or

algorithm:
crossover:
method: random_element
num_swaps: 2

mutation_type (GA)

This setting allows the user to define how individuals are mutated in the genetic algorithm optimizer. "Mutate by
gene" will randomly select a gene index within the chromosome and randomly change the gene at that position into
one of the other available gene options.

Currently "mutate by gene" is the only available mutation type option.

-Options-

mutate_by_gene

-Default-

mutate_by_gene

-Notes-

N/A

-Input Example-

algorithm:
mutation_type: mutate_by_gene

mutation_rate (GA)

This setting allows the user to define the probability of mutation in the genetic algorithm optimizer. Two options
are available to the user. By giving one number, MIDAS will assume a constant mutation rate. If two numbers are
provided, MIDAS will linearly update the mutation rate throughout the optimization. The first number provided will
be interpreted as the starting mutation rate and the second mutation rate will be the mutation rate during the final
generation.

-Options-

floats

-Default-

0.5

-Notes-

Dynamically updating mutation rates are generally not recommended when using a termination criteria.

-Input Example-

algorithm:
mutation_rate: 0.5

or

algorithm:
mutation_rate: 0.3, 0.6

elites (GA)

This setting allows the user to define elitism behavior in the genetic algorithm optimizer. Elitism allows for high
performing individuals to be copied to the next generation. This option will ensure that good genes remain in the
gene pool, but the elite individuals will displace child solutions.

The user can define the number of elites by giving an integer that represents the number of elite individuals copied
in each generation, or the user can define the number of elites using a float between 0 and 1. MIDAS will read the
the float option as the percentage of the population which are elite individuals.

-Options-

floats
integers

-Default-

0

-Notes-

N/A

-Input Example-

algorithm:
elites: 5

or

algorithm:
elites: 0.5

temperature (SA)

This setting allows the user to define the intial temperature used in a SA optimization.

-Options-

floats

-Default-

100

-Notes-

N/A

-Input Example-

algorithm:
temperature: 50

cooling_schedule (SA / PSA)

This setting allows the user to define the cooling schedule utilized by the simulated annealing and parallel simulated
annealing optimizers. For SA, the cooling schedule updates the temperature value after each iteration. For PSA, the cooling
schedule updates the global temperature. Each thread starts its individual optimization from this global temperature
and it gets updated with every buffer update. All cooling schedules can be used by both algorithms except for the 'lam'
cooling schedule which is specific to PSA. The equations used for the respective cooling schedules are as follows:

exponential_decrease:

$$ T_{g} = T_{g-1} * \alpha $$

linear_update:

$$ T_{g} = T_{0} + \frac{T_{0}}{total \ generations} \times (current \ generation + 1) $$

log_update:

$$ T_{g} = \frac{T_0}{log_{10}(2+current \ generation)} $$

lam:
Concept for multi-cycle nuclear fuel optimization based on parallel simulated annealing with mixing of states
-David J. Kropaczek

-Options-

exponential_decrease
linear_update
log_update
lam

-Default-

exponential_decrease

-Notes-

-Input Example-

algorithm:
cooling_schedule: exponential_decrease

update_factor (SA)

This setting allows the user to define the update factor, $$\alpha$$, used in the 'exponential_decrease' cooling schedule.

-Options-

floats (1.0 > $$\alpha$$ > 0.0)

-Default-

0.95

-Notes-

N/A

-Input Example-

algorithm:
update_factor: 0.95

perturbation_type (SA / PSA)

This setting allows the user to define how individuals are perturbed in the simulated annealing optimizer.
"perturb_by_gene" will randomly select a gene index within the chromosome and randomly change the gene at that
position into one of the other available gene options. The perturbation method works in the same as fassion as
GAs mutations.

-Options-

method:
perturb_by_genes
num_perturbations:
integers

-Default-

method:
perturb_by_genes
num_perturbations:
1

-Notes-

N/A

-Input Example-

algorithm:
perturbation_type:
method: perturb_by_gene
num_perturbations: 2

secondary_cooling_schedule (PSA)

This setting allows the user to define the cooling schedule utilized by the individual simulated annealing threads in a
parallel simulated annealing optimization. Each thread has a local temperature value, when a SA thread starts each local
temperature is set to the global value and the local temperatures decreases throughout the SA execution based on the
secondary cooling schedule selected. After a thread completes an SA execution, the local temperatures are reset to the
updated global value. All cooling schedules can be used for the secondary cooling schedule except for the 'lam' cooling
schedule which is specific for global teperatures in the PSA algorithm.

-Options-

exponential_decrease
linear_update
log_update
none

-Default-

exponential_decrease

-Notes-

N/A

-Input Example-

algorithm:
secondary_cooling_schedule: exponential_decrease

quality_factor (PSA)

This setting allows the user to define the quality factor used in the lam cooling schedule.
More information about the quality factor can be found in:
Concept for multi-cycle nuclear fuel optimization based on parallel simulated annealing with mixing of states
-David J. Kropaczek

-Options-

floats (2.0 > factor > 1.0)

-Default-

1.1

-Notes-

N/A

-Input Example-

algorithm:
quality_factor: 1.5

scaling_factor (PSA)

This setting allows the user to define the scaling factor used in the lam cooling schedule.
More information about the scaling factor can be found in:
Concept for multi-cycle nuclear fuel optimization based on parallel simulated annealing with mixing of states
-David J. Kropaczek

-Options-

floats (2.0 > factor > 1.0)

-Default-

1.5

-Notes-

N/A

-Input Example-

algorithm:
scaling_factor: 1.5

buffer_size (PSA)

This setting allows the user to define the size of the buffer used in PSA optimizations. The buffer holds solutions
to the optimization problem being solved. When a thread begins a SA execution it selects a solution from the buffer
to act as the starting point. The selection process is fitness weighted so individuals in the buffer which have a
higher fitness value are more likely to be selected as the starting point. Once all of the threads have completed
their execution, the best solutions from the execution are used to update the solutions in the buffer. The solutions
in the buffer with the lowest fitness values are replaced with the new solutions, and if one of the SA threads is not
able to create a solution with a fitness value higher than the lowest fitness in the buffer than no replacements are
made. The maximum number of replacements that can take place in one buffer update is equal to the number of threads
(cpus) used in the PSA optimization.

-Options-

integers

-Default-

10

-Notes-

The buffer size replaces the population size when generating the initial population of individuals

-Input Example-

algorithm:
buffer_size: 15

acquisition_function (BO)

This setting tells MIDAS which acquisition function to use in the bayesian optimization algorithm. In BO, the acquisition function serves as the method of evaluating prospective new solutions based on their predictive output from the gaussian process surrogate model and choosing the next candidate solutions to evaluate. The equations for all are shown below:

Let the Gaussian Process surrogate model at a candidate point ( x ) have

predictive mean: $\mu(x)$
predictive standard deviation: $\sigma(x)$

Let

$f^+$ be the best observed objective value so far
$\Phi(\cdot)$ be the CDF of the standard normal distribution
$\phi(\cdot)$ be the PDF of the standard normal distribution

Probability of Improvement (PI)

$$ PI(x) = \Phi\left( \frac{\mu(x) - f^+ - \kappa}{\sigma(x)} \right) $$

PI measures the probability that sampling at x will improve upon the current best value.

Expected Improvement (EI)

Define

$$ Z(x) = \frac{\mu(x) - f^+ - \kappa}{\sigma(x)} $$

Then

$$ EI(x) = (\mu(x) - f^+ - \kappa),\Phi(Z(x)) + \sigma(x),\phi(Z(x)) $$

EI measures the probability that sampling at x will improve upon the current best value, as well as the statistically expected magnitude of improvement.

Upper Confidence Bound (UCB)

$$ UCB(x) = \mu(x) + \kappa*\sigma(x) $$

UCB explicitly trades off exploitation (mean) and exploration (uncertainty) through $\kappa$, and searches explicitly for the best point based on predictive means and standard deviation. It is typically an optimistic evaluation for a maximization problem, or pessimistic for a minimization problem.

Lower Confidence Bound (LCB)

$$ LCB(x) = \mu(x) - \kappa*\sigma(x) $$

LCB explicitly trades off exploitation (mean) and exploration (uncertainty) through $\kappa$, and searches explicitly for the best point based on predictive means and standard deviation. It is typically a pessimistic evaluation for a maximization problem, or optimistic for a minimization problem.

-Options-

upper confidence bound (UCB)
lower confidence bound (LCB)
probability of improvement (PI)
expected improvement (EI)

-Default-

Lower confidence bound

-Notes-

BO solves using minimization, despite more positive fitness being represented by MIDAS as better, by inverting fitness values. Therefore, LCB is the optimistic evaluation and UCB is the pessimistic

-Input Example-

algorithm:
acquisition_function: lcb

exploration_exploitation_factor (BO)

This setting tells MIDAS how to balance the exploration-exploitation tradeoff when using the Bayesian Optimization (BO) algorithm. It is used in the acquisition function directly, shown as $\kappa$ in the acquisition function equations, described under the acquisition function section.

-Options-

Positive real numbers

-Default-

1.96 for Upper/lower confidence bound acquisition functions
0.0 for Probability of Improvement (PI) or Expected Improvement (EI) acquisition functions

-Notes-

It is recommended to have this value set at 0 if using the PI or EI acquisition functions

-Input Example-

algorithm:
exploration_exploitation_factor: 1.96

kernel_smoothness_factor (BO)

This setting is used for the kernel function in the gaussian process surrogate used by BO to control the expected smoothness of the fitness function. The kernel function used by BO is the Matern covariance function, shown below:

$$ k_{\nu}(r) = \frac{2^{1-\nu}}{\Gamma(\nu)} \left( \frac{\sqrt{2\nu}r}{\ell} \right)^{\nu} K_{\nu}\left( \frac{\sqrt{2\nu}r}{\ell} \right) $$

Where $$\nu$$ is the smoothness factor. The covariance/kernel function is then used to shape the predictive mean and standard deviation of the gaussian process surrogate model.

-Options-

0.5
1.5
2.5

-Default-

0.5

-Notes-

It is recommended to have this value set at 0.5 for discrete problems are problems where the fitness function is expected to be rough, and recommended to be 1.5 or 2.5 for a continuous problem or a problem with a smoother fitness function

-Input Example-

algorithm:
kernel_smoothness_factor: 0.5

hyperparameter_convergence_criteria (BO)

This setting is used for improving the speed of the gaussian process training, especially in later generations. This criteria is a fraction, and should be the amount of change after 10 generations that is acceptable to consider kernel hyperparameters to be converged, and to stop tuning the kernel hyperparameters.

-Options-

(0 < factor < 1.0)

-Default-

0.01 (1% change over 10 generations)

-Notes-

None

-Input Example-

algorithm:
hyperparameter_convergence_criteria: 0.01

surrogate_off_generation (BO)

This setting is used for improving computational time spent in the gaussian process, particularly in later generations. This represents the generation on which the gaussian process will cease to train on new data, and only predict new points, reducing the total computational cost.

-Options-

Integer between 1 and number of generations

-Default-

0.5*num_generations

-Notes-

None

-Input Example-

algorithm:
surrogate_off_generation: 50

Options Block

The options block provides MIDAS with information regarding the user defined genes which can be utilized during
the optimizations.

The options block cannot be initialized with 'options' and instead must be initialized for the type of problem being
solved. To specify the problem type, the user must initialize the block as 'gene_type_options' where 'gene_type' is
replaced by the specific type of gene handled in the optimization. Block initializations that are currently supported
by MIDAS are listed below:

'assembly_options'
'rod_options'

For loading pattern optimizations, the 'assembly_options' initialization must be used. Each type of assembly
used in the optimization must be explicitly defined within this block and cross-section files must be provided by
the user. For each axial fuel region or radial reflector defined in this block, the name of the associated
cross-section file must be provided in the 'serial' section (file extensions are provided in the 'calculation' block).

For assembly lattice optimizations, the 'rod_options' initialization must be used. To run lattice optimizations,
the user must have access to a lattice physics solver and ENDFs. Currently only Polaris is supported in MIDAS.
TODO fill out lattice optimization options.

reflectors

This setting is unique to the 'assembly_options' initialization and allows the user to define reflectors in the core
geometry. The type of reflectors that can be defined using this setting includes radial and axial reflectors, or
the reflector type can be set to 'all' to allow one cross-section file to be used for all reflectors in the geometry.

When defining the reflectors, the user must define the reflector name, type of reflector, and the associated files
(serial). When constructing input files for the core simulator, MIDAS will define one node for the top and bottom
reflectors.

-Options-

name:
strings
refl_type:
all
radial
top
bottom
serial:
strings

-Default-

None

-Notes-

All three types of reflectors must be defined in a core optimization either through the 'all' option or by defining
each individually

-Input Example-

assembly_options:
reflectors:
refl_name:
refl_type: all
serial: refl_file

or

assembly_options:
reflectors:
rad_refl_name:
refl_type: radial
serial: rad_refl_file
top_refl_name:
refl_type: top
serial: top_refl_file
bot_refl_name:
refl_type: bottom
serial: bot_refl_file

blankets

This setting is unique to the 'assembly_options' initialization and allows the user to define axial blankets in
the defined assemblies. Axial blankets occupy one node on the top and bottom of the assembly geometry between
the axial reflectors and the main fuel region.

When defining the blankets, the user must define the blanket name and the associated cross-section file name
(serial). Optionally, the enrichment and heavy metal loading of the blanket may be defined here if needed for
other MIDAS functionality. The enrichment can be provided as weight fraction or weight percent, and the heavy
metal loading must be provided in kilograms.

-Options-

name:
strings
serial:
strings
enrichment:
floats
hm_loading:
floats

-Default-

None

-Notes-

N/A

-Input Example-

assembly_options:
blankets:
blanket_name:
serial: blanket_file
enrichment: 1.50
hm_loading: 1000

fuel

This setting is unique to the 'assembly_options' initialization and allows the user to define the main fuel region of
the defined assemblies. MIDAS currently only allows for one fuel region per assembly (apart from blankets and reflectors).

When defining the fuel region, the user must define the fuel name, the fuel type (how the assembly is represented
in the core simulator), and the associated cross-section file name (serial). Optionally, defined blankets can be
linked to a fuel type, and the enrichment and heavy metal loading of the fuel may be defined here if needed for
other MIDAS functionality. The enrichment can be provided as weight fraction or weight percent, and the heavy metal
loading must be provided in kilograms.

-Options-

name:
strings
type:
integers
serial:
strings
blanket:
strings
enrichment:
floats
hm_loading:
floats

-Default-

None

-Notes-

The type of a fuel correlates to the assembly definition within the simulator. For instance if the type is '10' and
PARCS is the core simulator of choice, then '10' will be used to define the assembly which contains the associated
fuel within PARCS.

-Input Example-

assembly_options:
fuel:
fuel_name:
type: 10
serial: fuel_file
blanket: blanket_name
enrichment: 1.50
hm_loading: 1000

rod_geometries

This setting is unique to the 'rod_options' initialization and allows the user to define the types of rods which appear
in the lattice geometry. This setting is used for both fuel pins and intrumentation/water rods.

When defining the rod, the user must define the geometry type (the name assigned to the geometry in polaris), the
material radii in order from smallest to largest, and the materials used in the rod in order of raddii. The radii
and materials options should be provided in the same formats as would be expected in a standard Polaris input file.

-Options-

name:
strings
type:
alphanumeric characters
radii:
n floats
materials:
n strings

-Default-

None

-Notes-

N/A

-Input Example-

rod_options:
instrument_tube:
type: A
radii: 0.438 0.447
materials: COOL.1 CLAD.1 COOL.1

or

rod_options:
fuel:
type: B
radii: 0.438 0.447 0.5130
materials: FUEL.1 GAP.1 CLAD.1

compositions

This setting is unique to the 'rod_options' initialization and allows the user to define the material compositions
used in the lattice. The compositions can be defined in any form that Polaris accepts as long as the inputs remain
consistent.

When defining the composition, the user must define the composition type and the atomic specifications given in the
format specified in the composition type. The settings used to define the compositions should be provided in the
same formats as would be expected in a standard Polaris input file.

-Options-

name:
strings
type:
NUM, WT, FORM, CONC, LW, UOX, ENRU, UN, USI
values:
strings

-Default-

None

-Notes-

N/A

-Input Example-

compositions:
natural_uranium:
type: WT
values: U235=0.710 U238=-100

or

compositions:
natural_uranium:
type: WT
values: U235=0.710 U238=-100
gadolinia:
type: FORM
values: Gd=2 O=3
natural_uranium_with_gad:
type: WT
values: gadolinia=4.0 natural_uranium=-100

materials

This setting is unique to the 'rod_options' initialization and allows the user to define the materials used in the
lattice. The materials are comprised of the compositions defined elsewhere in 'rod_options', and any materials defined
in the 'materials' sub-setting of 'rod_geometries' must be also defined here (unless it is a default predefined material
in Polaris).

When defining the materials, the user must provide the material composition from the 'compositions' setting, the
material density, if the material is burnable, and the material temperature can be optionally provided here however
the 'bulk_temperatures' setting can be used to globally set the material temperatures.

-Options-

name:
strings
comp:
strings
dens:
floats
fueltype:
boolean
temp:
floats

-Default-

None

-Notes-

N/A

-Input Example-

materials:
Fuel.1:
comp: natural_uranium
dens: 10.26
temp: 950.0
fueltype: True

or

materials:
COOL.1:
comp: WATER
dens: 0.7373

Decision Variables Block

The 'decision_variables' block is used to provide MIDAS with information regarding the decision variables and
the solution space of the problem being solved.

assembly_parameters

This setting is used for loading pattern optimizations and allows the user to define the valid locations in
which a defined assembly can be placed within the core geometry and the maximum number of each assembly type
within the loading pattern.

When defining the parameters for a particular assembly type, the name of the parameter must be the same as the
assembly type of interest. Location maps are provided by the user as a list where 0 represents an invalid
location and 1 represents a valid location. The number of elements in the list is determined by the solution
space defined in the 'code_data' block and the 'solution_symmetry' setting found in the 'optimization' block.
MIDAS is capable of interpreting and handling BWR and PWR geometries (note that the example below shows the
quarter core map of a 193 assembly core where the quarter contains 49 assemblies.) The user can provide
different location maps for each assembly type but they must ensure that each map has the same number of
elements.

-Options-

name:
strings
map:
list of 1s and 0s
constraint:
type:
max_quantity
less_than_variable
value: integers

-Default-

None

-Notes-

The value setting in the constraints should always be the full core value regardless of the defined symmetry.

-Input Example-

decision_variables:
assembly_parameters:
fuel_name:
map:
[1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1,
1, 1, 1, 1]
constraint:
type: max_quantity
value: 100

batches

This setting is used for equilibrium core loading pattern optimizations and allows the user to define the fuel
batches used by MIDAS when constructing equilibrium cores. This setting is required for equilibrium core
optimizations and single cycle optimizations but not for fresh fuel core optimizations. When defining a batch,
the user must provide a location map along with the maximum number of assemblies in the batch. A unique entry
must be made for each batch and the name of said batch must be 'batch n' where n is an integer.

When entering the number of assemblies per batch, the user can either give an integer or point to a value from
a previous batch as shown in the example.

-Options-

name:
batch_n
map:
list of 1s and 0s
constraint:
type:
max_quantity
less_than_variable
value: integers

-Default-

None

-Notes-

N/A

-Input Example-

decision_variables:
batches:
batch_0:
map:
[1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1,
1, 1, 1, 1]
constraint:
type: max_quantity
value: 100
batch_1:
map:
[1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1,
1, 1, 1, 1]
constraint:
type: less_than_variable
value: batch_0

lattice_parameters

This setting is used for lattice physics optimizations and allows the user to define the valid locations in
which a defined fuel rods can be placed within the lattice geometry and the maximum number of each rod type
within the lattice.

When defining the parameters for a particular assembly type, the name of the parameter must be the same as the
assembly type of interest. Location maps are provided by the user as a list where 0 represents an invalid
location and 1 represents a valid location. The number of elements in the list is determined by the solution
space defined in the 'code_data' block and the 'solution_symmetry' setting found in the 'optimization' block.
MIDAS is capable of interpreting and handling BWR and PWR lattice geometries (note that the example below shows
a 17x17 PWR lattice with SE symmetry) The user can provide different location maps for each assembly type but
they must ensure that each map has the same number of elements.

-Options-

name:
strings
map:
list of 1s and 0s
constraint:
type:
max_quantity
less_than_variable
value: integers

-Default-

None

-Notes-

The value setting in the constraints should always be the full lattice value regardless of the defined symmetry.

-Input Example-

decision_variables:
lattice_parameters:
rod_name:
map:
[1,
1, 1,
1, 1, 1,
1, 1, 1, 1,
1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
constraint:
type: max_quantity
value: 100

Calculation Block

The 'calculation' block is used to provide MIDAS with information needed to run the physics simulator that is
utilized during the optimization. Any code specific information that is not provided in the 'decision_variable'
or 'options' blocks will be provided here.

The calculation block cannot be initialized with 'calculation' and instead must be initialized for a specific code.
To specify which code the information is relevant to, the user must initialize the block as 'code_data' where 'code'
is replaced by the specific simulator name. block initializations that are currently supported by MIDAS are listed
below:

'parcs_data'
'polaris_data'
'trace_data'
'nucale_data'

Note that when utilizing PARCS-TRACE coupled simulations, a 'parcs_data' and a 'trace_data' block is required.

exec_walltime

The executive walltime setting option can be used with any initialization and specifies the expected duration
(in seconds) of a solution evaluation using the user specified code/simulator. When running MIDAS, it is best
practice to overestimate the executive walltime.

-Options-

integers

-Default-

600

-Notes-

N/A

-Input Example-

parcs_data:
exec_walltime: 100

core_type

The core_type option is used in the 'parcs_data' initialization and specifies the type of core which is being
be optimized for loading pattern optimizations. This, along with the number of rows and columns, informs MIDAS
on how to handle core symmetries.

-Options-

PWR
BWR

-Default-

PWR

-Notes-

N/A

-Input Example-

parcs_data:
core_type: BWR

num_rows

This setting option is shared by the 'parcs_data' and 'polaris_data'initializations and specifies the number of
rows in the generated loading patterns / lattices. This setting must always be the full core value regardless of
solution symmetries.

-Options-

integers

-Default-

17

-Notes-

N/A

-Input Example-

parcs_data:
map:
num_rows: 17

num_cols

This setting option is shared by the 'parcs_data' and 'polaris_data'initializations and specifies the number of
rows in the generated loading patterns / lattices. This setting must always be the full core / lattice value
regardless of solution symmetries. If no value is provided, the num_cols will be set to the same value as num_rows.

-Options-

integers

-Default-

num_rows

-Notes-

N/A

-Input Example-

parcs_data:
map:
num_cols: 17

number_assemblies

This setting is used in the 'parcs_data' initialization and specifies the total number of assemblies in the
generated loading patterns. This setting must always be the full core / lattice value regardless of solution
symmetries. The 'number_assemblies' along with 'num_cols' and 'num_rows' allows MIDAS to construct the core
shape based on standard LWR cores.

-Options-

integers

-Default-

193

-Notes-

N/A

-Input Example-

parcs_data:
map:
num_assemblies: 193

assembly_pitch

This setting is used in the 'parcs_data' initialization and specifies the assembly pitch.

-Options-

floats

-Default-

21.50

-Notes-

N/A

-Input Example-

parcs_data:
map:
assembly_pitch: 25.0

core_symmetry

This setting is used in the 'parcs_data' initialization and specifies the core symmetry used when MIDAS
constructs the input file for the user selected core simulator.

-Options-

full
quarter

-Default-

full

-Notes-

N/A

-Input Example-

parcs_data:
map:
core_symmetry: quarter

xs_library_path

This setting is used in the 'parcs_data' initialization and specifies the path to the cross-section library
to be used by the selected core simulator. The path provided must be the path relative to the location of
the constructed input file.

-Options-

strings

-Default-

./

-Notes-

N/A

-Input Example-

parcs_data:
xs_library_path: ../../LIBRARY

xs_extension

This setting is used in the 'parcs_data' initialization and specifies the extension of the cross-section
libraries used. The type of extension is dependent on the core simulator used in the optimization.

-Options-

strings

-Default-

''

-Notes-

N/A

-Input Example-

parcs_data:
xs_extension: PMAXS

power

This setting is used in the 'parcs_data' initialization and specifies the core thermal power.

-Options-

floats

-Default-

3800.0

-Notes-

The user must be careful to ensure that the appropriate units are used for the simulator and the value
is correct for symmetry specified in the 'core_symmetry' setting.

-Input Example-

parcs_data:
power: 4500.0

flow

This setting is used in the 'parcs_data' initialization and specifies the core mass flow rate.

-Options-

floats

-Default-

18231.89

-Notes-

The user must be careful to ensure that the appropriate units are used for the simulator and the value
is correct for symmetry specified in the 'core_symmetry' setting.

-Input Example-

parcs_data:
flow: 10000.0

inlet_temperature

This setting is used in the 'parcs_data' initialization and specifies the coolant inlet temperature in
kelvin.

-Options-

floats

-Default-

565.0

-Notes-

N/A

-Input Example-

parcs_data:
inlet_temperature: 565.0

coolant_density

This setting is used in the 'parcs_data' initialization and specifies the coolant density in g/cm^3.
This setting is needed when running parcs with uniform state conditions.

-Options-

floats

-Default-

0.740

-Notes-

N/A

-Input Example-

parcs_data:
coolant_density: 1.000

fuel_temperature

This setting is used in the 'parcs_data' initialization and specifies the fuel temperature in kelvin.
This setting is needed when running parcs with uniform state conditions.

-Options-

floats

-Default-

900.0

-Notes-

N/A

-Input Example-

parcs_data:
fuel_temperature: 1000.0

th_fdbk

This setting is used in the 'parcs_data' initialization and is used to enable or disable thermal hydraulic
feedback in the PARCS solver. There are two options available to the user, PARCS' internal feedback
solver and PATHS which is external to PARCS but is part of the PARCS package. When using PATHS the
user must provide the location of the PATHS input file. MIDAS does not reconstruct the PATHS input
file and instead points to the provided input file. IT IS UP TO THE USER TO ENSURE THAT THE PATHS
INPUT IS CORRECT.

If apply is set to 'False' no feedback is included to the calculation. If apply is set to 'True' and loc
is not provided, or is given as 'None', the PARCS internal solver is used. If apply is set to 'True' and
loc is provided Paths will be used as the TH feedback solver.

-Options-

apply:
True
False
loc:
strings
None

-Default-

apply:
True
loc:
None

-Notes-

N/A

-Input Example-

parcs_data:
th_fdbk:
apply: False
loc: None

or

parcs_data:
th_fdbk:
apply: False
loc: None

or

parcs_data:
th_fdbk:
apply: False
loc: ./directory/paths.inp

pin_power_recon

This setting is used in the 'parcs_data' initialization and is used to enable or disable PARCS' pin
power reconstruction functionality.

-Options-

True
False

-Default-

True

-Notes-

N/A

-Input Example-

parcs_data:
pin_power_recon: True

assembly_pins

This setting is used in the 'parcs_data' initialization and is used to specify the number of fuel pins
per assembly for use in the pin power reconstruction.

-Options-

integers

-Default-

264

-Notes-

N/A

-Input Example-

parcs_data:
assembly_pins: 264

assembly_guide_tubes

This setting is used in the 'parcs_data' initialization and is used to specify the number of guide
tubes per assembly for use in the pin power reconstruction. This value includes guide tubes and
instrumentation tubes.

-Options-

integers

-Default-

25

-Notes-

N/A

-Input Example-

parcs_data:
assembly_guide_tubes: 25

pin_dimensions

This setting is used in the 'parcs_data' initialization and is used to specify the pin dimensions
for use in the pin power reconstruction. For simplicity, the values are provided all together as a
string which is pasted directly into the input file. The values in order are the fuel pellet radius,
cladding outter radius, cladding thickness, and guide tube outer radius. Each value is in mm.
More information can be found in the PARCS user manual.

-Options-

strings

-Default-

4.1 4.75 0.58 6.13

-Notes-

N/A

-Input Example-

parcs_data:
pin_dimensions: 4.1 4.75 0.58 6.13

num_axial_nodes

This setting is used in the 'parcs_data' initialization and is used to tell MIDAS the number of axial
nodes to define when constructing a PARCS input file. The number of nodes should include the main fuel
region of the assembly as well as the blankets and reflector regions.

-Options-

integers

-Default-

19

-Notes-

N/A

-Input Example-

parcs_data:
num_axial_nodes: 19

axial_nodes

This setting is used in the 'parcs_data' initialization and is used to define the axial lengrh (cm) of
the axial nodes. Users must present the axial nodes using a comman separated string where each element
is the axial length of the corresponding node, and the number of nodes must be equal to the value of
'num_axial_nodes'. The first and last elements will correspond to the reflector regions of the assembly,
the second and second to last elemets will correspond to the blanket regions of the assembly, and
everything in between will corrspond to the main fuel region.

The below example defines an assembly with 5 nodes where the reflectors are 10cm long, the blankets are
20cm long, and the main fuel region is 100cm long.

10.0, 20.0, 100.0, 20.0, 10.0

A shorthand for repeated strings can be utilized using N*L. Where N (integer) is the number of repeated
nodes and L is the length of the node (cm). The below example defines an assembly with 14 nodes where
the main fuel region is divided into 10 nodes of 10cm.

10.0, 20.0, 10*10.0, 20.0, 10.0

TODO I believe the default may not work. check

-Options-

strings

-Default-

[16.12, "15*25.739", 16.12]

-Notes-

N/A

-Input Example-

parcs_data:
axial_nodes: 16.12, 20.32, 15*25.739, 20.32, 16.12

boc_core_exposure

This setting is used in the 'parcs_data' initialization and is used to tell MIDAS the begining of
cycle core exposure (MWD/MTU) used when constucting the PARCS input files.

-Options-

floats

-Default-

0.0

-Notes-

N/A

-Input Example-

parcs_data:
boc_core_exposure: 0.0

depletion_steps

This setting is shared by the 'parcs_data' and 'polaris_data' initializations and is used to tell MIDAS
the number of depletion steps and the duration of each step in days. Users must present the depeltion steps
using a comma separated string simimlar to the 'axial_nodes' setting. The shorthand for repeated strings
can be utilized similar to the 'axial_nodes' setting.

The shorthand for repeated strings can only be used for optimizations using PARCS simulations.

-Options-

strings

-Default-

[1, 1, 30, 30, 30, 30, 30, 30]

-Notes-

N/A

-Input Example-

parcs_data:
depletion_steps: 1, 1, 2*14, 3*30, 4*60, 2*120, 100

equilibrium_cycles

This setting is used by the 'parcs_data' initialization and is used to determine how many cycles an
equilibirum core will be run for during equilbirum cycle optimizations.

-Options-

integers

-Default-

10

-Notes-

N/A

-Input Example-

parcs_data:
quilibrium_cycles: 6

system_type

The system_type option is used in the 'polaris_data' initialization and specifies the type of lattice which
is being be optimized for lattice physics optimizations. This informs MIDAS on how to handle lattice symmetries.

-Options-

PWR
BWR

-Default-

PWR

-Notes-

N/A

-Input Example-

polaris_data:
system_type: BWR

lattice_symmetry

This setting is used in the 'polaris_data' initialization and specifies the lattice symmetry used when MIDAS
constructs the input file for the user selected lattice physics simulator. Due to the nature of the different
systems, 'se' is only availble for PWR lattices and 'diagonal' is only available for BWR lattices.

-Options-

full
se
diagonal

-Default-

se

-Notes-

N/A

-Input Example-

polaris_data:
lattice_symmetry: quarter

xs_library

This setting is used in the 'polaris_data' initialization and specifies the cross-section library to be used
by the lattice physics simulator for material properties. The options available for polaris can be found in
the SCALE user manual.

-Options-

strings

-Default-

fine_therm

-Notes-

N/A

-Input Example-

polaris_data:
xs_library: broad_lwr

pin_pitch

This setting is used in the 'polaris_data' initialization and specifies the pin pitch.

-Options-

floats

-Default-

1.26

-Notes-

N/A

-Input Example-

polaris_data:
pin_pitch: 1.26

box

This setting is used in the 'polaris_data' initialization and is used to define a assembly channel typically
seen with BWR lattices. The required inputs can be provided exactly as they would in a polaris input file.
More information about the box setting can be found in the SCALE user manual.

-Options-

strings

-Default-

0

-Notes-

strings are taken as inputs because mutliple values can be provided in the box setting in Polaris.

-Input Example-

polaris_data:
box: 0.203

hgap

This setting is used in the 'polaris_data' initialization and is used to define a the half distance between
assemblies. The required inputs can be provided exactly as they would in a polaris input file. More
information about the hgap setting can be found in the SCALE user manual.

-Options-

strings

-Default-

0

-Notes-

strings are taken as inputs because mutliple values can be provided in the hgap setting in Polaris.

-Input Example-

polaris_data:
hgap: 0.50

powdens

This setting is used in the 'polaris_data' initialization and specifies the power density of the assembly
to be used by the lattice physics simulator for material depletions. The power density should be provided
in units of Watts / gram of initial heavy metal loading.

-Options-

floats

-Default-

36

-Notes-

N/A

-Input Example-

polaris_data:
powdens: 20

bulk_temperatures

This setting is used in the 'polaris_data' initialization and specifies the non-fuel material temperatures
in Kelvin.

-Options-

floats

-Default-

566.0

-Notes-

N/A

-Input Example-

polaris_data:
bulk_temperatures: 550.0

fuel_temperatures

This setting is used in the 'polaris_data' initialization and specifies the fuel material temperatures
in Kelvin.

-Options-

floats

-Default-

900.0

-Notes-

N/A

-Input Example-

polaris_data:
bulk_temperatures: 950.0

controlrods_inserted

This setting is used in the 'polaris_data' initialization and informs MIDAS if control rods are insterted
into the lattice during the optimization. This setting is currently only avialble for PWR lattices.

-Options-

booleans

-Default-

False

-Notes-

N/A

-Input Example-

polaris_data:
controlrods_inserted: False

borated_material

This setting is used in the 'polaris_data' initialization and is used to define if liquid materials contain
soluable boron. Two inputs are required from the user, the first being the name of the liquid material and
the boron concentration in ppm. The name of the liquid material should have already been defined in the
materials section of 'rod_options'.

-Options-

strings

-Default-

None

-Notes-

N/A

-Input Example-

polaris_data:
borated_material: COOL, 500

num_mesh_rings

This setting is used in the 'polaris_data' initialization and specifies the numner of rings per fuel pin
used in the Polaris simulation. The number of rings affects the radial nodalization of the simulation
affecting simulation times.

-Options-

integers

-Default-

3

-Notes-

A good balance of rings should be used when conduction optimizations as the number of rings is incredibly
imporatant for modeling accuracy but will drastically slow down optimizations.

-Input Example-

polaris_data:
num_mesh_rings: 10