gemseo / core

scenario module

Base class for all Scenarios

class gemseo.core.scenario.Scenario(disciplines, formulation, objective_name, design_space, name=None, **formulation_options)[source]

Bases: gemseo.core.discipline.MDODiscipline

Base class for MDO and DOE scenarios.

Multidisciplinary Design Optimization Scenario, main user interface Creates an optimization problem and solves it with a driver

MDO Problem description: links the disciplines and the formulation to create an optimization problem. Use the class by instantiation. Create your disciplines beforehand.

Specify the formulation by giving the class name such as the string “MDF”

The reference_input_data is the typical input data dict that is provided to the run method of the disciplines

Specify the objective function name, which must be an output of a discipline of the scenario, with the “objective_name” attribute

If you want to add additional design constraints, use the add_constraint method

To view the results, use the “post_process” method after execution. You can view:

  • The design variables history, the objective value, the constraints, by using: scenario.post_process(“OptHistoryView”, show=False, save=True)

  • Quadratic approximations of the functions close to the optimum, when using gradient based algorithms, by using: scenario.post_process(“QuadApprox”, method=”SR1”, show=False, save=True, function=”my_objective_name”, file_path=”appl_dir”)

  • Self Organizing Maps of the design space, by using: scenario.post_process(“SOM”, save=True, file_path=”appl_dir”)

To list post processings on your setup, use the method scenario.posts For more detains on their options, go to the “gemseo.post” package

Constructor, initializes the MDO scenario Objects instantiation and checks are made before run intentionally

Parameters
  • disciplines – the disciplines of the scenario

  • formulation – the formulation name, the class name of the formulation in gemseo.formulations

  • objective_name – the objective function name

  • design_space – the design space

  • name – scenario name

  • formulation_options – options for creation of the formulation

ALGO = 'algo'
ALGO_OPTIONS = 'algo_options'
L_BOUNDS = 'l_bounds'
U_BOUNDS = 'u_bounds'
X_0 = 'x_0'
add_constraint(output_name, constraint_type='eq', constraint_name=None, value=None, positive=False)[source]

Add a user constraint, i.e. a design constraint in addition to formulation specific constraints such as targets in IDF. The strategy of repartition of constraints is defined in the formulation class.

Parameters
  • output_name – the output name to be used as constraint for instance, if g_1 is given and constraint_type=”eq”, g_1=0 will be added as constraint to the optimizer If a list is given, a single discipline must provide all outputs

  • constraint_type – the type of constraint, “eq” for equality, “ineq” for inequality constraint (Default value = MDOFunction.TYPE_EQ)

  • constraint_name – name of the constraint to be stored, if None, generated from the output name (Default value = None)

  • value – Default value = None)

  • positive – Default value = False)

Returns

the constraint function as an MDOFunction

property design_space

Proxy for formulation.design_space

Returns

the design space

get_available_driver_names()[source]

Returns the list of available drivers

get_disciplines_statuses()[source]

Retrieves the disciplines statuses

Returns

the statuses dict, key: discipline name, value: status

get_expected_dataflow()[source]

Overriden method from MDODiscipline base class delegated to formulation object

get_expected_workflow()[source]

Overriden method from MDODiscipline base class delegated to formulation object

get_optim_variables_names()[source]

A convenience function to access formulation design variables names

Returns

the decision variables of the scenario

Return type

list(str)

get_optimum()[source]

Return the optimization results

Returns

Optimal solution found by the scenario if executed, None otherwise

Return type

OptimizationResult

static is_scenario()[source]

Retuns True if self is a scenario

Returns

True if self is a scenario

log_me()[source]

Logs a representation of the scenario characteristics logs self.__repr__ message

post_process(post_name, **options)[source]

Finds the appropriate library and executes the post processing on the problem

Parameters
  • post_name – the post processing name

  • options – options for the post method, see its package

property posts

Lists the available post processings

Returns

the list of methods

print_execution_metrics()[source]

Prints total number of executions and cumulated runtime by discipline

save_optimization_history(file_path, file_format='hdf5', append=False)[source]

Saves the optimization history of the scenario to a file

Parameters
  • file_path – The path to the file to save the history

  • file_format – The format of the file, either “hdf5” or “ggobi” (Default value = “hdf5”)

  • append – if True, data is appended to the file if not empty (Default value = False)

set_differentiation_method(method='user', step=1e-06)[source]

Sets the differentiation method for the process

Parameters
  • method – the method to use, either “user”, “finite_differences”, or “complex_step” or “no_derivatives”, which is equivalent to None. (Default value = “user”)

  • step – Default value = 1e-6)

set_optimization_history_backup(file_path, each_new_iter=False, each_store=True, erase=False, pre_load=False, generate_opt_plot=False)[source]

Sets the backup file for the optimization history during the run

Parameters
  • file_path – The path to the file to save the history

  • each_new_iter – if True, callback at every iteration

  • each_store – if True, callback at every call to store() in the database

  • erase – if True, the backup file is erased before the run

  • pre_load – if True, the backup file is loaded before run, useful after a crash

  • generate_opt_plot – generates the optimization history view at backup

xdsmize(monitor=False, outdir='.', print_statuses=False, outfilename='xdsm.html', latex_output=False, open_browser=False, html_output=True, json_output=False)[source]

Creates an xdsm.json file from the current scenario. If monitor is set to True, the xdsm.json file is updated to reflect discipline status update (hence monitor name).

Parameters
  • monitor (bool) – if True, updates the generated file at each discipline status change

  • outdir (str) – the directory where XDSM json file is generated

  • print_statuses (bool) – print the statuses in the console at each update

  • outfilename – file name of the output. THe basename is used and the extension adapted for the HTML / JSON / PDF outputs

  • latex_output (bool) – build .tex, .tikz and .pdf file

  • open_browser – if True, opens the web browser with the XDSM

  • html_output – if True, outputs a self contained HTML file

  • json_output – if True, outputs a JSON file for XDSMjs