Design space exploration

• Group: 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.

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: you have to create one or more blackboxes — blocks which evaluate model outputs — and connect them with the Design space exploration block. The optional initial sample in this case can contain values of responses in addition to values of variables.

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.

Block configuration dialog. 1 2 Variable and response definitions. 3 Exploration budget (response evaluation limit) and Study target settings. The study target setting applies to the Adaptive design technique only. 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 pane toggle. 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 button. After this you can change the technique using the selector 5 and tune the technique with its options. The button opens the technique configuration dialog which lists all options and provides tooltips with option descriptions.

By specifying Exploration budget, you can set the maximum number of designs to evaluate or the number of DoE points to generate. This setting is optional: with the Auto value (default), an appropriate budget is set automatically, depending on the number of variables and responses, the selected technique, its options, and other block settings. The tooltip on the Exploration budget field explains how this setting is applied to the current configuration.

A tooltip for Exploration budget explaining the current setting.

In the case of the Adaptive design technique, you can specify Study target to set the target number of feasible designs. The Study target setting is optional, and it has the following effect when using the Adaptive design technique:

• If you do not set the exploration budget and do not specify the study target, the block selects them automatically, depending on the design space dimension and the value of the technique’s Accelerator option. Since each of these parameters is set to a finite value, the generation ends as soon as the block finds a certain number of feasible designs, or when the automatically selected budget is exhausted, whichever comes first.
• If you set a certain exploration budget without specifying the study target, the block generates as many feasible designs as possible within that budget. The generation ends as soon as the exploration budget is exhausted.
• If you specify a certain study target without setting the exploration budget, the block generates new designs until it finds the specified number of feasible designs. This may require significantly more response evaluations than the study target number, depending upon the response behavior.
• If you set both the exploration budget and study target, the block aims to generate the specified number of feasible designs within the given exploration budget. The generation ends as soon as the block finds the target number of feasible designs, or when the budget is exhausted, whichever comes first. If the budget is not large enough, the block may find fewer feasible designs than the study target.

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

• A warning message means that the block can start but an error can occur during workflow run, or you can obtain unexpected results.
• An error message 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.

There are a few general configuration hints, which you can use to provide the block with additional 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).

In the SmartSelection mode, the block reads these hints to adjust the recommended configuration.

Variables

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

The Variables pane showing an example definition of an I-beam design. 1 The list of design variables, their properties and hints. 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 and hints. You can set main properties when adding a variable, then edit properties and add hints on the Variables pane. Some properties can also be set using special ports related to the variable.

Main properties are:

• Name. Identifies the variable and related ports.
• Type. The variable can be continuous (default), discrete, stepped, or categorical. The block handles each of these types in a specific manner.
• Size. The number of components for the variable (its dimension). You can add an input port that sets this property.
• Lower bound. The minimum allowed value for a continuous or a stepped variable. Ignored if the variable is discrete, categorical, or constant. You can add an input port that sets this property.
• Upper bound. The maximum allowed value for a continuous or a stepped variable. Ignored if the variable is discrete, categorical, or constant. You can add an input port that sets this property.
• Levels. Predefined values for discrete and categorical variables. Ignored for continuous variables and constants. You can add an input port that sets this property.

Additional properties, set by variable hints, are:

• Constant. A variable of any type can be set to constant, allowing you to freeze a variable — essentially, exclude it from consideration without deleting it. You can add an input port that sets this hint. The Constant hint only sets a variable to constant (freezes or unfreezes a variable), and requires the Value hint which specifies the fixed value.
• Initial guess. Sets the initial guess value in optimization. Ignored by DoE techniques; also ignored for constant variables (see Value). You can add an input port that sets this hint.
• Resolution. Specifies the minimum significant change of a continuous variable. Ignored for variables of other types.
• Step. This hint is required for a stepped variable and sets its step. Ignored for variables of other types.
• Value. The value for a constant variable. Ignored if the Constant hint is disabled. You can add an input port that sets this hint.

The properties listed above are described in more detail in sections Variable Properties and Variable Hints further.

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.

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, stepped, or categorical.

• Continuous: generic numerical variable, which may take any value within the design bounds. The bounds (see Lower bound, Upper bound) are required for continuous variables.
• Stepped: a numerical variable, that may take values distributed evenly within bounds, from lower to upper, at regular intervals (steps). A stepped variable requires bounds and the Step hint, which sets the step size.
• 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.

Internally, a stepped variable is similar to a continuous one, but with values adjusted to the regular grid defined by the variable’s bounds and step. A discrete variable may have arbitrary levels, although it is recommended to use this type only for true integer variables, or variables that cannot be defined as stepped.

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 following properties and hints: Lower bound, Upper bound, Levels, Initial guess, Resolution, Step, and Value. 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 and stepped variables (see Type). Also, the Gradient-based optimization and Surrogate-based optimization techniques require that the range between bounds is at least \(10^{-6}\). 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, continuous and stepped 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).

Variable Hints

Constant

A constant variable has a fixed value defined by the Value hint. 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 hint 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 or to give some stepped variable a value that does not match any step. This is possible because constant variables ignore bounds, Levels, and Step and do not validate them — so you won’t need to change these settings.

This hint only switches the variable to constant and additionally requires the Value hint, which specifies the fixed value. Note that you can use special input ports to switch a variable to constant and set its value (see Ports and Parameters for details).

Initial guess

This hint specifies an initial guess value (the starting point) for optimization techniques. In particular, if you use the Gradient-based optimization technique, it is highly recommended to set a specific initial guess for all variables. Globalized optimization methods also use this value — for example, as one of the multistart points. Initial guesses are ignored by all techniques except Gradient-based optimization and Surrogate-based optimization, and are always ignored for constant variables (to set the value of a constant, use the Value hint).

There are the following requirements:

• For a continuous or a stepped variable, the initial guess must be within bounds.
• For a stepped variable, the initial guess must also be a valid value according to the step size (see Step).
• For a discrete or categorical variable, the initial guess must be a valid value according to Levels.

Initial guess can be scalar or vector:

• A scalar sets the same initial guess 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 initial guess 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 a special input port to specify the initial guess (see Ports and Parameters for details).

Resolution

An optional hint for a continuous variable, which specifies the minimum significant change of the variable. For example, if the variable is bound to the range \([1000.0, 5000.0]\), its changes less than 1 probably do not change responses noticeably, in which case you can set resolution to 1.0.

In optimization tasks, it is recommended to set Resolution for all continuous variables, as this enables the block to adjust precision of optimization algorithms accordingly and often improves performance. The value of Resolution should be based on the real, practical precision of a design variable. The minimum valid value is \(10^{-8}\). The maximum valid value is \(0.1 \cdot r\), where \(r\) is the range between bounds — although in practice such resolution is too coarse and is not recommended.

Resolution can be scalar or vector:

• A scalar sets the same resolution 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 resolution for each component. The number of vector components must be equal to the variable’s Size.

For syntax examples, see Types of Variables.

This hint is ignored by all types of variables except continuous, and is currently ignored by DoE techniques.

Step

A required hint for a stepped variable, which sets the step size. Note that the step size \(s\) should be relatively small compared to the range between bounds \(r\): the greatest valid step size is \(s_{max} = 0.1 \cdot r\), but in practice it is recommended to use steps with size \(s \le 0.01 \cdot r\). Also, the range between bounds must contain an integer number of steps.

In brief, the requirements for step size \(s\) are:

• \(s \ge 10^{-8}\) — but note that \(s\) is also validated against the bounds range \(r\).
• \(s \ge 10^{-4} \cdot r\), where \(r\) is the range between bounds.
• \(s \le 0.1 \cdot r\) — but note that it is recommended to use \(s \le 0.01 \cdot r\).
• \(s \cdot k = r\), where \(k\) is some integer — the range must be exactly divisible by step.

Step can be scalar or vector:

• A scalar sets the same step 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 step for each component. The number of vector components must be equal to the variable’s Size.

For syntax examples, see Types of Variables.

This hint is ignored by all types of variables except stepped, which is currently supported only in optimization techniques and in Adaptive design.

Value

A required hint for a constant variable (see Constant). Sets the fixed value that is used when the Constant hint is enabled for a variable. If the Constant hint is disabled, the block saves Value in variable settings but ignores it — so you can specify Value once and then use the Constant hint to freeze or unfreeze a variable.

Value may disagree with bounds, levels, and steps, since these settings are ignored for constants. However, Value must agree with the Type property — for example, a StringScalar value is valid only for a categorical constant.

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.

Note that you can use special input ports to switch a variable to constant and set its value (see Ports and Parameters for details).

