3.10. Option Reference

GTOpt/AbsoluteGradientTolerance

Use absolute magnitude for gradient tolerance.

Value:Boolean
Default:off

If on, the value of GTOpt/GradientTolerance option is treated as the required magnitude of absolute remaining gradient (optimal descent) with no regard to the current values of objective function(s).

GTOpt/BatchSize

The upper limit for the point batch size in the batch evaluation mode.

Value:integer in range \([2, 65536]\), 1 (disable batch mode), or 0 (no limit)
Default:0 (auto)

Changed in version 6.11 Service Pack 1: added the auto (0) value and increased the maximum option value from 16384 to 65536.

Changed in version 6.39: to avoid ambiguity in GTOpt solver configuration, the limit set by GTOpt/BatchSize cannot be less than GTOpt/ResponsesScalability.

Sets the maximum number of points in evaluation batches sent to methods that support batch evaluation, such as evaluate(), define_objectives_batch(), or define_constraints_batch().

Setting GTOpt/BatchSize to 1 effectively means disabling batch evaluations, so the value of 1 may be used as a “batch mode off” switch.

The default value (0) allows the optimizer to use any batch size.

Note that if you configure GTOpt to use concurrent response evaluations (set the GTOpt/ResponsesScalability option), the point batch size limit set by GTOpt/BatchSize cannot be less than concurrency set by GTOpt/ResponsesScalability, as that would lead to inefficient parallelization of response evaluations. Generally, if you set GTOpt/ResponsesScalability, it is recommended to keep GTOpt/BatchSize default.

GTOpt/ConstraintsSmoothness

Set assumed smoothness of constraint functions.

Value:"Smooth", "Noisy", or "Auto"
Default:"Auto"

This option allows user to specify that all constraints functions are smooth ("Smooth") or at least one of them is known to be noisy ("Noisy"). In noisy context GTOpt assumes that corresponding noise factor is less than 10%. If left default ("Auto"), GTOpt makes assumption on smoothness automatically.

  • "Smooth": all constraints are to be considered smooth functions.
  • "Noisy": at least one constraint is noisy with noise level at most 10%.
  • "Auto": GTOpt is free to assume whatever seems appropriate.

GTOpt/ConstraintsTolerance

Set required relative precision of constraints satisfaction.

Value:floating point number in range \([0.01 \cdot\) float32_epsilon \(, 1.0)\)
Default:\(10^{-5}\)

This option sets the required relative precision of constraints satisfaction. Constraints are required to be at most this number times relevant limit away from limiting value.

GTOpt/CoordinateTolerance

Set relative consecutive coordinate change threshold.

Value:floating point number in range \([l, 1.0)\) (\(l\) depends on gradients type, see GTOpt/DiffType), or 0.0
Default:auto, depends on gradients type

Optimization stops when \(L_{\infty}\) norm of relative consecutive coordinate change becomes smaller than value of this option. In case this option is set to 0.0 (this is not always valid), GTOpt does not use consecutive coordinate change norm value as optimization stop criterion.

The lower bound of this option value depends upon GTOpt/DiffType option:

For all these cases, actual value of GTOpt/CoordinateTolerance is forced to be within the valid range.

GTOpt/DetectNaNClusters

Try to avoid design space areas where blackbox responses evaluate to NaN.

Value:Boolean
Default:on

New in version 6.16.

This option works in surrogate-based optimization only (expensive problems). If there are no expensive responses in the problem (objectives or constraints marked with the "@GTOpt/EvaluationCostType" hint, see Hint Reference), this option has no effect.

By convention, a NaN value received from a blackbox as an evaluation result for some response means that the blackbox has failed to evaluate this response for given input. GTOpt/DetectNaNClusters changes the treatment of such evaluation failures:

  • When enabled (default), GTOpt assumes that the response which failed to evaluate is a function, which is undefined in some specific regions of the design space. It then tries to detect and avoid such regions in order to reduce the number of evaluation failures.
  • When disabled, GTOpt assumes that evaluation failures are independent and do not belong to a certain region. For example, if the blackbox returns a NaN response for some input point, GTOpt can still request evaluations for adjacent points.

Default is suitable for many real tasks, including those where all responses are well-defined — there are no drawbacks in this case. However if evaluation failures can appear randomly, this option should be disabled.

GTOpt/Deterministic

Require optimization process to be reproducible.

Value:Boolean or "Auto"
Default:"Auto"

New in version 6.12.

If on (True) then in randomized routines the optimizer uses the fixed seed specified by GTOpt/Seed. If off (False), a random seed is used. When "Auto", the seed value depends on problem description. Pure deterministic optimization routines (non-global gradient methods, for example) are not affected by this option.

This option may not work in the mixed integer linear problem context, when:

  • There are no objectives in the problem, or there is a single objective and this objective is linear.
  • There is at least 1 constraint, and all constraints are linear.
  • There is at least 1 integer variable.
  • Analytical gradients are enabled for the objective or constraints (see enable_objectives_gradient(), enable_constraints_gradient() ).
  • Multi-threading is enabled (GTOpt/MaxParallel is not 1).

If all of the above conditions are observed, the mixed integer linear problem solver may show non-deterministic behavior even with GTOpt/Deterministic enabled. It means that results obtained in repeated solver runs may be not exactly the same, howewer, in well-posed problems the differences are negligible.

GTOpt/DiffScheme

Set differentiation scheme order.

Value:"FirstOrder", "SecondOrder", "Adaptive", or "Auto"
Default:"Auto"

This options sets the differentiation scheme order and applies to both numerical and framed gradients. When analytic gradients are available, this option value is ignored.

  • "FirstOrder": utilize first order approximation exclusively, even close to optimality.
  • "SecondOrder": always use second order approximation, even far away from optimal set.
  • "Adaptive": adaptively switch between first and second order schemes basing on estimated distance to optimality.
  • "Auto": GTOpt is free to choose whatever scheme seems more appropriate.

GTOpt/DiffType

Set strategy for estimating derivatives.

Value:"Numerical", "Framed", or "Auto"
Default:"Auto"

This option allows user to specify strategy to use to estimate derivatives. Note that for analytical gradients this option is ignored.

  • "Numerical": use conventional numerical differentiation if analytic gradients are not available. Most suitable for smooth problems, not to be used in noisy context.
  • "Framed": use framed (simplex-based) gradients if analytic gradients are not available. Most suitable for noisy problems, in smooth context leads to (sometimes severe) performance degradation.
  • "Auto": GTOpt is free to choose whatever differentiation type seems more appropriate.

GTOpt/EnsureFeasibility

Require optimizer to stay within the feasible domain.

Value:Boolean
Default:off

In many real life cases optimizer is required to stay strictly within the feasible domain, for instance, when the objective function is difficult or impossible to calculate outside the feasible set. This option allows user to request strict feasibility of all optimization iterates. By default it is off since feasibility requirement frequently causes performance degradation.

GTOpt/FrontDensity

Density of points on the discovered Pareto frontier.

Value:integer in range \([1, 999]\)
Default:10

Controls how many Pareto optimal solutions should be generated when exploring the problem’s Pareto frontier. GTOpt will try to generate up to \(d^{K-1}\) solutions, where \(d\) is this option’s value, and \(K\) is the number of objective functions. Depending on the front complexity, the actual number of Pareto solutions generated may vary.

This option is intended for multi-objective optimization problems only and takes effect only if GTOpt/MOPIsGlobal is on.

GTOpt/GlobalPhaseIntensity

Configures global searching algorithms.

Value:floating point number in range \([0, 1]\) or "Auto"
Default:"Auto"

New in version 1.10.5.

Enables global optimum search and allows tuning the complexity of applied global optimization and surrogate-based optimization methods. The minimum sensible step is 0.01.

Changed in version 6.11: added the "Auto" value (now default) and changed the meaning of the 0 value for expensive problems.

This option has different meaning for expensive and non-expensive optimization problems (see Hint Reference).

For non-expensive problems:

  • "Auto" (default) and 0 disable global search completely.
  • Any positive value (0.01 or greater) enables global search and also sets algorithm complexity.

Lesser values (greater than 0.01 but close to zero) are suitable for “almost unimodal” problems in which multi-modality is not severe and simplest methods should work. Greater values (close to 1) may be used in hard to solve multi-modal cases. Setting a value close to 1 results in using most complex and time-consuming global algorithms. See section Local and Global Methods for more details.

For expensive problems:

  • "Auto" (default) allows GTOpt to select a suitable value of the option based on the provided number of expensive iterations (if set, see GTOpt/MaximumExpensiveIterations) and problem dimensionality.
  • 0 means to use the Direct SBO technique which does not consider error estimations of surrogate models (see Direct SBO).
  • Any positive value (0.01 or greater) enables the general surrogate-based optimization algorithm (see Surrogate Based Optimization) which takes into account both predicted values and error estimations of the internal surrogate models. In this case, higher values enable more intensive exploration and more accurate optimization of the internal criterion.

This option also has special behavior in problems with integer variables. In most cases, GTOpt automatically switches to using surrogate-based methods when solving such problems, so GTOpt/GlobalPhaseIntensity behaves in the same way as for expensive problems — even if you do not add any expensive functions in problem definition. The only exception is the case when all problem objectives and constraints are linear, and you provide analytical gradients for each of them. In this case, GTOpt does not automatically enable surrogate-based methods, which brings the behavior of GTOpt/GlobalPhaseIntensity back to normal: it depends on whether you add expensive functions to the problem.

GTOpt/GradientTolerance

Set gradient threshold.

Value:floating point number in range \([0.0, 1.0)\)
Default:\(10^{-5}\)

This option sets the \(L_{\infty}\) norm of remaining gradient (or optimal descent for constrained and multi-objective problems) at which optimization stops. In case option value is 0.0, GTOpt optimizer will not use gradient norm value as optimization stop criterion.

Note that by default gradient tolerance refers to relative magnitude of remaining gradient (optimal descent) which is measured with respect to current value of objective function (\(L_{\infty}\) norm of objective functions). GTOpt/AbsoluteGradientTolerance can be used to switch to absolute gradient tolerance.

GTOpt/LocalSearch

Switch the local search mode in surrogate-based optimization.

Value:"Disabled" or "Forced"
Default:"Disabled"

New in version 6.17.

In the forced local mode, the surrogate-based optimization algorithm does not aim to explore the design space globally, but focuses on the area close to the current optimum. The location and size of this area are adjusted at every new algorithm iteration, so the current optimum moves similarly to gradient-based optimization. Instead of a global response model, this mode uses local response models, which take less time to train, thus making the optimization algorithm less time-consuming.

Local search is intended to be used with an initial guess point or an initial sample:

  • If you specify an initial guess only, local search starts from this point.
  • If you add an initial sample, it is used to train an initial response model, which is then used to select the starting point for local search.
  • Otherwise, if there is no initial sample and no initial guess, GTOpt generates an initial global DoE and evaluates responses in DoE points, then uses this data as an initial sample.

GTOpt/LogLevel

Set minimum log level.

Value:"Debug", "Info", "Warn", "Error", "Fatal"
Default:"Info"

If this option is set, only messages with log level greater than or equal to the threshold are dumped to the log.

GTOpt/MaximumExpensiveIterations

The maximum number of expensive response evaluations, not counting the evaluations of initial guesses.

Value:integer in range \([1, 2^{31} - 1]\), or 0 (auto)
Default:0 (auto)

Changed in version 6.16: 1 and 2 are now valid values, previously the lowest valid non-default was 3.

Changed in version 6.39: if you use concurrent response evaluations (set the GTOpt/ResponsesScalability option), GTOpt/MaximumExpensiveIterations limits the number of batches that request evaluations of expensive responses, rather than the number of points where expensive responsive are evaluated (see the GTOpt/ResponsesScalability description for details).

Expensive responses are objectives and constraints marked with the "@GTOpt/EvaluationCostType" hint (see Hint Reference).

Non-default GTOpt/MaximumExpensiveIterations specifies the same evaluation budget for each of these responses. If left default, the evaluation budget is determined automatically. The automatic budget is finite but can vary depending on the problem properties.

In contrast with the GTOpt/MaximumIterations option, the budget set by GTOpt/MaximumExpensiveIterations is not expended when calculating expensive response values for the initial guess points (the sample_x argument to solve()). However, the number of expensive evaluations still cannot exceed the limit set by GTOpt/MaximumIterations. Consider the following examples:

  • sample_x contains 10 points (sample_f and sample_c are not given), GTOpt/MaximumIterations is 50, and GTOpt/MaximumExpensiveIterations is 15. Cheap responses will be evaluated 50 times: 10 for the initial guess points and 40 more until the GTOpt/MaximumIterations limit is reached. Each expensive response will be evaluated 25 times: 10 for the initial guess points and 15 more until the GTOpt/MaximumExpensiveIterations limit is reached.
  • sample_x contains 10 points (sample_f and sample_c are not given), GTOpt/MaximumIterations is 20, and GTOpt/MaximumExpensiveIterations is kept at 15. Cheap responses will be evaluated 20 times: 10 for the initial guess points and 10 more until the GTOpt/MaximumIterations limit is reached. Each expensive response will also be evaluated 20 (not 25) times, because their evaluations are now effectively limited by GTOpt/MaximumIterations. The GTOpt/MaximumExpensiveIterations limit will not be reached actually.

That is, the actual budget limit for an expensive response is the lowest of two values:

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

Once the budget limit for an expensive 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 this option will have no effect. For this reason, if you want to use the GTOpt/MaximumExpensiveIterations option, it is recommended to inherit your problem class from ProblemGeneric and implement the evaluate() method accordingly (see the method’s description for details).

Using GTOpt/MaximumExpensiveIterations with problem classes other than ProblemGeneric is possible only in some cases. For example, if you use ProblemConstrained and all your constraints are expensive, all constraint-related values in the querymask will be set to 0 after the GTOpt/MaximumExpensiveIterations is reached. This case will be automatically handled by the default evaluate() implementation because it can see that no constraint evaluations are requested, so it will simply stop calling define_constraints() (define_constraints_batch()). However, this is not possible if only some of the constraints are expensive: even after reaching the GTOpt/MaximumExpensiveIterations limit, GTOpt will continue to request evaluations for non-expensive constraints. Consequently, evaluate() will have to disregard the received querymask and evaluate all constraints, since the ProblemConstrained class does not provide methods that would allow to evaluate constraints selectively.

See also the @GT/EvaluationLimit hint that enables you to set an individual evaluation budget for an objective or constraint.

GTOpt/MaximumIterations

The maximum number of response evaluations, counting also the evaluations of initial guesses.

Value:integer in range \([0, 2^{32} - 2]\)
Default:0 (no limit)

Changed in version 6.39: if you use concurrent response evaluations (set the GTOpt/ResponsesScalability option), GTOpt/MaximumIterations limits the number of evaluation batches rather than the number of evaluated points (see the GTOpt/ResponsesScalability description for details).

Limits the number of evaluations for each response (objective or constraint). Non-default value specifies the same evaluation budget for each response. If set to 0 (default), there is no limit.

This budget is expended for each response evaluation, including those evaluations that are needed to calculate response values for the initial guess points (the sample_x argument to solve()). For example, if sample_x contains 10 points and GTOpt/MaximumIterations is 15, each response will be evaluated 15 times (assuming that sample_f and sample_c are not given): 10 for the initial guess points and 5 more when actually solving the problem. The same goes for initial guesses specified when adding variables to your problem with add_variable().

See also the @GT/EvaluationLimit hint that enables you to set an individual evaluation budget for an objective or constraint.

GTOpt/MaxParallel

Set the maximum number of parallel threads to use when solving.

Value:integer in range \([1, 512]\), or 0 (auto)
Default:0 (auto)

New in version 5.0 Release Candidate 1.

GTOpt can run in parallel to speed up solving. This option sets the maximum number of threads the solver is allowed to create.

Changed in version 6.12: auto (0) tries to detect hyper-threading CPUs in order to use only physical cores.

Changed in version 6.15: added the upper limit for the option value, previously was any positive integer.

Changed in version 6.17: changed the upper limit to 512 (was 100000).

Default (auto) behavior depends on the value of the OMP_NUM_THREADS environment variable.

If OMP_NUM_THREADS is set to a valid value, this value is the maximum number of threads by default. Note that OMP_NUM_THREADS must be set before the Python interpreter starts.

If OMP_NUM_THREADS is unset, set to 0 or an invalid value, the default maximum number of threads is equal to the number of cores detected by GTOpt. However if a hyper-threading CPU is detected, the default maximum number of threads is set to half the number of cores (to use only physical cores).

The behavior described above is only for the default (0) option value. If you set this option to a non-default value, it will be the maximum number of threads, regardless of your CPU.

GTOpt/MOPIsGlobal

Set multi-objective optimization mode.

Value:Boolean
Default:on

This option switches multi-objective optimization modes. Global (on, default) means discovery of whole Pareto frontier. Local (off) implies search of single Pareto optimal solution close to the initial point.

GTOpt/NumDiffStepSize

Numerical differentiation step.

Value:floating point number in range \([\) float32_epsilon \(, 1.0]\)
Default:float32_epsilon \(\cdot 10\)

This option sets the step size to use in numerical differentiation.

GTOpt/ObjectivesSmoothness

Set assumed smoothness of objective functions.

Value:"Smooth", "Noisy", or "Auto"
Default:"Auto"

This option allows user to specify that all objective functions are smooth ("Smooth") or at least one of them is known to be noisy ("Noisy"). In noisy context GTOpt assumes that corresponding noise factor is less than 10%. If left default ("Auto"), GTOpt makes assumption on smoothness automatically.

  • "Smooth": all objectives are to be considered smooth functions.
  • "Noisy": at least one objective function is noisy with noise level at most 10%.
  • "Auto": GTOpt is free to assume whatever seems appropriate.

GTOpt/ObjectiveTolerance

Set the threshold for relative consecutive change of objective functions.

Value:floating point number in range \([l, 1.0)\) (\(l\) depends on problem type), or 0.0
Default:\(l\)

Optimization stops when \(L_{\infty}\) norm of relative consecutive change of objective functions becomes smaller than value of this option. In case this option is set to 0.0 (this is not always valid), GTOpt does not use the norm of consecutive change of objective functions as optimization stop criterion.

If analytical gradients are available, \(l\) is set equal to \(0.1 \cdot\) float32_epsilon. When analytical gradients are not available in the problem, \(l\) is silently changed to \(10^4 \cdot\) float64_epsilon.

GTOpt/OptimalSetRigor

Set the degree of constraints violation allowed for the points in the extended result data set.

Value:floating point number in range \([0.0, 1.0]\)
Default:0.1

New in version 3.0 Beta 1.

This option controls the degree of constraint and feasibility violation allowed for points included in the infeasible result set when GTOpt/OptimalSetType is set to "Extended" and intensity of filtering for close points in results. Internally it sets several related thresholds in such a way that lower option values act as a weak filter, while higher values make the filter more aggressive. For example:

  • 0.0: no filtering; all optimal points that violate constraints are included in the infeasible set.
  • 1.0: no violation allowed; effectively the same as setting GTOpt/OptimalSetType to "Strict" (the infeasible set will be empty).

If GTOpt/OptimalSetType is "Strict", GTOpt/OptimalSetRigor is ignored. For more details, see also sections Optimal Solution and Optimal and Infeasible Result Sets.

GTOpt/OptimalSetType

Types of points to include in the result data set.

Value:"Extended", "Strict", or "Auto"
Default:"Auto"

New in version 3.0 Beta 1.

Since version 3.0 Beta 1, an optimization result may include additional points that satisfy optimality criteria but violate problem constraints and feasibility measures to a certain extent.

  • "Extended": include additional points as the infeasible set.
  • "Strict": include non-violating points only; with this setting, the infeasible set is empty (similar to solver behavior prior to 3.0 Beta 1).
  • "Auto": defaults to "Extended".

The degree of constraint violation allowed for infeasible result points is controlled by the GTOpt/OptimalSetRigor option. For more details, see also sections Optimal Solution and Optimal and Infeasible Result Sets.

Note that in robust optimization problems setting GTOpt/OptimalSetType to "Extended" can also have an effect on which points are included into the optimal set due to some aspects of selecting candidate solutions (see section Approximated Problem Solution for details). That is, comparing the results of solving the same robust optimization problem with GTOpt/OptimalSetType set to "Strict" and "Extended" can show differences. These differences are minor if we consider overall quality of the result. For more details on how optimal and infeasible results are formed in the robust case, see Robust Problem Optimal Solution.

GTOpt/RestoreAnalyticResponses

Enable training internal models of linear and quadratic responses and using those models to obtain response values instead of requesting response evaluations from the problem.

Value:Boolean or "Auto"
Default:"Auto"

New in version 3.0 Beta 1.

Changed in version 6.29: for linear responses, True is now interpreted as a requirement: if a response is hinted as linear but cannot be fitted with a linear model, optimization stops and raises an exception.

Changed in version 6.32: for linear responses, you can use the @GT/EvaluationLimit hint to increase the number of response evaluations required when training an internal response model.

GTOpt supports internal modeling of responses (objectives and constraints) that are hinted as linear or quadratic using the @GTOpt/LinearityType hint (see Hint Reference). Behavior depends on the response type.

For linear responses:

  • If set to True, GTOpt aims to fit each linear response with a linear model prior to starting the main optimization algorithm. This requires initially sampling a certain number of linear response evaluations that depends upon the number of design variables. You can also require a higher number of linear response evaluations by setting the @GT/EvaluationLimit hint on a per-response basis — for example, to improve model accuracy in the case of a noisy linear response. If you set @GT/EvaluationLimit for a linear response, its internal modeling takes as many evaluations as specified by that hint. If some linear response cannot be fitted with a linear model, it means that the linearity requirement is not met, and in this case GTOpt raises an exception. If response modeling succeeds, optimization continues to use the obtained response model internally. This guarantees that GTOpt will not request any more linear response evaluations from the problem.
  • If "Auto" (default), GTOpt also tries modeling linear responses before optimization, but does not raise an exception if modeling fails: instead, it issues a warning, and optimization continues normally. Since there is no internal response model in case of failure, linear response evaluations are requested from the problem. In that case, linear responses are treated according to their @GTOpt/EvaluationCostType hint values.

For quadratic responses:

  • True and "Auto" (default) have the same behavior. GTOpt never performs initial sampling of quadratic responses, since the number of evaluations required to train an accurate quadratic model grows rapidly with the number of design variables. Quadratic response evaluations are requested from the problem, and if enough data are collected during solving, GTOpt begins fitting it with a quadratic model. If modeling succeeds and optimization is not yet finished, GTOpt continues to use the obtained response model internally instead of requesting quadratic response evaluations from the problem. This behavior does not guarantee that quadratic response modeling succeeds. Until an internal quadratic response model is available, GTOpt continues to treat that response according to its @GTOpt/EvaluationCostType hint value.

Setting this option to False completely disables internal modeling of both linear and quadratic response types.

GTOpt/RobustConstraintsTolerance

Set constraints violation relative error threshold for robust optimization.

Value:floating point number in range \([0.01 \cdot\) float32_epsilon \(, 1.0)\)
Default:0.025

Robust optimization can stop only when current estimate of constraints violation relative error at proposed optimal point becomes smaller than this option value. See also GTOpt/RobustObjectiveTolerance.

GTOpt/RobustGradientTolerance

Set the gradient threshold for robust optimization.

Value:floating point number in range \([0.0, 1.0)\)
Default:0.0 (disabled)

Within the robust optimization context it might be desirable to check the magnitude of extremality of proposed solution. This option provides an upper bound on required relative uncertainty of estimated extremality measure. Note that explicit verification of solution extremality might be quite expensive (normally the solution is indeed extremal without explicit checks). For this reason default option value disables extremality testing.

GTOpt/RobustObjectiveTolerance

Set objective value relative error threshold for robust optimization.

Value:floating point number in range \([\)float32_epsilon \(, 1.0)\)
Default:0.025

Robust optimization can stop only when current estimate of relative error of the objective value at proposed optimal solution becomes smaller than this option value. See also GTOpt/RobustConstraintsTolerance.

GTOpt/ResponsesScalability

The maximum number of concurrent response evaluations supported by the problem.

Value:integer in range \([1, 512]\)
Default:1

New in version 6.11 Service Pack 1.

