Design Study#

This block specifies the actual study that is going to be carried out, e.g., parametric study or optimization. iVABS inherits most of the keywords and layout of Dakota input. Users can find more detailed guide from Dakota’s manual. Here only the differences are explained. The overall layout is shown in Listing 15.

Listing 15 Layout of the study input block#

study:
  method:
    ...
  variables:
    ...
  responses:
    ...
  interface:
    ...

Overall, same as Dakota, specifications are grouped into blocks. The four important ones are method, variables, responses, and interface.

Method#

This blocks specifies the configurations for the study method. The structure is the same as Dakota with the syntax as the only differece. An example is given below comparing the different formats.

For example, to do 10 random sampling in the design space using the LHS method, the input using Dakota format is shown in Listing 16 while the one using iVABS format is shown in Listing 17.

Listing 16 Dakota input for sampling#

method
  sampling
    sampling_type
      lhs
    samples = 10

Listing 17 iVABS input for sampling#

method:
  sampling:
    sample_type:
      lhs:
    samples: 10

Variables#

This block specifies the design variables used in the study. The syntax of this block has the most difference from Dakota. Instead of a hierarchical layout of keywords, iVABS uses a CSV style arrangement of inputs. The general syntax is shown in Listing 18.

Listing 18 Sample input for the variables block#

variables:
  data: |
    dv1, design, continuous, 0:1
    dv2, design, discrete, range, 1:9

All specifications of design variables are placed under the keyword data using the YAML literal block (Scalars). Each row is a design variable entry starting by the name. Specifications for a design variable includes type, domain, space, class, and other arguments. Name, type, and domain are required for every design variable and the rest specifications depend on the choice of domain:

<name>, <type>, <domain>, <args>

Note

<> means a placeholder in this guide. It should be replaced with the actual keyword or argument in your input.

Type can be design or state. Domain can be continuous or discrete.

If domain is continuous, the last argument is the pair of numbers specifying the lower bound (lb) and upper bound (ub):

<name>, design, continous, <lb>:<ub>

If domain is discrete, the next argument specifies the space of the design variable, which can be range or set. If space is range, the last argument needed is the pair of of numbers specifying the lower and upper bounds:

<name>, design, discrete, range, <lb>:<ub>

If space is set, the next argument specifies the class of the design variable, which can be integer, real, or string. Then any number of values can follow class, specifying all options in the set:

<name>, design, discrete, set, <value1>, <value2>, <value3>, ...

Comments are indicated by a starting hash tag (#). Commented lines are ignored by iVABS.

variables:
  data: |
    dv1, design, continuous, 0:1
    # dv2, design, discrete, range, 1:9

Responses#

This block specifies the output needed in a design study, for instance simple responses for parametric studies and objectives and constraints for optimization. Similar to the previous block for design variables, responses are also specified in a tabular list. The general syntax is shown in Listing 19.

Listing 19 Sample input for the responses block#

responses:
  data: |
    response1, objective, min, 0.5
    response2, objective, min, 0.8
    response3, inequality_constraint, 1:1e12

All specifications of responses are placed under the keyword data using the YAML literal block (Scalars). Each row is a response entry starting by the name. Specifications for a response includes type and other arguments. Name and type are required for every response and the rest specifications depend on the choice of type:

<name>, <type>, <args>

Type can be response, objective or inequality_constraint.

If type is response, no more arguments needed:

<name>, response

If type is objective, the rest arguments specify the sense and weight:

<name>, objective, <sense>, <weight>

Sense can be min or max. Weight is a number specifying the weighting factor for the current objective function.

If type is inequality_constraint, the last argument is a pair of numbers specifying the lower bound (lb) and upper bound (ub):

<name>, inequality_constraint, <lb>:<ub>

Comments are indicated by a starting hash tag (#). Commented lines are ignored by iVABS.

responses:
  data: |
    response1, objective, min, 0.5
    # response2, objective, min, 0.8
    response3, inequality_constraint, 1:1e12

Interface#

Since iVABS is mainly integrated using Python, the analysis driver used by Dakota is “fork”. All configurations below this keyword are supported except link_files and copy_files which are used in Linux and Windows, respectively. To simplify the input, a new keyword required_files is used to replace these two.

A typical example of this block is shown in Listing 20

Listing 20 Sample input for the interface block#

interface:
  fork:
    parameters_file: "params.in"
    results_file: "results.out"
    file_save: on
    work_directory:
      directory_tag: on
      directory_save: on
  required_files:
    - "airfoil.dat"
    - "custom/*"
  asynchronous:
    evaluation_concurrency: 4
  failure_capture:
    recover: [-1, -1, -1]

Design Study

Contents

Design Study#

Method#

Variables#

Responses#

Interface#