Automatic Setting of Execution Order#

By default, subsystems of a Group are executed in the same order as they were added to that Group. Depending on the data connections between those subsystems, that order could result in some subsystems being executed before their inputs have been updated. This can result in a performance impact by increasing the number of solver iterations required to achieve convergence.

In come cases it’s obvious what the order should be and you can simply declare the subsystems in the correct order. However, as models evolve and become more complex, it becomes more likely that out of order execution may occur. One way to prevent this from happening is to set the auto_order option on the Group. This will cause OpenMDAO to set the Group’s subsystem execution order based on the dependency graph of that Group. Note that if connections within a Group result in some subsystems forming a cycle in the graph, then OpenMDAO will not attempt to reorder the cycle. It will, however, order the cycle properly with respect to any subsystems outside of the cycle. Below is a simple example where OpenMDAO will automatically reorder the subsystems of group G1 based on their data dependencies.

import openmdao.api as om

class SimpleComp(om.ExplicitComponent):
    def setup(self):
        self.declare_partials('*', '*')

    def compute(self, inputs, outputs):
        print(f"running {}")
        outputs['y'] = 2.0*inputs['x']

p = om.Problem()
model = p.model
G1 = model.add_subsystem('G1', om.Group())
G1.add_subsystem('C2', SimpleComp())
G1.add_subsystem('C1', SimpleComp())
G1.add_subsystem('C3', SimpleComp())
G1.connect('C1.y', 'C2.x')
G1.connect('C2.y', 'C3.x')

# tell OpenMDAO to auto-order the components in G1
G1.options['auto_order'] = True

running C1
running C2
running C3

The components in G1 were declared in the order [‘C2’, ‘C1’, ‘C3’], but they should execute in the order [‘C1’, ‘C2’, ‘C3’] based on how they are connected to each other.

Turning Off Auto Ordering Globally#

For auto ordering to be possible, the framework must be able to change the order of a Group’s subsystems after all of that Group’s connections are known. To make this possible, the setup order of subsystems in a Group is converted to alphabetical (instead of order of execution) in order to make the order of OpenMDAO’s internal data structures, including the order of variables within Vectors, independent of subsystem execution order. This allows the execution order of subsystems to be changed after connection information is known. It also has the side benefit of removing previous restrictions on the Group set_order function that did not allow calling it during the configure function.

As a result of ordering the setup of subsystems alphabetically, some very slight numerical changes may occur in a model due to, for example, rows and/or columns changing order in a jacobian. In some cases, if a model is very sensitive, this might cause convergence failures or make convergence take longer. To mitigate this, an option called allow_post_setup_reorder has been added to Problem. This option defaults to True, but if it is set to False, then the setup order of subsystems will not be alphabetical, and all auto_order options on Groups in that Problem will be ignored. Setting the allow_post_setup_reorder option is shown below.

import openmdao.api as om

p = om.Problem(allow_post_setup_reorder=False)