Adding Variables

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

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. For a continuous variable, the block generates values from the interval specified by their bounds. Some DoE techniques assign levels to continuous variables internally — for example, Full factorial or Orthogonal array design.

The bounds (Lower bound and Upper bound properties) are required for a continuous variable, unless it is constant. The range between bounds must be \(10^{-6}\) or greater. 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 and 2.0 (lower, upper).
  • Use RealVector bounds if required by your workflow: (0.5) and (2.0). 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 and 2.0 in this case are equivalents of (0.5, 0.5, 0.5) and (2.0, 2.0, 2.0).
  • Use a RealVector value to specify different bounds for components: (0.5, 0.1, -0.1) and (2.0, 1.6, 1.4) — note that the number of vector components is equal to Size.

In optimization tasks it is recommended to set an initial guess and resolution for continuous variables, using the optional Initial guess and Resolution hints. Similarly to bounds, values of these hints can be RealScalar or RealVector.

The bounds and the initial guess can be specified in block configuration or sent to special input ports: <variable_name>.Lower bound, <variable_name>.Upper bound, and <variable_name>.Initial guess. These additional ports are disabled by default; see Ports and Parameters for usage. The resolution can be specified in block configuration only.

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, initial guess, and resolution settings are ignored. All new designs generated by the block will contain the fixed value of such variable. Also, the values of this variable contained in the initial sample are not required to be within bounds.

Stepped Variables

Note

Stepped variables are currently supported only in the Adaptive design, Surrogate-based optimization, and Gradient-based optimization techniques.

For a stepped variable, the block generates values adjusted to the regular grid defined by the variable’s bounds and step. For each value \(v_i\), it guarantees that \(v_i = b_l + k \cdot s\), \(b_l \le v_i \le b_u\), where \(b_l\), \(b_u\) are the lower and upper bound, \(s\) is the step size, and \(k\) is some integer. That is, the values of a stepped variable match steps and are placed within bounds.

Stepped variables are intended for the cases where the dependency between a variable and responses is in fact continuous, but the generated designs are required to include only predefined variable values. This makes stepped variables different from discrete variables, which do not imply continuity. A typical example of a stepped variable is a geometry parameter of a part selected from a catalog. For example, the catalog may contain metal plates with thickness 1.0, 1.1, …, 4.9, 5.0 mm, so the thickness variable cannot have an arbitrary value between 1.0 and 5.0. However, plate properties such as mass and strength are continuous functions of the thickness variable: a plate with 2.625 mm thickness can exist, it is just not acceptable in the design. In this example, plate thickness is naturally defined as a stepped variable in \([1.0, 5.0]\) with step size 0.1.

A stepped variable requires bounds (the Lower bound and Upper bound properties) and the Step hint. The range between bounds must be \(10^{-6}\) or greater, same as for a continuous variable. Similarly to a continuous variable, the bounds of a stepped variable can be set using RealScalar or RealVector values (see the syntax examples above in section Continuous Variables).

The step should be relatively small compared to the range between bounds. There are also certain requirements for the step — see the Step hint description for details. The value of the Step hint may be a RealScalar or a RealVector, depending on the variable’s Size. For example:

• If the Size of a variable is 1:
  • Use a RealScalar value: 0.1. A RealVector value with a single component is also acceptable: (0.1).
• If the variable has multiple components, for example, its Size is 3:
  • Use a RealScalar value as a shorthand to set the same step for all components: 0.1 is equivalent to (0.1, 0.1, 0.1).
  • Use a RealVector value to set a specific step for each of the components: (0.1, 0.05, 0.1) — note that the number of vector components is equal to Size.

If you use stepped variables in optimization tasks, it is also recommended to add the Initial guess hint to a stepped variable. Note that the initial guess value for a stepped variable must be valid with regard to its bounds and step — that is, the initial guess must match some step. The Resolution hint is ignored for stepped variables as meaningless.

Similarly to continuous variables, the bound values and the initial guess of a stepped variable can be specified in block configuration or sent to special input ports: <variable_name>.Lower bound, <variable_name>.Upper bound, and <variable_name>.Initial guess. These additional ports are disabled by default; see Ports and Parameters for usage. However, the step can be specified in block configuration only.

If you use an initial sample, the block checks whether the values of a stepped variable contained in the sample are within bounds and whether they match steps. Points of the initial sample, which contain out-of-bound or non-matching values of stepped variables, are considered infeasible and are excluded from the feasible and optimal result matrices (see Initial Samples and Results). Responses in such points are never evaluated, since they violate the stepped variable definition.

If you set a stepped variable to constant, the bounds, initial guess, and step settings are ignored, so effectively the variable is not considered to be stepped. All new designs generated by the block will contain the fixed value of such variable. Also, if a stepped variable is constant, its values in the initial sample are not required to be within bounds and to match steps.

Discrete Variables

A discrete variable is defined by a set of allowed values (levels). This set is specified by the Levels property, which is required for a discrete variable. Levels of a discrete variable may be arbitrary — they are not required to be placed at regular intervals, contrary to a stepped variable.

Discrete type also implies that the dependency between a variable and responses is discontinuous, although the values of a discrete variable can be compared numerically (for being less, greater, or equal). This assumption is important in the optimization and adaptive design techniques, where using discrete variables is not recommended: when possible, prefer to define a variable as stepped with an appropriate step, rather than to define it as discrete with preset levels.

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 enumerates material grades, like ("S235", "S275", "S355"). 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 other settings, but you have to specify the Value hint, and the value 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 may be a scalar or a vector. Constant values are validated with regard to the variable’s Type only. For example:

• If the Size of a constant is 1:
  • Use a RealScalar or an IntScalar value for continuous, stepped, and discrete constant variables: 0.5, 3. In case of a stepped variable, the value may disregard Step (do not match it).
  • 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, stepped, or discrete constant variable: 0.5 is equivalent to (0.5, 0.5, 0.5); 3 is equivalent to (3, 3, 3). Values of a stepped constant variable may disregard its step settings.
  • 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 by sending a True or False value to this port. 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.

The Responses pane showing an example of responses which are characteristics of an I-beam design. 1 The list of responses, their properties and hints. 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 and hints. You can set main properties when adding a response, then edit properties and add hints on the Responses pane. Some properties can be also set using special ports related to a specific response.

Main properties are:

• 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.

Additional properties, set by response hints, are:

• Function type. Additional information about the response used by some techniques.
• No blackbox. Disables blackbox evaluations for the response.
• Value. The contour value for a response which is the target of a function contour restoration study. Ignored by all other response types.

The properties listed above are described in more detail in sections Response Properties and Response Hints further.

Similarly to variables, you can skip 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 hint). 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).

Response Hints

Function type

This hint notifies the block about certain response attributes. Any response, regardless of its Type, can be hinted 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 hint 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.

Important

Responses with different Function type settings must be evaluated by separate blackboxes (different blocks). Note that when you change the Function type setting 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 Function type settings for all responses. See Blackboxes for details.

Due to the behavior noted above, the Function type hint is sometimes useful even if you select a technique that ignores it: in this case, you can arbitrarily select function types for responses simply to distribute their evaluations to different blackboxes.

No blackbox

By default, the block assumes that response evaluations are available from some other block in your workflow (a blackbox). However, you can disable evaluations for a response by adding the No blackbox hint. Note that when you add this hint to a response, the block automatically removes the ports which receive the response values. Consequently, once you apply the block’s configuration, pSeven removes links connected to these ports, if such links exist in the 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).

Value

A specific hint for a function contour restoration study — one of the adaptive design tasks. Specifies the target (contour) value of the response. The value is always RealScalar (cannot be RealVector), since multi-dimensional contour responses are not supported. A contour type response requires this hint, other types ignore it.

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

Adding Responses

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

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 type property in certain cases, determines how the block “explores” the response function and what is the study goal for the response. That is, the block’s task is mostly defined by the response types you select. For example, by combining adaptive, constraint, and minimization response 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 approach for 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 starts sending data to this blackbox only after the generated points are checked for feasibility and optimality (depending on the types of other responses), and sends 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 a two-entity ratio. 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 Exploration budget 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 design 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 hint, which is required for a contour 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 number of times the block can evaluate responses does not exceed the number specified by the Evaluation budget setting. When using the Adaptive design or Surrogate-based optimization technique, this limitation can be removed for certain responses by adding the Function type hint and setting it 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 Evaluation budget specifies.

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

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 create internal models of linear and quadratic responses and use these models instead of evaluating the actual response. To enable this behavior, set the Function type hint of a response to Linear or Quadratic. This feature has several limitations:

• It should be used only when it is known that the response is a linear (quadratic) function of design variables, or when known that a linear (quadratic) model fits it with enough accuracy. Otherwise the internal response model will be very inaccurate, and you will obtain incorrect results.

• If block configuration contains discrete variables, quadratic responses may be modeled only if levels of those variable are placed at regular intervals (are adjusted to a regular grid, for example: (0.0, 0.2, 0.4, 0.6, 0.8, 1.0)). Otherwise, quadratic responses are treated as generic in Gradient-based optimization, and as analytical in Surrogate-based optimization and Adaptive design.

  Note also that discrete variables with levels placed at regular intervals are usually better defined as the stepped variable type; discrete type implies that the dependency between a variable and responses is discontinuous (see Types of Variables for details).

• Models of quadratic responses are trained only if there are less than 10 design variables; in higher dimensions, quadratic responses are treated as generic. In high dimensions, creating an accurate quadratic model requires too many evaluations of the actual response, which defeats the purpose.

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.

Variable editing. 1 A cell in edit mode. 2 The value editor button. 3 Variable hints (double-click to open the hints dialog). 4 The list of variables is filtered by name. 5 The button to clear the filter.

• To quickly edit a property, double-click its value or click the icon which appears when you hover the cell with your mouse cursor.
• While the cell is in edit mode, you can also click the 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.

To add or edit hints, double-click a cell in the Hints column. An additional hints dialog will appear, where you can see the hint details.

The variable hints dialog. 1 The initial guess value is set and saved, but currently unused because the hint is disabled. 2 The step size is set, and the hint is enabled to apply this setting.

To add a hint, specify its value (double-click the cell to edit), then enable the hint with the checkbox on the left. If the hint is disabled (unchecked), its value is stored in block configuration but unused — so you can temporarily disable a hint without removing its value. Note that the block saves the hint settings only when you click OK or Apply in the main configuration dialog. If you click OK in the hints dialog and Cancel in the configuration dialog, the block discards recent changes in the hint settings.

If you need to set the same property for a number of variables or responses, you can apply this change in a few clicks using multi-edit. This feature is supported for the main properties only — hints can be set only individually for each variable, using the hints dialog.

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 icon in the property column header to open the edit dialog. This icon appears when you hover the header with your mouse cursor.

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 icon which appears when you hover the column header. This copies a comma-separated list of names to the clipboard.

The and 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 that 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 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 .

Problem Definition Ports

This group includes the Exploration budget port, the Study target port, and input ports that set properties of variables and responses (the property ports).

The Exploration budget port corresponds to the Exploration budget setting in the block configuration dialog. The Study target port corresponds to the Study target setting in that dialog. These two ports are 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 you to “freeze” a variable from Run, without opening the block configuration dialog.

Samples and Designs

This group includes input ports that accept initial samples (see Initial Samples), and output ports that 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 that 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 that 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 that 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 that 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 that output the index of the current blackbox iteration. Blackboxes can use this index, for example, to generate the names of the files they create.

• Blackbox.Index — the index for a blackbox that 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 it could not evaluate any response. The response matrix may also contain special values denoting failed or skipped evaluations.

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).

An element of the response matrix may be:

• A numeric value of a response evaluated by the blackbox.
• A RealScalar NaN value indicating that a response is impossible to evaluate — for example, the response function is not defined at some input point.
• A RealScalar N/A value indicating that the blackbox skipped a response evaluation, and response function behavior at that point is not known — for example, the blackbox uses an external solver that crashed during evaluation and did not return a result.

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

According to the above, if the blackbox could not evaluate any response, the response matrix should be filled with NaN values. For convenience, the following values are also recognized as indicating a completely failed evaluation:

• An empty matrix.
• A matrix containing a single NaN element.
• A RealScalar NaN value.

Optimization and Adaptive Design techniques can handle missing and NaN response values 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 and api.NA to output missing values. See NaN Output Values for details.

Types of Blackboxes

The output ports created for each variable depend upon response type settings: responses with the Function type hint must be evaluated by separate blackboxes, so separate outputs are created to pass values of variables to different blackboxes, which evaluate responses of different types.

Note

Only a few techniques actually consider the Function type hint when evaluating responses (for example, approximate linear and quadratic functions). However, even if the technique does not support specific handling of different function types, you can still use the Function type hint to perform response evaluations in 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.

An example configuration. Note the responses with function type hints.

This configuration contains three responses with different function types:

• mass is an analytical (fast evaluation) constraint. Related input is Blackbox.mass.
• stress is a generic objective. Generic responses without the Function type hint are considered computationally expensive by default. 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.

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 (expensive 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.

Omitted above is the Blackbox.section.Quadratic output: it is not present because there are no quadratic responses in the 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 from 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 two separate 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. The response part may be omitted: the number of matrix columns should either be equal to the total Size of variables, or be equal to the total Size of variables and responses together. 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 Variables.Initial sample and Responses.Initial sample ports accept initial values of variables and responses as two separate 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. Responses may be omitted — for example, if you do not connect the Responses.Initial sample port, this is interpreted as missing response values. However if you pass the response data to Responses.Initial sample, then Variables.Initial sample is also required — and in this case both matrices must have the same number of rows.

    The Variables.Initial sample and Responses.Initial sample ports can be useful if you need to pass a full initial sample but its input an response parts come from different blocks. If you need to pass an initial sample of variables only, just send it to the Initial sample port.

  • Also you can enable component-wise initial sample ports. Their names follow the <variable name>.Initial sample and <response name>.Initial sample pattern. These ports accept sample matrices, where the number of columns in each matrix is equal to the Size of the respective variable or response. All matrices received to component-wise initial sample ports must have the same number of rows. Any of the response component-wise samples may be omitted.

    Component-wise sample ports can be useful, for example, if you want to omit initial samples only for some of the responses: all <response name>.Initial sample ports are optional, and if any of them is not connected, this is interpreted as missing values for the respective response. However if you pass data to any of the <response name>.Initial sample ports, then all <variable name>.Initial sample ports are also required. Due to this, in certain situations it may be more convenient to use the Variables.Initial sample and Responses.Initial sample ports, and pass a matrix with empty columns to Responses.Initial sample (filled with None values, see further).

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. Note that the column cannot be removed even if it is empty, since this would change the sample matrix shape.

  If you import the initial sample data from a CSV or an Excel file (using the CSVParser or Excel block), empty CSV fields or empty spreadsheet cells are converted to None automatically.

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 Evaluation budget 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 — enable or disable batch response evaluation mode.
• CPU cores limit — the maximum number of parallel threads used by the block.
• Detailed log — output detailed information to the workflow run log.
• Deterministic — configures deterministic generation of randomized designs.
• Error handling behavior — the action to perform if the block encounters an error.
• Include initial sample — include points from the initial sample into the result sample.
• Maximum batch size — the maximum number of points that the block may request to evaluate in a single batch, when running adaptive DoE or optimization technique in batch mode (updated in 6.39).
• Random seed — seed value for randomized generation algorithms.

---

Batch mode

Toggles batch response evaluation mode.

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

Most design space exploration techniques generate new points in batches:

• Space-filling DoE techniques generate the entire sample in one pass.
• Each iteration of the Gradient-based optimization technique requests a batch of evaluations required to estimate response gradients.
• Adaptive DoE techniques (Adaptive design, Adaptive design for GP) and Surrogate-based optimization request batch evaluations when updating internal response models.

If batch mode is enabled, the point batches are output as they are generated by the technique. In that case, the ports used to send values of variables to blackboxes output matrices with several rows, where each row corresponds to a design point, and the matrix represents a batch of variable values. If disabled, the block always outputs points sequentially, and output matrices contain a single row.

In space-filling DoE and Gradient-based optimization, the number of points in batches generated by the technique (the batch size) is uniquely determined by task settings and, in optimization, by the current working stage of the underlying algorithm:

• In DoE, the batch size is equal to the generated DoE size.
• In Gradient-based optimization, the batch size depends on the number of required gradient estimates, which in turn depends on the problem dimension — the number of variables, responses, and their dimension (the Size property).

In the adaptive DoE and Surrogate-based optimization techniques, the batch size also depends on task settings, but can be adjusted when evaluating generic responses, which are considered computationally expensive. By default, those techniques aim to generate batches of minimum possible size when requesting evaluations of generic responses, in order to save computational resources (other response types are considered cheap and may be evaluated in big batches). If the blackbox that evaluates generic responses supports concurrent computations, that default technique behavior may lead to ineffective use of computational resources: often, batch size will not be a multiple of the maximum blackbox concurrency, meaning that the batch evaluations cannot be distributed efficiently and some of the batch processors will remain unused because they have no data to process. In that case, it is recommended to set the Maximum batch size option equal to the maximum blackbox concurrency. If you set that option, the considered techniques will use an alternative version of their algorithms, which aim to generate batches of size being a multiple of the option value — so they can be evenly split into batches of the specified maximum size when output by the block. That switch does not occur automatically when you enable batch mode, because the alternative algorithm implementation differs significantly from the default one, and using it not as intended may lead to performance degradation or reduce quality of results.

Note also that the Maximum batch size option does not set a fixed batch size, as it is not always possible for a technique to select a specific number of points to evaluate. Even if you set that option, the block can still occasionally output a batch containing less points than the maximum size. However the adaptive DoE and Surrogate-based optimization techniques aim to minimize the number of such “uneven” batches in order to maintain efficiency of concurrent evaluations.

If you run the Gradient-based optimization technique and set the Maximum batch size option, the option does not affect the technique behavior, but specifies that you are using a parallel blackbox and adjusts the meaning of the Exploration budget setting accordingly.

Regardless of the Batch mode option, each of the result samples (see Results) is always a single matrix.

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

The maximum number of points that the block may request to evaluate in a single batch, when using one of the adaptive DoE or optimization techniques in batch mode.

Value:integer in range \([2, 512]\), or Auto Default:Auto (allow any size)

Changed in version 6.37: in adaptive DoE and surrogate-based optimization, specifies both the blackbox concurrency (previously specified by the Computational scalability technique option) and the maximum output batch size; in other techniques, this option is now ignored; value range changed, and minimum is 2 (previously allowed 1, which is actually the same as disabling batch mode); added the default Auto value, which allows any batch size (essentially the same as the previous default value of 1000, although less confusing).

Changed in version 6.39: since this option is intended for configuring the block with blackboxes that provide real concurrent evaluations, the Exploration budget setting in batch mode is now interpreted with regard to the blackbox concurrency set by this option: if you specify Maximum batch size, then Exploration budget limits the total number of batches output for evaluation — that is, it limits the number of the blackbox block startups, rather than the total number of response evaluations performed by the blackbox.

Changed in version 6.39: the Gradient-based optimization technique no longer ignores this option.

This option is intended to configure the block for more efficient usage of blackboxes that provide real concurrent evaluations, and should be left default if your blackbox does not support parallelization. It sets an upper limit for the size of a point batch output by the block for evaluations, alters the Exploration budget setting, and adjusts behavior of the adaptive design and Surrogate-based optimization techniques. Option value should be equal to the maximum blackbox concurrency — see the Batch mode option description for additional details.

When you set Maximum batch size to some non-default value \(p\), Exploration budget becomes the limit for the total number of point batches output by the block for evaluation, where each batch contains up to \(p\) points to evaluate. That is, Exploration budget limits the number of batch evaluation requests the block can send to the blackbox — rather than the total number of points in those requests.

In Gradient-based optimization, specifying the Maximum batch size option only affects the meaning of the Exploration budget setting as described above, and does not change the optimization algorithm behavior.

In the adaptive DoE and Surrogate-based optimization techniques, this option also adjusts the technoque behavior so that the batch it generates can be evenly split into output batches of the maximum size. This adjustment is done only in point batches that request generic (computationally expensive) response evaluation; batches requesting evaluation of other response types (computationally cheap) may have any size. Note that specifying the Maximum batch size option does not set a fixed batch size, as it is not always possible for a technique to select a specific number of points to evaluate. Even if you set this option, the block can still occasionally output a batch containing less points than the maximum size. However the adaptive DoE and Surrogate-based optimization techniques aim to minimize the number of such “uneven” batches in order to maintain efficiency of concurrent evaluations.

The Maximum batch size option changes the block and technique behavior significantly, and should be set only if your blackbox block provides real concurrency — that is, it can process up to a specific number of evaluations synchronously, and each evaluation is done by an independent processing unit with dedicated resources. Otherwise the technique performance may suffer, or result quality degradation may occur. If your blackbox accepts batches but processes them sequentially, enable the Batch mode option, keep Maximum batch size default (Auto) and implement a blackbox that can sequentially process a batch of any size.

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 and 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:

   

   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.