Design space exploration

The Design space exploration block solves a variety of design space exploration tasks using design of experiments and optimization methods. It can generate DoE samples with specific properties, collect response samples from a block which evaluates these designs, and solve optimization problems. It also provides advanced methods such as adaptive design generation, response function contour restoration, gradient-based and surrogate-based optimization.

This block employs a task-based approach: its configuration focuses on defining the design space (variables, responses, and their properties) and design goals which can be set individually for each response. To aid you in configuration, the block supports the SmartSelection technology which recommends the method to use based on your design space definition. This approach allows you to easily switch between tasks and even to combine several methods in a single study.

Introduction

The Design space exploration block solves a variety of design tasks related to studying the behavior of some computational model. You can begin your study with generating a DoE sample with specific properties, then add functional constraints, generate an adaptive DoE optimized for a more accurate representation of the model responses, or run optimization. All these tasks use the same definitions of variables and responses, so it is easy to switch between them without reconfiguring the block.

There are two typical configurations for a Design space exploration block in a workflow:

  1. Sample generator — configuration where you describe only design variables and their properties.
  2. Blackbox driver — configuration where you describe design variables and responses from a studied model. This configuration requires connecting Design space exploration block with other blocks that evaluate model responses (the blackboxes).

In the sample generator configuration, the block receives all required information from its settings — properties of design variables and technique options you specify. Also it can receive an optional initial sample, which in this case is updated with new generated design points.

../_images/page_blocks_Design_space_exploration_wf_samplegen.png

Workflow pattern with a Design space exploration block in the sample generator configuration.

The sample generator configuration is used for such tasks as:

  • Generating a space-filling DoE sample within the variables’ bounds. The space-filling properties of this sample depend on the generation technique you select.
  • Updating an existing DoE, which is sent to the block as the initial sample. By default the block simply adds points from the initial sample to its output sample — that is, the information from the initial sample is not used in the generation process. However, some techniques can be configured to “continue” generating the initial sample, preserving its properties.

In the blackbox driver configuration, the Design space exploration block becomes a tool for performing computational experiments according to the generated design. This configuration adds responses to block’s settings. Together, the variables and responses describe the inputs and outputs of some computational model. However, the Design space exploration block does not define or calculate this model: it has to be connected with one or more blackboxes — blocks which evaluate model outputs. The optional initial sample in this case can contain values of responses in addition to values of variables.

../_images/page_blocks_Design_space_exploration_wf_bbox.png

Workflow pattern with a Design space exploration block in the blackbox driver configuration.

When running with this configuration, the Design space exploration block outputs values of design variables to the connected blackboxes and receives values of responses. A blackbox can be a Composite block containing some computational chain or a set of blocks, which calculate different outputs of the model. The final result contains all data exchanged with the model — both the design of experiments (values of variables) and the outcome (response values).

The blackbox driver configuration is used for such tasks as:

  • Solving optimization problems.
  • Generating a space-filling design of experiments sample subject to functional constraints.
  • Generating a design of experiments sample and evaluating model responses for this sample.
  • Evaluating model responses for an existing input sample, without generating new points.
  • Running a controlled experiment in which the block continuously generates new input points until you stop it manually.

Configuration

The first and the most important step when configuring a Design space exploration block is defining variables and responses. Based on these definitions, the block automatically selects an appropriate technique (the SmartSelection mode). You can further tune this technique manually, using the automatically selected settings as initial recommendations.

../_images/page_blocks_Design_space_exploration_conf_dialog.png

Block configuration dialog. 12 Variable and response definitions. 3 Evaluation limit. 4 SmartSelection toggle. 5 Technique selector. 6 Technique options. Only non-default option values are listed, the full list is available in the technique configuration dialog. 7 Validation issues. 8 General options, see Run Options. 9 Port settings, see Ports and Parameters. 10 General configuration hints.

To change technique options, first disable the SmartSelection mode with the b_blconf_ss button. After this you can change the technique using the selector 5 and tune the technique with its options. The b_blconf_gear button opens the technique configuration dialog which lists all options and provides tooltips with option descriptions.

You can specify Number of designs to add a limit for the maximum number of blackbox evaluations or to set the number of DoE points to generate. This setting is optional: the Auto value (default) selects an appropriate limit depending on the number of variables and responses, selected technique, its options, and other block settings. The tooltip for the Number of designs value explains how this setting is applied to the current configuration.

../_images/page_blocks_Design_space_exploration_nod_tooltip.png

A tooltip for Number of designs explaining the current setting.

The block automatically validates its configuration and notifies you if any issues are found. The b_blconf_warning button opens the validation pane where you can view the details.

  • A warning message b_blconf_issues_warn means that the block can start but an error can occur during workflow run, or you can obtain unexpected results.
  • An error message b_blconf_issues_err means that the block cannot start. A workflow with this block will not start either.

Important

Warnings may provide valuable information and configuration hints. A good practice is to review all warnings issued by the block and fix them before running the workflow, unless you are sure that the behavior described in a warning is acceptable for your task.

Additional hints 10 can be added to configuration to provide the block with some general information about the task:

  • Add the Noisy responses hint if the initial sample data or some response evaluations contain noise.
  • Add the Cheap responses hint if all responses are computationally cheap (fast to evaluate).

The hints are used by SmartSelection to adjust the recommended technique configuration in these specific cases.

Variables

Design variables are a required part of the block’s configuration. They are listed on the Variables pane.

../_images/page_blocks_Design_space_exploration_varpane.png

The Variables pane showing an example definition of an I-beam design. 1 The list of design variables and their properties. 2 Name filter to find variables in the list. 3 Variable add and remove buttons. 4 Variable ordering buttons. 5 Context menu.

Each variable is described by a number of properties. You can set these properties when adding a variable and edit them on the Variables pane. In addition, some properties can be set using special ports related to the variable.

  • Name. Identifies the variable and related ports.
  • Type. The variable can be continuous (default), discrete, or categorical. The block handles each of these types in a specific manner.
  • Size. The number of components for the variable (its dimension).
  • Lower bound. The minimum allowed value for a continuous variable. Ignored if the variable is discrete, categorical, or constant.
  • Upper bound. The maximum allowed value for a continuous variable. Ignored if the variable is discrete, categorical, or constant.
  • Levels. Predefined values for discrete and categorical variables. Ignored for continuous variables and constants.
  • Constant. A variable of any type can be switched to constant, essentially allowing you to exclude the variable from consideration without deleting it.
  • Value. The value for a constant variable. In gradient-based optimization, becomes the initial guess for non-constant variables. Ignored in other cases.

These properties are described in more detail in section Variable Properties below.

Generally, you are required to set those properties which are not ignored due to the type of a variable. For example, Size is always required, bounds are required for continuous variables, and so on. You can also set ignored properties — their values are saved to the block’s configuration so you can use them later. Values of ignored properties are grayed out on the Variables pane.

../_images/page_blocks_Design_space_exploration_ignored_var_prop.png

A constant variable with specified bounds. The tooltip explains why the Lower bound property is ignored.

If you hover an ignored value with your mouse cursor, the pane shows a tooltip explaining why the current configuration ignores your setting.

Variable Properties

Name

The name of a variable identifies it on the Variables pane and forms names of related input and output ports. There are several ports related to each variable — some of them can be used to set properties, others send or receive the variable data. These ports are described in section Ports and Parameters.

Since the name of a variable becomes a part of related port names, it cannot include any of the following characters: . < > : " / \ | ? *. The dot . is used as a separator in port names and is prohibited in names of variables to avoid confusion. Other characters are prohibited in port names, so the block also prohibits them in names of variables (and responses).

All names of variables must be unique. Also, the same name cannot be used for a variable and a response, to avoid confusion when connecting ports.

You can change the name of a variable after adding it (see Editing Variables and Responses). Note that it automatically changes the names of related ports. If some of these ports are already connected, pSeven keeps existing links when possible.

Type

A variable can be continuous (default type), discrete, or categorical.

  • Continuous: generic numerical variable, which can take any value within the design bounds. The bounds (see Lower bound, Upper bound) are required for continuous variables.
  • Discrete: a numerical variable with a limited set of allowed values (see Levels). Levels are required for discrete variables, and must be numeric; bounds are ignored. In particular, this type can be used to describe an integer variable.
  • Categorical: a non-numerical variable. A categorical variable also has a limited set of allowed values, but these values can be strings. Categorical variables require levels and ignore bounds.

Discrete and categorical variables are processed differently by the block’s design generation and optimization algorithms:

  • Values of a discrete variable can be compared numerically (less, greater, or equal). They can be ordered and used in arithmetic operations.
  • Values of a categorical variable can be compared only for equality, even if all of them are numerical.

For more details on configuring variables of different types, see Types of Variables.

Size

This property specifies the number of components for a variable, or its dimension. For example, if you do not want to create multiple variables of the same type, you can add a single multi-dimensional variable instead. Components of this variable can have different bounds or sets of levels.

The Size property affects the following:

  • The syntax of the Lower bound, Upper bound, Levels, and Value properties. See Types of Variables for details.
  • The number of columns corresponding to this variable in the initial sample matrices. See Initial Samples for details.
  • The number of corresponding columns in the result matrices (see Results).
  • The number of columns in the samples containing the variable data, which are sent to blackboxes for evaluation (see Blackboxes).

Note that you can use a special input port to set the Size property (see Ports and Parameters for details). In particular, this allows creating variables with varying dimension, which can be quickly changed in workflow configuration.

Lower bound
Upper bound

The lower and upper bounds specify, respectively, the minimum and maximum allowed values for a variable. This property is required for continuous variables (see Type). Constant, discrete, and categorical variables ignore bounds and do not validate them.

The value of a bound can be RealScalar or RealVector:

  • RealScalar sets the same bound for all components of a variable. Usually used for variables with Size 1, this form is also valid for multi-dimensional variables.
  • RealVector sets a specific bound for each component. The number of vector components must be equal to the variable’s Size.

For syntax examples, see Types of Variables.

Note that you can use special input ports to set the bounds (see Ports and Parameters for details).

Levels

If a variable is discrete or categorical (see Type), it requires you to define a finite set of allowed values which are called levels. Constant variables of any type and continuous variables ignore this property and do not validate it.

The value of Levels can be a single vector or a List containing multiple vectors:

  • A single vector specifies the same set of levels for every variable component. This form is natural for variables with Size 1, and is also valid for multi-dimensional variables.
  • A List specifies an individual set of levels for each component. The number of elements (vectors) in the list must be equal to the variable’s Size.

See Types of Variables for more details and syntax examples.

Every vector representing a set of levels (for a variable or its component) must include at least 2 elements, since a discrete or categorical variable with 1 level is just a constant. Also, for discrete variables the type of a vector implicitly defines whether the variable is real or integer.

Note that you can use a special input port to set Levels (see Ports and Parameters for details).

Constant

A constant variable has a fixed value defined by the Value property. This value is the same in all generated designs. A constant variable generates a constant column (columns, if multi-dimensional) in the result matrices. One exceptional case is when you add an initial sample for a constant variable: the values in the initial sample can be non-constant and are not required to be equal to the variable’s Value. If the initial sample is added to result, you can obtain a non-constant column for a constant variable (see Initial Samples for more details).

This property is mostly intended as a means to temporarily exclude a variable from consideration while keeping the variable’s settings and the links connected to the related ports.

You can also switch a variable to constant when you want to try some value out of bounds. This is possible because constant variables ignore bounds and Levels and do not validate them — so you won’t need to change these settings.

Value

This property is used in two distinct ways.

  • For a constant variable, this property is required since it sets the variable’s fixed value. This value may disagree with bounds and levels, since these properties are ignored for constants. However, Value must agree with the Type property — for example, a StringScalar value is valid only for a categorical constant.
  • For a non-constant variable, this property is ignored unless the Gradient-based optimization technique is selected. In this case:
    • Value is interpreted as the initial guess in optimization.
    • For a continuous variable, it must be within bounds.
    • For a discrete or categorical variable, it must be a valid value according to Levels.

Value can be scalar or vector:

  • A scalar sets the same value for all components of a variable. Usually used for variables with Size 1, this form is also valid for multi-dimensional variables.
  • A vector defines a specific value for each component. The number of vector components must be equal to the variable’s Size.

For syntax examples, see Types of Variables.

Constant variables always validate this property. Non-constant variables validate it only if the Gradient-based optimization technique is selected, and ignore in other cases.

Note that you can use a special input port to set the Value property (see Ports and Parameters for details).

Adding Variables

To add variables, click the b_blconf_add button on the Variables pane or select Add variables… from the pane’s context menu b_blconf_context. These actions bring up the Add variables dialog where you specify one or more names (required) and other properties (optional).

../_images/page_blocks_Design_space_exploration_addvar.png

The Add variables dialog showing 3 continuous scalar variables, each bound to \([10.0, 20.0]\). Ignored properties are grayed out.

You can add multiple variables at once using the Name field:

  • Input a comma-separated list (see the example above) to add multiple variables with different names.
  • Input a range to add multiple variables with the same base name and different indices. For example, x1-x3 adds 3 variables named x1, x2, and x3.

Note that if you specify other properties when adding multiple variables, all these variables will have the same settings. Later you can edit them on the Variables pane.

Certain characters are prohibited in names of variables (see Name in Variable Properties for details). In addition, if you want to add a name which includes a hyphen, this name must be quoted, for example: "my-var1". This is needed to distinguish such names from name ranges.

The Add variables dialog validates names of variables only. All other settings are validated by the block after you add the variables. If there are errors or warnings, the block will show them in its Issues pane. Also, the block never validates settings which are ignored in its current configuration — for example, the lower and upper bounds are not validated for constant variables.

Adding a variable automatically creates a result output port specific to this variable, in addition to the common result outputs. If some responses are already defined in the block’s configuration, it also creates ports which output values of this variable for blackbox evaluations. Finally, in the Ports and parameters dialog you can enable additional result ports and special input ports which set the variable’s properties. For details on using this dialog, see Ports and Parameters.

Types of Variables

This section explains how variables of different types can be used, and provides some additional details on properties required by each type. Note that actually you can specify and save all properties of a variable, even if some of them are ignored by its current type — this is useful if you are going to change the type later.

Continuous Variables

Continuous variables are supported by all techniques except Orthogonal array design. For a continuous variable, the block generates values from the interval specified by their bounds. Some DoE techniques assign levels to continuous variables internally.

The bounds (Lower bound and Upper bound properties) are required for a continuous variable, unless it is constant. The bounds can be set using RealScalar or RealVector values, for example:

  • If the Size of a variable is 1:
    • Use RealScalar bounds for simplicity: 0.5.
    • Use RealVector bounds if required by your workflow: (0.5). Note that the vector has a single component.
  • If the variable has multiple components, for example, its Size is 3:
    • Use a RealScalar value as a shorthand to set the same bound for all components: 0.5 is equivalent to (0.5, 0.5, 0.5).
    • Use RealVector value to specify different bounds for components: (0.5, 0.1, -0.1) — note that the number of vector components is equal to Size.

