Closed JustinSGray closed 3 years ago
If a parameter or control is specified as opt=False
, then it exists as a potential input which some other output can connect to. There's no simple way to tell if these inputs are ultimately tied to a design variable or not.
Therefore, if implemented, this capability will be limited to states and time. Given this limitation, are we giving the user a false sense of security that everything is OK when in reality they have some incompatibility that we can't check? I suspect that it's probably preferable to implement this for states and time, since those are by far the most common variable types to be linked between phases.
I think the non states/time that you are referring to don't have the option for fix_initial
and fix_final
do they?
So we can apply the error check in cases where we allow things to be explicitly fixed as boundary conditions. The error can even include the term bounary condition
. I don't think its unreasonable to catch an error we can, just because there are some other less common errors that we can't.
Right, we can check fix_initial/fix_final. The option opt=True|False
is commonly used to fix the value of design parameters or controls, but since it makes those inputs we cannot be certain as to whether or not they're fixed.
Summary of Issue
It is a common mistake for users to link a state/control across two phases, but then set both sides of that linkage to fixed. This seems like something we could check for in setup and provide a clear error for.
Issue Type
Description
Give an error saying
"Linkage between the final side of phase0 and the initial side of phase1 for variable
foo
is not configured correctly. Both sides of the connection are fixed, which makes the problem ill-posed. Change at least one side non-fixed"Example
This toy example has two cases:
1) bad time linkage. 2) bad state linkage.
Both these cases are common and easy mistakes to make, and we should error on setup with them