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.
Problem
RemoteExplicitComponentandRemoteImplicitComponentsend 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:
initialize()declares options from the server'sGetAvailableOptionsresponse (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.comp.options['dimension'] = 10after the component is built changes nothing on the server. There is no re-send atsetup()time, so the server's value is whatever the lastSetOptionscall 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:151andphilote_mdo/openmdao/implicit.py:158:kwargsis the dict the caller passed.self.optionsis the validated, defaulted result. The second is what the server should receive.Proposed fix
Send the resolved options. Something along the lines of:
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 thatSetOptionsafterSetupis now refused withFAILED_PRECONDITION(see #76), so it has to happen beforeclient_setup()runs.Notes
Found while tracing the OpenMDAO call path for #76. Pre-existing on
main; not introduced by the job work.