Configuration Guide#
Example Configurations#
Single Objective Optimization#
# Single objective optimization config
########################
# Optimization Options #
########################
# The general optimization options that control everything
# from the acquisition function to what your objective metric is
optimization_options:
objective_options:
objectives:
# List all of your metrics here,
# only list 1 metric for a single objective optimization
- name: rmse
metric: RootMeanSquaredError
# List all outcome constraints here
outcome_constraints: []
# Here we explicitly define a generation strategy
# for our trials.
# This can always be done, but if left off,
# Will be autoselected.
# Here we say we want for first 5 trials
# To be a random sobol survey,
# and then the rest be Gaussian process expected improvement
generation_strategy:
steps:
# Other options are possible, see Ax GenerationStrategy
# for more information
- model: SOBOL
num_trials: 5
- model: GPEI
num_trials: -1
# experiment options we wish to use
# we specify an experiment name, which we can
# also use to name our experiment running and output directory
experiment:
name: "test_experiment"
# Scheduler options we wish to use
# Here we specify a total of 10 trials will be ran.
scheduler:
total_trials: 10
# Instead of putting all of your parameters under the parameters key,
# You can put them under different keys, and then
# pass a list of lists where each list is the json/yaml pathing to the
# additional parameters key section.
# See below for an example.
parameter_keys: []
# working_dir: .
# append_timestamp: True
# This last option appends a timestamp to our output experiment directory.
# This is also the default (True)
# optimization parameters
parameters:
x1:
type: range
bounds: [0, 1]
value_type: float
x2:
type: range
bounds: [0, 1]
value_type: float
x3:
type: range
bounds: [0, 1]
value_type: float
x4:
type: range
bounds: [0, 1]
value_type: float
x5:
type: fixed
value: .5
value_type: float
#########################
# Parameter Constraints #
#########################
# optimization parameter constraints
parameter_constraints:
- x2 + x1 >= .1
- x2 + x1 + .6*x1 <= .6
#################
# Model Options #
#################
# non optimization model options
# anything can go here that you want to pass to your model
# instead of BOA
model_options:
model_specific_options:
- 1
- 2
- 3
##################
# Script Options #
##################
# The script options section is for is you are using the BOA command line
# interface and passing your configuration file directly by path to BOA
# by command line
# see the example "Running an Experiment from Command Line (Python Wrapper)" for more info
script_options:
# wrapper_path: ./wrapper.py
# wrapper_name: Wrapper
Multi Objective Optimization#
# MultiObjective Optimization config
optimization_options:
objective_options:
objectives:
# List all of your metrics here,
# only list multiple objectives for a multi objective optimization
- metric: RMSE
- name: Meanyyy
metric: Mean
outcome_constraints: []
objective_thresholds: []
experiment:
name: "test_experiment"
scheduler:
total_trials: 10
parameters:
x1:
type: range
bounds: [0, 1]
value_type: float
x2:
type: range
bounds: [0, 1]
value_type: float
x3:
type: range
bounds: [0, 1]
value_type: float
x4:
type: range
bounds: [0, 1]
value_type: float
x5:
type: fixed
value: .5
value_type: float
parameter_constraints:
- x2 + x1 >= .1
- x2 + x1 + .6*x1 <= .6
model_options:
model_specific_options:
- 1
- 2
- 3
Additional Configurations#
Example of parameters being specified in alternative ways than the traditional parameters key location.
Useful for if you have multiple sections of parameters that you want to keep logically separated but you are still optimizing over them all, such as different plant species in a multi-species plant model.
optimization_options:
# Instead of putting all of your parameters under the parameters key,
# You can put them under different keys, and then
# pass a list of lists where each list is the json/yaml pathing to the
# additional parameters key section.
# Useful for if you have multiple sections of parameters that you
# want to keep logically separated but you are still optimizing over
# them all, such as different plant species in a multi-species plant model.
parameter_keys: [
["params", "a"],
["params", "b"],
["params_a"],
["params2", 0, 0],
["params2", 1, 0],
]
# Alternatively, these keys can be expressed in more traditional YAML
# syntax, but the above more traditional json like syntax might be easier
# to understand. They both mean the same thing, a list of lists
# -
# - "params"
# - "a"
# -
# - "params"
# - "b"
# -
# - "params_a"
# -
# - "params2"
# - 0
# - 0
# -
# - "params2"
# - 1
# - 0
params:
a:
x1:
type: range
bounds: [0, 1]
value_type: float
x2:
type: fixed
value: 0.5
value_type: float
b:
x1:
type: range
bounds: [ 0, 1 ]
value_type: float
x2:
type: fixed
value: 0.5
value_type: float
params_a:
x1:
type: range
bounds: [ 0, 1 ]
value_type: float
x2:
type: fixed
value: 0.5
value_type: float
params2:
- 0:
x1:
type: range
bounds: [ 0, 1 ]
value_type: float
x2:
type: fixed
value: 0.5
value_type: float
- 0:
x1:
type: range
bounds: [ 0, 1 ]
value_type: float
x2:
type: fixed
value: 0.5
value_type: float