3.11. Hint Reference

GTOpt hints specify types of variables and additional properties of objectives and constraints in an optimization problem.

This section lists available hints, corresponding keys recognized in hints, and their valid values.

Variable Hints

  • key: "@GT/VariableType", value: "Continuous" (default), "Integer", or "Discrete"

Changed in version 6.1: integer variables are now supported in gradient-based optimization (previously were supported in surrogate-based optimization only).

Changed in version 6.14: renamed the key to "@GT/VariableType" since it is now also used by a similar hint in GTDoE.

Changed in version 6.15: added the discrete variable type.

Objective Hints

  • key: "@GTOpt/EvaluationCostType", value: "Cheap" (default) or "Expensive"
  • key: "@GTOpt/ExpensiveEvaluations", value: integer in range \([0, 65535]\), -1, or "Auto" (default); -1 and "Auto" are the same
  • key: "@GTOpt/LinearityType", value: "Generic" (default), "Linear", or "Quadratic"

Changed in version 1.10.2: GTOpt now allows multiple expensive objectives and/or constraints in the given problem, thus supporting the multi-objective surrogate based optimization. Prior to 1.10.2, SBO was supported only in problems with a single objective or functional constraint (single-objective box-constrained problems and constraint satisfaction problems with one constraint).

Changed in version 6.6: the @GTOpt/LinearityType hint is no longer ignored in robust optimization problems. However, GTOpt now assumes that objectives hinted as linear or quadratic do not depend on any stochastic variable. This can lead to unexpected behavior if your definition of some objective includes a stochastic variable and at the same time you specify it to be a linear or quadratic function. Note that this is incorrect problem formulation, but GTOpt cannot automatically detect it.

Note

It is not recommended to set non-default @GTOpt/LinearityType and @GTOpt/EvaluationCostType for the same objective. See the note in Constraint Hints below for more details.

Constraint Hints

  • key: "@GTOpt/ConstraintAlpha", value: float in range \([0.0001, 0.9999]\); for example: 0.05; default: no value
  • key: "@GTOpt/ConstraintType", value: "ExpectationConstraint" (default) or "ChanceConstraint"
  • key: "@GTOpt/EvaluationCostType", value: "Cheap" (default) or "Expensive"
  • key: "@GTOpt/ExpensiveEvaluations", value: integer in range \([0, 65535]\), -1, or "Auto" (default); -1 and "Auto" are the same
  • key: "@GTOpt/LinearityType", value: "Generic" (default), "Linear", or "Quadratic"

Note

If @GTOpt/ConstraintType is set to "ChanceConstraint", then @GTOpt/ConstraintAlpha must also be set to a valid value since it has no default.

Changed in version 6.6: the @GTOpt/LinearityType hint is no longer ignored in robust optimization problems. However, GTOpt now assumes that constraints hinted as linear or quadratic do not depend on any stochastic variable. This can lead to unexpected behavior if your definition of some constraint includes a stochastic variable, and at the same time you specify it to be a linear or quadratic function. Note that this is incorrect problem formulation, but GTOpt cannot automatically detect it.

Note

It is not recommended to set non-default @GTOpt/LinearityType and @GTOpt/EvaluationCostType for the same response (objective or constraint). This combination of hints is accepted, but the @GTOpt/LinearityType hints becomes generally ineffective. For example, the method that restores the analytical form of linear and quadratic responses (see GTOpt/RestoreAnalyticResponses) is not used if the response is expensive: depending on the number of variables in the response, analytical restoration may require more evaluations than allowed by the GTOpt/MaximumExpensiveIterations option or the the @GTOpt/ExpensiveEvaluations hint.

Note

Linear and quadratic constraints cannot have the chance constraint type. If you set "@GTOpt/ConstraintType" to "ChanceConstraint" for a linear or quadratic constraint, this "@GTOpt/ConstraintType" setting is ignored.

@GTOpt/ExpensiveEvaluations

Restricts the number of evaluations individually for each expensive objective or constraint, including the evaluations of initial guess points.

Value:integer in range \([0, 65535]\), -1, or "Auto"
Default:"Auto"

New in version 6.13.

This hint is intended for response functions (objectives and constraints) that were marked as expensive using the @GTOpt/EvaluationCostType hint. In addition to the common expensive evaluations limit specified by GTOpt/MaximumExpensiveIterations, you can set a specific limit for any expensive response which works as follows:

  • A positive @GTOpt/ExpensiveEvaluations value can be used to impose a more strict limit than the one set by GTOpt/MaximumExpensiveIterations and GTOpt/MaximumIterations. That is, the lowest of these three limits is selected and becomes the evaluation budget for this response.

    Note that if GTOpt/MaximumExpensiveIterations is left default, GTOpt will analyze problem’s properties (number of variables, responses, and other) to automatically determine the common expensive evaluations limit. Then it will select the most strict limit among @GTOpt/ExpensiveEvaluations, GTOpt/MaximumIterations, and the internally determined GTOpt/MaximumExpensiveIterations. Since this behavior can be ambiguous, it is not recommended to use the @GTOpt/ExpensiveEvaluations hint with the default value of the GTOpt/MaximumExpensiveIterations option.

  • If you set @GTOpt/ExpensiveEvaluations for some expensive response to 0, GTOpt will never request evaluations for this response, regardless of the mentioned options’ values. Note that it also prohibits evaluating this response for the initial guess points (specified when adding variables to your problem or by passing the sample_x argument to solve()).

  • If the @GTOpt/ExpensiveEvaluations hint is not set, or set to one of the “auto” values (-1 or "Auto", default), the evaluation limit is controlled only by the GTOpt/MaximumIterations and GTOpt/MaximumExpensiveIterations options.

@GTOpt/ExpensiveEvaluations regards the evaluations required to obtain response values for the initial guess points in the same way as the GTOpt/MaximumIterations: such evaluations expend the budget specified by this hint. That is, for an expensive response with an added @GTOpt/ExpensiveEvaluations hint, the actual budget limit becomes the lowest of three values:

  1. the limit set by GTOpt/MaximumIterations,
  2. the number of initial guesses plus the limit set by GTOpt/MaximumExpensiveIterations, and
  3. the limit set by @GTOpt/ExpensiveEvaluations.

Once the evaluation limit for a response is reached, GTOpt stops requesting its evaluations by setting the corresponding values in the querymask that it sends to the problem’s evaluation method to 0. A proper handling of such selective evaluations requires a method that correctly parses the querymask — otherwise the hint you specified will have no effect. For this reason, if you want to use the @GTOpt/ExpensiveEvaluations hint, it is recommended to inherit your problem class from ProblemGeneric and implement the evaluate() method accordingly (see the method’s description for details).