search

modelica / ModelicaSpecification

Specification of the Modelica Language
https://specification.modelica.org
Creative Commons Attribution Share Alike 4.0 International
98 stars 42 forks source link

Specification of cardinality #1409

Closed modelica-trac-importer closed 5 years ago

modelica-trac-importer commented 5 years ago

Reported by adrpo on 5 Feb 2014 13:21 UTC Before you tell me that cardinality is deprecated, have a look at the latest MSL trunk/ or MSL 3.2.1. There are 98 occurrences of cardinality in there. Not to speak of a lot of other libraries.

We really need a *full* definition of cardinality that give *all* the restrictions so tools behave the same when it comes to cardinality. The specification says almost nothing about cardinality and that is really bad.

So what is cardinality supposed to return?

Here are some cases:

  1. Reordering of connects Supposedly a tool can reorder connects connect(a, b) + connect(b, c) is equivalent with connect(a, b) + connect(a, c) So, should cardinality return 2 in this case?

    parameter Integer i = cardinality(a);
equation
connect(a, b);
connect(b, c);

  2. Cardinality and deleted components Let's go with an easy model:

    model CardinalityDeleted1
connector I = input Real;
connector O = output Real;
parameter Integer x = cardinality(u);
I u;
O a if b;
parameter Boolean b = false;
parameter Real z[x] = fill(0, x);
equation 
connect(u, a);
end CardinalityDeleted1;

    I guess in this case x = 0; Let's try another one:

    model CardinalityDeleted2
connector I = input Real;
connector O = output Real;
parameter Integer x = cardinality(u);
I u;
O a if b;
parameter Boolean b = x > 0;
parameter Real z[x] = fill(0, x);
equation 
connect(u, a);
end CardinalityDeleted2;

    So what's the cardinality now?

  3. Cardinality and expandable connectors Supposedly connectors can be used inside expandable connectors. Let's try:

    model CardinalityExpandable
connector I = input Real;
connector O = output Real;
expandable connector E
end E;
E e;
I i;
O o;
parameter Integer c = cardinality(e.x);
equation 
connect(e.x, i);
connect(i, o);
end CardinalityExpandable;

    So, what's the cardinality of e.x?

  4. Cardinality used for array dimensions See case 1. for a model. Is this allowed?

  5. Cardinality and the overconstrained connection graph The specification says that a tool has to break the connection graph BUT IT DOESN'T SAY WHERE! So what's the cardinality(frame)? I guess it totally depends on where the graph cycle is broken. Also, do Connection.branch counts towards cardinality?

I really think that we should restrict cardinality to *only* be used inside the equation section and it should not be used:

Migrated-From: https://trac.modelica.org/Modelica/ticket/1409

modelica-trac-importer commented 5 years ago

Comment by perost on 5 Feb 2014 13:35 UTC Another case to consider:

model M
  SomeConnector c1[2], c2[2];
  parameter ??? c = cardinality(c1);
equation
  connect(c1[1], c2[2]);
  connect(c2[1], c1[2]);
end M;

What should cardinality(c1) return? 0, 2, {1, 1}, or something else?

modelica-trac-importer commented 5 years ago

Modified by fcasella on 5 Feb 2014 13:43 UTC

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 5 Feb 2014 13:54 UTC I only got 43 classes with cardinality; and it might still be possible to actually remove them:

Some only had it in comments.

Most of the uses were asserts for incorrect connections in: Modelica.Fluid.Fittings.MultiPort Modelica.Fluid.Fittings.TeeJunctionVolume (and some other fluid models) Modelica.Mechanics.MultiBody.Interfaces.PartialAbsoluteSensor Modelica.Mechanics.MultiBody.Joints.GearConstraint (etc) and also in StateGraph.

It should be possible to handle that in another better way I guess.

And then there was the odd use in: Modelica.Mechanics.MultiBody.Forces.LineForceWithMass (and similar ones) --- As for the questions above: It is not specified that a tool can reorder connect - it is just that connect generate equations based on connection-sets and the building of sets is transitive - i.e. connect(a,b);connect(b,c); does in most cases give the same equations as connect(a,b);connect(a,c); (Most; since the results will differ if a or b is disabled.)

That is just a consequence of the specified connection-handling and does not imply that cardinality is changed.

Similarly over-determined connection handling does not remove connect-statements; it is just that connect-statement generate different equations depending on whether the connect is part of a spanning tree or not. There is nothing indicating that this difference should change cardinality. Counting Connections.branch as "connect" would be odd, especially since it is normally not applied to the actual connectors.

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 5 Feb 2014 14:03 UTC Cardinality has to be restricted it pretty aggressively - equation sections only isn't enough (see second example below). Anything at all that can affect flattening can lead to undefined behavior.

More examples:

model Ex1
  connector C = input Real;

  model A
    outer C c1;
    C c2;
  equation
    connect(c1, c2);
  end A;

  inner C c1;
  parameter Integer b = cardinality(c1);
  A a[b+1];
end Ex1;

Edit: The second example is already forbidden, as pointed out by Adrian.

model Ex2
  connector C = input Real;

  C c1[10];
  C c2;
equation
  for i in 1:(cardinality(c2) + 1) loop
    connect(c1[i], c2);
  end loop;
end Ex2;

However, all of this are the reasons it is deprecated. The real issue is removing it from MSL. When I implemented support for cardinality, I noted that most of the uses in MSL are in the tests of asserts. If we could find another way to express that use, and change the other MSL uses, then we might be able to phase it out (perhaps remove it entirely in 3.3 or 3.4).

modelica-trac-importer commented 5 years ago

Comment by sjoelund.se on 5 Feb 2014 14:16 UTC Replying to [comment:4 jmattsson]:

However, all of this are the reasons it is deprecated. The real issue is removing it from MSL.

Removing it from user libraries is harder... I keep telling users that cardinality is poorly specified and basically it will return garbage you should never rely on. And the reply is obviously: what do we use instead?

If we do not have a replacement, we should simply specify it better with all necessary restrictions. Until this is resolved, user libraries will keep using cardinality; users are still surprised the operator is deprecated.

modelica-trac-importer commented 5 years ago

Comment by adrpo on 5 Feb 2014 14:28 UTC Good. We already have quite a bit of information that we didn't had before:

  1. overconstrained-connection graph does not influence cardinality
  2. good to know also that a tool is not allowed to rewrite connects (i don't think any tool does it, but if we specify that is not allowed is way better)
  3. cardinality should be restricted to equation sections at least (also it should not be used in deleted components conditions).

jmattson, you cannot use cardinality in for equation ranges, see #1082, this was added to the specification. See Modelica Spec 3.2 revision 2:

8.3.3 Connect-Equations
A connect-equation has the following syntax:
connect "(" component_reference "," component_reference ")" ";"
These can be placed inside for-equations and if-equations; provided the indices of the for-loop and conditions of the if-clause are parameter expressions that do not depend on cardinality, rooted, Connections.rooted, or Connections.isRoot.

I also think that we should really specify cardinality even if is deprecated and it will be phased out. A lot of libraries uses it and people complain they don't know how to get rid of it. So we need two things:

  1. specification of cardinality (so that backwards compatibility is ensured)
  2. a howto guide on how to remove the cardinality from your library or model
modelica-trac-importer commented 5 years ago

Comment by jmattsson on 5 Feb 2014 14:45 UTC Replying to [comment:6 adrpo]:

jmattson, you cannot use cardinality in for equation ranges, see #1082, this was added to the specification. See Modelica Spec 3.2 revision 2:

Actually, that doesn't say that you can't use cardinality in for equation ranges - read it again. It does, however, make my example illegal.

Replying to [comment:6 adrpo]:

I also think that we should really specify cardinality even if is deprecated and it will be phased out. A lot of libraries uses it and people complain they don't know how to get rid of it. So we need two things:

  1. specification of cardinality (so that backwards compatibility is ensured)
  2. a howto guide on how to remove the cardinality from your library or model

I agree that those are needed. I'm just afraid that we will specify it and then everyone will move on to other things, and it will stay in the spec as deprecated until hell freezes over or Modelica 4 is released (whichever comes first). It's important that we work on making it possible to remove it from MSL as well.

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 5 Feb 2014 14:52 UTC Please ignore this comment - wrong button.

modelica-trac-importer commented 5 years ago

Comment by adrpo on 5 Feb 2014 15:09 UTC

model Ex1
  connector C = input Real;

  model A
    outer C c1;
    C c2;
  equation
    connect(c1, c2);
  end A;

  inner C c1;
  parameter Integer b = cardinality(c1);
  A a[b+1];  // Edit2: typo
end Ex1;

This is illegal because cannot connect two inputs (c1, c2).

But yes, is a problem model as you have an array with outer pointing to the same inner. Not to speak that the array dimension depends on cardinality which depends on the array dimension. Good one :)

Say we disallow cardinality to be used in array dimensions.

model Ex1
  connector C = input Real;
  connector O = output Real;

  model A
    outer C c1;
    O c2;
  equation
    connect(c1, c2);
  end A;

  inner C c1;
  parameter Integer b = cardinality(c1);
  A a[10];  // Edit2: typo
end Ex1;

Then in this case cardinality should be 10.

modelica-trac-importer commented 5 years ago

Comment by stefanv on 5 Feb 2014 17:26 UTC Cardinality issues aside, isn't example 3 already illegal?

As far as I know, "expandable connector" means that fields are added to the expandable connector to correspond to fields on the other side of the connection. You can't just add fields to an expandable connector by writing them for the first time in a connect equation.

modelica-trac-importer commented 5 years ago

Comment by stefanv on 5 Feb 2014 17:27 UTC On a related note, I'd like to propose that Modelica library version x.y cannot use langauge features that were deprecated in language version x.y or older.

modelica-trac-importer commented 5 years ago

Comment by hubertus on 5 Feb 2014 18:01 UTC That is a good proposal. I will file a high priority ticket for the MSL to work on that, start with Martin Otter as owner for MultiBody and then we can pass it around the library maintainers to remove it. Hans, could you attach the complete list that you seem to have?

modelica-trac-importer commented 5 years ago

Comment by eshmoylova on 5 Feb 2014 18:05 UTC In Spec 3.2 Rev 2, the cardinality operator is defined as: Returns the number of (inside and outside) occurrences of connector instance c in a connect-equation as an Integer number.

Suggestion for cardinality in Example 1 to return 2 makes me think that you are not simply counting occurrences of the connector instance in the connect equations. What is exactly cardinality then?

Regardless of what it is, let's looks only at what are the restrictions on where it can be used as specified in 8.3.3, already quoted above. Connect-equations cannot occur inside if- and for-statements whose conditions depend on cardinality. In the second model of Example 2, the condition b depends on cardinality. There was a discussion on connections to conditionally declared components and the care that must be used in dealing with them in #1183. Having the conditional component and writing a connect equation to it is equivalent to having the condition applied to the connect equation, so your equations is actually:

   if b then
      connect(u, a);
   end if;

So you end up having a connect-equation inside an if-statement whose condition depends on cardinality, which makes this example illegal.

So really we should not try to define what cardinality must give in these cases but emphasize that it's illegal.

I agree with Jesper's comment that the cardinality has to be restricted pretty aggressively. Enforcing the deprecation of it in the library is a pretty good way of achieving that, in my opinion.

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 6 Feb 2014 08:24 UTC Replying to [comment:12 hubertus]:

That is a good proposal. I will file a high priority ticket for the MSL to work on that, start with Martin Otter as owner for MultiBody and then we can pass it around the library maintainers to remove it. Hans, could you attach the complete list that you seem to have?

I think it is easier to forward the instructions: in Dymola I did Search in MSL for cardinality in the text. Out of 43 hits, 2 (at least) are comments and the rest are only in Modelica.Fluid, Modelica.Mechanics.MultiBody, and Modelica.StateGraph.

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 6 Feb 2014 08:27 UTC Replying to [comment:10 stefanv]:

As far as I know, "expandable connector" means that fields are added to the expandable connector to correspond to fields on the other side of the connection. You can't just add fields to an expandable connector by writing them for the first time in a connect equation.

You can. First you add all the components that have been connected to *in* the expandable connectors, then you all everything in other expandable connectors connected to *it*. There is another ticket about the chapter on expandable connectors - it is confusing and needs a rewrite.

modelica-trac-importer commented 5 years ago

Comment by stefanv on 6 Feb 2014 14:21 UTC I still think the third example (that is, the one marked 3) is illegal. What is the type of e.x? I don't care what the spec for expandable connectors says or ought to say, but I'm pretty sure that introducing a variable to it in the middle of an equation and nowhere else is not legal. It needs to be declaredsomewhere.

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 6 Feb 2014 15:05 UTC Replying to [comment:16 stefanv]:

I still think the third example (that is, the one marked 3) is illegal. What is the type of e.x? I don't care what the spec for expandable connectors says or ought to say, but I'm pretty sure that introducing a variable to it in the middle of an equation and nowhere else is not legal. It needs to be declaredsomewhere.

Sorry, but expandable connectors *are* that nasty. You can add new elements to them simply by connecting to a member that is not declared. However, the example *is* illegal, because you are not allowed to access an undeclared member of an expandable connector other than in connect clauses.

The type of e.x is calculated from the type of i.

modelica-trac-importer commented 5 years ago

Comment by adrpo on 6 Feb 2014 15:23 UTC I think that case 3 above is valid. You can access the virtual variable in the expandable connector anywhere if it also appears in a connect. All the ones in the expandable that do not appear in any connect are removed. So the specification seems very clear: 3 people 3 different interpretations :)

modelica-trac-importer commented 5 years ago

Comment by stefanv on 6 Feb 2014 15:26 UTC So, please, what is the type of e.x in that example?

modelica-trac-importer commented 5 years ago

Comment by adrpo on 6 Feb 2014 15:32 UTC Real.

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 6 Feb 2014 15:37 UTC Replying to [comment:18 adrpo]:

I think that case 3 above is valid. You can access the virtual variable in the expandable connector anywhere if it also appears in a connect. All the ones in the expandable that do not appear in any connect are removed. So the specification seems very clear: 3 people 3 different interpretations :)

It is only in the non-normative text (again, there is another ticket for changing that). Spec 3.2r2, p 95: "the expressions can only "read" variables from the bus that are actually declared in the connector".

Replying to [comment:19 stefanv]:

So, please, what is the type of e.x in that example?

Real. Or possibly input Real, you are supposed to change input/output so that the connect is legal and keep everything else from whatever you connect to.

The tricky part comes when you do connect(e.x[2], i); - then you have to look at all connects to e.x before you can figure out the array size. To make that case even worse, if there are no connects to e.x[1], then e.x[2] exists, but not e.x[1] (though the spec allows the tool to let it exist and add an equation that sets it to 0).

modelica-trac-importer commented 5 years ago

Comment by adrpo on 6 Feb 2014 15:42 UTC I would say is Real because you already have an input and an output in the connection set.

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 6 Feb 2014 16:06 UTC Replying to [comment:21 jmattsson]:

Replying to [comment:18 adrpo]:

I think that case 3 above is valid. You can access the virtual variable in the expandable connector anywhere if it also appears in a connect. All the ones in the expandable that do not appear in any connect are removed. So the specification seems very clear: 3 people 3 different interpretations :) It is only in the non-normative text (again, there is another ticket for changing that). Spec 3.2r2, p 95: "the expressions can only "read" variables from the bus that are actually declared in the connector".

Yes. The normative text makes clear that if you had declared the variable in the expandable connector and not connected to it it would be an error, but misses the case where the variable is not even declared (which the non-normative text includes).

One way of explaining it is that it is assumed that the elaboration that introduces the new variables in the expandable connectors occurs when all variables outside of connect should be known.

Replying to [comment:19 stefanv]:

So, please, what is the type of e.x in that example? Real. Or possibly input Real, you are supposed to change input/output so that the connect is legal and keep everything else from whatever you connect to.

I think you mean "output Real":

The connect involves two public outside connectors (i and e.x) - see section 9.1.2. 9.1.3 states that it should be either input or output according to 9.3; so it cannot be just "Real" - it must be "input Real" or "output Real". 9.3. States that a connection set may at most involve one public outside input connector (and "i" is part of it) - so it cannot be input Real, i.e only "output Real" remains as a possibility.

Basically the signal is externally connected to "i" and then propagated to "o" and "e.x".

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 6 Feb 2014 16:31 UTC Replying to [comment:23 hansolsson]:

I think you mean "output Real":

I have no idea how the rules for what combinations of input/output you are allowed to connect work. I just knew that they were what controlled if the generated member of the expandable connector should be input/output. So I assume that you are correct.

modelica-trac-importer commented 5 years ago

Comment by msasena on 6 Feb 2014 19:00 UTC Replying to [comment:12 hubertus]:

That is a good proposal. I will file a high priority ticket for the MSL to work on that, start with Martin Otter as owner for MultiBody and then we can pass it around the library maintainers to remove it. Hans, could you attach the complete list that you seem to have?

It seems to have gone unnoticed, but I filed a ticket like that last September (#1265). Perhaps I put it in the wrong category. Regardless, we should avoid duplicating tickets, so we should consider closing either #1410 or #1265 with status "duplication".

modelica-trac-importer commented 5 years ago

Comment by eshmoylova on 6 Feb 2014 20:26 UTC Replying to [comment:13 eshmoylova]:

In Spec 3.2 Rev 2, the cardinality operator is defined as: Returns the number of (inside and outside) occurrences of connector instance c in a connect-equation as an Integer number.

Suggestion for cardinality in Example 1 to return 2 makes me think that you are not simply counting occurrences of the connector instance in the connect equations. What is exactly cardinality then?

I still would like to know why you count the cardinality as 2 in Example 1.

modelica-trac-importer commented 5 years ago

Comment by adrpo on 6 Feb 2014 21:02 UTC You don't count it as 2, you count it as 1. It was just an example of how it could be interpreted wrongly.

Replying to [comment:26 eshmoylova]:

Replying to [comment:13 eshmoylova]:

In Spec 3.2 Rev 2, the cardinality operator is defined as: Returns the number of (inside and outside) occurrences of connector instance c in a connect-equation as an Integer number.

Suggestion for cardinality in Example 1 to return 2 makes me think that you are not simply counting occurrences of the connector instance in the connect equations. What is exactly cardinality then?

I still would like to know why you count the cardinality as 2 in Example 1.

modelica-trac-importer commented 5 years ago

Comment by eshmoylova on 6 Feb 2014 21:32 UTC Reading the specification carefully, I have to say that

connect(e.x, i);

in Example 3 is illegal. In 9.1.3: • expandable connectors can only be connected to other expandable connectors. e is an expandable connector, i is a connector but not expandable. Until you connected e to another expandable connector, it should not be expanded.

modelica-trac-importer commented 5 years ago

Comment by perost on 6 Feb 2014 23:01 UTC Replying to [comment:28 eshmoylova]:

Reading the specification carefully, I have to say that

connect(e.x, i);

in Example 3 is illegal. In 9.1.3: • expandable connectors can only be connected to other expandable connectors. e is an expandable connector, i is a connector but not expandable. Until you connected e to another expandable connector, it should not be expanded.

e is an expandable connector, but e.x isn't (unless it's connected to one, which it isn't in this case). The rule you quote only state that if you have e.g. connect(e, i), then i must also be an expandable connector. Otherwise pretty much every example of expandable connectors in the specification would be illegal.

modelica-trac-importer commented 5 years ago

Comment by eshmoylova on 7 Feb 2014 16:23 UTC True, lots of examples of expandable connectors have the same form. Either the examples are illegal or the Specification needs to be updated. The rule for elaborations connections with expandable connectors says: Then connections containing expandable connectors are elaborated: • When two expandable connectors are connected, each is augmented with the variables that are only declared in the other expandable connector (the new variables are neither input nor output). This is repeated until all connected expandable connector instances have matching variables [i.e. each of the connector instances is expanded to be the union of all connector variables.]

e.x and i are not expandable. e.x should not exist until e is connected to some other expandable connector that contains x, according to this rule. Or there must be another rule that says that the expandable connector must be elaborated when a non-expandable connector is connected to something that should be inside an expandable connector.

I would prefer changing the examples instead of changing the rules. The problem is a tool is implemented based on the rules. But a user follows examples for guidance. When the examples violate the rules we either have to update all the tools or tell the user to follow the rules as they should have, in the first place. Do we need to submit a separate ticket for that? Or is there already a ticket about it?

modelica-trac-importer commented 5 years ago

Comment by perost on 7 Feb 2014 16:33 UTC The spec says the following (from 3.2rev2, page 100):

• One connector in the connect equation must reference a declared component and the (other) undeclared component is handled as follows: • The expandable connector instance is automatically augmented with a new component having the used name and corresponding type. • [Some more rules]

modelica-trac-importer commented 5 years ago

Comment by eshmoylova on 7 Feb 2014 19:06 UTC There are two sets of rules that are specified in 9.1.3. One is about elaborating expandable connectors, let's call it A: How to elaborate connections containing expandable connectors. There is only one case specified for it: "When two expandable connectors are connected,..." The second one is about the rules that apply to expandable connectors, let's call it B. The rules on page 100 are part of the second set.

A and B are written in a way (not part of the same bullet-item list) that implies they act independently. That they must both be satisfied in order to make an equation legal. The rule A is written such that it satisfies the principle of excluded middle. So if the condition of the rule A is not satisfied, we are not in the place to elaborate expandable connectors.

A subrule of B that says "the expandable connector instance is automatically augmented..." but, in order for us to take an action on it, we need to make sure we follow the rule A, which is not the case for connect(e.x, i);. Either the rule A needs to have an additional bullet-item allowing elaborating an expandable connector if we have a connect equation which refers to it anywhere, or the examples need to be changed.

modelica-trac-importer commented 5 years ago

Comment by otter on 8 Feb 2014 19:49 UTC Here is an analysis of the usage of cardinality in the MultiBody library (MSL3.2.1):

Cardinality is used 52-times in asserts of the type:

assert(cardinality(frame_a) > 0, "Connector frame_a must be connected at least once");

If desired, these asserts can be removed (this is backwards compatible). These asserts are present to get better diagnostics. The reason is that for most of the elements of the MultiBody library, something goes wrong if the connectors are not connected. These asserts had been introduced, because users complaint about error messages that are difficult to understand (equations are missing, singular system). Here are some examples:

Since cardinality is used only for better diagnostics here, it could be replaced by an annotation. E.g. 

Frame frame annotation(__Modelica_MustBeConnected=true);

The "Modelica" indicates that it is a vendor annotation and therefore tools can ignore it. This annotation could be introduced in the next MSL version without releasing a new version of the Modelica language standard. If a tool supports this "vendor" annotation, the diagnostics is as good as of today.

Cardinality is used 6-times in two components:

Modelica.Mechanics.MultiBody.Forces.LineForceWithMass
Modelica.Mechanics.MultiBody.Forces.LineForceWithTwoMasses

Here, cardinality is used to add equations: If a Translational force element is only connected to one of the two frames, then the force is added to the other connector with negative sign. I agree this design is not good (the reason was to help users to get correct models). Cardinality cannot be removed in a backwards compatible way. Here are some proposals

(1) Make a non-backwards compatible change and add the "Modelica_MustBeConnected" annotation and hope that this feature was not used too often. If it was used, the corresponding model will lead to an error with a new MSL version.

(2) Make a conversion script and move the current implementation in an "ObsoleteLibrary". Add an implementation that does not use cardinality.

modelica-trac-importer commented 5 years ago

Comment by adrpo on 8 Feb 2014 19:58 UTC From my side I don't think cardinality is bad.

If restricted enough (used just in conditionals in equations and asserts) then we can keep it (make it non-deprecated) and use it for better diagnostics until we come up with better solutions for its usage patterns.

All I'm saying is that we need to come up with better specification on it and restrict it as much as possible.

modelica-trac-importer commented 5 years ago

Comment by pharman on 9 Feb 2014 13:37 UTC Replying to [comment:34 adrpo]:

From my side I don't think cardinality is bad.

I agree, it seems it is deprecated because it is a non-optimal solution, yet so far there isn't an alternative (I don't think yet-another-annotation is really an alternative) and all vendors have had to implement it (including those who started after it was deprecated!).

The issue that some sets of equations are dependent on the connection-sets doesn't go away if cardinality is removed, because we still have Connections.isRoot and Connections.rooted which have the same restrictions on where they can be used. So I too think that a clearer and non-deprecated specification would be better than trying to find another non-optimal solution.

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 10 Feb 2014 08:36 UTC Replying to [comment:32 eshmoylova]:

There are two sets of rules that are specified in 9.1.3. One is about elaborating expandable connectors, let's call it A: How to elaborate connections containing expandable connectors. There is only one case specified for it: "When two expandable connectors are connected,..." The second one is about the rules that apply to expandable connectors, let's call it B. The rules on page 100 are part of the second set.

A and B are written in a way (not part of the same bullet-item list) that implies they act independently. That they must both be satisfied in order to make an equation legal. The rule A is written such that it satisfies the principle of excluded middle. So if the condition of the rule A is not satisfied, we are not in the place to elaborate expandable connectors.

A subrule of B that says "the expandable connector instance is automatically augmented..." but, in order for us to take an action on it, we need to make sure we follow the rule A, which is not the case for connect(e.x, i);. Either the rule A needs to have an additional bullet-item allowing elaborating an expandable connector if we have a connect equation which refers to it anywhere, or the examples need to be changed.

I suggest that this discussion is continued in #1330. See also #1279, #1311 and #1312 (and perhaps #428 and #829). This ticket is long and complicated enough anyway.

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 10 Feb 2014 11:02 UTC Replying to [comment:35 pharman]:

Replying to [comment:34 adrpo]:

From my side I don't think cardinality is bad.

I agree, it seems it is deprecated because it is a non-optimal solution, yet so far there isn't an alternative (I don't think yet-another-annotation is really an alternative) and all vendors have had to implement it (including those who started after it was deprecated!).

The issue that some sets of equations are dependent on the connection-sets doesn't go away if cardinality is removed, because we still have Connections.isRoot and Connections.rooted which have the same restrictions on where they can be used. So I too think that a clearer and non-deprecated specification would be better than trying to find another non-optimal solution.

I would say all of these seem to be solutions that we know are "flawed".

From a spec. point of view the important issue is to ensure that they can be easily implemented, and since we know that they are "flawed" we can be overly strict as long as the actual use-cases work.

So connect, conditional components, and array dimensions depending on them could all be forbidden. As well as applying them to array of connectors, expandable connectors, and anything in expandable connectors. (And possibly additional restrictions; as long as non-connect equations and assert can depend on them.)

Having a better solution than Connections.rooted (which is used to help the compiler by manually "inverting" equations) has also been discussed; I believe something involving inverses would work - but it needs more investigation and we have never had the time to fully investigate that. One reason for using inverse instead is that we could verify both set of equations, to detect mistakes.

For Connections.isRoot it is more complicated, since some variables might have different values depending on the roots selected - it is just that dynamics should stay the same, and I don't know how we can formulate that. Look at Modelica.Mechanics.MultiBody.Parts.Body as an example. Look also at Modelica.Mechanics.MultiBody.Parts.PointMass which had bugs due to this, see https://trac.modelica.org/Modelica/changeset/416 and #50

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 14 Mar 2014 13:56 UTC So connect, conditional components, and array dimensions depending on cardinality etc could all be forbidden.

Hilding: Strictest: assert and if-conditions (without connect in the bodies of them).

For conditional components the cardinality is counted after removing conditionally disabled. As well as applying them to array of connectors, expandable connectors, and anything in expandable connectors.

Go for strictest restriction above Agree: 7 Against: 0 Abstain: 15 (should construct a better solution for the future - including looking at VHDL-AMS that solves this in a global way.)

modelica-trac-importer commented 5 years ago

Comment by msasena on 14 Mar 2014 14:15 UTC This is the 2009 conference paper from Sébastien Furic detailing how concepts from VHDL-AMS could be used to improve model composability in Modelica: Furic 2009

modelica-trac-importer commented 5 years ago

Comment by otter on 15 Mar 2014 20:55 UTC Replying to [comment:38 hansolsson]:

... (should construct a better solution for the future - including looking at VHDL-AMS that solves this in a global way.)

Replying to [comment:39 msasena]:

This is the 2009 conference paper from Sébastien Furic detailing how concepts from VHDL-AMS could be used to improve model composability in Modelica: Furic 2009

To avoid misunderstandings:

Modelica models can be arbitrarily connected together provided the model instances are balanced. This results always in a balanced number of equations and unknowns. In this sense, Modelica models compose (any connection of balanced Modelica models is a valid model).

However, the user would like to have more: Whenever he combines models, the resulting model DAE should have a unique solution. Neither Modelica nor VDHL-AMS nor any other physical modeling environment that I know, has such a guarantee. It seems also very unlikely, that it will ever be possible to construct a language that has such a guarantee: For example, even for a purely linear systems of equations A*x = b (a very simple system) that appears when connecting models together, it is impossible to determine for any A (from a language point of view), whether this system has a unique solution x (without numerical calculations). So clearly, this user wish cannot be fulfilled.

In the paper above from Sébastien Furic it is proposed to use a similar type of connectors as for VHDL-AMS to resolve one potential singularity of electrical circuits when using Modelica connectors (out of millions of possible reasons). Basically, this just means that the model description does not require absolute references as Modelica does. The proposal might work for electrical circuits (this is not yet clear to me, especially for applications on earth where the "grounding" of electrical systems is an important hardware feature for safety reasons and it then might be better to enforce an absolute reference, the earth) but it would make modeling of mechanical and fluid systems unsafe: The reason is that mechanical and fluid systems need an absolute "reference" (zero absolute velocity, zero absolute pressure, zero absolute temperature) and by not enforcing an absolute reference (as VHDL-AMS does, but Modelica does not), it is easy to construct models that are correct from a language point of view, but do not fulfill the physical balance equations (without noticing it).

modelica-trac-importer commented 5 years ago

Comment by msasena on 19 Mar 2014 18:13 UTC Replying to [comment:40 otter]:

In the paper above from Sébastien Furic it is proposed to use a similar type of connectors as for VHDL-AMS to resolve one potential singularity of electrical circuits when using Modelica connectors (out of millions of possible reasons). Basically, this just means that the model description does not require absolute references as Modelica does. The proposal might work for electrical circuits (this is not yet clear to me, especially for applications on earth where the "grounding" of electrical systems is an important hardware feature for safety reasons and it then might be better to enforce an absolute reference, the earth) but it would make modeling of mechanical and fluid systems unsafe: The reason is that mechanical and fluid systems need an absolute "reference" (zero absolute velocity, zero absolute pressure, zero absolute temperature) and by not enforcing an absolute reference (as VHDL-AMS does, but Modelica does not), it is easy to construct models that are correct from a language point of view, but do not fulfill the physical balance equations (without noticing it).

To clarify, Sébastien's paper is not about solving one particular problem. It is about adding features to the connection semantics of Modelica that allow a full view of the connection topology of the entire system. With this information, you can detect singular systems of any domain - not just ones where a ground is missing / misplaced - at compile time. It also provides a method to define absoulte values as well, so your other concern about grounded systems has been addressed in his proposal.

Does it fix every possible topological mistake a user can make? No. But it can reliably and programmatically detect an important class of problems that will help model developers identify their mistakes before they begin simulation work. While I'm not expert, I think the language group would benefit from reading the proposal carefully and deciding how those ideas could help improve the stability of Modelica models.

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 22 Mar 2014 10:25 UTC Updated in r7444