The bound values can be specified in block configuration or sent to special input ports: <variable_name>.Lower bound and <variable_name>.Upper bound. These additional ports are disabled by default; see Ports and Parameters for usage.

Bounds of continuous variables are also checked when evaluating an initial sample. Points of the initial sample, which contain out-of-bound values of continuous variables, are considered infeasible and are excluded from the feasible and optimal result matrices (see Initial Samples and Results).

If you set a continuous variable to constant, the bounds are ignored — both in the initial sample and when generating new designs.

Discrete Variables

Discrete type is usually used for design variables which represent continuous entities, but have a limited set of allowed values. This set of values is specified by the Levels property which is required for a discrete variable. Use this type only for variables with numeric values: the block assumes that values of a discrete variable can be compared numerically (for being less, greater, or equal), and this assumption is important in some techniques. A typical example of a discrete variable is some geometry parameter with predefined values.

Discrete variables are unsupported or only partially supported by many techniques. Some of the techniques which support discrete variables also have additional requirements to their properties. Partial support generally means that a technique allows discrete variables in configuration but uses an algorithm which cannot work with discrete variables. In such cases, the block usually runs an independent study for each combination of levels of discrete (and categorical) variables, and then merges the results.

At least 2 levels must be defined for each component of a discrete variable, and all level values must be unique. Levels can be defined using RealVector, IntVector, or List values, for example:

  • If the Size of a variable is 1:
    • Use RealVector in general case: (1.1, 2.1, 3.1) specifies 3 levels for a variable.
    • Use IntVector to create an integer variable: a discrete variable with levels (1, 2, 3, 4) is interpreted as an integer variable in range \([1, 4]\).
    • Use List if required by your workflow: [(1.1, 2.1, 3.1)] or [(1, 2, 3, 4)]. Note that the list contains a single vector element.
  • If the variable has multiple components, for example, its Size is 3:
    • Use RealVector or IntVector as a shorthand to specify the same levels for all components: (1, 2) is equivalent to [(1, 2), (1, 2), (1, 2)].
    • Use List to specify different levels: [(1, 2, 3), (-0.5, 0.5), (3.1, 3.2, 3.3, 3.4)] defines 3, 2, and 4 levels for the first, second, and third component respectively. Note that the number of elements (vectors) in the list is equal to Size, and components can have different number of levels.

The levels can be specified in block configuration or sent to the special input port <variable_name>.Levels. This additional port is disabled by default; see Ports and Parameters for usage.

Levels of discrete variables are also checked when evaluating an initial sample. Points of the initial sample, which contain values of discrete variables do not matching their levels, are considered infeasible and are excluded from the feasible and optimal result matrices (see Initial Samples and Results).

If you set a discrete variable to constant, the levels specified for this variable are ignored — both in the initial sample and when generating new designs.

Categorical Variables

Categorical variables are a further generalization of the discrete variable type. They have a limited set of allowed values specified by the Levels property. This property is required and must define at least 2 levels. Levels may be numbers or strings, all level values must be unique and must have the same type.

Even when levels are numeric, a categorical variable is never processed as a numeric one: its values can be compared for equality only (match or no match). Categorical variables can be used to define a set of keys recognized by a blackbox. A typical example is a variable which specifies the materials used in construction, like ("S235", "S275", "S355") (steel grades). Generated design points will contain one of these keys; the blackbox shall recognize the key received and use the characteristics of the specified material when evaluating the design.

Most techniques work with categorical variables by running an independent study for each combination of levels of categorical (and discrete) variables and then merging the results. Some techniques which support categorical variables impose additional requirements on them.

Levels of categorical variables are specified in the same way as for discrete variables, with the addition of strings as valid values. The levels are also checked when evaluating an initial sample. However if you set a categorical variable to constant, its levels are ignored both in the initial sample and when generating new designs.

Constant Variables

As noted above, a variable of any type can be set to constant. Constants ignore bounds and levels, but you have to specify their Value property, and your setting must be valid for the selected variable type — for example, you cannot assign a string value to a discrete constant.

Constant variable has the same value (or component values) in all new designs generated by the block. The initial sample, however, can contain different values of this variable — the block does not check whether the values of a constant variable in the initial sample are actually constant.

Value can be scalar or vector. It can disregard bounds or levels of the variable, but must be a valid value with regard to the Type property. For example:

  • If the Size of a constant is 1:
    • Use RealScalar or IntScalar value for continuous and discrete constant variables: 0.5, 3.
    • A StringScalar value can be used for a categorical constant: "string".
    • Vector form is allowed: (0.5), (3), ("string"). Note that the vector has a single component.
  • If the constant has multiple components, for example, its Size is 3:
    • Use a RealScalar or IntScalar value as a shorthand to set the same value for all components of a continuous or discrete constant variable: 0.5 is equivalent to (0.5, 0.5, 0.5); 3 is equivalent to (3, 3, 3).
    • A StringScalar value can be used in the same way for a categorical constant: "str" is equivalent to ("str", "str", "str").
    • Use vector values to specify different values for components: (-0.5, 0.0, 0.5), (-1, 0, 1), ("A", "B", "C"). Note that the number of vector components is equal to Size.

Additional input port <variable_name>.Value can be enabled and used to set the constant. You can also enable the special <variable_name>.Constant port and use it to switch the variable between constant and non-constant. See Ports and Parameters for details.

Responses

Responses are needed in configuration when you connect the block to blackboxes or use an initial sample containing response values. Certain techniques — for example, optimization — require response definitions, since they always work with a blackbox. Others treat responses as an optional part of the configuration — for example, DoE techniques require definitions of variables to generate the sample, and can optionally evaluate responses for the generated design points, if a blackbox is connected.

../_images/page_blocks_Design_space_exploration_resppane.png

The Responses pane showing an example of responses which are characteristics of an I-beam design. 1 The list of responses and their properties. 2 Name filter to find responses in the list. 3 Response add and remove buttons. 4 Response ordering buttons. 5 Context menu.

There are certain similarities in configuration of variables and responses. Each response is described by a number of properties, which you can set when adding a response and edit on the Responses pane afterwards. Some of these properties can be also set using special ports.

  • Name. Identifies the response and related ports.
  • Type. Specifies the role of this response in your study — for example, it can be a design constraint, an optimization objective, or other.
  • Size. The number of response components (its dimension).
  • Lower bound. The lower bound for constraint type responses. Ignored by all other response types.
  • Upper bound. The upper bound for constraint type responses. Ignored by all other response types.
  • Value. The contour value for a response which is the target of a function contour restoration study. Ignored by all other response types.
  • Function. Additional information about the response used by some techniques.
  • Blackbox. Enables or disables blackbox evaluations for the response.

These properties are described in more detail in section Response Properties below.

Similarly to variables, you can skip those properties which are ignored due to the response type, or specify them if you want to change the response type later. Values of ignored properties are grayed out on the Responses pane, and value tooltips explain the reason.

Response Properties

Name

The name of a response identifies it on the Responses pane and forms names of related input and output ports. These ports include inputs which receive initial data samples, outputs which send results, and the ports which are used to connect the block with blackboxes (see Ports and Parameters and Blackboxes for details).

Restrictions applied to response names are the same as for variables:

  • Response names cannot include dots (., used as a separator in port names) and cannot include characters prohibited in port names: < > : " / \ | ? *.
  • All response names must be unique, and the same name cannot be used for a variable and a response.

You can change the name of a response after adding it (see Editing Variables and Responses). Renaming a response automatically changes the names of related ports, and existing links are kept when possible.

Type

This property sets a study goal for the response and determines how the response is handled during the study. It plays a significant role in configuration, since the block’s task is mainly defined by the combination of response types.

  • Evaluation (default): a response which is never analyzed during the study. Values of evaluation responses are simply collected and included in the final result.
  • Constraint: some design characteristic which must satisfy certain bounding conditions. The conditions are set by the Lower bound and Upper bound properties. At least one of these bounds is required for a constraint response.
  • Minimization: a design quality criterion, some characteristic which should be minimized. Usually a minimization type response is an optimization objective, however this type can also be used in DoE studies. Also called cost function or loss function in optimization and other methods.
  • Maximization: the counterpart of the minimization type. Also called reward function or utility function.
  • Adaptive: when using adaptive DoE techniques, the design point distribution is optimized with regard to responses of this type. Other DoE and optimization techniques disregard adaptive responses, treating them in the same manner as the evaluation type.
  • Contour: a response which is the target of a function contour restoration study. Requires using the Adaptive design technique — all other techniques disregard this type and treat it as an evaluation response. A contour response must have Size 1, and a contour value must be set (see the Value property). Incompatible with adaptive responses.

Note that constraint, minimization, and maximization responses are supported by all techniques (not only optimization), but their interpretation is different. The usage of response types is explained in more detail further in section Response Types.

Size

This property specifies the number of response components, or its dimension. The components can have different bounds (for constraint responses), but other properties are the same for all components. Also note that a contour type response cannot be multi-dimensional.

The Size property affects the following:

  • The syntax of the Lower bound and Upper bound properties. See Response Types for details.
  • The number of columns corresponding to this response in the initial sample matrices. See Initial Samples for details.
  • The number of corresponding columns in the result matrices (see Results).
  • The expected number of columns in the samples containing response evaluation data, which are received from blackboxes (see Blackboxes).

Note that you can use a special input port to set the Size property (see Ports and Parameters for details). In particular, this allows creating responses with varying dimension, which can be quickly changed in workflow configuration.

Lower bound
Upper bound

The lower and upper bounds specify, respectively, the minimum and maximum allowed value of a constraint type response (see Type). Optimization techniques and Adaptive design require at least one finite bound for every constraint. Other techniques allow constraints with no bounds or both infinite bounds, and treat such constraints as always satisfied.

  • If only one bound (lower or upper) is specified, the response value is required to be, respectively, greater or less than the bound.
  • If both bounds are specified, the response value is required to fall into the range within bounds.
  • Infinity and -Infinity are valid values for the upper and lower bound respectively. An infinite value means that there is no bound.

Those design points, for which the value of any constraint response is out of bounds, are considered infeasible and are excluded from the feasible and optimal result matrices (see Results for details).

If the response type is not constraint, the block ignores its Lower bound and Upper bound properties and does not validate them. This allows, for example, to easily switch the response type from constraint to evaluation and back. In that way you can activate or deactivate a constraint in your study without the need to edit any other properties of the corresponding response except its Type.

Similarly to the bounds of variables, the value of a response bound can be RealScalar or RealVector:

  • RealScalar sets the same bound for all response components.
  • RealVector sets a specific bound for each component. The number of vector components must be equal to the response’s Size. The vector can contain infinite values — use +Inf and -Inf to disable the upper or lower bound for a specific component.

For syntax examples, see Response Types.

Note that you can use special input ports to set the bounds (see Ports and Parameters for details).

Value

A property used specifically in a function contour restoration study — one of the adaptive DoE tasks. Specifies the target (contour) value of the response. The value is always RealScalar, since multi-dimensional contour responses are not supported. A contour type response requires this property, other types ignore it.

Note that you can use a special input port to set the Value property (see Ports and Parameters for details).

Function

An advanced property which you can use to notify the block about certain response attributes. Any response, regardless of its Type, can be declared as:

  • Generic (default): a response with no special features.
  • Analytical: a computationally cheap function, typically a response with a known analytical formula (hence the name).
  • Linear: a response which is a linear function of design variables, or should be treated as linear.
  • Quadratic: similarly, a quadratic function of design variables.

Information provided by this property changes behavior of the Adaptive design, Gradient-based optimization, and Surrogate-based optimization techniques. These relationships are explained in more detail in Response Types. Other techniques — for example, non-adaptive DoE — do not use this additional information in any meaningful way. With such techniques the Function property can be used just to distribute response evaluations to different blackboxes.

Important

Responses with different Function settings must be evaluated by separate blackboxes (different blocks). Note that when you change the Function property for a response, the block automatically adds or removes the output ports which are used to connect the blackboxes, so usually you will need to re-create some links. Due to this it is not recommended to connect the blackboxes until you finish with the response Function settings. See Blackboxes for details.

Blackbox

By default, the block assumes that response evaluations are available from some other block in your workflow (a blackbox). However you can add a response to your task definition but disable its evaluations. Note that when you disable the Blackbox property for a response, the block automatically removes the ports which receive the response data from a blackbox, so this action can remove existing links in your workflow.

Some techniques cannot be used if your configuration includes a response with no blackbox. Some others support such responses but require initial samples for them (see Initial Samples).

Adding Responses

Responses are added and edited on the Responses pane: click the b_blconf_add button or select Add responses… from the pane’s context menu b_blconf_context to bring up the Add responses dialog.

../_images/page_blocks_Design_space_exploration_addresp.png

The Add responses dialog showing 2 evaluation type responses with default settings. Ignored properties are grayed out.

You can add multiple responses at once using the Name field:

  • Input a comma-separated list (see the example above) to add multiple responses with different names.
  • Input a range to add multiple responses with the same base name and different indices. For example, f1-f3 adds 3 responses named f1, f2, and f3.

Note that when you add multiple responses, they will get the same properties. Later you can edit the properties on the Responses pane.

Limitations for names of responses are the same as for names of variables:

  • Certain characters are prohibited — see Name in Response Properties.
  • Names with hyphens must be quoted to distinguish them from name ranges. For example: "my-func1".

The Add responses dialog validates response names only. Other settings are validated after you add responses — use the block’s Issues pane to check for errors and warnings.

All other settings are validated by the block after you add the responses. If there are errors or warnings, the block will show them in its Issues pane. Settings which are ignored in current configuration are not validated — for example, the lower and upper bounds are not validated for evaluation responses.

Ports related to responses are described in sections Ports and Parameters and Blackboxes. Note that similarly to variables, you can use the Ports and parameters dialog to add special input ports which set response properties.

Response Types

Response types are an important part of the block’s configuration: the Type property, along with the Function property in certain cases, determines how the block “explores” the response function and what is the study goal for the response. Thus the block’s task is mainly defined by the response types you select. For example, by combining adaptive, constraint, and minimization types, you can configure the block to generate an adaptive DoE which satisfies additional functional constraints and then select the design with the minimum value of a certain response.

This section explains how the block handles responses of different types, and provides some additional details on properties required by each type. Note that actually you can specify and save all properties of a response, even if some of them are ignored by its current type — this is useful if you are going to change the type later.

Evaluation Responses

Default type compatible with all techniques. The block collects values of evaluation responses, but these values are not actually used by its internal algorithms — they are simply added to the final result. The general policy regarding evaluation responses is to evaluate them as few times as possible. For example, if an evaluation response is calculated by a separate blackbox, the block will call this blackbox only after the generated points are checked for feasibility and optimality (depending on the types of other responses), and will send only feasible (or optimal) designs to evaluation. However, if an evaluation response is calculated by the same blackbox as some other response type, the block will collect all its values and include them in results.

The evaluation type is typically used to:

  • Calculate some response only for feasible or optimal design points, as noted above.
  • Temporarily deactivate a constraint in your study while keeping its settings and related links.
  • Include some intermediate calculations in optimization results. For example, some optimization tasks search for a minimum or maximum value of some two-entity ratio, so the blackbox outputs this ratio, which is defined as a minimization or maximization response. To add values of the actual design characteristics (which are terms of the ratio) to optimization results, you can add these characteristics to blackbox outputs, and add 2 evaluation responses. Note that with such configuration, values of the evaluation type responses will be available for all design points generated during optimization, since these responses are always received from blackbox outputs together with the value of the optimization objective.

Constraint Responses

Constraint responses are compatible with all techniques, but are handled differently depending on the technique type.

  • Non-adaptive DoE techniques and Adaptive design for GP use constraints to check generated designs for feasibility — that is, they first generate all design points according to the Number of designs setting, and evaluate constraints after the generation phase finishes. These techniques allow constraints with no bounds and treat them as always satisfied.
  • Optimization techniques and Adaptive design evaluate constraints during the optimization (generation) phase and actively use this information to discover the feasibility domain. These techniques require at least one finite bound for every constraint (every response component, in the case of multi-dimensional constraints).

The bounds can be set using RealScalar or RealVector values, for example:

  • If the Size of a constraint is 1:
    • Use RealScalar bounds for simplicity: 0.5.
    • Use RealVector bounds if required by your workflow: (0.5). Note that the vector has a single component.
  • If the constraint has multiple components, for example, its Size is 3:
    • Use a RealScalar value as a shorthand to set the same bound for all components: 0.5 is equivalent to (0.5, 0.5, 0.5).
    • Use a RealVector value to specify different bounds for components. The number of vector components must be equal to Size. For a component which has no lower or upper bound, use a -Infinity or Infinity value respectively. For example, if Lower bound is (-Infinity, 0.0, 20.0), and Upper bound is (0.0, Infinity, 50.0):
      • The first response component is required to be less than or equal to \(0\).
      • The second component is required to be greater than or equal to \(0\).
      • The third component is required to fall into the \([20.0, 50.0]\) range.

The bound values can be specified in block configuration or sent to special input ports: <constraint_name>.Lower bound and <constraint_name>.Upper bound. These additional ports are disabled by default; see Ports and Parameters for usage.

Constraint bounds are also checked when evaluating an initial sample. Points of the initial sample with constraint values out of bounds are considered infeasible and are excluded from the feasible and optimal result matrices (see Initial Samples and Results).

Minimization and Maximization Responses

These response types are compatible with all techniques. In optimization, they are used to specify the objectives — that is, optimization techniques seek to minimize (maximize) these responses. In DoE studies, these responses are considered on the final stage, when forming the result matrices: these techniques select optimum points from the generated designs (see Results for details).

Adaptive Responses

This is a special response type supported by the adaptive DoE techniques:

  • The Adaptive design technique analyzes behavior of adaptive responses and generates more design points in “areas of interest” — for example, the areas with high function gradients. This technique supports multiple adaptive responses.

    Note also that adaptive responses are not required to use the Adaptive design technique. For example, if your configuration includes only constraint and evaluation type responses, this technique will generate a uniformly distributed sample with regard to constraints.

  • The Adaptive design for GP technique trains an internal model of the adaptive response and generates new design points to fill the areas with highest uncertainty of the model. This technique supports only 1 adaptive response, and its Size must be 1.

Other techniques treat adaptive responses in the same way as evaluation responses.

Contour Response

A special response type supported by the Adaptive design technique only. Specifies the response which is the target of a contour restoration study: the block will generate more such design points which evaluate to the given response value. This target value is set by the Value property of a response.

Additional limitations related to contour responses are:

  • You can define only 1 contour response, and its Size must be 1.
  • You configuration cannot include both adaptive and contour type responses.

All other techniques except Adaptive design treat contour responses in the same way as evaluation responses.

Generic and Analytical Responses

By default, the block evaluates responses at most Number of designs times. When using the Adaptive design or Surrogate-based optimization techniques, this limit can be removed for certain responses by changing their Function property from Generic (default) to Analytical. Use this setting only for responses which are computationally cheap compared to others: since it removes the evaluation limit, the block can evaluate any analytical response much more times than Number of designs.

All other techniques disregard analytical responses and treat them in the same way as generic.

Analytical responses have to be evaluated by a separate blackbox — see Blackboxes for details.

Linear and Quadratic Responses

The Adaptive design, Gradient-based optimization, and Surrogate-based optimization techniques have the ability to reconstruct linear and quadratic responses internally and use these internal models instead of evaluating the actual response. To enable this behavior, set the Function property of a response to Linear or Quadratic. Keep in mind that these settings should be used only when it is known that the response is a linear (or quadratic) function of design variables — otherwise you may obtain incorrect results.

All other techniques disregard linear and quadratic responses and treat them in the same way as generic.

Linear and quadratic responses have to be evaluated by separate blackboxes — see Blackboxes for details.

Editing Variables and Responses

Existing variables and responses can be edited on the Variables and Responses panes. They both provide similar functions: you can change names and other properties of variables and responses, reorder or remove them. The name filter at the bottom of each pane can be used to find specific variables and responses. A list of variable (or response) names can be copied from the respective pane — for example, to add variables with the same names to a blackbox block.

../_images/page_blocks_Design_space_exploration_varpane_editvar.png

Variable editing. 1 A cell in edit mode. 2 The value editor button. 3 The list of variables is filtered by name. 4 The button to clear the filter.

  • To quickly edit a property, double-click its value or click the b_editval icon which appears when you hover the cell with your mouse cursor.
  • While the cell is in edit mode, you can also click the b_editval_dialog button inside it to open the Edit value dialog. This can be useful when editing multi-dimensional variables and responses.
  • To copy some value, select its cell with a single click and hit Ctrl C. There is no need to enter the edit mode.
  • The Name column allows copying multiple names at once — see below.

Note that editing the name of a variable or response automatically changes the names of related ports. If some of these ports are already connected, pSeven keeps existing links when possible.

If you need to set the same property for a number of variables (responses), you can apply this change in a few clicks using multi-edit.

../_images/page_blocks_Design_space_exploration_varpane_multiedit.png

Editing multiple variables. 1 Selected variables. 2 The multi-edit icon (appears on hover).

To change the value of some property for multiple variables or responses at once:

  • Select corresponding rows on the pane (hold Ctrl or Shift for multiselection).
  • Click the b_editval icon in the property column header to open the edit dialog. This icon appears when you hover the header with your mouse cursor.
../_images/page_blocks_Design_space_exploration_respane_copynames.png

Copying response names. 1 Selected responses. 2 The copy icon (appears on hover).

In a similar way you can copy names from the Name column:

  • Select the names (rows) to copy. To select all, hit Ctrl A.
  • Click the b_blconf_copynames icon which appears when you hover the column header. This copies a comma-separated list of names to the clipboard.

