Wsrtjtyk

With reconfigurable model execution it is possible to resize inputs and outputs of components. How are the connections updated, when reconfigured outputs and inputs are connected?

In the example below the output c2.y and c3.y is resized at each model run. This input and output is supposed to be connected, as shown in the N2 chart. However, after the reconfiguration the connection size seems to be not updated automatically, it throws the following error:

ValueError: The source and target shapes do not match or are ambiguous for the connection 'c2.y' to 'c3.y'. Expected (1,) but got (2,).

I included below 3 tests, with promoted connection, absolute connection, and the last one with reconfiguration but without the connection (which works).

The last chance would be to declare the connection in the parent group of the comps, which I did not try yet.

The tests:

1. Promoted connection


2. Absolute connection


3. No connection

Reconfigurable component classes and tests:

from __future__ import division



import logging



import numpy as np

import unittest



from openmdao.api import Problem, Group, IndepVarComp, ExplicitComponent

from openmdao.utils.assert_utils import assert_rel_error





class ReconfComp(ExplicitComponent):



    def initialize(self):

        self.size = 1

        self.counter = 0



    def reconfigure(self):

        logging.info('reconf started {}'.format(self.pathname))

        self.counter += 1

        logging.info('reconf ended {}'.format(self.pathname))



        if self.counter % 2 == 0:

            self.size += 1

            return True

        else:

            return False



    def setup(self):

        logging.info('setup started {}'.format(self.pathname))

        self.add_input('x', val=1.0)

        self.add_output('y', val=np.zeros(self.size))

        # All derivatives are defined.

        self.declare_partials(of='*', wrt='*')

        logging.info('setup ended {}'.format(self.pathname))



    def compute(self, inputs, outputs):

        logging.info('compute started {}'.format(self.pathname))

        outputs['y'] = 2 * inputs['x']

        logging.info('compute ended {}'.format(self.pathname))



    def compute_partials(self, inputs, jacobian):

        jacobian['y', 'x'] = 2 * np.ones((self.size, 1))





class ReconfComp2(ReconfComp):

    """The size of the y input changes the same as way as in ReconfComp"""



    def setup(self):

        logging.info('setup started {}'.format(self.pathname))

        self.add_input('y', val=np.zeros(self.size))

        self.add_output('f', val=np.zeros(self.size))

        # All derivatives are defined.

        self.declare_partials(of='*', wrt='*')

        logging.info('setup ended {}'.format(self.pathname))



    def compute(self, inputs, outputs):

        logging.info('compute started {}'.format(self.pathname))

        outputs['f'] = 2 * inputs['y']

        logging.info('compute ended {}'.format(self.pathname))



    def compute_partials(self, inputs, jacobian):

        jacobian['f', 'y'] = 2 * np.ones((self.size, 1))





class TestReconfConnections(unittest.TestCase):



    def test_reconf_comp_promoted_connections(self):

        p = Problem()



        p.model = Group()

        p.model.add_subsystem('c1', IndepVarComp('x', 1.0), promotes_outputs=['x'])

        p.model.add_subsystem('c2', ReconfComp(), promotes_inputs=['x'], promotes_outputs=['y'])

        p.model.add_subsystem('c3', ReconfComp2(), promotes_inputs=['y'],

                              promotes_outputs=['f'])



        p.setup()

        p['x'] = 3.



        # First run the model once; counter = 1, size of y = 1

        p.run_model()

        totals = p.compute_totals(wrt=['x'], of=['y'])

        assert_rel_error(self, p['x'], 3.0)

        assert_rel_error(self, p['y'], 6.0)

        assert_rel_error(self, totals['y', 'x'], [[2.0]])

        print(p['x'], p['y'], totals['y', 'x'].flatten())



        # Run the model again, which will trigger reconfiguration; counter = 2, size of y = 2

        p.run_model()  # FIXME Fails with ValueError



    def test_reconf_comp_connections(self):

        p = Problem()



        p.model = Group()

        p.model.add_subsystem('c1', IndepVarComp('x', 1.0), promotes_outputs=['x'])

        p.model.add_subsystem('c2', ReconfComp(), promotes_inputs=['x'])

        p.model.add_subsystem('c3', ReconfComp2(), promotes_outputs=['f'])

        p.model.connect('c2.y', 'c3.y')

        p.setup()

        p['x'] = 3.



        # First run the model once; counter = 1, size of y = 1

        p.run_model()



        # Run the model again, which will trigger reconfiguration; counter = 2, size of y = 2

        p.run_model()  # FIXME Fails with ValueError



    def test_reconf_comp_not_connected(self):

        p = Problem()



        p.model = Group()

        p.model.add_subsystem('c1', IndepVarComp('x', 1.0), promotes_outputs=['x'])

        p.model.add_subsystem('c2', ReconfComp(), promotes_inputs=['x'])

        p.model.add_subsystem('c3', ReconfComp2(), promotes_outputs=['f'])

        # c2.y not connected to c3.y

        p.setup()

        p['x'] = 3.



        # First run the model once; counter = 1, size of y = 1

        p.run_model()



        # Run the model again, which will trigger reconfiguration; counter = 2, size of y = 2

        fail, _, _ = p.run_model()

        self.assertFalse(fail)





if __name__ == '__main__':

    unittest.main()

UPDATE:

It seems, that in Group._var_abs2meta only the source size is updated, but not the target. The setup of the connections starts, before the setup of the parent group or the setup of the other component would be called.

UPDATE 2:

This happens with the default NonlinearRunOnce solver, with a NewtonSolver of NonlinearBlockGS there is no error, but the variable sizes also don't change.

As of OpenMDAO V2.5 reconfigurable model variables is not an officially supported feature in the framework. The bare bones of the capability has been in the code since that research was done, but it wasn't something that was high priority enough for us to finalize. A recent major refactor in V2.4 re-worked how some underlying data-structures worked and must have broken this functionality.

It is on our development priority list to get this working again, but its not super high on that list. We focus development mainly on features that have a direct in-house applications, and we don't have one of those yet.

If you could provide a decently complete set of tests for it, we could take a look at getting the functionality working.