7.3. Option Reference


GTDoE/Adaptive/Accelerator

Five-position switch to control the trade-off between speed and accuracy of approximations used by adaptive DoE.

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

This option is identical to GTApprox/Accelerator and controls the training time of approximator used by adaptive DoE.

GTDoE/Adaptive/AcceptableQualityLevel

Sets the acceptable RRMS error of the internal model trained by the Adaptive DoE technique.

Value:float
Default:0.0

New in version 6.21.

Adaptive DoE generation stops when the RRMS error of the internal model reaches this value, or when the maximum number of points is generated.

GTDoE/Adaptive/AnnealingCount

The number of criterion evaluations in simulated annealing procedure.

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

Each sample point added by adaptive DoE process is the result of optimization by selected adaptive DoE criterion. This optimization is iterative, and the more iterations it can make, the better the new point will probably be. This option adjusts the number of optimizer iterations. Note that it also directly affects the working time of adaptive DoE algorithm.

Default (0) is an automatic estimate based on the design space dimensionality (\(d_{in}\)), which sets the number of iterations to \(min(500 + 100 \cdot d_{in}, 3000)\).

GTDoE/Adaptive/Criterion

Control the behavior of adaptive generation algorithm.

Value:"IntegratedMseGainMaxVar", "MaximumVariance", "Uniform", or "Auto"
Default:"Auto"

Sets the criterion for placing new DoE points.

  • "IntegratedMseGainMaxVar": most accurate and time-consuming method. Estimates the error of approximation with new candidate point added to the sample and selects the point which minimizes the expected error.
  • "MaximumVariance": samples points in the region with highest uncertainty, relying on model accuracy evaluation. Faster but less accurate.
  • "Uniform": does not aim to increase model quality. Generates next sample point in such a way that overall sample is as uniform as possible. Note that in fact this is the only valid criterion for the sample-based adaptive DoE when only the input part of the initial sample is available.
  • "Auto": selects one of the above, depending on the mode and data available (blackbox- or sample-based, full sample or the input part only).

GTDoE/Adaptive/ExactFitRequired

Require all approximations to fit the training data exactly.

Value:Boolean
Default:off

If this option is on (True), all approximations constructed in the adaptive DoE process fit the sample points exactly. If off (False) then no fitting condition is imposed.

This option sets GTApprox/ExactFitRequired on for the internal approximator used in the adaptive DoE.

GTDoE/Adaptive/InitialCount

The size of the initial training sample for the Adaptive Design of Experiments technique.

Value:0 (auto), or an integer in range \([\tilde{N}_{min}, N]\), where \(\tilde{N}_{min}\) is the minimum sample size to train a GTApprox GP model, and \(N\) is the full DoE size (point count, blackbox budget)
Default:0 (auto)

In case you do not provide an initial training set to Adaptive DoE, the technique generates an initial sample using the uniform sampling criterion (see Criteria). The generated sample is then evaluated with the blackbox, and the generated inputs and obtained blackbox outputs are used to train the initial adaptive model.

GTDoE/Adaptive/InitialCount sets the size of that initial sample. If this option is default (0), Adaptive DoE selects the size based on the design space dimension, adjusted to values of the GTDoE/Adaptive/OneStepCount and GTDoE/ResponsesScalability options. The lower value limit comes from the GTApprox sample size requirements to train a Gaussian Processes model in the dependent outputs mode, \(\tilde{N}_{min} = 2 (\tilde{d}_{in} + \tilde{d}_{out}) + 1\) where \(\tilde{d}_{in}\) and \(\tilde{d}_{out}\) are the effective input (variables) and output (response) dimensions (see section Sample Size Requirements in the GTApprox guide for details).

This option is used only by the blackbox-based adaptive DoE. In the sample-based adaptive DoE it is ignored.

GTDoE/Adaptive/InitialDoeTechnique

Deprecated since version 6.45: kept for compatibility only and may be removed in future versions; no longer has any effect — the initial training set is now generated by the Adaptive Design of Experiments technique using the uniform sampling criterion (see Criteria).

Deprecated option used previously to specify the DoE technique to use when generating the initial training set for Adaptive Design of Experiments.

GTDoE/Adaptive/InitialModelQualityLevel

Sets the RRMS error threshold for the internal Adaptive DoE model, after which the technique switches to the adaptive generation mode.

Value:float
Default:0.8

New in version 6.21.

The Adaptive DoE technique starts with a stage of space-filling (non-adaptive) generation where it uses the uniform sampling criterion (see Criteria) to place new points. During that stage, Adaptive DoE updates and tests its internal response model. Once the RRMS error of the internal model reaches GTDoE/Adaptive/InitialModelQualityLevel, the technique switches to the adaptive generation mode and continues until the model RRMS reaches GTDoE/Adaptive/AcceptableQualityLevel or the maximum number of points is generated.

GTDoE/Adaptive/InternalValidation

Enable or disable internal validation for approximations used by adaptive DoE.

Value:Boolean
Default:off

Enables internal validation of the approximation models built by adaptive DoE process. Note that internal validation scores are computed for every model built, including intermediate models built between DoE iterations, so switching this on may significantly increase DoE generation time.

Note that in the sample-based adaptive DoE mode, internal validation requires the response part of the initial sample. This is due to the fact that sample-based adaptive DoE with initial input part only is just random uniform generation which does not involve approximation models, so the option has no sense.

GTDoE/Adaptive/OneStepCount

In Adaptive Design of Experiments, specifies the maximum number of points that can be added to DoE on each iteration.

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

Changed in version 6.38: added the 0 (auto) value, which is now default.

Each adaptive DoE iteration may generate more than one point. This option sets the maximum number of points which can be accepted to the result DoE on each iteration. Note that this option does not set the exact number of points per iteration: in some cases, it is not possible to generate the maximum allowed number of points, so any iteration may add one or more points up to the number allowed by this option.

The 0 (auto) value sets the maximum number of points per iteration based on the number on non-constant DoE variables.

Note that if GTDoE/ResponsesScalability is also set, the maximum number of points per iteration is internally adjusted up to the closest multiple of GTDoE/ResponsesScalability — otherwise it could lead to inefficient parallelization. If GTDoE/ResponsesScalability is set and GTDoE/Adaptive/OneStepCount is left default, the maximum number of points per iteration naturally equals parallelization ratio specified by GTDoE/ResponsesScalability.

GTDoE/Adaptive/TrainIterations

In Adaptive Design of Experiments, sets the number of algorithm iterations between full rebuilds of the internal response model.

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

Usually the approximation model of responses used by adaptive DoE process is expected to only change slightly when a few points are added to the training set, so there is no need to rebuild the model at every iteration. This assumption, however, is not always true, especially when training set is not big enough to ensure that approximation has reasonable quality. This option sets the number of steps between rebuilds.

This option takes effect in the blackbox-based adaptive DoE mode only.

GTDoE/AdaptiveDesign/ContourLevel

Sets the target function value for a contour restoration problem solved by the Adaptive Design technique.

Value:float
Default:NaN

New in version 6.14.

Any non-default value switches the Adaptive Design technique to the function contour restoration mode and sets the target value of the function (the contour level).

If you set this option, the DoE blackbox must satisfy the following requirements:

  • If you inherit the blackbox from ProblemGeneric, it must define exactly one objective. However the number of constraints is not limited.
  • If the blackbox is a Blackbox instance, a gtapprox.Model, or a gtdf.Model, it must have 1D output (a single output component).

GTDoE/AdaptiveDesign/DetectNaNClusters

When running Adaptive Design, try to avoid design space areas where blackbox responses evaluate to NaN.

Value:Boolean
Default:on

New in version 6.16.

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. This option changes treatment of such evaluation failures:

  • When enabled (default), Adaptive Design 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, Adaptive Design 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, Adaptive Design 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.

GTDoE/AdaptiveDesign/MaximumExpensiveIterations

The maximum number of computationally expensive response evaluations that you allow the Adaptive Design technique to perform, not counting the evaluations of initial guesses.

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

New in version 6.19.

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

This option has the same behavior as GTOpt/MaximumExpensiveIterations, because it actually sets the latter for the internal solver used in Adaptive Design.

GTDoE/AdaptiveDesign/MaximumIterations

The maximum number of response evaluations that you allow the Adaptive Design technique to perform, counting also the evaluations of initial guesses.

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

New in version 6.19.

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

This option has the same behavior as GTOpt/MaximumIterations, because it actually sets the latter for the internal solver used in Adaptive Design.

GTDoE/AdaptiveDesign/RestoreAnalyticResponses

In Adaptive Design, enables training internal models of linear and quadratic responses and using those models to obtain response values rather than requesting response evaluations from the blackbox.

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

New in version 6.29.

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.

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

For linear responses:

  • If set to True, Adaptive Design aims to fit each linear response with a linear model prior to starting the main adaptive DoE algorithm. This requires initially sampling a certain relatively low number of linear response evaluations, which depends on 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 GTDoE raises an exception. If response modeling succeeds, Adaptive Design generation continues to use the obtained response model internally. This guarantees that GTDoE will not request any more linear response evaluations from the DoE blackbox.

  • If "Auto" (default), the behavior of Adaptive Design regarding linear responses is the same as the behavior of other GTDoE techniques. It tries modeling linear responses before DoE generation, but does not raise an exception if modeling fails — instead, it issues a warning, and generation continues normally. In case when modeling fails, all linear response evaluations are requested from the blackbox, since there is no internal response model. 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. Adaptive Design 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 DoE blackbox, and if enough data are collected during solving, Adaptive Design begins fitting it with a quadratic model. If modeling succeeds and DoE generation is not yet finished, Adaptive Design continues to use the obtained response model internally instead of requesting quadratic response evaluations from the blackbox. This behavior does not guarantee that quadratic response modeling succeeds. Until an internal quadratic response model is available, Adaptive Design 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.

GTDoE/AdaptiveDesign/SearchIntensity

Changes the intensity of internal routines which affect quality of the Adaptive Design result.

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

New in version 6.14.

Any non-default value (0.01 or greater) specifies the intensity of global search and other adaptive algorithms used by the Adaptive Design technique, with higher values allowing more resource-consuming computations, which may improve quality of the result.

The minimum sensible step for the value is 0.01.

GTDOE/BoxBehnken/IsFull

Always generate a full Box-Behnken design regardless of the requested number of points.

Value:Boolean
Default:off

New in version 1.10.1.

If this option is on (True), GTDoE always generates a full Box-Behnken design including \(2d(d - 1) + 1\) points where \(d\) is the number of design variables. In this case, the setting for the number of points is silently ignored.

By default (when GTDOE/BoxBehnken/IsFull is False), Box-Behnken design generation respects the set number of points to generate by randomly excluding some points from a full design to return the requested number of points in case the latter is less than the number of points in the full design (\(2d(d - 1) + 1\)). Note that the full design is the maximum sample size which can be generated by the Box-Behnken technique, so if the requested number of points exceeds \(2d(d - 1) + 1\), GTDOE/BoxBehnken/IsFull is False and GTDoE/Technique is set to "BoxBehnken", point generation will not start.

GTDoE/CategoricalVariables

Declares categorical variables.

Value:list containing indices of categorical variables and their levels
Default:[] (no categorical variables)

New in version 1.9.1: makes the GTDoE/OptimalDesign/CategoricalVariables option obsolete.

Changed in version 1.10.1: added categorical variables support in the Box-Behnken technique.

Changed in version 3.0: added categorical variables support in the Fractional Factorial technique.

Changed in version 6.0: added categorical variables support in the Orthogonal Array technique.

Changed in version 6.3: added categorical variables support in the Adaptive Design of Experiments technique.

Changed in version 6.16: allowed categorical variables with 1 level (effectively constants).

Changed in version 6.26: canceled categorical variables support in the Box-Behnken technique; added categorical variables support to more GTDoE techniques, excluding the low-discrepancy sequence techniques and Adaptive Design.

Changed in version 6.33: added categorical variables support in the Adaptive Design technique.

Changed in version 6.36: for compatibility with Adaptive Design, most techniques now handle categorical variables in a similar manner — generate a DoE for each possible combination of categories — so generation result may be used as an initial sample in Adaptive Design without issues; only the Full Factorial, Fractional Factorial and Orthogonal Array techniques do not change their behavior from 6.35.

Deprecated since version 6.38: kept for compatibility only and may be removed in future versions; use variable hints to setup categorical variables (see Hint Reference).

This option specifies the indices of categorical variables and their levels (possible values). Option value is a list in the following format: [id, [l1, l2, ...], ...], where id is a zero-based index of the variable, and l1, l2 and so on are level values. For example, [0, [2., 3.], 4, [0.1, 0.2, 0.3]] specifies that two of the design variables (indexed 0 and 4) are categorical, and defines levels for each. Note that only int and float values are accepted as levels. At least one level must be defined for each categorical variable (a variable with 1 level is effectively a constant).

See example_gtdoe_levels.py for usage.

Note

Categorical variables are not affected by bounds — that is, corresponding elements in the bounds tuple are ignored when generating a value of a categorical variable. Still, some placeholder numeric values should be present in bounds just to keep the order of variables.

Note

The Fractional Factorial technique implements 2-level fractional design only, so it requires exactly 2 levels for each categorical variable. Note also that Fractional Factorial generates combinations of categorical variables as per its generating string, so it may not generate all possible combinations.

GTDoE/Deterministic

Require generation to be reproducible.

Value:Boolean
Default:off

If this option is on (True), then a fixed seed (the one set by the GTDoE/Seed option) is used in all randomized GTDoE algorithms.

GTDoE/FractionalFactorial/GeneratingString

Specifies alias structure for a fractional factorial design, optional.

Value:a string containing generator expressions, separated by whitespace
Default:"" (empty)

This option uses the conventional fractional factorial notation to create an alias structure that determines which effects are confounded with each other. Each generator expression contains one or more letters. Single letter expression specifies a main factor, letter combinations give interactions for confound factors. For example, "a b c ab bcd d" means that variables indexed 0, 1, 2, and 5 are main factors and a full factorial design for them is generated; design values for variables 3 and 4 are generated from main factor values: for each point, the value of variable 3 is the product of variables 0 and 1 (“ab”), and the value of variable 4 is the product of variables 1, 2, and 3 (“bcd”).

Note

In 2-level fractional factorial design implemented by the Fractional Factorial technique, factor levels (possible values of variables) are conventionally denoted \(-\) (low level) and \(+\) (high level). Above, “product” actually means the rule for selecting a high or low value for a dependent factor, and may be understood as a product of values mapped to \(\pm 1\), or logical equality (XNOR).

Note that the number of generator expressions is equal to the total number of design variables.

If GTDoE/FractionalFactorial/GeneratingString is empty, main factors are selected by GTDoE/FractionalFactorial/MainFactors, and remaining generator expressions are created automatically.

If both these options are left default (empty) when selecting the Fractional Factorial technique (see GTDoE/Technique), GTDoE first selects a number of main factors so it is enough to generate the requested number of points, then adds generator expressions for the remaining factors.

If both GTDoE/FractionalFactorial/GeneratingString and GTDoE/FractionalFactorial/MainFactors are specified, they must be consistent (that is, select the same main factors).

GTDoE/FractionalFactorial/MainFactors

Specifies main (independent) design factors, optional.

Value:list of indices of main factors (variables)
Default:[] (empty list)

This option provides a simplified way to create an alias structure for a fractional factorial design (compared with GTDoE/FractionalFactorial/GeneratingString). The list contains only the indices of variables to be selected as main factors, and interactions for confound factors are then created automatically (unless you also set GTDoE/FractionalFactorial/GeneratingString).

If both GTDoE/FractionalFactorial/GeneratingString and GTDoE/FractionalFactorial/MainFactors are specified, they must be consistent (that is, select the same main factors).

If both these options are left default (empty) when selecting the Fractional Factorial technique (see GTDoE/Technique), GTDoE first selects a number of main factors so it is enough to generate the requested number of points, then adds generator expressions for the remaining factors.

GTDoE/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 into log.

GTDoE/MaxParallel

Set the maximum number of parallel threads to use when generating DoE.

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

New in version 5.0 Release Candidate 1.

GTDoE can run in parallel to speed up design generation. This option sets the maximum number of threads it 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 GTDoE. 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.

GTDoE/Normalize

Enable or disable internal normalization of the design space.

Value:Boolean
Default:on

New in version 6.16.

Certain DoE techniques (for example, OLHS) use internal quality criteria based on spatial measures, interpoint distance in particular. Since design variables are usually different quantities (have different physical meaning), their values (bounds) may differ by several orders of magnitude. Due to this, such techniques by default normalize the design space internally, scaling each variable to the \([0, 1]\) range — otherwise their internal criteria may work incorrectly.

This option allows you to disable internal normalization, which generally makes sense only when variables are indeed of the same quantity, but have very different value ranges. It has no effect for techniques that do not optimize point distribution, and should be kept default except for the mentioned unusual cases.

GTDoE/OLHS/Iterations

Maximum number of optimization iterations in OLHS generation.

Value:integer in range \([2, 65535]\)
Default:300

This option allows user to specify maximum number of optimization iterations for OLHS. OLHS optimization may take a long time, so it may be useful to decrease number of optimization iterations.

GTDoE/OptimalDesign/CategoricalVariables

Deprecated since version 1.9.1: kept for compatibility only and may be removed in future versions; use variable hints to setup categorical variables (see Hint Reference).

Deprecated option previously used to specify categorical variables for the Optimal Design technique.

GTDoE/OptimalDesign/Model

The type of the regression model to optimize for.

Value:"linear", "interaction", "quadratic", or "purequadratic"
Default:"linear"

This option controls the order of the regression model.

  • "linear" — model includes constant and linear terms.
  • "interaction" — model includes constant, linear, and cross product terms.
  • "quadratic" — model includes constant, linear, cross product and squared terms.
  • "purequadratic" — model includes constant, linear and squared terms.

GTDoE/OptimalDesign/Tries

The number of optimal design generation tries.

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

Sets maximum number of tries to generate a design from new starting point, using random points for each try.

GTDoE/OptimalDesign/Type

Sets optimality criterion.

Value:"D" (D-optimal) or "I" (I-optimal)
Default:"D"

Specifies the type of objective function to evaluate experimental design.

  • D-optimality (determinant): seeks to minimize \(|(X'X)^{-1}|\), or equivalently maximize the determinant of the information matrix \(X'X\) of the design. This criterion results in maximizing the differential Shannon information content of the parameter estimates.
  • I-optimality (integrated): seeks to minimize the average prediction variance over the design space.

GTDoE/OrthogonalArray/ArrayType

Specifies the type of orthogonal array to generate.

Value:"orthogonal", "balanced", or "irregular"
Default:"balanced"

New in version 6.16.

This option can be used to generate a “nearly orthogonal” array when the specified sample size (the count argument to generate()) is not enough to generate a proper orthogonal array.

  • "orthogonal": a proper simple 2-strength orthogonal array. Has a strict minimum size determined by the number of variables and number of their levels. Array size can be increased only in specific increments. The size requested by count is adjusted to the closest possible increment. If the sample size is less that the possible minimum, generation fails.
  • "balanced" (default): an array which conforms to the orthogonal array definition with an exception that pairwise combinations of variables’ levels may appear in the array different number of times (not guaranteed to be a 2-strength array). Also has a minimum size and specific size increments, but both of them are smaller than for a proper orthogonal array. The requested size is adjusted to the closest increment. If the sample size is less than the minimum, generation fails. If the sample size is suitable to generate a proper orthogonal array, the latter is generated.
  • "irregular": an array of arbitrary size with properties as close to an orthogonal array as possible for the requested sample size. Has no minimum and increment limitations. If the sample size is suitable to generate a balanced or proper orthogonal array, then one of these types is generated.

See section Orthogonal Array for details.

GTDoE/OrthogonalArray/LevelsNumber

Specifies the number of levels for variables in an orthogonal array design.

Value:list of integers specifying the number of levels for each variable
Default:[]

New in version 6.0.

Changed in version 6.16: this option is no longer required for the OA technique: if levels are not specified, the technique selects them automatically.

The orthogonal array generation algorithm requires predefined levels for variables. If this option is default, the Orthogonal Array technique assigns levels to variables automatically, depending on the design space dimension (the number of variables) and the requested sample size, and with regard to levels specified for categorical and discrete variables. Otherwise, the specified number of levels is generated for each variable, distributed uniformly between the variable’s bounds. In this case, option value must be a list of integers, with length equal to the number of variables.

You can skip certain variables by using the 0 value as a placeholder where you do not want to set the number of levels. If GTDoE/OrthogonalArray/LevelsNumber does not set the number of levels for some variable, the technique will generate its levels automatically. In particular, this is useful when the design includes a mix of continuous and categorical (or discrete) variables: you can specify the number of levels for continuous variables, and use 0 for other types of variables, since for those types you specify levels when adding the variable.

GTDoE/OrthogonalArray/MultistartIterations

The maximum number of additional initial guesses (multistarts) in the orthogonal array generation.

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

New in version 6.0.

Changed in version 6.16: removed the maximum value limit (was 1000).

Changed in version 6.16.1: changed the default value to 500 (was 10).

Changed in version 6.17: added the auto setting, which is now default; reintroduced the maximum value limit.

Generating an orthogonal array is a non-trivial combinatorial optimization problem. The Orthogonal Array technique solves it using an algorithm which generates 1 deterministic initial guess and a number of additional random initial guesses, which are used as multistart points in optimization. This option sets the number of additional starting points, providing a trade-off between the generation time and DoE quality.

When set to -1 (auto), the number of multistarts is selected automatically according to the number of variables, levels, and the type of array set by GTDoE/OrthogonalArray/ArrayType.

See section Orthogonal Array for details.

GTDoE/ResponsesScalability

The maximum number of concurrent response evaluations supported by the adaptive DoE blackbox.

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

New in version 6.29.

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

Adjusts behavior of the Adaptive Design and Adaptive Design of Experiments techniques to use parallel calculations more efficiently. Ignored by all other GTDoE techniques.

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 adaptive DoE techniques will use maximum concurrency when evaluating problem responses.

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

When you set GTDoE/ResponsesScalability to \(p\) (2 or greater) in Adaptive Design, the GTDoE/AdaptiveDesign/MaximumIterations and GTDoE/AdaptiveDesign/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 GTDoE/ResponsesScalability is 4:

  • If you set GTDoE/AdaptiveDesign/MaximumIterations to 50, this allows GTDoE 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 GTDoE/AdaptiveDesign/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.

GTDoE/Seed

Fixed random seed.

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

This option sets fixed seed value, which is used in all randomized algorithms if GTDoE/Deterministic option is on. If GTDoE/Deterministic is off, the GTDoE/Seed value is ignored.

GTDoE/Sequential/Leap

Sequence leap size.

Value:integer in range \([0, 65535]\)
Default:0

This option allows sequential techniques to leap over elements of sequence. Its value is the leap size (number of elements). Default is no leaping.

Combined with GTDoE/Sequential/Skip, it results in the following: let \(x_i\) be the i-th element of the original sequence, \(l\) be the leap size (GTDoE/Sequential/Leap value), and \(s\) be the skip size (GTDoE/Sequential/Skip value); then the resulting sequence is \(X = \{x_s, x_{s + (l+1)}, x_{s + (l+1) \cdot 2}, ..., x_{s + (l+1) \cdot n}\}\).

GTDoE/Sequential/Skip

Skip elements at the beginning of sequence.

Value:integer in range \([0, 65535]\)
Default:0

This option specifies the number of elements to skip from sequence start. May be combined with GTDoE/Sequential/Leap.

GTDoE/Technique

Specify the generation algorithm to use.

Value:"RandomSeq", "SobolSeq", "HaltonSeq", "FaureSeq", "FullFactorial", "FractionalFactorial", "LHS", "OLHS", "OptimalDesign", "OrthogonalArray", "ParametricStudy", "BoxBehnken", "Adaptive", "AdaptiveDesign", or "Auto"
Default:"Auto"

New in version 1.10.0: Parametric Study technique.

New in version 1.10.1: Box-Behnken design.

New in version 2.0: sample-based adaptive DoE technique.

New in version 3.0: Fractional Factorial technique.

New in version 6.0: Orthogonal Array technique.

New in version 6.14: Adaptive Design technique.

Use this option to explicitly specify the DoE generation algorithm (DoE technique). Default value, "Auto", selects a compatible technique automatically.

  • "RandomSeq" — sequential uniform random generation.
  • "SobolSeq" — Sobol sequence.
  • "HaltonSeq" — Halton sequence.
  • "FaureSeq" — Faure sequence.
  • "FullFactorial" — common full factorial design.
  • "FractionalFactorial" — a design consisting of a subset (fraction) of a full factorial design.
  • "LHS" — Latin Hypercube Sampling.
  • "OLHS" — Optimized Latin Hypercube Sampling.
  • "OptimalDesign" — optimal design for response surface models.
  • "OrthogonalArray" — a design with multilevel discrete design variables.
  • "ParametricStudy" — parametric study process. Selects a central point and generates points from center by changing one of the variables while others are fixed, repeating this step for each variable.
  • "BoxBehnken" — Box-Behnken design, a classic design for response surface methodology. Requires at least three design variables.
  • "Adaptive" — sample-based adaptive DoE (added in 2.0). When used in generate(), acts as a mode selector.
  • "AdaptiveDesign" — Adaptive Design technique (added in 6.14). Supported only by build_doe().

Note that the blackbox-based adaptive mode in generate() completely ignores this option. See options GTDoE/Adaptive/InitialDoeTechnique and GTDoE/Adaptive/Criterion if you are using generate() in the adaptive mode.