NOMAD usage
This chapter describes how to use NOMAD for solving blackbox optimization problems. Functionalities of NOMAD that are considered more advanced such as parallel evaluations are presented in Advanced functionalities.
Note
New users are encouraged to first read Getting started to understand the basics of NOMAD utilization.
Note
Many examples are provided in $NOMAD_HOME/examples
with typical optimization outputs.
Batch mode is presented first, followed by a description of the basic parameters to setup and solve the majority of optimization problems that NOMAD can handle. The library mode is described in Optimization in library mode.
NOMAD should be cited with the reference [AuLeRoTr2021]. Other relevant papers by the developers are accessible through the NOMAD website http://www.gerad.ca/nomad.
Optimization in batch mode
The batch mode allows to separate the evaluation of the objectives and constraints by the blackbox program from NOMAD executable. This mode has the advantage that if your blackbox program crashes, it will not affect NOMAD: The point that caused this crash will simply be tagged as a blackbox failure.
Handling crashes in library mode requires special attention to isolate the part of code that may generate crashes. And, in general, using the library mode will require more computer programming than the batch mode. However, the library mode offers more options and flexibility for blackbox integration and management of optimization (see Optimization in library mode).
The different steps for solving your problem in batch mode are:
Create a directory for your problem. The problem directory is where the NOMAD command is executed. It is a convenient place to put the blackbox executable, the parameters file and the output files, but those locations can be customized.
Create your blackbox evaluation, which corresponds to a program (a binary executable or a script). This program can be located in the problem directory or not. This program outputs the objectives and the constraints for a given design vector. If you already have a blackbox program in a certain format, you need to interface it with a wrapper program to match NOMAD specifications (see Getting started for blackbox basics).
Create a parameters file, for example
param.txt
. This file can be located in the problem directory or not (see Basic parameters description for more details).In the problem directory, start the optimization with a command like:
$NOMAD_HOME/bin/nomad param.txt
Basic parameters description
This section describes the basic parameters for the optimization problem definition, the algorithmic parameters and the parameters to manage output information. Additional information can be obtained by executing the command:
$NOMAD_HOME/bin/nomad -h
to see all parameters, or:
$NOMAD_HOME/bin/nomad -h PARAM_NAME
for a particular parameter.
The remaining content of a line is ignored after the character #
. Except for the file names, all strings and parameter names are case insensitive: DIMENSION 2
is the same as Dimension 2
. File names refer to files in the problem directory. To indicate a file name containing spaces, use quotes "name"
or 'name'
. These names may include directory information relatively to the problem directory. The problem directory will be added to the names, unless the $
character is used in front of the names. For example, if a blackbox executable is run by the command python script.py
, define parameter BB_EXE "$python script.py"
.
Some parameters consists of a list of variable indices taken from 0 to \(n-1\) (where \(n\) is the number of variables). Variable indices may be entered individually or as a range with format i-j
. Character *
may be used to replace 0 to \(n-1\). Other parameters require arguments of type boolean: these values may be entered with the strings yes
, no
, y
, n
, 0
, or 1
. Finally, some parameters need vectors as arguments, use (v1 v2 ... vn)
for those. The strings -
, inf
, -inf
or +inf
are accepted to enter undefined real values (NOMAD considers \(\pm \infty\) as an undefined value).
Parameters are classified into problem, algorithmic and output parameters, and provided in what follows. The advanced functionalities of NOMAD are presented in Advanced functionalities.
Problem parameters
Name |
Argument |
Short description |
Default |
---|---|---|---|
list of strings |
blackbox executables (required in batch mode) |
Empty string |
|
list of types |
blackbox input types |
|
|
list of types |
blackbox output types (required) |
|
|
DIMENSION |
integer |
\(n\) the number of variables (required) |
0 |
array of doubles |
lower bounds |
none |
|
array of doubles |
upper bounds |
none |
BB_EXE
In batch mode, BB_EXE
indicates the names of the blackbox executables.
A single string may be given if a single blackbox is used and gives several outputs. It is also possible to indicate several blackbox executables.
A blackbox program can return more than one function BB_OUTPUT_TYPE:
BB_EXE bb.exe # defines that `bb.exe' is an
BB_OUTPUT_TYPE OBJ EB EB # executable with 3 outputs
A mapping between the names of the blackbox programs and the BB_OUTPUT_TYPE
may be established to identify which function is returned by which blackbox:
BB_EXE bb1.exe bb2.exe # defines two blackboxes
BB_OUTPUT_TYPE OBJ EB # `bb1.exe' and `bb2.exe'
# with one output each
Blackbox program names can be repeated to establish more complex mapping:
BB_EXE bb1.exe bb2.exe bb2.exe # defines TWO blackboxes
# NO duplication if names are repeated
BB_OUTPUT_TYPE EB OBJ PB # bb1.exe has one output
# bb2.exe has two outputs
# bb1.exe is executed first.
#!! If EB constraint is feasible then
#!! bb2.exe is executed.
#!! If EB constraint not feasible then
#!! bb2.exe is not launched.
A path can precede the blackbox program but spaces are not accepted in the path:
BB_EXE "dir_of_blackbox/bb.exe"
To prevent NOMAD from adding a path, the special character $
should be put in front of a command:
BB_EXE "$python bb.py" # the blackbox is a python
# script: it is run with
# command
# `python PROBLEM_DIR/bb.py'
Or:
BB_EXE "$nice bb.exe" # to run bb.exe
# in nice mode on X systems
BB_INPUT_TYPE
This parameter indicates the types of each variable.
It may be defined once with a list of \(n\) input types with format (t1 t2 ... tn)
or `` * t``.
Input types t
are values in R, B, I
. R
is for real/continuous variables, B
for binary variables, and I
for integer variables.
The default type is R
. See also Detailed information.
Note
Categorical variables are not yet supported in NOMAD 4 but are available in NOMAD 3.
BB_OUTPUT_TYPE
This parameter characterizes the values supplied by the blackbox, and in particular tells how constraint values are to be treated. The arguments are a list of \(m\) types, where \(m\) is the number of outputs of the blackbox. At least one of these values must correspond to the objective function that NOMAD minimizes. Currently, NOMAD 4 only supports single objective problem (NOMAD 3 can handle bi-objective). Other values typically are constraints of the form \(c_j(x) \leq 0\), and the blackbox must display the left-hand side of the constraint with this format.
Note
A terminology is used to describe the different types of constraints [AuDe09a]
EB
constraints correspond to constraints that need to be always satisfied (unrelaxable constraints). The technique used to deal with those is the Extreme Barrier approach, consisting in simply rejecting the infeasible points.PB
andF
constraints correspond to constraints that need to be satisfied only at the solution, and not necessarily at intermediate points (relaxable constraints). More precisely,F
constraints are treated with the Filter approach [AuDe04a], andPB
constraints are treated with the Progressive Barrier approach [AuDe09a].There may be another type of constraints, the hidden constraints, but these only appear inside the blackbox during an execution, and thus they cannot be indicated in advance to NOMAD (when such a constraint is violated, the evaluation simply fails and the point is not considered).
If the user is not sure about the nature of its constraints, we suggest using the keyword CSTR
, which corresponds by default to PB
constraints.
All the types are:
|
Must be 0 or 1: count or not the blackbox evaluation |
|
Constraint treated with Extreme Barrier (infeasible points are ignored) |
|
Constraint treated with Filter approach |
|
The output is ignored by algorithm but will appear in cache and history file. |
|
Objective value to be minimized |
|
Constraint treated with Progressive Barrier |
Please note that F
constraints are not compatible with CSTR
or PB
. However, EB
can be combined with F
, CSTR
or PB
.
LOWER_BOUND
and UPPER_BOUND
Warning
NOMAD is 0 based \(\rightarrow\) The first variable has a 0 index.
Parameters LOWER_BOUND
and UPPER_BOUND
are used to define bounds on variables. For example, with \(n=7\):
LOWER_BOUND 0-2 -5.0
LOWER_BOUND 3 0.0
LOWER_BOUND 5-6 -4.0
UPPER_BOUND 0-5 8.0
is equivalent to:
LOWER_BOUND ( -5 -5 -5 0 - -4 -4 ) # `-' or `-inf' means that x_4
# has no lower bound
UPPER_BOUND ( 8 8 8 8 8 8 inf ) # `-' or `inf' or `+inf' means
# that x_6 has no upper bound.
Each of these two sequences define the following bounds
Algorithmic parameters
Name |
Argument |
Short description |
Default |
---|---|---|---|
direction type |
type of directions for the poll |
|
|
array of doubles |
\(\delta_0\) [AuDe2006] |
none |
|
array of doubles |
\(\Delta_0\) [AuDe2006] |
|
|
LH_SEARCH |
2 integers: |
LH (Latin-Hypercube) search ( |
none |
MAX_BB_EVAL |
integer |
maximum number of blackbox evaluations |
none |
MAX_TIME |
integer |
maximum wall-clock time (in seconds) |
none |
string |
temporary directory for blackbox i/o files |
problem directory |
|
point |
starting point(s) |
best point from a cache file or from an initial LH search |
DIRECTION_TYPE
This parameter defines the type of directions for Mads Poll step. The possible arguments are:
|
OrthoMADS, n+1, with (n+1)th dir = quad model optimization [Default since 4.2][AuIaLeDTr2014]_ |
|
OrthoMADS, 2n. This corresponds to the original Ortho Mads algorithm [AbAuDeLe09] with \(2n\) directions. |
|
OrthoMADS, n+1, with ((n+1)th dir = negative sum of the first n dirs) [AuIaLeDTr2014] |
|
MADS with n+1, using \(n+1\) uniformly distributed directions. |
|
A single direction is produced |
|
Two opposite directions are produced |
Multiple direction types may be chosen by specifying DIRECTION_TYPE
several times.
INITIAL_MESH_SIZE
and INITIAL_FRAME_SIZE
The Poll step initial frame size \(\Delta_0\) is decided by INITIAL_FRAME_SIZE
. In order to achieve the scaling between variables, NOMAD considers the frame size parameter for each variable independently. The initial mesh size parameter \delta_0
is decided based on \Delta_0
. INITIAL_FRAME_SIZE
may be entered with the following formats:
INITIAL_FRAME_SIZE d0 (same initial mesh size for all variables)
INITIAL_FRAME_SIZE (d0 d1 ... dn-1) (for all variables ``-`` may be used, and defaults will be considered)
INITIAL_FRAME_SIZE i d0 (initial mesh size provided for variable ``i`` only)
INITIAL_FRAME_SIZE i-j d0 (initial mesh size provided for variables ``i`` to ``j``)
The same logic and format apply for providing the INITIAL_MESH_SIZE
, MIN_MESH_SIZE
and MIN_FRAME_SIZE
.
TMP_DIR
If NOMAD is installed on a network file system, with the batch mode use, the cost of read/write files will be high if no local temporary directory is defined. On linux/unix/osxsystems, the directory /tmp
is local and we advise the user to define TMP_DIR /tmp
.
X0
Parameter X0
indicates the starting point of the algorithm. Several starting points may be proposed by entering this parameter several times. If no starting point is indicated, NOMAD considers the best evaluated point from an existing cache file (parameter CACHE_FILE
) or from an initial Latin-Hypercube search (argument p0
of LH_SEARCH
).
The X0
parameter may take several types of arguments:
A string indicating an existing cache file, containing several points (they can be already evaluated or not). This file may be the same as the one indicated with
CACHE_FILE
. If so, this file will be updated during the program execution, otherwise the file will not be modified.A string indicating a text file containing the coordinates of one or several points (values are separated by spaces or line breaks).
\(n\) real values with format
(v0 v1 ... vn-1)
.X0
keyword plus integer(s) and one real
X0 i v: (i+1)th coordinate set to v.
X0 i-j v: coordinates i to j set to v.
X0 * v: all coordinates set to v.
One integer, another integer (or index range) and one real: the same as above except that the first integer k refers to the (k+1)th starting point.
The following example with \(n=3\) corresponds to the two starting points \(( 5~0~0)\) and \((-5~1~1)\):
X0 * 0.0
X0 0 5.0
X0 1 * 1.0
X0 1 0 -5.0
Output parameters
Name |
Argument |
Short description |
Default |
---|---|---|---|
string |
cache file; if the file does not exist, it will be created |
none |
|
DISPLAY_ALL_EVAL |
bool |
if |
|
DISPLAY_DEGREE |
integer in [0 ; 3] or a string with four digits (see online help) |
0 no display and 3 full display |
|
list of strings |
what information is displayed at each success |
|
|
HISTORY_FILE |
string |
file containing all trial points with format |
none |
SOLUTION_FILE |
string |
file to save the best feasible incumbent point in a simple format (SOL BBO) |
none |
string |
the same as |
none |
CACHE_FILE
The cache file is used to store evaluations (true blackbox and surrogate) during optimization. Evaluation points are ordered according to the coordinates of the points. When NOMAD generates a trial point, before starting an evaluation, the cache is scanned for the point. If the evaluation information is available it will be used and the point will not be re-evaluated. It is possible to not use evaluation from cache by setting EVAL_USE_CACHE false.
Evaluation points in a cache file can be read for another optimization on the same problem. The dimension of the problem and the number of outputs must correspond. If no initial point is provided, NOMAD will consider the best point(s) from the cache as the initial best incumbent(s) for the optimization. The evaluation points in a cache file are also used to initialize the barrier and to build quadratic models.
By setting the flag USE_CACHE_FILE_FOR_RERUN true a special cache set is loaded from the cache file and is used to rerun an optimization. If an algorithm proposes a new trial point (not in regular cache), that is in the cache for rerun, the evaluation results will be used. Points not in cache for rerun will be evaluated with blackbox. This allows to perform a hot restart or reset the state of an algorithm (for example, an end-of-optimization state) to possibly suggest new points.
An example is given in $NOMAD_HOME/examples/advanced/batch/UseCacheFileForRerun
.
DISPLAY_DEGREE
Four different levels of display can be set via the parameter DISPLAY_DEGREE
. The DISPLAY_MAX_STEP_LEVEL
can be used to control the number of steps displayed. To control the display of the Models, a QUAD_MODEL_DISPLAY
and a SGTELIB_MODEL_DISPLAY
are available. More information on these parameters can be obtained with online documentation: $NOMAD_HOME/bin/nomad -h display
DISPLAY_STATS
and STATS_FILE
These parameters display information each time a new feasible incumbent (i.e. a new best solution) is found. DISPLAY_STATS
is used to display at the standard output and STATS_FILE
is used to write into a file. These parameters need a list of strings as argument, without any quotes. These strings may include the following keywords:
|
The number of blackbox evaluations |
|
The blackbox outputs |
|
The objective function value |
|
The current feasible iterate |
Note
More display options are available. Check the online help: $NOMAD_HOME/bin/nomad -h display_stats