Invalid "form for a connector" error in new frontend

[crupp@…]

Using this model:

model Connection_test

model Massholder

Modelica.Mechanics.MultiBody.Parts.Body[3] body(each m=1);

end Massholder;
  
  inner Modelica.Mechanics.MultiBody.World world;
  Massholder holder;
  Modelica.Mechanics.MultiBody.Forces.Spring spring(c = 1, s_unstretched = 1);
  Modelica.Mechanics.MultiBody.Parts.Fixed fixed(r = {1, 1, 1});
  
equation
 
  connect(fixed.frame_b, spring.frame_a);
  
  for i in 1:3 loop
    connect(spring.frame_b, holder.body[i].frame_a);
  end for;

end Connection_test;

I get the translation error:

[Connection_test: 19:5-19:52]: holder.body[i].frame_a is not a valid form for a connector, connectors must be either c1.c2...cn or m.c (where c is a connector and m is a non-connector).

This model works with the old frontend, but not the new. As far as I'm aware, everything is valid Modelica.

[Francesco Casella]

@perost, if this is a quick fix it would be nice to have in 1.14.0, since it is a regression w.r.t. the old frontend. Otherwise please reschedule to 2.0.0

[Per Östlund]

The error is correct as far as I can see, the connector reference does not conform to either of the two forms laid out in the Modelica specification (section 9.1). The old frontend didn't check that restriction, while the new one does.

I don't really know the reason for this particular restriction though. I could change the error to a warning instead, but maybe there are good reasons for why the specification only allows the forms it does?

[Francesco Casella]

My interpretation of the specification is that c1, c2, ... cn are connectors, and in this case body[i].frame is indeed a connector. Otherwise, connecting arrays of objects together would be pretty impossible. There is no reason for the restriction you mention.

BTW, the ​TransmissionLine model in the ScalableTestSuite library already uses this construct:

      for i in 1:N loop
        connect(R[i].n, L[i].p);
        connect(C[i].p, L[i].n);
        connect(C[i].n, pin_ground);
      end for;

and it works fine with the NF, as expected, so I suspect the issue here is that there is one more level of indirection than in the ScalableTestSuite test case.

[Per Östlund]

Replying to casella:

My interpretation of the specification is that c1, c2, ... cn are connectors, and in this case body[i].frame is indeed a connector. Otherwise, connecting arrays of objects together would be pretty impossible. There is no reason for the restriction you mention.

body[i].frame is a connector reference, and it follows the second form of reference mentioned in the specification, m.c where m is a non-connector element and c is a connector element. Any of the components may optionally also have array subscripts.

body[i].frame would in fact have been perfectly fine, but the model is using holder.body[i].frame_a which conforms to neither the c1.c2...cn nor the m.c forms but rather m1.m2.c.

BTW, the ​TransmissionLine model in the ScalableTestSuite library already uses this construct:

      for i in 1:N loop
        connect(R[i].n, L[i].p);
        connect(C[i].p, L[i].n);
        connect(C[i].n, pin_ground);
      end for;

and it works fine with the NF, as expected, so I suspect the issue here is that there is one more level of indirection than in the ScalableTestSuite test case.

Same thing here, it's using the m.c form.

[Francesco Casella]

Replying to perost:

body[i].frame would in fact have been perfectly fine, but the model is using holder.body[i].frame_a which conforms to neither the c1.c2...cn nor the m.c forms but rather m1.m2.c.

Sorry, I missed this point. However, by following the same argument I put forward in the previous comment, holder.body[i] is indeed a model, so holder.body[i].frame_a fits m.c nicely

I understand the rationale of the specification is that you can have two types of connector references: one for inside connections, where you have a reference to a connector, or to a sub-connector in hierarchical connectors, and another one where you refer to connectors of non-connector components. Whether or not this non-connector component has a dot in the name, it shouldn't matter. At least, I can't see any good reason for such a limitation.

I agree that the specification could be more explicit, indicating m1.m2...mp.c. Shall I open a ticket on the MA github page?

[Per Östlund]

Replying to casella:

I agree that the specification could be more explicit, indicating m1.m2...mp.c. Shall I open a ticket on the MA github page?

Please do, if it's actually intended that m1.m2...mp.c should be allowed the specification needs to be changed. None of the libraries that we test use this form, so I've always assumed there's a good reason for not allowing it.

[Francesco Casella]

See ​#2410 on the Modelica Specification issue tracker.

I would suggest @perost and @adrpo to subscribe to the MA github group, so I can involve them in the discussion.

[Per Östlund]

Replying to casella:

I would suggest @perost and @adrpo to subscribe to the MA github group, so I can involve them in the discussion.

I already am.

[Francesco Casella]

Strange that I didn't manage to assign you to the issue. Can you please do it yourself?

[Per Östlund]

Replying to casella:

Strange that I didn't manage to assign you to the issue. Can you please do it yourself?

I don't think I can do that myself. But it doesn't really matter, I'm notified when anyone writes something on an issue anyway.

[Francesco Casella]

Maybe only Thomas Beutlich can do that

[Francesco Casella]

Hans Olsson in [ModelicaSpecification #2410] suggests to expose the body connector

model Massholder
     Modelica.Mechanics.MultiBody.Parts.Body[3] body(each m=1);
     .. frame_a[3];
   equation
       connect(frame_a, body.frame_a);
   end Massholder;
   Massholder holder;
equation 
  connect(..., holder.frame_a[j]);

and then connect to that frame_a connector. This solves the user requirement of this ticket without the need of discussing changes to the Modelica Specification.

[crupp@…]

Replying to casella:

Hans Olsson in [ModelicaSpecification #2410] suggests to expose the body connector
and then connect to that frame_a connector. This solves the user requirement of this ticket without the need of discussing changes to the Modelica Specification.

Understood. I had come to a similar workaround in the meantime.

Thank you for your diligence on this topic.