Closed robfalck closed 1 year ago
If your whole model is one component... AutoIVC has no meaning. We simply shouldn't create any, right?
Say we don't generate the AutoIVC. The third test case should not work then? We're then requiring the root system to be a Group if we do optimization (you need IVCs to hold your design variables). The error message should be something along the lines of Design variables require an IndepVarComp
. but since we strongly favor AutoIVC that might be confusing. It may just be simpler and more clear to require the root to be a Group.
Promotes should also fail when promoting from the root system, that would address the second test case.
promotes_inputs is an argument on Group.add_subsystem
, not ExecComp.__init__
. The user should have seen that in the error message. The error you are seeing is because all arguments in ExecComp are supposed to be input or output names with the value being a dictionary of metadata.
I'm all for restricting prob.model to be a Group though.
Description
A user reported that the AutoIVC feature doesn't work correctly when the system is a single component, as there is no Group in which to put the automatically created IndepVarComp.
While testing this, I uncovered a few other issues with problems in which the model was a single system. Our reliance on AutoIVC has me tempted to say that we should just deprecate this behavior and in the future require that
Problem.model
be a Group, or at least be derived from Group.Some of these cases are captured below. Others include the N2 being wonky (but still generated as a report) in this situation.
Example
OpenMDAO Version
3.21.1-dev
Relevant environment information
No response