/**
* Load the NodeInfo window with connection information for an off-diagonal cell.
+ * Within a component, this NodeInfo window will have the title "Jacobian {input} --> {output}."
+ * For true connections between components, the window title is "Connections {source} --> {target}."
* @param {Object} event Reference to the event that triggered the function.
* @param {MatrixCell} cell Reference to the cell that was hovered.
* @param {String} color The color of the title bar.
@@ -8396,7 +8398,8 @@
Toolbar Help
newRow.append('td').html(conn.tgt);
}
- let title = 'Connections';
+ let title = (color == OmStyle.color.declaredPartial) ? "Jacobian" : "Connections";
+
if ( ! (cell.srcObj.isLeaf() || cell.tgtObj.isLeaf()) ) {
title += ` from ${cell.srcObj.path} to ${cell.tgtObj.path}`;
}
diff --git a/TestScenarioAeroStructuralParallel.html b/TestScenarioAeroStructuralParallel.html
index 14fd7a19..1e4b355f 100644
--- a/TestScenarioAeroStructuralParallel.html
+++ b/TestScenarioAeroStructuralParallel.html
@@ -2955,7 +2955,7 @@
-
+
@@ -3255,7 +3255,7 @@
Toolbar Help
@@ -8372,6 +8372,8 @@
Toolbar Help
/**
* Load the NodeInfo window with connection information for an off-diagonal cell.
+ * Within a component, this NodeInfo window will have the title "Jacobian {input} --> {output}."
+ * For true connections between components, the window title is "Connections {source} --> {target}."
* @param {Object} event Reference to the event that triggered the function.
* @param {MatrixCell} cell Reference to the cell that was hovered.
* @param {String} color The color of the title bar.
@@ -8396,7 +8398,8 @@
Toolbar Help
newRow.append('td').html(conn.tgt);
}
- let title = 'Connections';
+ let title = (color == OmStyle.color.declaredPartial) ? "Jacobian" : "Connections";
+
if ( ! (cell.srcObj.isLeaf() || cell.tgtObj.isLeaf()) ) {
title += ` from ${cell.srcObj.path} to ${cell.tgtObj.path}`;
}
diff --git a/TestScenarioAeroStructuralParallelWithGeometry.html b/TestScenarioAeroStructuralParallelWithGeometry.html
index 7ead1830..9add14a1 100644
--- a/TestScenarioAeroStructuralParallelWithGeometry.html
+++ b/TestScenarioAeroStructuralParallelWithGeometry.html
@@ -2955,7 +2955,7 @@
-
+
@@ -3255,7 +3255,7 @@
Toolbar Help
@@ -8372,6 +8372,8 @@
Toolbar Help
/**
* Load the NodeInfo window with connection information for an off-diagonal cell.
+ * Within a component, this NodeInfo window will have the title "Jacobian {input} --> {output}."
+ * For true connections between components, the window title is "Connections {source} --> {target}."
* @param {Object} event Reference to the event that triggered the function.
* @param {MatrixCell} cell Reference to the cell that was hovered.
* @param {String} color The color of the title bar.
@@ -8396,7 +8398,8 @@
Toolbar Help
newRow.append('td').html(conn.tgt);
}
- let title = 'Connections';
+ let title = (color == OmStyle.color.declaredPartial) ? "Jacobian" : "Connections";
+
if ( ! (cell.srcObj.isLeaf() || cell.tgtObj.isLeaf()) ) {
title += ` from ${cell.srcObj.path} to ${cell.tgtObj.path}`;
}
diff --git a/TestScenarioAerodynamic.html b/TestScenarioAerodynamic.html
index c530759c..084dbc47 100644
--- a/TestScenarioAerodynamic.html
+++ b/TestScenarioAerodynamic.html
@@ -2955,7 +2955,7 @@
-
+
@@ -3255,7 +3255,7 @@
Toolbar Help
@@ -8372,6 +8372,8 @@
Toolbar Help
/**
* Load the NodeInfo window with connection information for an off-diagonal cell.
+ * Within a component, this NodeInfo window will have the title "Jacobian {input} --> {output}."
+ * For true connections between components, the window title is "Connections {source} --> {target}."
* @param {Object} event Reference to the event that triggered the function.
* @param {MatrixCell} cell Reference to the cell that was hovered.
* @param {String} color The color of the title bar.
@@ -8396,7 +8398,8 @@
Toolbar Help
newRow.append('td').html(conn.tgt);
}
- let title = 'Connections';
+ let title = (color == OmStyle.color.declaredPartial) ? "Jacobian" : "Connections";
+
if ( ! (cell.srcObj.isLeaf() || cell.tgtObj.isLeaf()) ) {
title += ` from ${cell.srcObj.path} to ${cell.tgtObj.path}`;
}
diff --git a/TestScenarioAerodynamicParallel.html b/TestScenarioAerodynamicParallel.html
index 93a53e87..035aeafe 100644
--- a/TestScenarioAerodynamicParallel.html
+++ b/TestScenarioAerodynamicParallel.html
@@ -2955,7 +2955,7 @@
-
+
@@ -3255,7 +3255,7 @@
Toolbar Help
@@ -8372,6 +8372,8 @@
Toolbar Help
/**
* Load the NodeInfo window with connection information for an off-diagonal cell.
+ * Within a component, this NodeInfo window will have the title "Jacobian {input} --> {output}."
+ * For true connections between components, the window title is "Connections {source} --> {target}."
* @param {Object} event Reference to the event that triggered the function.
* @param {MatrixCell} cell Reference to the cell that was hovered.
* @param {String} color The color of the title bar.
@@ -8396,7 +8398,8 @@
Toolbar Help
newRow.append('td').html(conn.tgt);
}
- let title = 'Connections';
+ let title = (color == OmStyle.color.declaredPartial) ? "Jacobian" : "Connections";
+
if ( ! (cell.srcObj.isLeaf() || cell.tgtObj.isLeaf()) ) {
title += ` from ${cell.srcObj.path} to ${cell.tgtObj.path}`;
}
diff --git a/TestScenarioAerodynamicParallelWithGeometry.html b/TestScenarioAerodynamicParallelWithGeometry.html
index f09497e1..27cb92da 100644
--- a/TestScenarioAerodynamicParallelWithGeometry.html
+++ b/TestScenarioAerodynamicParallelWithGeometry.html
@@ -2955,7 +2955,7 @@
-
+
@@ -3255,7 +3255,7 @@
Toolbar Help
@@ -8372,6 +8372,8 @@
Toolbar Help
/**
* Load the NodeInfo window with connection information for an off-diagonal cell.
+ * Within a component, this NodeInfo window will have the title "Jacobian {input} --> {output}."
+ * For true connections between components, the window title is "Connections {source} --> {target}."
* @param {Object} event Reference to the event that triggered the function.
* @param {MatrixCell} cell Reference to the cell that was hovered.
* @param {String} color The color of the title bar.
@@ -8396,7 +8398,8 @@
Toolbar Help
newRow.append('td').html(conn.tgt);
}
- let title = 'Connections';
+ let title = (color == OmStyle.color.declaredPartial) ? "Jacobian" : "Connections";
+
if ( ! (cell.srcObj.isLeaf() || cell.tgtObj.isLeaf()) ) {
title += ` from ${cell.srcObj.path} to ${cell.tgtObj.path}`;
}
diff --git a/TestScenarioStructural.html b/TestScenarioStructural.html
index 7fc6214f..9dab2cc3 100644
--- a/TestScenarioStructural.html
+++ b/TestScenarioStructural.html
@@ -2955,7 +2955,7 @@
-
+
@@ -3255,7 +3255,7 @@
Toolbar Help
@@ -8372,6 +8372,8 @@
Toolbar Help
/**
* Load the NodeInfo window with connection information for an off-diagonal cell.
+ * Within a component, this NodeInfo window will have the title "Jacobian {input} --> {output}."
+ * For true connections between components, the window title is "Connections {source} --> {target}."
* @param {Object} event Reference to the event that triggered the function.
* @param {MatrixCell} cell Reference to the cell that was hovered.
* @param {String} color The color of the title bar.
@@ -8396,7 +8398,8 @@
Toolbar Help
newRow.append('td').html(conn.tgt);
}
- let title = 'Connections';
+ let title = (color == OmStyle.color.declaredPartial) ? "Jacobian" : "Connections";
+
if ( ! (cell.srcObj.isLeaf() || cell.tgtObj.isLeaf()) ) {
title += ` from ${cell.srcObj.path} to ${cell.tgtObj.path}`;
}
diff --git a/TestScenarioStructuralParallel.html b/TestScenarioStructuralParallel.html
index 79d1944c..9f37bded 100644
--- a/TestScenarioStructuralParallel.html
+++ b/TestScenarioStructuralParallel.html
@@ -2955,7 +2955,7 @@
-
+
@@ -3255,7 +3255,7 @@
Toolbar Help
@@ -8372,6 +8372,8 @@
Toolbar Help
/**
* Load the NodeInfo window with connection information for an off-diagonal cell.
+ * Within a component, this NodeInfo window will have the title "Jacobian {input} --> {output}."
+ * For true connections between components, the window title is "Connections {source} --> {target}."
* @param {Object} event Reference to the event that triggered the function.
* @param {MatrixCell} cell Reference to the cell that was hovered.
* @param {String} color The color of the title bar.
@@ -8396,7 +8398,8 @@
Toolbar Help
newRow.append('td').html(conn.tgt);
}
- let title = 'Connections';
+ let title = (color == OmStyle.color.declaredPartial) ? "Jacobian" : "Connections";
+
if ( ! (cell.srcObj.isLeaf() || cell.tgtObj.isLeaf()) ) {
title += ` from ${cell.srcObj.path} to ${cell.tgtObj.path}`;
}
diff --git a/TestScenarioStructuralParallelWithGeometry.html b/TestScenarioStructuralParallelWithGeometry.html
index e9ff50c3..b16c0f39 100644
--- a/TestScenarioStructuralParallelWithGeometry.html
+++ b/TestScenarioStructuralParallelWithGeometry.html
@@ -2955,7 +2955,7 @@
-
+
@@ -3255,7 +3255,7 @@
Toolbar Help
@@ -8372,6 +8372,8 @@
Toolbar Help
/**
* Load the NodeInfo window with connection information for an off-diagonal cell.
+ * Within a component, this NodeInfo window will have the title "Jacobian {input} --> {output}."
+ * For true connections between components, the window title is "Connections {source} --> {target}."
* @param {Object} event Reference to the event that triggered the function.
* @param {MatrixCell} cell Reference to the cell that was hovered.
* @param {String} color The color of the title bar.
@@ -8396,7 +8398,8 @@
Toolbar Help
newRow.append('td').html(conn.tgt);
}
- let title = 'Connections';
+ let title = (color == OmStyle.color.declaredPartial) ? "Jacobian" : "Connections";
+
if ( ! (cell.srcObj.isLeaf() || cell.tgtObj.isLeaf()) ) {
title += ` from ${cell.srcObj.path} to ${cell.tgtObj.path}`;
}
diff --git a/_images/mphys_logo_no_background.png b/_images/mphys_logo_no_background.png
new file mode 100644
index 00000000..4fbc6a5b
Binary files /dev/null and b/_images/mphys_logo_no_background.png differ
diff --git a/_images/mphys_model_assembly.png b/_images/mphys_model_assembly.png
new file mode 100644
index 00000000..aa2117f8
Binary files /dev/null and b/_images/mphys_model_assembly.png differ
diff --git a/_images/multipoint_example.png b/_images/multipoint_example.png
new file mode 100644
index 00000000..50cd097f
Binary files /dev/null and b/_images/multipoint_example.png differ
diff --git a/_images/scenario_example.png b/_images/scenario_example.png
new file mode 100644
index 00000000..beba9d44
Binary files /dev/null and b/_images/scenario_example.png differ
diff --git a/_modules/index.html b/_modules/index.html
index 0254b299..9c87682b 100644
--- a/_modules/index.html
+++ b/_modules/index.html
@@ -1,19 +1,19 @@
-
+
Overview: module code — MPhys documentation
-
-
-
+
+
+
-
+[docs]
+ definitialize(self,comm):""" Initialize the solver, transfer scheme, etc. This method will be called when the MPI comm is available
@@ -61,7 +65,10 @@
+[docs]
+ defget_mesh_coordinate_subsystem(self,scenario_name=None):""" The subsystem that contains the subsystem that will return the mesh coordinates
@@ -78,7 +85,10 @@
+[docs]
+ defget_coupling_group_subsystem(self,scenario_name=None):""" The subsystem that this builder will add to the CouplingGroup
@@ -95,7 +105,10 @@
+[docs]
+ defget_pre_coupling_subsystem(self,scenario_name=None):""" Method that returns the openmdao subsystem to be added to each scenario before the coupling group
@@ -110,7 +123,10 @@
+[docs]
+ defget_post_coupling_subsystem(self,scenario_name=None):""" Method that returns the openmdao subsystem to be added to each scenario after the coupling group
@@ -125,7 +141,10 @@
+[docs]
+ defget_tagged_indices(self,tags):""" Method that returns grid IDs for a list of body/boundary tags.
@@ -162,73 +187,76 @@
Source code for mphys.builder
grid_ids : list list of grid IDs that correspond to given body/boundary tags """
- raiseNotImplementedError('Function get_tagged_indices has not been implemented in the builder.')
+ raiseNotImplementedError('Function get_tagged_indices has not been implemented in the builder.')
+[docs]
+ defmphys_add_subsystem(self,name,subsystem):""" Adding an mphys subsystem will add the subsystem and then set the group to automatically promote the mphys tagged variables
@@ -55,9 +59,12 @@
+[docs]
+ defconfigure(self):"""
- Promote the mphys-tagged variables of subsystems added by :func:`~MphysGroup.mphys_add_subsystem`
+ Promote the mphys-tagged variables of subsystems added by :func:`~MPhysGroup.mphys_add_subsystem` """self._mphys_promote_coupling_variables()self._mphys_promote_inputs()
@@ -65,6 +72,7 @@
importopenmdao.apiasom
-
defset_coupling_algorithms_in_scenarios(multipoint_group):""" Set the stored linear and nonlinear solver into the coupling group if the
@@ -52,7 +51,9 @@
+[docs]
+classMultipoint(om.Group):""" An extension of the standard OpenMDAO group that adds the :func:`~mphys_add_scenario` method. For sequential evaluations of the MPhys scenarios.
@@ -62,7 +63,9 @@
---------- name : str The name of the scenario
- Scenario: :class:`~mphys.scenario.Scenario`
+ Scenario: :class:`~mphys.Scenario` The scenario object coupling_nonlinear_solver: openmdao.solvers.solver.NonlinearSolver The nonlinear solver to assign to the coupling group primal problem
@@ -82,37 +85,15 @@
[docs]defmphys_connect_scenario_coordinate_source(self,source,scenarios,disciplines):
-"""
- A helper method to aid in connecting mesh coordinate sources to the scenarios
- in this multipoint group.
- The source and target variable names are assumed to be `'x_{discipline}0'`
-
- Parameters
- ----------
- source: openmdao.api.Group or openmdao.api.Component
- The source subsystem for the mesh coordinate variables
- scenarios : str or list[str]
- The names of the scenarios to be the target of the connections
- disciplines : str or list[str]
- The names of the disciplines for the mesh coordinates.
-
- """
- scenarios_list=scenariosiftype(scenarios)==listelse[scenarios]
- disciplines_list=disciplinesiftype(disciplines)==listelse[disciplines]
-
- forscenarioinscenarios_list:
- fordisciplineindisciplines_list:
- src=f'{source}.x_{discipline}0'
- target=f'{scenario}.x_{discipline}0'
- self.connect(src,target)
+[docs]
+classMultipointParallel(om.ParallelGroup):""" An OpenMDAO parallel group that adds the :func:`~mphys_add_scenario` method. For simultaneous evaluations of the MPhys scenarios.
@@ -122,7 +103,9 @@
---------- name : str The name of the scenario
- Scenario: :class:`~mphys.scenario.Scenario`
+ Scenario: :class:`~mphys.Scenario` The scenario object coupling_nonlinear_solver: openmdao.solvers.solver.NonlinearSolver The nonlinear solver to assign to the coupling group primal problem
@@ -142,74 +125,77 @@
fromfunctoolsimportwraps
-from.mphys_groupimportMphysGroup
-from.utils.directory_utilsimportcd
+from.mphys_groupimportMPhysGroup
+frommphys.utils.directory_utilsimportcd
-# Define decorator functions for methods where run directory must be switched before callingdefswitch_run_directory(method):
+"""
+ Decorator function for methods where run directory must be switched before calling
+ """@wraps(method)defwrapped_method(self,*args,**kwargs):withcd(self.options['run_directory']):
@@ -48,7 +50,9 @@
+[docs]
+ definitialize(self):self.options.declare('run_directory',default='',types=str,desc='Path in which to execute subsystems in this scenario group.'+' The default of empty string will not change the directory.')
+
def_mphys_scenario_setup(self):""" This function is where specific scenarios populate pre-coupling, coupling,
@@ -75,7 +82,10 @@
+[docs]
+ @switch_run_directory
+ defsetup(self):""" The main setup call for all multiphysics scenarios. Multiphysics scenarios should implement setup-type operations in _mphys_scenario_setup().
@@ -84,7 +94,10 @@
---------- name: str Name of the discipline
- builder: :class:`~mphys.builder.Builder`
+ builder: :class:`~mphys.Builder` The discipline's builder object scenario_name: str or None Name of the scenario being setup (optional)
@@ -150,7 +164,7 @@
Source code for mphys.scenario
---------- name: str Name of the discipline
- builder: :class:`~mphys.builder.Builder`
+ builder: :class:`~mphys.Builder` The discipline's builder object scenario_name: str or None Name of the scenario being setup (optional)
@@ -173,72 +187,74 @@
+[docs]
+classRemoteComp(om.ExplicitComponent):""" A component used for network communication between top-level OpenMDAO problem and remote problem evaluated on an HPC job. Serves as the
@@ -51,7 +53,9 @@
Source code for mphys.network.remote_component
# shortcut for stopping server from top level
self.server_manager.stop_server()
-
+[docs]
+ definitialize(self):self.options.declare('run_server_filename',default="mphys_server.py",desc="python file that will launch the Server class")self.options.declare('time_estimate_multiplier',default=2.0,desc="when determining whether to reboot the server, estimate model run time as this times max prior run time")self.options.declare('time_estimate_buffer',default=0.0,types=float,desc="constant time in seconds to add to model evaluation esimate. "
@@ -66,7 +70,10 @@
Source code for mphys.network.remote_component
self.options.declare('additional_remote_outputs',default=[],types=list,desc="additional outputs not defined as objective/constraints in the remote component")self.options.declare('use_derivative_coloring',default=False,types=bool,desc="assign derivative coloring to objective/constraints. Only for cases with parallel servers")
+[docs]
+ defsetup(self):ifself.comm.size>1:raiseSystemError('Using Remote Component on more than 1 rank is not supported')self.time_estimate_multiplier=self.options['time_estimate_multiplier']
@@ -104,7 +111,10 @@
+[docs]
+ defcompute_partials(self,inputs,partials):# NOTE: this will not use of and wrt inputs, if given in outer script's compute_totals/check_totalsinput_dict=self._create_input_dict_for_server(inputs)
@@ -122,6 +135,7 @@
+[docs]
+classServer:""" A class that serves as an OpenMDAO model analysis server. Launched by a server run file by the ServerManager and runs on an HPC job,
@@ -325,7 +327,9 @@
+[docs]
+ defrun(self):""" Run the server. """
@@ -386,14 +390,16 @@
Source code for mphys.network.server
self._send_outputs_to_client(output_dict)# write current n2 with values
- om.n2(self.prob,show_browser=False,outfile=f"n2_inner_analysis_{input_dict['component_name']}.html")
+[docs]
+classServerManager:""" A class used by the client-side RemoteComp to facilitate communication with the remote, server-side OpenMDAO problem.
@@ -42,19 +44,27 @@
Source code for mphys.network.server_manager
To make a particular derived class, implement the start_server,
stop_server, and enough_time_is_remaining functions. """
-
+[docs]
+ defenough_time_is_remaining(self,estimated_model_time):""" Check if the current HPC job has enough time remaining to run the next analysis.
@@ -64,14 +74,16 @@
Source code for mphys.network.server_manager
estimated_model_time : float
How much time the new analysis is estimated to take """
- returnTrue
+[docs]
+classRemoteZeroMQComp(RemoteComp):""" A derived RemoteComp class that uses pbs4py for HPC job management and ZeroMQ for network communication. """
-
+[docs]
+ definitialize(self):self.options.declare('pbs',"pbs4py Launcher object")self.options.declare('port',default=5081,desc="port number for server/client communication")self.options.declare('acceptable_port_range',default=[5081,6000],desc="port range to look through if 'port' is currently busy")
@@ -58,6 +62,7 @@
Source code for mphys.network.zmq_pbs
super().initialize()self.server_manager=None# for avoiding reinitialization due to multiple setup calls
+[docs]
+classMPhysZeroMQServerManager(ServerManager):""" A derived ServerManager class that uses pbs4py for HPC job management and ZeroMQ for network communication.
@@ -116,24 +124,33 @@
Source code for mphys.network.zmq_pbs
self.server_counter=0# for saving output of each server to different filesself.start_server()
-
\ No newline at end of file
diff --git a/_sources/basics/builders.rst.txt b/_sources/basics/builders.rst.txt
index f546c563..6dee74db 100644
--- a/_sources/basics/builders.rst.txt
+++ b/_sources/basics/builders.rst.txt
@@ -1,10 +1,10 @@
.. _builders:
-########
+========
Builders
-########
+========
-In large multiphysics problems, creation and connection of the OpenMDAO can be complicated and time-consuming.
+In large multiphysics problems, creation and connection of the OpenMDAO model can be complicated and time-consuming.
The design of MPhys is based on builder classes in order to reduce the burden on the user.
Most of the assembly of the OpenMDAO model with MPhys is handled by a set of builder helper objects.
@@ -13,7 +13,8 @@ Not all builders need to implement all the methods.
For example, a transfer scheme builder may not need a precoupling post coupling subsystem in the scenario.
-.. automodule:: mphys.builder
+.. automodule:: mphys
+ :noindex:
.. autoclass:: Builder
:members:
diff --git a/_sources/basics/model_assembly.rst.txt b/_sources/basics/model_assembly.rst.txt
new file mode 100644
index 00000000..7fb0154a
--- /dev/null
+++ b/_sources/basics/model_assembly.rst.txt
@@ -0,0 +1,79 @@
+.. _model_assembly:
+
+=========================
+Assembling an MPhys Model
+=========================
+
+
+MPhys seeks to automate most of its model assembly process using the builder software design pattern.
+If using a :class:`MultipointParallel ` group,
+skip steps 3-4 as these are handled within the Scenario since each Scenario will have its own MPI communicator.
+
+
+
+.. code-block:: python
+
+ import openmdao.api as om
+ from mphys import Multipoint, MPhysVariables
+ from mphys.scenarios import ScenarioAerodynamic
+
+ from my_aero_code import AeroBuilder
+
+ # Step 1
+ class MyMPhysModel(Multipoint):
+ def setup(self):
+
+ dvs = self.add_subsystem('dvs', om.IndepVarComp())
+ dvs.add_output('aoa', val=0.0, units='deg')
+
+ # Step 2
+ aero_builder = AeroBuilder(mesh="naca0012.ugrid")
+
+ # Step 3
+ aero_builder.initialize(self.comm)
+
+ # Step 4
+ self.add_subsystem("aero_mesh", aero_builder.get_mesh_coordinate_subsystem())
+
+ # Step 5
+ scenario = ScenarioAerodynamic(aero_builder=aero_builder)
+
+ # Step 6
+ self.mphys_add_scenario("cruise", scenario)
+
+ # Step 7
+ self.connect("dvs.aoa", "cruise.aoa")
+ self.connect(MPhysVariables.Aerodynamics.Mesh.COORDINATES,
+ MPhysVariables.Aerodynamics.Surface.COORDINATES)
+
+1. Define an :class:`Multipoint ` group.
+2. In the ``setup()`` method of the Multipoint group, instantiate
+ the :ref:`Builder ` associated with the disciplinary solvers you intend to use.
+3. Initialize the disciplinary Builders with the MPI communicator of the Multipoint group.
+ This should be done in the ``setup()`` method of the Multipoint group after the builder is instantiated.
+ For example, ``aero_builder.initialize(self.comm)``
+4. If applicable to the discipline, add a subsystem for the initial mesh coordinates from the builder's :func:`get_mesh_coordinate_subsystem ` function.
+ This subsystem allows the disciplinary solver to dictate the parallel decomposition of its mesh.
+ Any geometry manipulation subsystems, data transfer scheme subsystems, etc. will then be connected to the mesh subsystem's mesh coordinate output.
+5. Create an MPhys scenario from the :ref:`scenario_library`.
+6. Use :func:`mphys_add_scenario ` to add the scenario to the Multipoint group.
+ Add customized coupled nonlinear and linear solvers to the scenario in this function call.
+7. Connect inputs to the scenarios. Since MPhys uses :ref:`tagged_promotion`,
+ these inputs will have been promoted to ``{scenario_name}.{variable_name}``.
+ Typically the inputs that need to be connected are the design variables of the disciplinary solvers
+ and mesh coordinates (if applicable to the discipline).
+ These mesh coordinates may come from the initial mesh, or be altered by a geometry tool.
+8. Repeat steps 5-7 until your Multipoint group is fully defined.
+
+.. figure:: mphys_model_assembly.png
+ :scale: 50 %
+ :alt: Flow chart of MPhys model assembly
+
+
+--------
+Examples
+--------
+
+
+- The `supersonic panel example `_ provides an example of this model assembly and usage in a self-contained problem (no external disciplinary solvers).
+- The `oas_tacs_wing example `_ is another relatively simple example case that uses open-source disciplinary solvers.
diff --git a/_sources/basics/model_hierarchy.rst.txt b/_sources/basics/model_hierarchy.rst.txt
index 590f85db..4bd500d8 100644
--- a/_sources/basics/model_hierarchy.rst.txt
+++ b/_sources/basics/model_hierarchy.rst.txt
@@ -1,70 +1,83 @@
-***************
+===============
Model Hierarchy
-***************
+===============
-MPhys uses a pattern to build multiphysics optimization problems.
-Each level of the pattern is a different type of group that MPhys provides.
+MPhys uses a hierarchical set of OpenMDAO groups to build multiphysics models.
+Each level of the hierarchy is a different OpenMDAO group that MPhys provides.
The highest level of the model is the multipoint group.
-The multipoint group consist of scenarios which represent different conditions and/or types of multiphysics analyses to performed.
+The multipoint group consists of scenarios which represent different conditions and/or types of multiphysics analyses to be performed.
Within the scenario is the coupling group which represents the primary multiphysics problem for the scenario.
+See :ref:`model_assembly` for guidance on how to create this model hierarchy for a particular problem.
:ref:`builders` are used to help populate these levels of the model hierarchy with subsystems from the solvers.
:ref:`tagged_promotion` is used to promote specific variables to the level of scenario.
.. _coupling_groups:
-===============
+---------------
Coupling Groups
-===============
+---------------
The CouplingGroup is the primary physics coupling being solved.
-That is it contains physics modules, such as an aerodynamic or structural solver,
-and potentially modules that transfer or interpolate between the physics modules, such as a load or displacement transfer schemes.
+That is, it contains physics modules, such as an aerodynamic or structural solver,
+and potentially modules that transfer or interpolate between the physics modules, such as a load or displacement transfer scheme.
Each type of scenario typically has an associated coupling group that it will add automatically given the proper builders.
Within the Scenario group, the coupling group will have the name 'coupling'.
The scenario-specific coupling group will have a default nonlinear and linear solvers,
-but these can be overwritten with the optional arguments to :func:`~mphys.multipoint.Multipoint.mphys_add_scenario`.
+but these can be overwritten with the optional arguments to :func:`~mphys.Multipoint.mphys_add_scenario`.
.. _scenario_groups:
-===============
+---------------
Scenario Groups
-===============
+---------------
The scenario level is an OpenMDAO group that represents a specific condition in a multipoint optimization.
For example, a scenario could be a cruise flight condition that requires a coupling group to determine the lift and drag.
The scenario group contains a coupling group and any scenario-specific computation that needs to occur before or after the associated coupled problem is solved.
-For example, a sonic boom propagator requires the flow solution as an input but this one-way coupling does not require it to be in the coupling group; therefore, it should be put in the scenario group to be solved after the coupling group converges.
+The subsystems before the coupled problem are referred to as 'pre_coupling' subsystems.
+The subsystems after the coupled problem are referred to as 'post_coupling' subsystems.
+An example post_coupling subsystem would be a sonic boom propagation analysis after an aeropropulsive coupling analysis.
+
+
+.. figure:: scenario_example.png
+ :scale: 50 %
+ :alt: Example Scenario
MPhys provides a library of these Scenario groups designed for specific type problems.
See :ref:`scenario_library` for details about specific standardized scenarios.
-If a particular multiphysics problem is not covered by the MPhys library, new scenarios and coupling groups can be created by subclassing the :class:`~mphys.mphys_group.MphysGroup`.
+If a particular multiphysics problem is not covered by the MPhys library, new scenarios and coupling groups can be created by subclassing the :class:`~mphys.MPhysGroup`.
-=================
+-----------------
Multipoint Groups
-=================
+-----------------
There are two versions of the multipoint group:
1. ``Multipoint`` is derived from the standard OpenMDAO ``Group``
2. ``MultipointParallel`` is derived for the OpenMDAO ``ParallelGroup``.
-For both versions have a function, :func:`~mphys.multipoint.Multipoint.mphys_add_scenario`, is used to populate
+For both versions, a function :func:`~mphys.Multipoint.mphys_add_scenario` is used to populate
the lower levels of the model hierarchy.
-----------
+.. figure:: multipoint_example.png
+ :scale: 50 %
+ :alt: Example Multipoint Group
+
+
+^^^^^^^^^^
Multipoint
-----------
+^^^^^^^^^^
The ``Multipoint`` group will sequentially evaluate the scenario groups.
The ``Multipoint`` group can be the top group of the OpenMDAO model or a subsystem.
In the ``setup`` method of the Multipoint group, the following steps must be done:
1. Instantiate the builders
-2. Call :func:`~mphys.builder.Builder.initialize` for each builder with the Multipoint's comm (``self.comm``)
+2. Call :func:`~mphys.core.builder.Builder.initialize` for each builder with the Multipoint's comm (``self.comm``)
3. Add the mesh components and/or other mesh coordinate source like geometry.
4. Add the scenarios
5. Connect the mesh coordinates to the scenarios
@@ -72,15 +85,15 @@ In the ``setup`` method of the Multipoint group, the following steps must be don
Additionally, the Multipoint group can hold the design variables or other inputs and subsystems to be evaluated after the scenarios.
These extra subsystem can then be connected to the scenarios by the user.
-.. automodule:: mphys.multipoint
+.. automodule:: mphys
.. autoclass:: Multipoint
:members:
:exclude-members: configure
-------------------
+^^^^^^^^^^^^^^^^^^
MultipointParallel
-------------------
+^^^^^^^^^^^^^^^^^^
If given a number of MPI ranks greater than or equal to the number of scenarios, the ``MultipointParallel`` group will simultaneously evaluate the scenario groups.
Unlike the sequential Multipoint group, the MPI communicators are different for each scenario in MultipointParallel, so the scenarios will call the builder's initialize method.
diff --git a/_sources/basics/naming_conventions.rst.txt b/_sources/basics/naming_conventions.rst.txt
index c3e5cb1e..4b375695 100644
--- a/_sources/basics/naming_conventions.rst.txt
+++ b/_sources/basics/naming_conventions.rst.txt
@@ -1,48 +1,90 @@
-***************************
+===========================
Variable Naming Conventions
-***************************
+===========================
While it is possible to set up the same OpenMDAO multiphysics problem with different sets of variable names, it is preferable for codes solving the same physics to use the same variable names to be more easily interchangeable.
This table provides the required names for coupling variables associated with a particular physics in MPhys.
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| Variable | Associated Solver | MPhys tag | Variable description |
-+======================+===================+===================+===============================================================================+
-| :code:`x_aero0` | Aerodynamic | mphys_coordinates | Aerodynamic surface coordinates (jig shape) |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`x_aero` | Aerodynamic | mphys_coupling | Aerodynamic surface coordinates (deformed) |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`u_aero` | Aerodynamic | mphys_coupling | Aerodynamic surface displacements |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`f_aero` | Aerodynamic | mphys_coupling | Aerodynamic surface forces |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`T_convect` | Aerodynamic | mphys_coupling | Temperature for convective solver at interface |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`q_convect` | Aerodynamic | mphys_coupling | Convective heat flow at interface |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`x_struct0` | Structural | mphys_coordinates | Structural coordinates (jig shape) |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`u_struct` | Structural | mphys_coupling | Structural state vector (displacements) |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`f_struct` | Structural | mphys_coupling | Structural forces |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`T_conduct` | Thermal | mphys_coupling | Temperature at interface (structural side) |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
-| :code:`q_conduct` | Thermal | mphys_coupling | Conductive heat flow at interface (structural side) |
-+----------------------+-------------------+-------------------+-------------------------------------------------------------------------------+
+The variable naming convention is defined as a Nested Classes with static variables.
+The names are access from the ``MPhysVariables`` class.
+If defining an component that uses the MPhys variable names repeatedly, it is often uses to define a local copy due to the long names that the nested variable classes.
+
+.. code-block:: python
+
+ import openmdao.api as om
+ from mphys import MPhysVariables
+
+ X_AERO0 = MPhysVariables.Aerodynamics.Surface.COORDINATES_INITIAL
+ U_AERO = MPhysVariables.Aerodynamics.Surface.DISPLACEMENTS
+ F_AERO = MPhysVariables.Aerodynamics.Surface.LOADS
+
+ class AeroSolver(om.ImplicitComponent):
+ def setup(self):
+ self.add_input(X_AERO0, shape=5, distributed=True, tags=['mphys_coordinates'])
+ self.add_input(U_AERO0, shape=5, distributed=True, tags=['mphys_coupling'])
+ self.add_output(F_AERO0, shape=3, distributed=True, tags=['mphys_coupling'])
+
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| Code Access | Associated Solver | MPhys tag | Variable description |
++=================================================================+===================+===================+==================================================================+
+| MPhysVariables.Aerodynamics.Surface.Mesh.COORDINATES | Aerodynamic | mphys_coordinates | Aerodynamic surface coordinates from initial mesh file |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.Surface.Geometry.COORDINATES_INPUT | Aerodynamic | mphys_coordinates | Aerodynamic surface coordinates (initial coordinates) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.Surface.Geometry.COORDINATES_OUTPUT | Aerodynamic | mphys_coordinates | Aerodynamic surface coordinates (geometry-deform jig shape) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.Surface.COORDINATES_INITIAL | Aerodynamic | mphys_coordinates | Aerodynamic surface coordinates (jig shape) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.Surface.COORDINATES_DEFORMED | Aerodynamic | mphys_coupling | Aerodynamic surface coordinates (deformed) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.Surface.DISPLACEMENTS | Aerodynamic | mphys_coupling | Aerodynamic surface displacements |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.Surface.LOADS | Aerodynamic | mphys_coupling | Aerodynamic surface forces |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.Surface.TEMPERATURE | Aerodynamic | mphys_coupling | Temperature for convective solver at interface |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.Surface.HEAT_FLOW | Aerodynamic | mphys_coupling | Convective heat flow at interface |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Structures.Mesh.COORDINATES | Structural | mphys_coordinates | Structural coordinates from initial mesh file |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Structures.Geometry.COORDINATES_INPUT | Structural | mphys_coordinates | Structural coordinates (initial coordinates) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Structures.Geometry.COORDINATES_OUTPUT | Structural | mphys_coordinates | Structural coordinates (geometry-deformed jig shape) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Structures.COORDINATES | Structural | mphys_coordinates | Structural coordinates (jig shape) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Structures.DISPLACEMENTS | Structural | mphys_coupling | Structural state vector (displacements) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Structures.LOADS.AERODYNAMIC | Structural | mphys_coupling | Structural forces due to aerodynamics |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Thermal.Mesh.COORDINATES | Thermal | mphys_coupling | Thermal coordinates from initial mesh file |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Thermal.Geometry.COORDINATES_INPUT | Thermal | mphys_coupling | Thermal coordinates (initial coordinates) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Thermal.Geometry.COORDINATES_OUTPUT | Thermal | mphys_coupling | Thermal coordinates (geometry-deformed jig shape) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Thermal.COORDINATES | Thermal | mphys_coupling | Thermal coordinates (jig shape) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Thermal.TEMPERATURE | Thermal | mphys_coupling | Temperature at interface (thermal solver side) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+| MPhysVariables.Thermal.HeatFlow.AERODYNAMIC | Thermal | mphys_coupling | heat flow at interface due to aerodynamics (thermal solver side) |
++-----------------------------------------------------------------+-------------------+-------------------+------------------------------------------------------------------+
+
To make swapping solvers easier, it is also helpful to share noncoupling variable names if possible:
-+----------------------+-------------------+-------------------+---------------------------------------------------------------------------------+
-| Variable | Associated Solver | MPhys tag | Variable description |
-+======================+===================+===================+=================================================================================+
-| :code:`aoa` | Aerodynamic | mphys_input | Angle of attack (please include units='deg' or 'rad' when declared) |
-+----------------------+-------------------+-------------------+---------------------------------------------------------------------------------+
-| :code:`yaw` | Aerodynamic | mphys_input | Yaw angle (please include units='deg' or 'rad' when declared) |
-+----------------------+-------------------+-------------------+---------------------------------------------------------------------------------+
-| :code:`mach` | Aerodynamic | mphys_input | Reference Mach number |
-+----------------------+-------------------+-------------------+---------------------------------------------------------------------------------+
-| :code:`reynolds` | Aerodynamic | mphys_input | Reference Reynolds number |
-+----------------------+-------------------+-------------------+---------------------------------------------------------------------------------+
-| :code:`q_inf` | Aerodynamic | mphys_input | Dynamic pressure |
-+----------------------+-------------------+-------------------+---------------------------------------------------------------------------------+
+
+
++-------------------------------------------------------------+-------------------+-------------+---------------------------------------------------------------------+
+| Variable | Associated Solver | MPhys tag | Variable description |
++=============================================================+===================+=============+=====================================================================+
+| MPhysVariables.Aerodynamics.FlowConditions.ANGLE_OF_ATTACK | Aerodynamic | mphys_input | Angle of attack (please include units='deg' or 'rad' when declared) |
++-------------------------------------------------------------+-------------------+-------------+---------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.FlowConditions.YAW_ANGLE | Aerodynamic | mphys_input | Yaw angle (please include units='deg' or 'rad' when declared) |
++-------------------------------------------------------------+-------------------+-------------+---------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.FlowConditions.MACH_NUMBER | Aerodynamic | mphys_input | Reference Mach number |
++-------------------------------------------------------------+-------------------+-------------+---------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.FlowConditions.REYNOLDS_NUMBER | Aerodynamic | mphys_input | Reference Reynolds number |
++-------------------------------------------------------------+-------------------+-------------+---------------------------------------------------------------------+
+| MPhysVariables.Aerodynamics.FlowConditions.DYNAMIC_PRESSURE | Aerodynamic | mphys_input | Dynamic pressure |
++-------------------------------------------------------------+-------------------+-------------+---------------------------------------------------------------------+
diff --git a/_sources/basics/remote_components.rst.txt b/_sources/basics/remote_components.rst.txt
index 1b2ba290..401baf1d 100644
--- a/_sources/basics/remote_components.rst.txt
+++ b/_sources/basics/remote_components.rst.txt
@@ -1,8 +1,8 @@
.. _remote_components:
-*****************
+=================
Remote Components
-*****************
+=================
The purpose of remote components is to provide a means of adding a remote physics analysis to a local OpenMDAO problem.
One situation in which this may be desirable is when the time to carry out a full optimization exceeds an HPC job time limit.
@@ -27,15 +27,17 @@ Currently, there is one derived class for each, which use pbs4py for HPC job con
* :class:`~mphys.network.zmq_pbs.MPhysZeroMQServerManager`: Uses ZeroMQ socket and ssh port forwarding from login to compute node to communicate with server, and pbs4py to start, stop, and check status of HPC jobs.
* :class:`~mphys.network.zmq_pbs.MPhysZeroMQServer`: Uses ZeroMQ socket to send and receive encoded JSON dictionaries.
+------------------------
RemoteZeroMQComp Options
-========================
+------------------------
.. embed-options::
mphys.network.zmq_pbs
RemoteZeroMQComp
options
+-----
Usage
-=====
+-----
When adding a :code:`RemoteZeroMQComp` component, the two required options are :code:`run_server_filename`, which is the server to be launched on an HPC job, and :code:`pbs`, which is the pbs4py Launcher object.
The server file should accept port number as an argument to facilitate communication with the client.
Within this file, the :code:`MPhysZeroMQServer` class's :code:`get_om_group_function_pointer` option is the pointer to the OpenMDAO Group or Multipoint class to be evaluated.
@@ -48,8 +50,9 @@ Searching for the keyword "SERVER" will display what the server is currently doi
The HPC job for the component's server is named :code:`MPhys`; the pbs4py-generated job submission script is the same followed by ".pbs".
Note that running the remote component in parallel is not supported, and a SystemError will be triggered otherwise.
+-------
Example
-=======
+-------
Two examples are provided for the `supersonic panel aerostructural case `_: :code:`as_opt_remote_serial.py` and :code:`as_opt_remote_parallel.py`.
Both run the optimization problem defined in :code:`as_opt_parallel.py`, which contains a :code:`MultipointParallel` class and thus evaluates two aerostructural scenarios in parallel.
The serial remote example runs this group on one server.
@@ -60,8 +63,9 @@ In this particular case, scenario name(s) are sent as :code:`additional_server_a
Using the scenario :code:`run_directory` option, the scenarios can then be evaluated in different directories.
In both examples, the remote component(s) use a :code:`K4` pbs4py Launcher object, which will launch, monitor, and stop jobs using the K4 queue of the NASA K-cluster.
+---------------
Troubleshooting
-===============
+---------------
The :code:`dump_json` option for :code:`RemoteZeroMQComp` will make the component write input and output JSON files, which contain all data sent to and received from the server.
An exception is the :code:`wall_time` entry (given in seconds) in the output JSON file, which is added on the client-side after the server has completed the design evaluation.
Another entry that is only provided for informational purposes is :code:`design_counter`, which keeps track of how many different designs have been evaluated on the current server.
diff --git a/_sources/basics/tagged_promotion.rst.txt b/_sources/basics/tagged_promotion.rst.txt
index 65ec589d..e2af70a6 100644
--- a/_sources/basics/tagged_promotion.rst.txt
+++ b/_sources/basics/tagged_promotion.rst.txt
@@ -1,8 +1,8 @@
.. _tagged_promotion:
-****************
+================
Tagged Promotion
-****************
+================
MPhys uses tags to selectively promote variables to the level of scenario.
There are four types of tags in MPhys that represent different types of data.
diff --git a/_sources/developers/mphys_group.rst.txt b/_sources/developers/mphys_group.rst.txt
index 54d7dd75..5dc1c9a9 100644
--- a/_sources/developers/mphys_group.rst.txt
+++ b/_sources/developers/mphys_group.rst.txt
@@ -1,29 +1,30 @@
-**************
-The MphysGroup
-**************
+==============
+The MPhysGroup
+==============
-The purpose of the MphysGroup is to implement the mechananics of promoting the MPhys variables by tags.
-Subsystems with tagged variables that will be promoted are added with the :func:`~mphys.mphys_group.MphysGroup.mphys_add_subsystem` method.
+The purpose of the MPhysGroup is to implement the mechanics of promoting the MPhys variables by tags.
+Subsystems with tagged variables that will be promoted are added with the :func:`~mphys.MPhysGroup.mphys_add_subsystem` method.
Subsystems that have variables that should not be promoted can still be added with ``add_subsystem``
The automated promotion of tagged variables is done during the configure phase of OpenMDAO setup.
If you need to use ``configure`` in your CouplingGroup or Scenario group, be sure to call the parent's configure with
``super().configure()``.
-The :class:`~mphys.mphys_group.MphysGroup` is the base class of the :ref:`dev_coupling_group` and :ref:`dev_scenario_group`.
-While it is important to understand the MphysGroup's :func:`~mphys.mphys_group.MphysGroup.configure` and :func:`~mphys.mphys_group.MphysGroup.mphys_add_subsystem` interactions,
-any new scenario or coupling group should inherit from :class:`~mphys.scenario.Scenario` and :class:`~mphys.coupling_group.CouplingGroup`.
-rather than subclassing MphysGroup directly.
+The :class:`~mphys.MPhysGroup` is the base class of the :ref:`dev_coupling_group` and :ref:`dev_scenario_group`.
+While it is important to understand the MPhysGroup's :func:`~mphys.MPhysGroup.configure` and :func:`~mphys.MPhysGroup.mphys_add_subsystem` interactions,
+any new scenario or coupling group should inherit from :class:`~mphys.Scenario` and :class:`~mphys.CouplingGroup`.
+rather than subclassing MPhysGroup directly.
-.. automodule:: mphys.mphys_group
+.. automodule:: mphys
+ :noindex:
-.. autoclass:: MphysGroup
+.. autoclass:: MPhysGroup
:members:
-==============================
+------------------------------
Manual Connection of Variables
-==============================
+------------------------------
In some instances, the use of automated promotion is not appropriate.
-Because the MphysGroup inherits from the standard OpenMDAO group,
+Because the MPhysGroup inherits from the standard OpenMDAO group,
subsystems can be added with the standard ``add_subsystem`` method and connected manually.
diff --git a/_sources/developers/new_multiphysics_problems.rst.txt b/_sources/developers/new_multiphysics_problems.rst.txt
index e02f4eff..6f7d6078 100644
--- a/_sources/developers/new_multiphysics_problems.rst.txt
+++ b/_sources/developers/new_multiphysics_problems.rst.txt
@@ -1,56 +1,58 @@
-******************************
+==============================
Extending the Scenario Library
-******************************
+==============================
.. _dev_coupling_group:
-===============
+---------------
Coupling Groups
-===============
+---------------
In ``initialize``, the coupling group needs to have the required builders declared as options.
-In the setup phase, :func:`~mphys.builder.Builder.get_coupling_group_subsystem` is used to get subsystems from the builders,
+In the setup phase, :func:`~mphys.Builder.get_coupling_group_subsystem` is used to get subsystems from the builders,
and ``self.mphys_add_subsystem`` is used to add them.
Other components like balance components can be added directly.
Setting a default linear and nonlinear solver suitable for this type of problem is also helpful in ``setup``.
In most cases using a configure phase is not necessary for the scenario, but if you do implement a ``configure``
method, you must call ``super().configure()`` to do the tagged promotion of variables from the scenario's subsystems.
-.. automodule:: mphys.coupling_group
+.. automodule:: mphys
+ :noindex:
.. autoclass:: CouplingGroup
:members:
.. _dev_scenario_group:
-=========
+---------
Scenarios
-=========
+---------
Your custom Scenario should at least implement the ``initialize`` and ``setup`` methods.
As with the ``CouplingGroup``, you must call the ``configure`` method of the parent class if you implement a
``configure`` method in the Scenario.
-----------
+^^^^^^^^^^
Initialize
-----------
+^^^^^^^^^^
The Scenario's ``initialize`` method should declare the necessary builders as options.
An ``in_MultipointParallel`` option should also be included if that mode of operation will be implemented.
Otherwise the developer is free to add options specific to the scenario type.
------
+^^^^^
Setup
------
+^^^^^
The basic pattern for the scenario group's setup method is:
0. If ``in_MultipointParallel``, initialize all the builders
-1. Call :func:`~mphys.scenario.Scenario.mphys_add_pre_coupling_subsystem` for each builder.
+1. Call :func:`~mphys.Scenario.mphys_add_pre_coupling_subsystem` for each builder.
2. Instantiate the associated :class:`~mphys.coupling_group.CouplingGroup`.
-3. Call :func:`~mphys.scenario.Scenario.mphys_add_post_coupling_subsystem` for each builder.
+3. Call :func:`~mphys.Scenario.mphys_add_post_coupling_subsystem` for each builder.
-.. automodule:: mphys.scenario
+.. automodule:: mphys
+ :noindex:
.. autoclass:: Scenario
:members:
diff --git a/_sources/index.rst.txt b/_sources/index.rst.txt
index 64570468..a84f899f 100644
--- a/_sources/index.rst.txt
+++ b/_sources/index.rst.txt
@@ -1,3 +1,6 @@
+.. image:: logo/mphys_logo_no_background.png
+ :scale: 15 %
+
%%%%%%%%%%%%%%%%%%%%%%%
Documentation for MPhys
%%%%%%%%%%%%%%%%%%%%%%%
@@ -10,6 +13,7 @@ However, by following the MPhys conventions, the usage of OpenMDAO for multiphys
This eases technology transfer and collaboration in this area of research.
The standardization strives for modularity of multiphysics problems with large parallel physics codes.
+************
MPhys Basics
************
@@ -22,6 +26,7 @@ These are descriptions of how MPhys works and how it interfaces with solvers and
basics/model_hierarchy.rst
basics/tagged_promotion.rst
basics/builders.rst
+ basics/model_assembly.rst
basics/naming_conventions.rst
basics/remote_components.rst
diff --git a/_sources/scenarios/aerodynamic.rst.txt b/_sources/scenarios/aerodynamic.rst.txt
index 1c5d2005..b20f827f 100644
--- a/_sources/scenarios/aerodynamic.rst.txt
+++ b/_sources/scenarios/aerodynamic.rst.txt
@@ -1,36 +1,41 @@
-%%%%%%%%%%%%%%%%%%%%
+====================
Aerodynamic Scenario
-%%%%%%%%%%%%%%%%%%%%
-The :class:`ScenarioAerodynamic` is for scenarios that only need the aerodynamic solver.
+====================
+The :class:`ScenarioAerodynamic` is for scenarios that only need the aerodynamic solver.
+---------------
Default Solvers
-===============
+---------------
The default solvers are NonlinearRunOnce and LinearRunOnce that execute the pre coupling, coupling, and post coupling subsystems in order.
+-------
Options
-=======
+-------
.. embed-options::
- mphys.scenario_aerodynamic
+ mphys.scenarios.aerodynamic
ScenarioAerodynamic
options
+--------
N2:Basic
-========
+--------
.. embed-pregen-n2::
../tests/unit_tests/n2/TestScenarioAerodynamic.html
+-------------------------
N2: in_MultipointParallel
-=========================
+-------------------------
.. embed-pregen-n2::
../tests/unit_tests/n2/TestScenarioAerodynamicParallel.html
+-----------------------------------------------
N2: in_MultipointParallel with geometry_builder
-===============================================
+-----------------------------------------------
.. embed-pregen-n2::
../tests/unit_tests/n2/TestScenarioAerodynamicParallelWithGeometry.html
diff --git a/_sources/scenarios/aerostructural.rst.txt b/_sources/scenarios/aerostructural.rst.txt
index fa58268d..581fda2a 100644
--- a/_sources/scenarios/aerostructural.rst.txt
+++ b/_sources/scenarios/aerostructural.rst.txt
@@ -1,54 +1,64 @@
-%%%%%%%%%%%%%%%%%%%%%%%
+=======================
Aerostructural Scenario
-%%%%%%%%%%%%%%%%%%%%%%%
+=======================
-The :class:`ScenarioAeroStructural` is for static fluid structure interaction problems.
+The :class:`ScenarioAeroStructural` is for static fluid structure interaction problems.
The primary physics modules required for this problem are:
+
1. The aerodynamics which computes forces given the displaced aerodynamic surface coordinates.
2. The structures which computes structural displacements given the loads at structural nodes.
3. The displacement transfer which projects the structural displacements to the aerodynamic surface mesh
4. The load transfer which computes the loads on the structure from the aerodynamic output.
-MPhys will add a :class:`~mphy.geo_disp.GeoDisp` subsystem to compute the displaced aerodynamic coordinates given the undeformed surface coordinates and the displacements.
+MPhys will add a :class:`~mphys.scenarios.geo_disp.GeoDisp` subsystem to compute the displaced aerodynamic coordinates given the undeformed surface coordinates and the displacements.
+
+--------------------
Builder Requirements
-====================
+--------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Load and Displacement Transfer Builder
---------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Because the load and displacement transfers are typically tied together by the principle of virtual work, but are not adjacent in the coupling loop,
-the load and displacement Builder's :meth:`~Builder.get_coupling_group_subsystem` must return both the displacement transfer and load tranfer subsystems as a tuple.
+the load and displacement Builder's :func:`get_coupling_group_subsystem() ` function must return both the displacement transfer and load transfer subsystems as a tuple.
+^^^^^^^^^^^^^^^^^^^^^^^^^
Structural Solver Builder
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
The structural solver builder must implement the ``get_ndof`` method in order for the displacement transfer to know if it needs to slice the displacements from the full structural state vector.
For example, the structural state vector for linear shell elements includes linearized rotation degrees of freedom at each node in addition to the translational displacements.
+^^^^^^^^^^^^^^^
Default Solvers
-===============
+^^^^^^^^^^^^^^^
The default solvers are NonlinearBlockGS and LinearBlockGS with ``use_aitken=True``.
+^^^^^^^
Options
-=======
+^^^^^^^
.. embed-options::
- mphys.scenario_aerostructural
+ mphys.scenarios.aerostructural
ScenarioAeroStructural
options
+^^^^^^^^^
N2: Basic
-=========
+^^^^^^^^^
.. embed-pregen-n2::
../tests/unit_tests/n2/TestScenarioAeroStructural.html
+^^^^^^^^^^^^^^^^^^^^^^^^^
N2: in_MultipointParallel
-=========================
+^^^^^^^^^^^^^^^^^^^^^^^^^
.. embed-pregen-n2::
../tests/unit_tests/n2/TestScenarioAeroStructuralParallel.html
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
N2: in_MultipointParallel with geometry_builder
-===============================================
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. embed-pregen-n2::
../tests/unit_tests/n2/TestScenarioAeroStructuralParallelWithGeometry.html
diff --git a/_sources/scenarios/structural.rst.txt b/_sources/scenarios/structural.rst.txt
index 99b7d288..6eafb929 100644
--- a/_sources/scenarios/structural.rst.txt
+++ b/_sources/scenarios/structural.rst.txt
@@ -1,38 +1,43 @@
-%%%%%%%%%%%%%%%%%%%
+===================
Structural Scenario
-%%%%%%%%%%%%%%%%%%%
+===================
-The :class:`ScenarioStructural` is for scenarios that only need the structural solver.
+The :class:`ScenarioStructural` is for scenarios that only need the structural solver.
An examples use case for this scenario would be a stress constraint from a static load generated by the structural solver subsystem(s).
+---------------
Default Solvers
-===============
+---------------
The default solvers are NonlinearRunOnce and LinearRunOnce that execute the pre coupling, coupling, and post coupling subsystems in order.
+-------
Options
-=======
+-------
.. embed-options::
- mphys.scenario_structural
+ mphys.scenarios.structural
ScenarioStructural
options
+--------
N2:Basic
-========
+--------
.. embed-pregen-n2::
../tests/unit_tests/n2/TestScenarioStructural.html
+-------------------------
N2: in_MultipointParallel
-=========================
+-------------------------
.. embed-pregen-n2::
../tests/unit_tests/n2/TestScenarioStructuralParallel.html
+-----------------------------------------------
N2: in_MultipointParallel with geometry_builder
-===============================================
+-----------------------------------------------
.. embed-pregen-n2::
../tests/unit_tests/n2/TestScenarioStructuralParallelWithGeometry.html
diff --git a/_static/basic.css b/_static/basic.css
index cfc60b86..f316efcb 100644
--- a/_static/basic.css
+++ b/_static/basic.css
@@ -4,7 +4,7 @@
*
* Sphinx stylesheet -- basic theme.
*
- * :copyright: Copyright 2007-2023 by the Sphinx team, see AUTHORS.
+ * :copyright: Copyright 2007-2024 by the Sphinx team, see AUTHORS.
* :license: BSD, see LICENSE for details.
*
*/
@@ -237,6 +237,10 @@ a.headerlink {
visibility: hidden;
}
+a:visited {
+ color: #551A8B;
+}
+
h1:hover > a.headerlink,
h2:hover > a.headerlink,
h3:hover > a.headerlink,
diff --git a/_static/doctools.js b/_static/doctools.js
index d06a71d7..4d67807d 100644
--- a/_static/doctools.js
+++ b/_static/doctools.js
@@ -4,7 +4,7 @@
*
* Base JavaScript utilities for all Sphinx HTML documentation.
*
- * :copyright: Copyright 2007-2023 by the Sphinx team, see AUTHORS.
+ * :copyright: Copyright 2007-2024 by the Sphinx team, see AUTHORS.
* :license: BSD, see LICENSE for details.
*
*/
diff --git a/_static/documentation_options.js b/_static/documentation_options.js
index b57ae3b8..7e4c114f 100644
--- a/_static/documentation_options.js
+++ b/_static/documentation_options.js
@@ -1,5 +1,4 @@
-var DOCUMENTATION_OPTIONS = {
- URL_ROOT: document.getElementById("documentation_options").getAttribute('data-url_root'),
+const DOCUMENTATION_OPTIONS = {
VERSION: '',
LANGUAGE: 'en',
COLLAPSE_INDEX: false,
diff --git a/_static/language_data.js b/_static/language_data.js
index 250f5665..367b8ed8 100644
--- a/_static/language_data.js
+++ b/_static/language_data.js
@@ -5,7 +5,7 @@
* This script contains the language-specific data used by searchtools.js,
* namely the list of stopwords, stemmer, scorer and splitter.
*
- * :copyright: Copyright 2007-2023 by the Sphinx team, see AUTHORS.
+ * :copyright: Copyright 2007-2024 by the Sphinx team, see AUTHORS.
* :license: BSD, see LICENSE for details.
*
*/
@@ -13,7 +13,7 @@
var stopwords = ["a", "and", "are", "as", "at", "be", "but", "by", "for", "if", "in", "into", "is", "it", "near", "no", "not", "of", "on", "or", "such", "that", "the", "their", "then", "there", "these", "they", "this", "to", "was", "will", "with"];
-/* Non-minified version is copied as a separate JS file, is available */
+/* Non-minified version is copied as a separate JS file, if available */
/**
* Porter Stemmer
diff --git a/_static/sphinx_highlight.js b/_static/sphinx_highlight.js
index aae669d7..8a96c69a 100644
--- a/_static/sphinx_highlight.js
+++ b/_static/sphinx_highlight.js
@@ -29,14 +29,19 @@ const _highlight = (node, addItems, text, className) => {
}
span.appendChild(document.createTextNode(val.substr(pos, text.length)));
+ const rest = document.createTextNode(val.substr(pos + text.length));
parent.insertBefore(
span,
parent.insertBefore(
- document.createTextNode(val.substr(pos + text.length)),
+ rest,
node.nextSibling
)
);
node.nodeValue = val.substr(0, pos);
+ /* There may be more occurrences of search term in this node. So call this
+ * function recursively on the remaining fragment.
+ */
+ _highlight(rest, addItems, text, className);
if (isInSVG) {
const rect = document.createElementNS(
@@ -140,5 +145,10 @@ const SphinxHighlight = {
},
};
-_ready(SphinxHighlight.highlightSearchWords);
-_ready(SphinxHighlight.initEscapeListener);
+_ready(() => {
+ /* Do not call highlightSearchWords() when we are on the search page.
+ * It will highlight words from the *previous* search query.
+ */
+ if (typeof Search === "undefined") SphinxHighlight.highlightSearchWords();
+ SphinxHighlight.initEscapeListener();
+});
diff --git a/_static/sphinxdoc.css b/_static/sphinxdoc.css
index 3dadf44f..b03830b4 100644
--- a/_static/sphinxdoc.css
+++ b/_static/sphinxdoc.css
@@ -5,7 +5,7 @@
* Sphinx stylesheet -- sphinxdoc theme. Originally created by
* Armin Ronacher for Werkzeug.
*
- * :copyright: Copyright 2007-2023 by the Sphinx team, see AUTHORS.
+ * :copyright: Copyright 2007-2024 by the Sphinx team, see AUTHORS.
* :license: BSD, see LICENSE for details.
*
*/
@@ -151,6 +151,10 @@ a:hover {
color: #2491CF;
}
+a:visited {
+ color: #551A8B;
+}
+
div.body a {
text-decoration: underline;
}
diff --git a/basics/builders.html b/basics/builders.html
index 3d33e6c6..28d27866 100644
--- a/basics/builders.html
+++ b/basics/builders.html
@@ -1,22 +1,22 @@
-
+
-
+
Builders — MPhys documentation
-
-
-
+
+
+
-
+
-
In large multiphysics problems, creation and connection of the OpenMDAO model can be complicated and time-consuming.
The design of MPhys is based on builder classes in order to reduce the burden on the user.
Most of the assembly of the OpenMDAO model with MPhys is handled by a set of builder helper objects.
Developers wishing to integrate their code to MPhys should subclass the builder and implement the methods relevant to their code.
Not all builders need to implement all the methods.
For example, a transfer scheme builder may not need a precoupling post coupling subsystem in the scenario.
MPHYS builder base class. Template for developers to create their builders.
Because the MPI communicator that will be used inside the OpenMDAO
problem is not known when the builder is instantiated. The actual
solver, transfer scheme, etc. should not be instantiated in the
constructor.
MPhys seeks to automate most of its model assembly process using the builder software design pattern.
+If using a MultipointParallel group,
+skip steps 3-4 as these are handled within the Scenario since each Scenario will have its own MPI communicator.
In the setup() method of the Multipoint group, instantiate
+the Builder associated with the disciplinary solvers you intend to use.
+
Initialize the disciplinary Builders with the MPI communicator of the Multipoint group.
+This should be done in the setup() method of the Multipoint group after the builder is instantiated.
+For example, aero_builder.initialize(self.comm)
+
If applicable to the discipline, add a subsystem for the initial mesh coordinates from the builder’s get_mesh_coordinate_subsystem function.
+This subsystem allows the disciplinary solver to dictate the parallel decomposition of its mesh.
+Any geometry manipulation subsystems, data transfer scheme subsystems, etc. will then be connected to the mesh subsystem’s mesh coordinate output.
Use mphys_add_scenario to add the scenario to the Multipoint group.
+Add customized coupled nonlinear and linear solvers to the scenario in this function call.
+
Connect inputs to the scenarios. Since MPhys uses Tagged Promotion,
+these inputs will have been promoted to {scenario_name}.{variable_name}.
+Typically the inputs that need to be connected are the design variables of the disciplinary solvers
+and mesh coordinates (if applicable to the discipline).
+These mesh coordinates may come from the initial mesh, or be altered by a geometry tool.
+
Repeat steps 5-7 until your Multipoint group is fully defined.
MPhys uses a hierarchical set of OpenMDAO groups to build multiphysics models.
+Each level of the hierarchy is a different OpenMDAO group that MPhys provides.
The highest level of the model is the multipoint group.
-The multipoint group consist of scenarios which represent different conditions and/or types of multiphysics analyses to performed.
+The multipoint group consists of scenarios which represent different conditions and/or types of multiphysics analyses to be performed.
Within the scenario is the coupling group which represents the primary multiphysics problem for the scenario.
+
See Assembling an MPhys Model for guidance on how to create this model hierarchy for a particular problem.
Builders are used to help populate these levels of the model hierarchy with subsystems from the solvers.
Tagged Promotion is used to promote specific variables to the level of scenario.
The CouplingGroup is the primary physics coupling being solved.
-That is it contains physics modules, such as an aerodynamic or structural solver,
-and potentially modules that transfer or interpolate between the physics modules, such as a load or displacement transfer schemes.
+That is, it contains physics modules, such as an aerodynamic or structural solver,
+and potentially modules that transfer or interpolate between the physics modules, such as a load or displacement transfer scheme.
Each type of scenario typically has an associated coupling group that it will add automatically given the proper builders.
Within the Scenario group, the coupling group will have the name ‘coupling’.
The scenario-specific coupling group will have a default nonlinear and linear solvers,
-but these can be overwritten with the optional arguments to mphys_add_scenario().
+but these can be overwritten with the optional arguments to mphys_add_scenario().
-
The scenario level is an OpenMDAO group that represents a specific condition in a multipoint optimization.
For example, a scenario could be a cruise flight condition that requires a coupling group to determine the lift and drag.
The scenario group contains a coupling group and any scenario-specific computation that needs to occur before or after the associated coupled problem is solved.
-For example, a sonic boom propagator requires the flow solution as an input but this one-way coupling does not require it to be in the coupling group; therefore, it should be put in the scenario group to be solved after the coupling group converges.
+The subsystems before the coupled problem are referred to as ‘pre_coupling’ subsystems.
+The subsystems after the coupled problem are referred to as ‘post_coupling’ subsystems.
+An example post_coupling subsystem would be a sonic boom propagation analysis after an aeropropulsive coupling analysis.
+
+
+
+
MPhys provides a library of these Scenario groups designed for specific type problems.
See MPhys Scenario Library for details about specific standardized scenarios.
-If a particular multiphysics problem is not covered by the MPhys library, new scenarios and coupling groups can be created by subclassing the MphysGroup.
+If a particular multiphysics problem is not covered by the MPhys library, new scenarios and coupling groups can be created by subclassing the MPhysGroup.
-
The Multipoint group will sequentially evaluate the scenario groups.
The Multipoint group can be the top group of the OpenMDAO model or a subsystem.
In the setup method of the Multipoint group, the following steps must be done:
Instantiate the builders
-
Call initialize() for each builder with the Multipoint’s comm (self.comm)
+
Call initialize() for each builder with the Multipoint’s comm (self.comm)
Add the mesh components and/or other mesh coordinate source like geometry.
Add the scenarios
Connect the mesh coordinates to the scenarios
Additionally, the Multipoint group can hold the design variables or other inputs and subsystems to be evaluated after the scenarios.
These extra subsystem can then be connected to the scenarios by the user.
A helper method to aid in connecting mesh coordinate sources to the scenarios
-in this multipoint group.
-The source and target variable names are assumed to be ‘x_{discipline}0’
-
-
Parameters:
-
-
source: openmdao.api.Group or openmdao.api.Component
The source subsystem for the mesh coordinate variables
-
-
scenariosstr or list[str]
The names of the scenarios to be the target of the connections
-
-
disciplinesstr or list[str]
The names of the disciplines for the mesh coordinates.
If given a number of MPI ranks greater than or equal to the number of scenarios, the MultipointParallel group will simultaneously evaluate the scenario groups.
Unlike the sequential Multipoint group, the MPI communicators are different for each scenario in MultipointParallel, so the scenarios will call the builder’s initialize method.
In the setup method of the MultipointParallel group, the following steps must be done:
While it is possible to set up the same OpenMDAO multiphysics problem with different sets of variable names, it is preferable for codes solving the same physics to use the same variable names to be more easily interchangeable.
This table provides the required names for coupling variables associated with a particular physics in MPhys.
+
The variable naming convention is defined as a Nested Classes with static variables.
+The names are access from the MPhysVariables class.
+If defining an component that uses the MPhys variable names repeatedly, it is often uses to define a local copy due to the long names that the nested variable classes.
The purpose of remote components is to provide a means of adding a remote physics analysis to a local OpenMDAO problem.
One situation in which this may be desirable is when the time to carry out a full optimization exceeds an HPC job time limit.
Such a situation, without remote components, may normally require manual restarts of the optimization, and would thus limit one to optimizers with this capability.
@@ -65,7 +65,7 @@
Navigation
MPhysZeroMQServer: Uses ZeroMQ socket to send and receive encoded JSON dictionaries.
If True, set all variables in this component as distributed across multiple processes
-
dump_json
+
dump_json
False
N/A
N/A
dump input/output json file in client
-
dump_separate_json
+
dump_separate_json
False
N/A
N/A
dump a separate input/output json file for each evaluation
-
pbs
+
pbs
pbs4py Launcher object
N/A
N/A
-
port
+
port
5081
N/A
N/A
port number for server/client communication
-
reboot_only_on_function_call
+
reboot_only_on_function_call
True
N/A
N/A
only allows server reboot before function call, not gradient call. Avoids having to rerun forward solution on next job, but shortens current job time
-
run_root_only
+
run_root_only
False
[True, False]
[‘bool’]
If True, call compute, compute_partials, linearize, apply_linear, apply_nonlinear, and compute_jacvec_product only on rank 0 and broadcast the results to the other ranks.
-
run_server_filename
+
run_server_filename
mphys_server.py
N/A
N/A
python file that will launch the Server class
-
time_estimate_buffer
+
time_estimate_buffer
0.0
N/A
[‘float’]
constant time in seconds to add to model evaluation esimate. When using parallel remote components with very different evaluation times, setting to slowest component’s estimated evaluation time avoids having the faster component’s job expire while the slower one is being evaluated
-
time_estimate_multiplier
+
time_estimate_multiplier
2.0
N/A
N/A
when determining whether to reboot the server, estimate model run time as this times max prior run time
-
use_derivative_coloring
+
use_derivative_coloring
False
[True, False]
[‘bool’]
assign derivative coloring to objective/constraints. Only for cases with parallel servers
+
use_jit
+
True
+
[True, False]
+
[‘bool’]
+
If True, attempt to use jit on compute_primal, assuming jax or some other AD package is active.
When adding a RemoteZeroMQComp component, the two required options are run_server_filename, which is the server to be launched on an HPC job, and pbs, which is the pbs4py Launcher object.
The server file should accept port number as an argument to facilitate communication with the client.
Within this file, the MPhysZeroMQServer class’s get_om_group_function_pointer option is the pointer to the OpenMDAO Group or Multipoint class to be evaluated.
@@ -195,7 +207,7 @@
Two examples are provided for the supersonic panel aerostructural case: as_opt_remote_serial.py and as_opt_remote_parallel.py.
Both run the optimization problem defined in as_opt_parallel.py, which contains a MultipointParallel class and thus evaluates two aerostructural scenarios in parallel.
The serial remote example runs this group on one server.
@@ -207,15 +219,14 @@
The dump_json option for RemoteZeroMQComp will make the component write input and output JSON files, which contain all data sent to and received from the server.
An exception is the wall_time entry (given in seconds) in the output JSON file, which is added on the client-side after the server has completed the design evaluation.
Another entry that is only provided for informational purposes is design_counter, which keeps track of how many different designs have been evaluated on the current server.
If dump_separate_json is set to True, then separate files will be written for each design evaluation.
On the server side, an n2 file titled n2_inner_analysis_<componentname>.html will be written after each evaluation.
A pbs4py Launcher must be implemented for your HPC environment
On the client side, RemoteZeroMQComp.stop_server() should be added after your analysis/optimization to stop the HPC job and ssh port forwarding, which the server manager starts as a background process.
A component used for network communication between top-level OpenMDAO
problem and remote problem evaluated on an HPC job. Serves as the
top-level component on the client side.
A class that serves as an OpenMDAO model analysis server. Launched
by a server run file by the ServerManager and runs on an HPC job,
awaiting design variables to evaluate and sending back resulting
@@ -353,7 +366,7 @@
MPhys uses tags to selectively promote variables to the level of scenario.
There are four types of tags in MPhys that represent different types of data.
The purpose of the MphysGroup is to implement the mechananics of promoting the MPhys variables by tags.
-Subsystems with tagged variables that will be promoted are added with the mphys_add_subsystem() method.
+
The purpose of the MPhysGroup is to implement the mechanics of promoting the MPhys variables by tags.
+Subsystems with tagged variables that will be promoted are added with the mphys_add_subsystem() method.
Subsystems that have variables that should not be promoted can still be added with add_subsystem
The automated promotion of tagged variables is done during the configure phase of OpenMDAO setup.
If you need to use configure in your CouplingGroup or Scenario group, be sure to call the parent’s configure with
super().configure().
In some instances, the use of automated promotion is not appropriate.
-Because the MphysGroup inherits from the standard OpenMDAO group,
+Because the MPhysGroup inherits from the standard OpenMDAO group,
subsystems can be added with the standard add_subsystem method and connected manually.
In initialize, the coupling group needs to have the required builders declared as options.
-In the setup phase, get_coupling_group_subsystem() is used to get subsystems from the builders,
+In the setup phase, get_coupling_group_subsystem() is used to get subsystems from the builders,
and self.mphys_add_subsystem is used to add them.
Other components like balance components can be added directly.
Setting a default linear and nonlinear solver suitable for this type of problem is also helpful in setup.
In most cases using a configure phase is not necessary for the scenario, but if you do implement a configure
method, you must call super().configure() to do the tagged promotion of variables from the scenario’s subsystems.
Your custom Scenario should at least implement the initialize and setup methods.
As with the CouplingGroup, you must call the configure method of the parent class if you implement a
configure method in the Scenario.
The Scenario’s initialize method should declare the necessary builders as options.
An in_MultipointParallel option should also be included if that mode of operation will be implemented.
Otherwise the developer is free to add options specific to the scenario type.
The main setup call for all multiphysics scenarios.
Multiphysics scenarios should implement setup-type operations in _mphys_scenario_setup().
Adds the builder subsystems, then adds user-defined post subsystems.
MPhys is a package that standardizes high-fidelity multiphysics problems in OpenMDAO.
MPhys eases the problem set up, provides straightforward extension to new disciplines, and has a library of OpenMDAO groups for multidisciplinary problems addressed by its standard.
While MPhys does provide these conventions, it is not absolutely necessary to follow these guidelines in order to solve these types of problems with OpenMDAO given its very general coupling capability.
@@ -46,7 +48,7 @@
These are descriptions of the groups in the MPhys library of multiphysics problems.
They describe physics problem being solved, the standards set by MPhys, requirements of the Builders, and the options available for each group.
M. A. Saja Abdul-Kaiyoom, Anil Yildirim, and and Joaquim R. R. A. Martins. Coupled aeropropulsive design optimization of an over-wing nacelle configuration. In AIAA SciTech Forum. January 2023. doi:10.2514/6.2023-0327.
The ScenarioAeroStructural is for static fluid structure interaction problems.
-The primary physics modules required for this problem are:
-1. The aerodynamics which computes forces given the displaced aerodynamic surface coordinates.
-2. The structures which computes structural displacements given the loads at structural nodes.
-3. The displacement transfer which projects the structural displacements to the aerodynamic surface mesh
-4. The load transfer which computes the loads on the structure from the aerodynamic output.
+The primary physics modules required for this problem are:
+
+
The aerodynamics which computes forces given the displaced aerodynamic surface coordinates.
+
The structures which computes structural displacements given the loads at structural nodes.
+
The displacement transfer which projects the structural displacements to the aerodynamic surface mesh
+
The load transfer which computes the loads on the structure from the aerodynamic output.
+
MPhys will add a GeoDisp subsystem to compute the displaced aerodynamic coordinates given the undeformed surface coordinates and the displacements.
Because the load and displacement transfers are typically tied together by the principle of virtual work, but are not adjacent in the coupling loop,
-the load and displacement Builder’s get_coupling_group_subsystem() must return both the displacement transfer and load tranfer subsystems as a tuple.
+the load and displacement Builder’s get_coupling_group_subsystem() function must return both the displacement transfer and load transfer subsystems as a tuple.
-
The structural solver builder must implement the get_ndof method in order for the displacement transfer to know if it needs to slice the displacements from the full structural state vector.
For example, the structural state vector for linear shell elements includes linearized rotation degrees of freedom at each node in addition to the translational displacements.
The ScenarioStructural is for scenarios that only need the structural solver.
An examples use case for this scenario would be a stress constraint from a static load generated by the structural solver subsystem(s).
+
+
+
+
+
+
+