Skip to content

OpenMDAO components send constructor kwargs instead of resolved options #77

Description

@chrislupp

Problem

RemoteExplicitComponent and RemoteImplicitComponent send the raw constructor keyword arguments to the server, not the component's resolved options. Any option value that reaches the component by another route is never transmitted, and the server keeps computing with whatever it had.

Two cases are affected:

  • Declared defaults. initialize() declares options from the server's GetAvailableOptions response (openmdao/utils.py:45-57). An option the caller does not pass explicitly keeps its OpenMDAO default locally, but the server never hears about it.
  • Post-construction assignment. comp.options['dimension'] = 10 after the component is built changes nothing on the server. There is no re-send at setup() time, so the server's value is whatever the last SetOptions call carried.

The failure is silent. The component reports the option as set, the server computes with a different one, and the results are wrong rather than erroneous.

Root cause

philote_mdo/openmdao/explicit.py:151 and philote_mdo/openmdao/implicit.py:158:

super().__init__(num_par_fd=num_par_fd, **kwargs)   # OpenMDAO validates and assigns
self._client.send_options(kwargs)                   # ...but the raw dict is sent

kwargs is the dict the caller passed. self.options is the validated, defaulted result. The second is what the server should receive.

Proposed fix

Send the resolved options. Something along the lines of:

self._client.send_options({name: self.options[name] for name in self._client.options_list})

restricted to the names the server actually declared, so unrelated OpenMDAO options are not forwarded.

Whether a re-send belongs in setup() as well is worth deciding at the same time: without one, assignment after construction still cannot reach the server. If a re-send is added, note that SetOptions after Setup is now refused with FAILED_PRECONDITION (see #76), so it has to happen before client_setup() runs.

Notes

Found while tracing the OpenMDAO call path for #76. Pre-existing on main; not introduced by the job work.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions