You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #178 we decided that enabled conditional connectors must be connected.
After actually enabling this warning in Dymola, it seems we should reconsider it.
In MSL it is used in several models see: modelica/ModelicaStandardLibrary#3947
And additionally many uses of Modelica.Mechanics.MultiBody.Joints.Revolute - e.g., Modelica.Mechanics.MultiBody.Examples.Systems.RobotR3.FullRobot where mechanics.r1.support is conditional and unconnected.
On the other hand the problem it is intended to find is real - enabling support for idealGear in Modelica.Mechanics.Rotational.Examples.FirstGrounded without connecting it is not good modeling.
I believe the issue is that we tried to solve the wrong problem.
We had the issue that for specific unconnected non-conditional connectors we can use asserts to generate diagnostics (using cardinality). That doesn't work for unconnected enabled conditional connectors, and based on some examples where the same applies for them we tried to add a rule for all of them (in this ticket and then amended to not be "all").
We failed to realize that support in rotational is special - it only enables one connector, and if disabled we have other equations.
For the other cases above the condition enables multiple connectors, and you don't have to use all of them.
Instead we should figure out a way to specify that a connector should be connected; and obviously skip that diagnostics if the connector is disabled. One possibility would be an annotation for connector components (this was also suggested in #1409 ): parameter String mustBeConnected="..."
If non-empty it indicates that a diagnostics should be given if the connector is not connected (for a conditional connector this check is only active if the connector is enabled). For an array of connectors it applies separately to each element.
And possibly mayOnlyConnectOnce for the reverse.
If people think this diagnostics is super-useful and really hate annotations leading to diagnostics we could introduce some special construct for it.
With both of these annotations I believe this would allow us to remove all but two uses of cardinality in MSL, the remaining ones are:
PointMass
The ones in Modelica.Mechanics.MultiBody.Forces.LineForceWithMass* although I'm not sure if they are really that useful.
The text was updated successfully, but these errors were encountered:
* Describe new annotation for checking number of connections.
* Do not require that conditionally active connectors are connected; reverting #178Closes#3117
* Apply suggestions from code review
* Removed elided code as suggested, and indicate that something is missing.
Also reduce to one flange-connector.
* Remove 2nd one; turn into separate PR.
Co-authored-by: Henrik Tidefelt <henrikt@wolfram.com>
In #178 we decided that enabled conditional connectors must be connected.
After actually enabling this warning in Dymola, it seems we should reconsider it.
In MSL it is used in several models see:
modelica/ModelicaStandardLibrary#3947
And additionally many uses of Modelica.Mechanics.MultiBody.Joints.Revolute - e.g., Modelica.Mechanics.MultiBody.Examples.Systems.RobotR3.FullRobot where mechanics.r1.support is conditional and unconnected.
On the other hand the problem it is intended to find is real - enabling support for idealGear in Modelica.Mechanics.Rotational.Examples.FirstGrounded without connecting it is not good modeling.
I believe the issue is that we tried to solve the wrong problem.
We had the issue that for specific unconnected non-conditional connectors we can use asserts to generate diagnostics (using cardinality). That doesn't work for unconnected enabled conditional connectors, and based on some examples where the same applies for them we tried to add a rule for all of them (in this ticket and then amended to not be "all").
We failed to realize that
support
in rotational is special - it only enables one connector, and if disabled we have other equations.For the other cases above the condition enables multiple connectors, and you don't have to use all of them.
Instead we should figure out a way to specify that a connector should be connected; and obviously skip that diagnostics if the connector is disabled. One possibility would be an annotation for connector components (this was also suggested in #1409 ):
parameter String mustBeConnected="..."
If non-empty it indicates that a diagnostics should be given if the connector is not connected (for a conditional connector this check is only active if the connector is enabled). For an array of connectors it applies separately to each element.
And possibly
mayOnlyConnectOnce
for the reverse.If people think this diagnostics is super-useful and really hate annotations leading to diagnostics we could introduce some special construct for it.
With both of these annotations I believe this would allow us to remove all but two uses of cardinality in MSL, the remaining ones are:
The text was updated successfully, but these errors were encountered: