Repository navigation
Input Manual
As of 6/29/2026, the user manual is valid for MIDAS v2.0.0 (main branch)
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.
The 'General' block provides information regarding the type of optimization to be conducted, file handling,
and data post processing.
The optimizer option specifies the optimization method.
-Options-
genetic_algorithm
bayesian_optimization
simulated_annealing
tabu_search (devel)
gradient_descent (devel)
-Default-
genetic_algorithm
-Notes-
Different optimizers require specific input settings in the "optimization" block.
-Input Example-
general:
optimizer: genetic_algorithm
The code type option specifies which code MIDAS will interface with during an optimization. Several test
problems are natively available in MIDAS such as styblinski_tang and traveling_salesman for
benchmarking.
-Options-
parcs342
parcs343
parcs343_axial
parcs343_crp
ipwr_database
ipwr_database_legacy
trace50p5
polaris624
list_sum (devel)
styblinski_tang (devel)
levy_function (devel)
traveling_salesman (devel)
-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
The calc type option specifies the type of optimization problem to be conducted by MIDAS.
-Options-
single_cycle
eq_cycle
axial_zones (devel)
control_rod_pattern (devel)
lattice_physics
numeric_variable (devel)
categorical (devel)
-Default-
single_cycle
-Notes-
N/A
-Input Example-
general:
calc_type: single_cycle
This option is available for single cycle, equilibrium cycle, and axial assembly optimizations through
the parcs343 and parcs343_axial modules. Detailed explanations are available in the 'Template file
tutorial' tab of this wiki. The path to the template file is relative to the location of the yaml file. If the
template file is in the same directory as the yaml file then './template.inp' is sufficient.
Some calcaulation types can be run without input templates while others require a template to effectively
execute the optimization. The optimization problems that require templates are:
- single_cyle, BWR
- eq_cycle, BWR
- axial_zones
- control_rod_pattern
-Options-
apply:
True
False
loc:
strings
-Default-
apply:
False
loc:
''
-Notes-
MIDAS checks for basic input requirements but does not check the accuracy of the input file.
-Input Example-
general:
input_template:
apply: False
or
general:
input_template:
apply: True
loc: ./directory/template.inp
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
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
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
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
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
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
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
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
In this equation,
number of genes in the individual. The
evaluated using and external solver (e.g. a loading pattern would be evaluated by PARCS).
the target objective which is to be maximized and
optimization.
For a typical four-loop PWR,
can be reduced to
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.
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
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
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
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
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:
minimize:
meet_target:
greater_than_target:
less_than_target:
-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
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.
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
TODO...
-Options-
-Default-
-Notes-
N/A
-Input Example-
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
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
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
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
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
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:
linear_update:
log_update:
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
This setting allows the user to define the update factor,
-Options-
floats (1.0 >
$$\alpha$$ > 0.0)
-Default-
0.95
-Notes-
N/A
-Input Example-
algorithm:
update_factor: 0.95
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
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
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
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
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
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 measures the probability that sampling at x will improve upon the current best value.
Expected Improvement (EI)
Define
Then
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 explicitly trades off exploitation (mean) and exploration (uncertainty)
through
is typically an optimistic evaluation for a maximization problem, or pessimistic for a minimization problem.
Lower Confidence Bound (LCB)
LCB explicitly trades off exploitation (mean) and exploration (uncertainty)
through
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
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
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
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:
Where
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
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
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
This setting allows the user to define how chromosomes are perturbed to create children and generate a neighborhood
in the tabu search optimizer. "mutate" will perform random mutations on the active solution to construct the children.
-Options-
mutate
-Default-
mutate
-Notes-
N/A
-Input Example-
algorithm:
construct_neightbors: mutate
This setting allows the user to define how the number of tabu moves that are stored in the tabu list during a
TS optimization.
-Options-
integers
-Default-
10
-Notes-
N/A
-Input Example-
algorithm:
num_tabu: 10
This setting allows the user to define ranges for tabu moves when conducting continuous variable optimizations
using TS. Because the probability of a gene repeating the same exact value after being perturbed is extremely
low for continuous variables, the user can define tabu_bands. The bands create a range of values which become tabu
rather than a singular value. A factor of ± tabu_band is applied to gene value to create the tabu range.
This setting is only needed when conducting numeric_variable optimizations where the genes have a continuous
range.
-Options-
floats
-Default-
0.1
-Notes-
Remember that continuous variables are internally encoded as value between 0 and 1. The tabu band is applied
to the encoded genes, so the user should define the tabu band with this in mind.
-Input Example-
algorithm:
tabu_bands: 0.05
This setting allows the user to define aspiration criteria to be used during a TS optimization. Aspiration criteria
allow for a child chromosome to become the 'active' chromosome only if the aspiration criteria is met. This is only
required if moving from the child chromosome into the active chromosome requires a tabu move. If a tabu move
is not required to transition, then the aspiration criteria is not called and the child will automatically become the
active.
The 'improved_best' aspiration criteria allows for the child to become the active chromosome only if the fitness
value of the child chromosome is the highest value achieved thus far in the optimization. The 'relative_increase'
criteria allows the child chromosome to become the active if the fitness value of the child chromosome improves
apon the fitness of the previous active chromosome by some threshold. This fitness threshold is defined using the
'increase' parameter.
-Options-
method:
improved_best
relative_increase
increase:
floats
-Default-
method:
improved_best
-Notes-
Because the aspiration criteria depends on fitness values, the value for the 'increase' parameter is highly problem
dependent. Users should take care to determine a best value for this parameter.
-Input Example-
algorithm:
aspiration:
method: relative_increase
increase: 50
This setting allows the user to define the perturbation factor used to generate children and compute the gradient.
For each dimension, two children are created. This is done by perturbing the corresponding gene of the parent by a
factor of ± epsilon. The fitness values of the children are then used to compute the gradient.
-Options-
floats
-Default-
0.05
-Notes-
N/A
-Input Example-
algorithm:
epsilon: 0.05
This setting allows the user to define the learning rate which controls the size of the step taken during each
iteration as the algorithm moves toward an optima.
-Options-
floats
-Default-
0.005
-Notes-
N/A
-Input Example-
algorithm:
learning_rate: 0.005
This setting enables or disables the stochastic variant of gradient descent (SGD). When stochastic is set to false,
the population_size is overwritten and set to 2n+1 where n is the number of genes per chromosome. If stochastic is
true, then any value can be used as long as it is odd and is less than 2n+1.
-Options-
boolean
-Default-
False
-Notes-
While similar, GD and SGD have unique behaviors leading to differnt optimization dynamics.
-Input Example-
algorithm:
stochastic: True
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'
- 'axial_assembly_options' (devel)
- 'control_rod_options'
- 'gene_options' (devel)
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.
For assembly bundle optimizations, the 'axial_assembly_options' initialization must be used. To run these
optimizations, the user must have access to a nodal diffusion solver. Currently only PARCS is supported in MIDAS.
For control rod pattern optimizations, the 'control_rod_options' initialization must be used. To run these
optimizations, the user must have access to a nodal diffusion solver. Currently only PARCS is supported in MIDAS.
The 'gene_options' initializations is used for all generic optimization types including, numeric optimizations with
either continuous variables, discrete variables, or a combination of the two, and combinatorial optimizations.
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
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
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
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
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
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
This setting is unique to the 'axial_assembly_options' initialization and allows the user to define the assembly
lattices that can be used to populate the axial zones of an assembly during an axial assembly optimization.
When defining the lattices, the user must define the lattice name, the corresponding axial region, and the
corresponding numeric cross-section designation which is used in PARCS. Any axial regions which are used in the
lattice definitions must be defined under 'axial_assembly_parameters' in the decision variables block.
-Options-
name:
strings
region:
strings
designation:
integers
-Default-
None
-Notes-
-Input Example-
axial_assembly_options:
zone_xs:
dom_4.95:
designation: 5
region: dominant
This setting is unique to the 'axial_assembly_options' initialization and allows the user to define the assembly
axial regions and their lattices that are needed to construct assemblies during the optimization but are not
actively being optimized.
When defining the axial region, the user must define the region name and the corresponding numeric cross-section
designation which is used in PARCS.
-Options-
name:
strings
designation:
integers
-Default-
None
-Notes-
-Input Example-
axial_assembly_options:
constant_xs:
top_blanket:
designation: 10
This setting is unique to the 'control_rod_options' initialization and allows the user to define a control rod and the
range of notches (axial positions) with which it can exist within a core.
Given that control rod positions are numeric decision variables, rod types can be defined using the discrete_range or
continous_range input formats. Users must also include a rod 'designation' so that multiple different rod types can
be included in a single core. See discrete_range or continous_range input formats for more information.
If a user is defining only one control rod type for the optimization, please use a designation > 1. If a designation
of 1 is used, MIDAS will assume the associated rod maps are binary which will cause errors in the optimizations.
This will be fixed in a future update.
-Options-
name:
strings
discrete_range:
list of two numbers
increment:
float, integer, or list
-Default-
None
-Notes-
The below example shows a BWR whose control rods can exist on notches between 1 and 30. A notch of 1 is a fully
inserted rod and a notch of 30 is a fully extracted rod. The defined increment shows that during the optimization
the control rods can only exist within the top third of the core or be fully extracted.
-Input Example-
gene_options:
rod_1:
discrete_range: [1, 30]
increment: [1,2,3,4,5,6,7,8,9,10,30]
designation: 2
This setting is unique to the 'gene_options' initialization and allows the user to define a numeric variable with
a continuous range of values.
continuous range variables can have any value between the user defined upper and lower bounds. Internally, any
realization of the variable is encoded as an inclusive number between 0 and 1 with with 53-bit precision. The encoded
variable is convereted to its true value when printing in any generated input files, the midas.out file, and the csv
files. When printing the value, the variable is rounded for enhanced readibility.
When defining a continuous range variable, the user must define the variable name and the user must also provide the
lower and upper bounds for the variable. The variable name can be anything the user wishes with the only requirement
being that there is a corresponding set of variable parameters defined with the same name in the 'decision_variables'
block.
-Options-
name:
strings
conitnuous_range:
list of two numbers
-Default-
None
-Notes-
-Input Example-
gene_options:
variable_1:
continuous_range: [-10, 10]
This setting is unique to the 'gene_options' initialization and allows the user to define a numeric variable with
a discrete range of values.
discrete range variables are similar to continuous range variables however they are restricted to a set of potential
values between the user defined upper and lower bounds. Internally, any realization of the variable is encoded as an
inclusive number between 0 and 1 with with 53-bit precision. The encoded variable is convereted to its true value
when printing in any generated input files, the midas.out file, and the csv files.
When defining a discrete range variable, the user must define the variable name and the user must also provide the
lower and upper bounds for the variable. The variable name can be anything the user wishes with the only requirement
being that there is a corresponding set of variable parameters defined with the same name in the 'decision_variables'
block.
To define the valid discrete values, the user must provide a single float/integer called the 'increment'. This
allows the discrete variable to have any value between the upper and lower bounds with equal spacing determined
by the increment. For example, a discrete variable with bounds [0, 2] and increment of 0.5 can have values of 0,
0.5, 1.0, 1.5, and 2.0. If the increment does not cleanly divide both boundaries than the range of values will
extend from the lower bound up to the closest value to the upper bound. Fore example, a discrete variable with
bounds [0, 2] and increment of 0.6 can have values of 0, 0.6, 1.2, and 1.8. Alternatively, The user can provide
a list of valid values between the bounds that can be used by the discrete variable. This method allows for the
valid variable options to have different spacings between the values.
-Options-
name:
strings
discrete_range:
list of two numbers
increment:
float, integer, or list
-Default-
None
-Notes-
-Input Example-
gene_options:
variable_1:
discrete_range: [-10, 10]
increment: 1
or
gene_options:
variable_1:
discrete_range: [-10, 10]
increment: [-10, -9, -7, -4, 0, 5, 10]
This setting is unique to the 'gene_options' initialization and allows the user to define categorical or combinatorial
variable types.
When defining a categorical variable, the user must define the variable name and the user must also provide a defining
attrtribute of the categorical variable. The defining attribute can have any name and can be any type of pythonic
object. How the defining atttribute is used is dependnet on the code interface. An example of a defining attribute is
a coordinate used to define the location of a city for the traveling salesman problem.
-Options-
name:
strings
defining_attribute:
pythonic object
-Default-
None
-Notes-
-Input Example-
gene_options:
City1:
coordinate: [4,9]
or
gene_options:
banana:
cost: 5
The 'decision_variables' block is used to provide MIDAS with information regarding the decision variables and
the solution space of the problem being solved.
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
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
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
This setting is used for axial assembly optimizations and allows the user to define the axial zones which
comprise the assemblies that will undergo the optimization process.
When defining the zones, any axial regions which are used in the lattice definitions must have a corresponding
zone in this block. Location maps are provided by the user as a list where 0 represents an invalid assembly
location (usually used to denote once-burned or twice-burned assemblies) and non-zero values represent unique
assembly definitions. Non-zero elements can be repeated which allows for a single assembly definition to be used
in multiple positions in the core. Additionally, the zone number must be provided by the user. The zone number
allows MIDAS to construct the chromosome where each assembly is represented as a sub-list with each element being
an axial zone. The zone numbers must start from 1 and increase sequentially. Zone 1 represents the bottom axial
zone, and the last zone is the top.
When conducting an optimization, the product of the number of unique non-zero elements in the map as well as the
number of axial zones is equal to the chromosome length.
-Options-
name:
strings
map:
list
zone:
integers
-Default-
None
-Notes-
-Input Example-
decision_variables:
axial_assembly_parameters:
dominant:
zone: 1
map:
[0,
1, 0,
2, 3, 0,
4, 5]
vanished:
zone: 2
map:
[0,
1, 0,
2, 3, 0,
4, 5]
or
decision_variables:
axial_assembly_parameters:
dominant:
zone: 1
map:
[0,
1, 0,
2, 3, 0,
2, 3]
vanished:
zone: 2
map:
[0,
1, 0,
2, 3, 0,
2, 3]
This setting is used for control rod pattern optimizations and allows the user to define control rod maps.
When defining the control rods in the "options" block, the maps are used to identify the valid locations for
the defined rods. The rod maps are provided by the user as a list where 0 represents an invalid rod location
and non-zero values represent a valid location for the defined control rods. The non-zero values should
correspond to the "designation" which is provided when defining the control rods. The number of elements
in the solution encoding is determined by the number of non-zero elements in the utilized rod maps and the
'bank_pattern' setting found in the 'optimization' block.
-Options-
name:
strings
map:
list
-Default-
None
-Notes-
For the control rod maps defined below, if bank_pattern was set to "A1,A2" the number of elements in the solution
list would be 11.
-Input Example-
decision_variables:
rod_bank_parameters:
A1:
map:
[0,
0, 2,
0, 0, 0,
0, 2, 0, 2,
0, 0, 0, 0, 0,
0, 2, 0, 2, 0, 0,
0, 0, 0, 0, 0,
0, 0, 0, 0]
A2:
map:
[2,
0, 0,
2, 0, 2,
0, 0, 0, 0,
2, 0, 2, 0, 2,
0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0,
0, 0, 0, 0]
This setting is used for generic numerical and categorical optimizations and allows the user to define valid
locations in which a defined variable can be placed within the generated chromosomes.
When defining the parameters for a variable, the name of the parameter must have a corresponding variable under
'gene_options'. Maps are provided by the user to desginate positions in the chromosome where the variable exists.
Each map must be the length of the desired chromosomes and the elements must be either a 0 or a 1.
For numerical optimizations, each 1 on the map designates an independent realization of the variable. This allows
for a varible to be defined once but used multiple times in the optimization. For example, if 'length' is defined
under gene_options and has a continous range from 0 to 10, the corresponding map can be defined as [1,1,1] so that
there are 3 independent realizations of the 'length' variable. Each independent realization is completely separate
from the others and will be optimized uniquely. Any 0 values on the map means that this particular variable does
not populate the corresponding position in the chromosome. Only one variable may populate a position in the map,
if multiple variables are defined is a single position then MIDAS will error out.
For categorical optimizations, each 1 on the map designates a valid position where the 'category' (variable) may
exist in the chromosome. For example, if 'blue' has a map of [1,1,1] then each element of the chromosomes can be
'blue'. Additionally, more variables can have overlapping positions on the map ('red': [1,0,1]). When optimizating,
MIDAS will populate each position of a chromosome based on what variables are valid at that position. 0 elements
show that a variable is not valid at that position. Users can define constraints for categorical optimizations.
Numeric and catergorical variables work in different ways. Numeric variables always exist at a defined position in
a chromosome (gene), and they designate a range of potential values that are valid at that position. When optimizing,
the algorithm can choose any valid value within the defined range, but the algorithm cannot change variable itself.
Categorical variables do not have a set position in the chromosome. They instead define a 'state' in which a gene
may exist. Any state can be used to populate a gene as long as it is valid for the particular gene. When optimizaing,
the algorithm can select from the set states and change and pertub the gene.
-Options-
name:
strings
map:
list of 1s and 0s
constraint:
type:
max_quantity
less_than_variable
value: integers
-Default-
None
-Notes-
Constraints are not valid for numerical optimizations
-Input Example-
decision_variables:
parameters:
length:
map: [1,0,0]
height:
map: [0,1,0]
width:
map: [0,0,1]
or
decision_variables:
parameters:
raleigh:
map: [1,1,1]
durham:
map: [1,1,1]
chapel_hill:
map: [1,1,1]
constraint:
type: max_quantity
value: 1
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'
- 'optimization_data'
The 'optimization_data' initialization is used for all problems that do not require a specific code to conduct
the optimization (i.e. styblinski tang or traveling salesman).
Note that when utilizing PARCS-TRACE coupled simulations, a 'parcs_data' and a 'trace_data' block is required.
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.
-Valid Optimization Types-
All
-Options-
integers
-Default-
600
-Notes-
N/A
-Input Example-
parcs_data:
exec_walltime: 100
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
PWR
BWR
-Default-
PWR
-Notes-
BWR optimizations require a PARCS input template while PWR optimizations do not.
-Input Example-
parcs_data:
core_type: BWR
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.
-Valid Optimization Types-
single_cycle, eq_cycle, lattice_physics
-Options-
integers
-Default-
17
-Notes-
N/A
-Input Example-
parcs_data:
map:
num_rows: 17
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.
-Valid Optimization Types-
single_cycle, eq_cycle, lattice_physics
-Options-
integers
-Default-
num_rows
-Notes-
N/A
-Input Example-
parcs_data:
map:
num_cols: 17
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
integers
-Default-
193
-Notes-
N/A
-Input Example-
parcs_data:
map:
num_assemblies: 193
This setting is used in the 'parcs_data' initialization and specifies the assembly pitch.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
floats
-Default-
21.50
-Notes-
N/A
-Input Example-
parcs_data:
map:
assembly_pitch: 25.0
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
full
quarter
-Default-
full
-Notes-
N/A
-Input Example-
parcs_data:
map:
core_symmetry: quarter
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
strings
-Default-
./
-Notes-
N/A
-Input Example-
parcs_data:
xs_library_path: ../../LIBRARY
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
strings
-Default-
''
-Notes-
N/A
-Input Example-
parcs_data:
xs_extension: PMAXS
This setting is used in the 'parcs_data' initialization and specifies the core thermal power.
-Valid Optimization Types-
single_cycle, eq_cycle
-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
This setting is used in the 'parcs_data' initialization and specifies the core mass flow rate.
-Valid Optimization Types-
single_cycle, eq_cycle
-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
This setting is used in the 'parcs_data' initialization and specifies the coolant inlet temperature in
kelvin.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
floats
-Default-
565.0
-Notes-
N/A
-Input Example-
parcs_data:
inlet_temperature: 565.0
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
floats
-Default-
0.740
-Notes-
N/A
-Input Example-
parcs_data:
coolant_density: 1.000
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
floats
-Default-
900.0
-Notes-
N/A
-Input Example-
parcs_data:
fuel_temperature: 1000.0
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.
-Valid Optimization Types-
single_cycle, eq_cycle, axial_zones, control_rod_pattern
-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
This setting is used in the 'parcs_data' initialization and is used to enable or disable PARCS' pin
power reconstruction functionality.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
True
False
-Default-
True
-Notes-
N/A
-Input Example-
parcs_data:
pin_power_recon: True
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
integers
-Default-
264
-Notes-
N/A
-Input Example-
parcs_data:
assembly_pins: 264
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
integers
-Default-
25
-Notes-
N/A
-Input Example-
parcs_data:
assembly_guide_tubes: 25
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-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
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
integers
-Default-
19
-Notes-
N/A
-Input Example-
parcs_data:
num_axial_nodes: 19
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 comma 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
-Valid Optimization Types-
single_cycle, eq_cycle
-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
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.
-Valid Optimization Types-
single_cycle, eq_cycle
-Options-
floats
-Default-
0.0
-Notes-
N/A
-Input Example-
parcs_data:
boc_core_exposure: 0.0
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.
-Valid Optimization Types-
single_cycle, eq_cycle, lattice_physics
-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
This setting is used in the 'parcs_data' initialization and is used to tell MIDAS if the true core cycle
length will be estimated by extraploating from the parcs outputs.
If extrapolation is toggled, MIDAS will extrapolate from the last instance of non-zero boron concentration
to estimate the cycle length. If the extrapolation is turned off, then MIDAS will use the last instance of
non-zero boron as the efpd.
-Valid Optimization Types-
single_cycle, eq_cycle, axial_zones, control_rod_pattern
-Options-
boolean
-Default-
True
-Notes-
If set to False, the cycle length will be slightly under represented.
-Input Example-
parcs_data:
eoc_extrapolate: False
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.
-Valid Optimization Types-
eq_cycle
-Options-
integers
-Default-
10
-Notes-
N/A
-Input Example-
parcs_data:
quilibrium_cycles: 6
This setting is used by the 'parcs_data' initialization and is used to inform MIDAS on the assembly
discretization used during axial assembly optimizations. This input allows MIDAS to construct assembly
definitions in parcs and translate chromosomes into their parcs representations.
Through this setting, the user will provide the number of nodes used in parcs to define an axial region, and
the user will provide the order of each axial zone so that MIDAS can construct the assembly correctly.
-Valid Optimization Types-
axial_zones
-Options-
name:
strings
num_nodes:
integers
order:
integers
-Default-
None
-Notes-
N/A
-Input Example-
optimization_data:
zone_discretization:
dominant:
> num_nodes: 5
> order: 1
vanished:
> num_nodes: 4
> order: 2
This setting is used by the 'parcs_data' initialization and is used to inform MIDAS of the sequence of
control rod maps utilized during the optimization. A control rod map must be defined for each depeltion
step considered in the optimization. As such, if the "bank_pattern" setting is provided by the user,
"depletion_steps" must also be provided and have an equivalent number of elements.
-Valid Optimization Types-
control_rod_pattern
-Options-
comma separated string
-Default-
None
-Notes-
N/A
-Input Example-
parcs_data:
bank_pattern: A1, A2, A1, A2
This setting is used by the 'parcs_data' initialization and is used to inform MIDAS of a "partial"
optimization where only a portion of the reactor's operational cycle is considered. This is
particularly helpful for control rod pattern optimization as the patterns over a full cycle create
a very large design space with many decision variables that will overwhelm any applied algorithm.
Being able to split up the optimization into several parts both speeds up converegence and leads to
improved optimization results.
Users must take caution to ensure that the depletion sequence of interest is bounded by the provided
partial sequence.
-Valid Optimization Types-
control_rod_pattern
-Options-
apply:
boolean
steps:
one-indexed list
-Default-
parcs_data:
partial_sequence:
apply: False
steps: []
-Notes-
N/A
-Input Example-
parcs_data:
partial_sequence:
apply: True
steps: [1, 5]
This setting is used by the 'parcs_data' initialization and is used to inform MIDAS of the fully
inserted and fully removed control rod positions.
The presence of this setting is needed as the range of values that a control rod can possess during
an optimization may not encompass the fully inserted and fully extracted values.
Additionally, different systems insert control rods in different ways. For example, PWRs insert
control rods from the top and BWRs insert control rods from the bottom. In the case where a rod is
at notch 0, a PWR would interpret this as fully removed while a BWR would interpret this as fully
inserted.
-Valid Optimization Types-
control_rod_pattern
-Options-
fully_inserted:
integer
fully_removed:
integer
-Default-
parcs_data:
control_rod_bounds:
fully_inserted: 0
fully_removed: 50
-Notes-
N/A
-Input Example-
parcs_data:
control_rod_bounds:
fully_inserted: 0
fully_removed: 30
This setting is used by the 'parcs_data' initialization and is used to inform MIDAS of the location
of each control rod bundle within the core.
This map enables MIDAS to translate the control rod pattern chromosome into a form that can be
interpreted by PARCS. The numeric name used to designate each bank location must match the scheme
used in the parcs input or else the translation from MIDAS to Parcs will be inaccurate.
Only one input is needed to represent a rod bank if a single rod bank spans several assemblies
(BWRs). Similarly, one input is needed to represent partial rod banks.
-Valid Optimization Types-
control_rod_pattern
-Options-
list
-Default-
None
-Notes-
N/A
-Input Example-
parcs_data:
control_bank_conf:
[1,
2, 9,
3, 10, 16,
4, 11, 17, 22,
5, 12, 18, 23, 27,
6, 13, 19, 24, 28, 30,
7, 14, 20, 25, 29,
8, 15, 21, 26]
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.
-Valid Optimization Types-
lattice_physics
-Options-
PWR
BWR
-Default-
PWR
-Notes-
N/A
-Input Example-
polaris_data:
system_type: BWR
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.
-Valid Optimization Types-
lattice_physics
-Options-
full
se
diagonal
-Default-
se
-Notes-
N/A
-Input Example-
polaris_data:
lattice_symmetry: quarter
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.
-Valid Optimization Types-
lattice_physics
-Options-
strings
-Default-
fine_therm
-Notes-
N/A
-Input Example-
polaris_data:
xs_library: broad_lwr
This setting is used in the 'polaris_data' initialization and specifies the pin pitch.
-Valid Optimization Types-
lattice_physics
-Options-
floats
-Default-
1.26
-Notes-
N/A
-Input Example-
polaris_data:
pin_pitch: 1.26
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.
-Valid Optimization Types-
lattice_physics
-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
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.
-Valid Optimization Types-
lattice_physics
-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
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.
-Valid Optimization Types-
lattice_physics
-Options-
floats
-Default-
36
-Notes-
N/A
-Input Example-
polaris_data:
powdens: 20
This setting is used in the 'polaris_data' initialization and specifies the non-fuel material temperatures
in Kelvin.
-Valid Optimization Types-
lattice_physics
-Options-
floats
-Default-
566.0
-Notes-
N/A
-Input Example-
polaris_data:
bulk_temperatures: 550.0
This setting is used in the 'polaris_data' initialization and specifies the fuel material temperatures
in Kelvin.
-Valid Optimization Types-
lattice_physics
-Options-
floats
-Default-
900.0
-Notes-
N/A
-Input Example-
polaris_data:
bulk_temperatures: 950.0
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.
-Valid Optimization Types-
lattice_physics
-Options-
booleans
-Default-
False
-Notes-
N/A
-Input Example-
polaris_data:
controlrods_inserted: False
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'.
-Valid Optimization Types-
lattice_physics
-Options-
strings
-Default-
None
-Notes-
N/A
-Input Example-
polaris_data:
borated_material: COOL, 500
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.
-Valid Optimization Types-
lattice_physics
-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
This setting is used in the 'optimization_data' initialization and informs MIDAS on the length of a
chromosome when running numeric or categorical optimizations. If a value is not provided then it will
be infered from the map sizes defined in 'decision_variables'.
-Valid Optimization Types-
numeric_variable, categorical
-Options-
integers
-Default-
0
-Notes-
N/A
-Input Example-
optimization_data:
chromosome_length: 10