Changed in version 6.39: specifying GTOpt/ResponsesScalability greater than 1 changes the GTOpt/MaximumIterations and GTOpt/MaximumExpensiveIterations option behavior with regard to concurrency in response evaluations.

Changed in version 6.39: to avoid ambiguity in GTOpt solver configuration, GTOpt/ResponsesScalability cannot be greater than the point batch size limit set by the GTOpt/BatchSize option.

Changes the computational model used by some methods (mainly Surrogate-Based Optimization and Robust Optimization) to use parallel calculations more efficiently. This option should be used only if your problem definition supports concurrent response evaluations. If you set it, this specifies the supported parallelization ratio but does not guarantee that GTOpt will use maximum concurrency when evaluating problem responses.

When possible, GTOpt adjusts sizes of point batches it sends for evaluation so that size is a multiple of the GTOpt/ResponsesScalability value. In surrogate-based optimization (SBO), such adjustment is forced at the initial solving stage — when evaluating points to train the initial internal model. On subsequent iterations GTOpt/ResponsesScalability may sometimes be neglected in SBO, as it is not always possible to select the needed number of points without violating the internal optimization criteria. This behavior depends on the response function behavior, presence of computationally cheap responses in an SBO problem, number of variables and responses, and other problem properties.

When you set GTOpt/ResponsesScalability to \(p\) (2 or greater), the GTOpt/MaximumIterations and GTOpt/MaximumExpensiveIterations options change their behavior with regard to concurrency: in that case, they set the maximum allowed number of evaluated batches, where a batch contains up to \(p\) points. For example, if GTOpt/ResponsesScalability is 4:

  • If you set GTOpt/MaximumIterations to 50, this allows GTOpt to evaluate up to 50 batches, containing up to 4 points each. The total number of points evaluated cannot exceed 200, but does not certainly reach 200 even in cases where all 50 batches are generated and evaluated, because batches may contain less than 4 points. This limit applies to any response regardless of its computational cost.
  • If you also set GTOpt/MaximumExpensiveIterations to 20, this limits the number of batches with expensive response evaluations to 20, and each of those batches may contain up to 4 points. The total number of points where expensive responses are evaluated cannot exceed 80, but does not certainly reach 80 even if all 20 batches are evaluated.

Using concurrent response evaluations requires the batch evaluation mode. The GTOpt/BatchSize and GTOpt/ResponsesScalability option settings must be consistent: the point batch size limit set by GTOpt/BatchSize cannot be less than concurrency set by GTOpt/ResponsesScalability, as that would lead to inefficient parallelization of response evaluations. Generally, if you set GTOpt/ResponsesScalability, it is recommended to leave GTOpt/BatchSize default, thus allowing GTOpt to evaluate batches of any size, adjusted to the GTOpt/ResponsesScalability value.

GTOpt/Seed

Random seed for deterministic mode.

Value:integer in range \([1, 2^{31}-2]\)
Default:100

New in version 6.12.

This value is used as the initial seed for randomized optimization routine if GTOpt/Deterministic is set to True. If GTOpt/Deterministic is set to False or "Auto", the GTOpt/Seed value is ignored.

GTOpt/Techniques

Limits the set of solving methods to use.

New in version 6.9.

Deprecated since version 6.25: kept for version compatibility only.

Using this deprecated option should be avoided as it is going to be removed in future versions. Solving methods implemented in GTOpt rely on selecting and combining multiple optimization techniques to solve different subproblems, which are created internally by the GTOpt solver when it grows the optimization tree (see section Solver Architecture for more information). Limiting GTOpt to an arbitrary smaller set of techniques usually leads to degradation of solution quality and may cause unexpected behavior in many kinds of optimization problems.

GTOpt/TimeLimit

Optimization time limit.

Value:integer in range \([0, 2^{32} - 2]\)
Default:0

This option sets the maximum allowed time to solve a problem in seconds. Defaults to 0, unlimited.

GTOpt/VerboseOutput

Turn on/off trace level logging of optimization process.

Value:Boolean
Default:off

New in version 1.6.2.

If on, GTOpt/LogLevel is always "Debug", and logs include additional information. Note that this option produces very large logs.