The b_blconf_up and b_blconf_down buttons on the pane toolbars reorder the list of variables (responses) by moving the selected variable (response) up or down. Moving multiple items together is also possible, but only if they are next to each other. The order of variables and responses on the panes determines the order of columns in the input and output data matrices (see Initial Samples, Results) and the default sorting order in the Ports and parameters dialog. It does not affect workflow links, properties of variables and responses, or other settings.

Ports and Parameters

The Ports and parameters dialog is used to:

  • Enable additional ports which set variable and response properties.
  • Add ports to workflow parameters.
  • Assign value to ports — for example, add initial samples or specify variable and response properties.
  • Setup port monitoring.

Note that by default many additional ports are disabled and not shown in the dialog. To show the disabled ports, use the b_blconf_dsx_p button on the dialog toolbar. To enable a port, tick the checkbox in the Port column.

Ports are sorted into several groups described below. You can show or hide an entire group using commands from the context menu b_blconf_context.

Problem Definition Ports

This group includes the Number of designs port and input ports which set properties of variables and responses (the property ports).

The Number of designs port corresponds to the Number of designs setting in the block configuration dialog. This port is always enabled.

The property ports are disabled by default. These ports have names of the form variable.property or response.property. For example, the material.Levels port sets the Levels property of the variable named material; the mass.Upper bound sets the upper bound for the mass response, and so on. You can also change the Constant property of a variable using a property port. If this port is enabled and receives a True value, the variable is interpreted as a constant (ignores bounds and levels, requires Value, and so on; see Types of Variables for details). If it receives a False value, the variable is interpreted according to its Type property. Adding this port to workflow parameters allows to “freeze” a variable from Run, without opening the block configuration dialog.

Samples and Designs

This group includes input ports which accept initial samples (see Initial Samples), and output ports which provide results.

The Initial sample input accepts the initial sample as a single matrix. This port is always enabled.

Changed in version 6.15: added the optional Variables.Initial sample and Responses.Initial sample ports.

If you have separate samples with values of variables and responses, you can enable the Variables.Initial sample and Responses.Initial sample ports and use them instead. You can also enable a separate initial sample input port for each variable and response. The name of this port is the name of the variable (response) with the Initial sample suffix added, for example: force.Initial sample, mass.Initial sample.

The All designs, Feasible designs, and Optimal designs ports output different result sets described in section Results. These ports are always enabled, and are monitored by default.

Changed in version 6.15: added optional output ports for feasibility measures.

The block can calculate a feasibility measure (constraint violation measure) for each design point in the result. This data is output to the following optional ports (disabled by default):

  • Feasibility.All designs — feasibility measures for points which are output to the All designs port.
  • Feasibility.Feasible designs — same for the Feasible designs port.
  • Feasibility.Optimal designs — same for the Optimal designs port.

For the definition of the feasibility measure used, see section Results.

Changed in version 6.15: added the optional result ports for variables and responses as two separate matrices.

You can enable the following additional ports which output the same result data separately for variables and responses. All of these ports are disabled by default:

  • For variables: Variables.All designs, Variables.Feasible designs, and Variables.Optimal designs.
  • For responses: Responses.All designs, Responses.Feasible designs, and Responses.Optimal designs.

There is also a similar set of ports available for each variable and response. For example, result ports related to the response named mass are: mass.All designs, mass.Feasible designs, and mass.Optimal designs. By default, the first two of them are disabled, and the optimal designs port is enabled and monitored.

Blackbox Ports

Includes all ports which are used to connect the block to blackboxes. All these ports are always enabled and monitored by default. Output ports in this group correspond to variables: they output values of variables generated by the block. Input ports correspond to responses: they accept response values calculated by blackboxes.

Ports of this group have names with the Blackbox prefix followed by the name of a variable or response. For example, the Blackbox.force outputs values of the variable named force; the Blackbox.mass receives values of the mass response, and so on.

The output ports created for each variable depend on the Function property of responses added to configuration. Since responses with different Function settings must be evaluated by separate blackboxes, the block automatically creates output ports which can send values of variables to multiple blocks. For example, the full set of blackbox ports for a variable named force is:

  • Blackbox.force — outputs values of the variable when it is required to evaluate a generic type response.
  • Blackbox.force.Linear — the same for a linear response.
  • Blackbox.force.Quadratic — for a quadratic response.
  • Blackbox.force.Analytical — for an analytical response.

Each of these outputs is present only if the block configuration includes at least one a response with the corresponding Function property. For more detailed explanations on using these ports to distribute evaluations between blackboxes, see section Blackboxes.

Changed in version 6.15: added the index output ports.

You can enable additional ports which output the index of current blackbox iteration. Blackboxes can use this index, for example, to generate names of files which they create.

  • Blackbox.Index — the index for a blackbox which evaluates a generic type response.
  • Blackbox.Index.Linear — the same for a linear response.
  • Blackbox.Index.Quadratic — for a quadratic response.
  • Blackbox.Index.Analytical — for an analytical response.

All index ports are disabled by default.

Signal Ports

This group includes the common do and done ports. See Signal Ports in section Block Configuration for more details.

Blackboxes

By default the block expects that each response is evaluated by some block which receives values of variables from the Design space exploration block and outputs the calculated response values. Such blocks are called blackboxes to note the fact that the Design space exploration block is unaware of their configuration and can only exchange data samples with them.

Blackbox Ports and Connections

Ports used in blackbox connections are automatically added to the block when you define variables and responses. These ports have names with the Blackbox prefix and are found in the Blackbox Ports group in the Ports and parameters dialog (see Ports and Parameters).

For each variable, one or more ports are added which output samples containing values of this variable. All these samples have matrix data types. The number of columns in the matrix is equal to the Size property of the variable. The number of matrix rows depends on the Batch mode option: if batch mode is disabled, the matrix always contains a single row; if batch mode is enabled, the matrix can contain up to Maximum batch size rows.

For each response, an input port is added which accepts samples with response values. These samples must be correctly formed by your blackbox: each sample is a matrix, the number of matrix columns is equal to the Size property of a response, and the number of matrix rows is equal to the number of rows in the matrix received by the blackbox (values of variables). It is also possible to use values which can be converted to a matrix of the correct shape (see pSeven Types Conversion).

You can also enable special ports which output the index of current blackbox iteration. Blackboxes can use this index, for example, to generate names of files which they create. See Ports and Parameters for details.

Blackbox Responses

For each input received from a Design space exploration block, the blackbox block has to output either a calculated response with the correct matrix shape, or a special value indicating an error, if the blackbox failed to evaluate.

The matrix shape of a response calculated by a blackbox is determined by the following:

  • The number of columns must be the same as the Size property of the response evaluated by the blackbox.
  • The number of rows must be the same as the number of rows in the input matrices which contain values of variables. Note that by default all matrices contain 1 row. Multi-row matrices can appear in batch mode only (see the Batch mode option).

The special value, which the blackbox must send to the Design space exploration block when it failed to evaluate, may be one of the following:

  • A matrix with the correct shape, filled with NaN values.
  • An empty matrix.
  • A matrix containing a single NaN element.
  • A RealScalar NaN value.

Changed in version 6.15: added empty matrix and single NaN as valid response values (previously, the block always required the correct shape of the response matrix).

An empty matrix and a single NaN value are supported for convenience. These values are automatically converted to a matrix of the required shape when received by the Design space exploration block.

Optimization and Adaptive Design techniques can handle response evaluation failures up to a certain extent — for example, optimization continues even if the Design space exploration block receives a NaN response value from a blackbox, but it will stop if the blackbox fails to evaluate too often. Adding the Noisy responses hint to the Design space exploration block configuration makes the workflow more stable it such cases.

Warning

If you are using a PythonScript block as a blackbox, use numpy.nan to output NaN values. See NaN Output Values for details.

Types of Blackboxes

The output ports created for each variable depend on the Function property of responses in block configuration. Since responses with different Function settings must be evaluated by different blackboxes, separate outputs are created for them.

Note

Only a few techniques actually consider the Function property when evaluating responses (for example, approximate linear and quadratic functions). However, even if the technique does not support specific handling of different functions, you can still use this property to connect multiple blackboxes (see the example below).

For example, take a look at the following configuration of the I-beam block which supposedly optimizes the design of an I-beam subject to some mass and geometry constraints.

../_images/page_blocks_Design_space_exploration_beamconf.png

An example configuration. Note that all responses have different Function properties.

This configuration contains three responses which have different Function properties:

  • mass is an analytical (fast evaluation) constraint. Related input is Blackbox.mass.
  • stress is a computationally expensive (generic) objective. Related input is Blackbox.stress.
  • geometry is a linear constraint. Related input is Blackbox.geometry.

Consider the output ports related to the section variable, shown below.

../_images/page_blocks_Design_space_exploration_beamports.png

Ports which output values of the section variable to blackboxes. The port list is filtered to show only the ports which are related to this variable.

There are 3 blackbox connection ports related to the section variable:

  • Blackbox.section — outputs the section variable value only when the block needs the stress (generic response) value.
  • Blackbox.section.Linear — outputs the section variable value only when the block needs the geometry (linear constraint) value.
  • Blackbox.section.Analytical — outputs the section variable value only when the block needs the mass (analytical response) value.

The Blackbox.section.Quadratic output is not present because there are no quadratic responses in this example configuration.

Assuming that the responses are evaluated by different blocks named Mass, Stress, and Geometry respectively, and each of them has an input named section (for the variable’s value) and an output named response (for the calculated response value), the following links have to be created:

  • To blackboxes:
    • I-beam.Blackbox.section to Stress.section.
    • I-beam.Blackbox.section.Linear to Geometry.section.
    • I-beam.Blackbox.section.Analytical to Mass.section.
  • From blackboxes:
    • Stress.response to I-beam.Blackbox.stress.
    • Geometry.response to I-beam.Blackbox.geometry.
    • Mass.response to I-beam.Blackbox.mass.

Initial Samples

Initial sample is optional input data sent to the block — an existing designs sample which can be used in several ways depending on the block configuration. The initial sample can contain either values of variables, or values of both variables and responses.

  • Non-adaptive DoE techniques add generated new designs to the initial sample and then process the obtained sample according to the current block configuration. For example, if there are constraint responses, all designs are checked for feasibility; if there is a blackbox connected, all feasible designs are evaluated, and so on.
  • The Initial sample evaluation technique processes the initial sample in the same way, it just does not generate any new design points.
  • If the initial sample is a Latin hypercube design, the Latin hypercube sampling technique can update it (generate new designs) in such a way that the new sample is also a Latin hypercube. This is a special mode enabled by the Property preservation option.
  • Adaptive DoE techniques can use an initial sample to train initial approximations of the response functions, thus improving generation quality. Another usage is when your configuration includes an adaptive type response which is not evaluated by a blackbox: in this case, the technique requires an initial sample for this response, and will use it to train an internal model which is evaluated instead of the blackbox.
  • The Surrogate-based optimization technique uses the initial sample to train initial approximation models of responses. If the initial sample does not contain response values, or some of them are missing, these designs are evaluated first.
  • The Gradient-based optimization technique uses the initial sample as an extended initial guess. If the initial sample contains both variable and response values, this technique selects optimum designs from the initial sample and starts searching form these points. If response values are missing, the initial designs are evaluated first, then analyzed for optimality.

The initial sample can be supplied as a single matrix, as 2 matrices with values of variables and responses, or as a number of separate samples — one for each variable and response.

  • The Initial sample input accepts the single initial sample matrix. The order of matrix columns should follow the order of variables and responses as they are listed on the Variables and Responses pane, with variables coming first. For a multi-dimensional variable or response, the number of corresponding matrix columns is equal to the variable (response) Size.
  • Additional ports which accept initial samples can be enabled in the Ports and parameters dialog (see Ports and Parameters). The matrices sent to these ports should have the same number of rows. When sending the initial sample as two matrices, the number of columns in the matrix of variables (responses) is equal to the total Size of variables (responses) added to the block’s configuration. When using separate initial sample ports for each variable and response, the number of columns in each matrix is equal to the Size of the respective variable or response.

The input part of the initial sample (values of variables) must be fully defined — that is, it cannot contain missing or NaN values, or empty columns. The output part (response values), however, can contain special values which have the following meaning:

  • NaN value of a response means that its evaluation failed for the corresponding design point. The block treats such points as infeasible.
  • None value means that a response was not evaluated for the corresponding design point. The block tests such points for feasibility (evaluating constraints, if they are missing), and then processes feasible initial points according to the current technique — for example, evaluates objectives in an optimization study. An empty column can be created in the response part of the initial sample by filling it with None values (the column cannot be removed since it would change the sample matrix shape).

Note that the initial sample is processed in a specific way if there are categorical or discrete variables in configuration, and the block runs a technique which does not provide full support for these types of variables (for example, some DoE techniques). In such cases the block performs a number of independent runs, one for each possible combination of variable levels. The initial sample is split between these runs according to values of variables in each combination, so each run actually uses its own initial sample, which is only a subset of the original. These subsets can contain different number of design points, which can lead to different technique behavior in different runs.

Controlled Generation

Controlled generation is a special run mode supported by sequential DoE techniques (Random uniform sequence and all low-discrepancy sequences). In this mode the block generates new designs indefinitely until you manually stop it (see Manual Stop). When stopped, it will output the result samples, so workflow execution will continue normally.

The abovementioned techniques switch to the controlled generation mode when Number of designs is set to Auto. Additional requirements for this mode are:

  • All variables must be continuous (see the Type property in Variable Properties).
  • The block must be connected to a blackbox.

Results

Regardless of its configuration, the block always produces 3 result samples (matrices) which are output to different ports:

  • The All designs port outputs a sample which always contains all generated data — design points generated by the block and response values evaluated by blackboxes. Note that some response values may be missing — it means that the response was not evaluated for some design point. By default, this sample also includes points from the initial sample — this behavior can be changed with the Include initial sample option.
  • The Feasible designs port outputs a sample containing all feasible points. A design is feasible if it satisfies all constraints, values of continuous variables are within bounds, and all discrete or categorical variables have values matching the levels defined for these variables. In certain situations, this sample is the same as the one output to All designs — for example, when there are no constraint responses in configuration, and initial sample is not used or contains only feasible points. Also, the feasible result set never includes points with missing values of responses.
  • The Optimal designs port outputs a sample containing all points which are both feasible and optimal with regard to minimization and maximization type responses. If your configuration does not include responses of these two types, the optimal result set is the same as the feasible one.

In most cases, the optimal set should be interpreted as the main result. In simple DoE tasks (no constraint responses, no initial sample), the contents of all three result sets are the same: the optimal result contains all generated points. In constrained DoE without minimization or maximization responses, the optimal and feasible results are the same: the optimal result contains all feasible points. In optimization, the optimal result set provides the solution to an optimization problem, and so on.

The sample which is output by All designs does not exactly represent the evaluation history: it is compacted to reduce the number of missing response values. For example, suppose there are two responses which depend on the same variables but are evaluated by different blackboxes. In evaluation history, each design point evaluated by both blackboxes would create two history entries, and each entry would contain values of all variables but only one response value. In the result sample, these entries are merged to a single matrix row containing all variable and response values. Due to this, the number on rows in the All designs matrix is generally not equal to the total number of evaluations performed.

Changed in version 6.15: added optional output ports for feasibility measures.

The block can calculate a feasibility measure (constraint violation measure) for each design point in the result and output this data to the Feasibility.All designs, Feasibility.Feasible designs, and Feasibility.Optimal designs ports (see Ports and Parameters for details).

The feasibility measure \(\psi\) is defined for a design point \(x\) as \(\psi(x) = \max_i \psi_i(x)\), where \(\psi_i(x)\) are individual constraint violation measures. The \(\psi_i(x)\) values are calculated separately for each constraint \(c_i\) with lower and upper bounds \(l_i\) and \(u_i\) as:

\[\psi_i(x) = \max\left[ \frac{l_i - c_i(x)}{\max(1, |l_i|)}, \frac{c_i(x) - u_i}{\max(1, |u_i|)} \right],\]

so \(\psi_i(x) > 0\) means that constraint \(c_i\) is violated, and \(\psi_i(x) \leq 0\) means that it is satisfied. Since \(\psi(x) = \max_i \psi_i(x)\), it is positive (\(\psi(x) > 0\)) for \(x\) which violates at least one constraint. Also, \(\psi_i(x)\) may be understood as a normalized distance from the \(c_i\) constraint bound, which is measured positive outside the feasibility domain and negative inside. The generalized measure \(\psi\) is then the maximum of these distances.

In addition to the ports described above, you can enable ports which output separate result matrices for variables and responses, or for each variable and response. See section Ports and Parameters for details.

Run Options

Batch mode

Toggles the batch evaluation mode.

Value:True (on) or False (off)
Default:False (off)

When the Design space exploration block requests values of responses, it can output either a single point to evaluate, or a batch of points. Batch mode is useful, for example, when the blocks which evaluate responses (the blackboxes) support parallel calculations.

  • True: batch mode is enabled. The ports used to send values of variables to blackboxes will output batches — matrices with several rows, where each row corresponds to a design point. The maximum number of points in a batch (rows in output matrices) is set by the Maximum batch size option.
  • False (default): batch mode is disabled, the block always outputs points one by one (output matrices contain a single row).

This option is ignored if there are no responses in configuration.

CPU cores limit

Maximum number of parallel threads used by the block.

Value:positive integer or Auto
Default:Auto

Parallel calculations can be used by optimization and adaptive DoE techniques. This option sets the maximum number of threads the block is allowed to create.

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 you launch pSeven.
  • 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 pSeven. 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).

If you set this option to a non-default value, it will be the maximum number of threads, regardless of your CPU.

Detailed log

Output detailed information to the workflow run log.

Value:True (on) or False (off)
Default:False (off)

Allows the block to print extended debug information to the run log. Note that enabling this option can produce very large logs.

To see the debug level messages, use the Level selector on the run log tab in Run.

Deterministic

Configures deterministic generation of randomized designs.

Value:Disable, Workflow run, Block run
Default:Workflow run

Fix the seed for all randomized DoE algorithms before each block or workflow run, or disable deterministic behavior. The seed is set by the Random seed option.

This option affects the following DoE techniques which involve pseudo-randomness:

  • Latin hypercube sampling
  • Random uniform sequence
  • Adaptive design
  • Adaptive design for GP
  • Orthogonal array design
  • D-optimal design
  • I-optimal design
  • Box-Behnken design

Other techniques are always deterministic, so this option has no effect on their behavior.

Error handling behavior

The action to perform if the block encounters an error.

Value:stop workflow, output defaults and signal, output signal only
Default:stop workflow

When this option is set to stop workflow, the block simply reports an error and the workflow interrupts.

If set to output defaults and signal, the block suppresses the error. In this case, instead of generated samples the block outputs values assigned to the result outputs (the defaults), and the done port outputs a False value (the signal).

The output signal only behavior means to output only the False value to done; nothing is output to other ports.

Include initial sample

Include points from the initial sample into the result sample.

Value:True (include) or False (do not include)
Default:True (include)

By default, points from the initial sample are evaluated and included in the result together with the new generated designs. If this option is set to False, the result samples will contain only the new points. Note that the False setting does not change the handling of initial samples described in section Initial Samples.

Maximum batch size

Maximum number of points in a batch for the batch mode.

Value:positive integer
Default:1000

This option can be used together with the Batch mode option to limit the number of points in batches which are send to blackbox blocks. Note that this option does not fix the batch size — the block can output batches containing less points when the limit set by this option.

This option is ignored if there are no responses in configuration, or the batch mode is disabled.

Random seed

Seed value for randomized generation algorithms.

Value:positive integer
Default:100

The value of this option is used to seed all randomized generation methods when deterministic generation is enabled (see the Deterministic option). If deterministic generation is disabled, this option is ignored.

Known Issues

This section describes known issues in the Design space exploration block.

Column Order in Results

In pSeven 6.16 and older versions, a bug in the block configuration dialog could invalidate the configuration in some cases — for example, when you reordered variables, then deleted one of them and created a new one with the same name. Due to the bug, pSeven did not correctly save the order of variables and responses, making their order shown on the Variables and Responses panes inconsistent with the column order in result samples. This led to various obscure issues in results, such as “mixed” columns in the matrix output to All designs, and also caused incorrect behavior of the variable and response reordering commands (the b_blconf_up and b_blconf_down buttons).

This bug is fixed since pSeven 6.16.1, but workflows created in pSeven 6.16 and older can still contain a block saved with invalid configuration. When you open such a workflow in pSeven 6.16.1 or newer, you will get validation errors in the Issues pane, like the following:

The order of variables may be inconsistent due to a configuration bug. Reopen the block to resolve the issue.
The order of responses may be inconsistent due to a configuration bug. Reopen the block to resolve the issue.

The workflow cannot run unless these errors are fixed. To remove the errors:

  1. Open the block which reports the error — see its name in the Source column in the Issues pane.

  2. When you open the block, an error dialog will pop up:

    ../_images/page_blocks_common_indexbug_message.png

    The error resolution dialog shown when you open a block with errors in variable or response configuration. pSeven can automatically fix these errors, but you will have to verify configuration afterwards, as the order of variables or responses may change.

  3. Click Resolve in the error dialog to fix the block. Note that the order of variables or responses may change after this: unfortunately, it is not possible to restore the correct order from the invalid configuration.

    • If you want to check the configuration without any changes, click Cancel in the error resolution dialog.
  4. After pSeven resolves errors, verify the order of variables and responses in the block configuration dialog, and make your adjustments. Usually there is a problem with one variable or response, and it is automatically moved to the bottom position on the pane.

  5. Click OK or Apply to save the fixed configuration, then save the workflow.

Note that clicking Cancel in the error resolution dialog or the block configuration dialog keeps the current (invalid) configuration. It does not remove the validation error, so pSeven will continue to show the error in the Issues pane and the block’s validation pane. No changes are done unless you select Resolve and save the block afterwards, so you can review the issue and make backup copies of the block or workflow before allowing pSeven to fix errors.