fast-aircraft-design / FAST-OAD

FAST-OAD: An open source framework for rapid Overall Aircraft Design
GNU General Public License v3.0
53 stars 26 forks source link

Undetected inputs when using IndepVarComp in a problem #406

Closed ScottDelbecq closed 2 years ago

ScottDelbecq commented 2 years ago

Describe the bug When generating the inputs of a problem containing an IndepVarComp, the outputs of the IndepVarComp should be considered as inputs and hence present in the generated .xml file.

To Reproduce Steps to reproduce the behavior.

import openmdao.api as om
from fastoad.api import generate_inputs

# build the model
prob = om.Problem()

# System variables
comp = om.IndepVarComp()
comp.add_output("system:x", val=3.0)
comp.add_output("system:y", val= -4.0)

prob.model.add_subsystem("indeps", comp, promotes=["*"])

prob.model.add_subsystem("paraboloid", om.ExecComp("f = (x-3)**2 + x*y + (y+4)**2 - 3"), promotes=["*"])

prob.model.connect("system:x", "x")
prob.model.connect("system:y", "y")

Expected behavior "system:x" and "system:y" should appear in the input file which is not the case

Error message

Environment

Additional context Add any other context about the problem here.

christophe-david commented 2 years ago

Thank you for the effort of clarity.

Nevertheless, I have to point out that your sample code does not help because it does not show how generate_inputs would be used in such case (and actually, I think it could not). Moreover, there is at least a typo. You didn't run it, did you?

Yet I think I see your point, and I'm not convinced this should be the expected behavior, and I don't see that as a bug. In the first place, why would a FAST-OAD model contain an IndepVarComp? If there is a need for defining default values, this should be done in the components, shouldn't it? Moreover, if you put these values in the input file, as we build an IndepVarComp that we insert in the problem, the concerned outputs will be twice in the problem, and OpenMDAO will raise an error (I agree that maybe we should handle input data differently, though).

In conclusion, I think it is at most a feature request, but I am not convinced it should be done, because it does not seem a logical behavior to me. But that can be discussed...

ScottDelbecq commented 2 years ago

Sorry for the typo which I corrected. I will try and make a complete reproduction of the issue but it requests more time as generate_inputs requires a configuration file.

I agree that this could be considered as a feature request neverthess if run in pure OpenMDAO we should provide values for these undetected inputs or else the computation will use nan. The need is not for defining default values in my case but rather creating a system level input and distribute it to my component inputs. In addition, it will not raise an error by OpenMDAO, the system input (tagged "input") will have the same value as the component inputs (tagged "output").

Again I agree it is more a feature request, maybe unlogic for pure FAST-OAD, but not for specific systems developped as custom modules.

christophe-david commented 2 years ago

Ok with the feature. As already said, this will need a refactoring of the way we insert input data in the problem (as I checked, you were right, Problem.set_val() will indeed overload the value of any existing IVC).