Problems with inheritance of the MultiBody.World model

[Francesco Casella]

Consider this simple test case

package TestWorldExtends
  model World
    extends Modelica.Mechanics.MultiBody.World(n = {0, 0, -1});
  end World;

  model Example
    inner World world;
  end Example;
end TestWorldExtends;

If I compile the Example model in OMC I get

Translation Error
[Modelica.Mechanics.MultiBody: 1431:3-1439:110]:
Variable Types.GravityTypes.PointGravity not found in scope TestWorldExtends.World

The model works in Dymola. I'm not sure if this is an OMC problem or a Modelica 3.3r1 specification problem, that actually does not allow this, while Dymola supports it anyway. Can you please have a look?

[Francesco Casella]

I have now a simpler example that reproduces the problem, please try the attached Test.S model.

Apparently the problem is related to functions defined in outer objects that are redeclared.

[Adrian Pop]

The things in Test.mo are not allowed by the Modelica Specification as far as I know.
You cannot get to a model via a component using the dot notation.
You can only get to a function (i.e. world.gravityAcceleration).

The test model has: system.Oil.density where:

• system is a component
• Oil is a model
• density is a function

TestWorldExtends should work fine but the current front-end has issues with it. That is a bug.

[Adrian Pop]

Hmmm, actually when looking a bit closer on Modelica Spec 3.3:

5.3.2 Composite Name Lookup

For a composite name of the form A.B or A.B.C, etc. lookup is performed as follows:

• The first identifier (A) is looked up as defined above.
• If the first identifier denotes a component, the rest of the name (e.g., B or B.C) is looked up among the declared named component elements of the component.
• If not found, and if the first identifier denotes a scalar component; and if the composite name is used as a function call, the lookup is also performed among the declared named class elements of the scalar component, and must find a non-operator function. All identifiers of the rest of the name (e.g., B and B.C] must be classes.

This can be interpreted in several ways: they say you should search the "class elements of the scalar component, and must find a non-operator function" which would mean that B should be a function but then they also say B and B.C must be classes which would mean they allow going through a model B to find a function C.

[Per Östlund]

Replying to adrpo:

This can be interpreted in several ways: they say you should search the "class elements of the scalar component, and must find a non-operator function" which would mean that B should be a function but then they also say B and B.C must be classes which would mean they allow going through a model B to find a function C.

The "must find" part refers to the final result of the lookup, i.e. the last part of the name must refer to a function if the first part is a scalar component and the rest classes. So this is legal.

The issue is that the dependency analysis doesn't figure out that Test.Fluids.RealOil.density is actually used, and removes it. A workaround is to just disable the dependency analysis with -d=-scodeDep and pray that it doesn't break anything.

[Francesco Casella]

Replying to perost:

The issue is that the dependency analysis doesn't figure out that Test.Fluids.RealOil.density is actually used, and removes it. A workaround is to just disable the dependency analysis with -d=-scodeDep and pray that it doesn't break anything.

I tried that, but got this:

Test.S.o:Test.S.c:(.rdata$.refptr.compiledWithSymSolver[.refptr.compiledWithSymSolver]+0x0):
undefined reference to `compiledWithSymSolver'
collect2.exe: error: ld returned 1 exit status
Test.S.makefile:30: recipe for target 'omc_main_target' failed
\tools\msys\mingw64\bin\mingw32-make: *** [omc_main_target] Error 1
Compilation process failed. Exited with code 2.

[Adrian Pop]

For me it works to compile with -d=-scodeDep on Windows.

[Francesco Casella]

The originally reported model still doesn't work. Let's see if it works with the new front-end when inner/outer gets implemented

[Per Östlund]

Replying to casella:

The originally reported model still doesn't work. Let's see if it works with the new front-end when inner/outer gets implemented

Inner/outer is already implemented, and should be much better than in the old instantiation. The simple test case in the description currently fails on a call to Orientation, since record constructors haven't been implemented yet.

[Francesco Casella]

Replying to perost:

Inner/outer is already implemented, and should be much better than in the old instantiation. The simple test case in the description currently fails on a call to Orientation, since record constructors haven't been implemented yet.

Ops, sorry, I missed that you changed from 0 to 90% implemented here.

[Francesco Casella]

I retried the TestWorldExtends.Example model, C code is generated, but at compile time I first get a warning

TestWorldExtends.Example.c: In function 'TestWorldExtends_Example_eqFunction_500':
TestWorldExtends.Example.c:530:3: warning: implicit declaration of function 'root' [-Wimplicit-function-declaration]
   root(omc_Modelica_Mechanics_MultiBody_Frames_Orientation(threadData, tmp3, tmp4));

and then a linker error

TestWorldExtends.Example.o:TestWorldExtends.Example.c:(.text+0x2831): undefined reference to `root'
TestWorldExtends.Example_06inz.o:TestWorldExtends.Example_06inz.c:(.text+0x2a27): undefined reference to `root'
collect2.exe: error: ld returned 1 exit status

If I flatten the model, I see this line

  root(world.frame_b.R);

which obviously doesn't make any sense in the flat model, where all the connection graph handling should have disappeared. Why is this declaration still there?

[Per Östlund]

Replying to casella:

If I flatten the model, I see this line

  root(world.frame_b.R);

which obviously doesn't make any sense in the flat model, where all the connection graph handling should have disappeared. Why is this declaration still there?

Because the overconstrained connection handling is still not implemented.

[Adrian Pop]

After #4966 was fixed we now get issues with the code generation for equation:

world.z_label.cylinders[1].lengthDirection = Modelica.Mechanics.MultiBody.Frames.T.resolve1(world.z_label.R_rel, vector({{{{world.z_label.lines[1,2,1], world.z_label.lines[1,2,2]}} - {{world.z_label.lines[1,1,1], world.z_label.lines[1,1,2]}}}, {0.0}}));

which results in compilation errors:

TestWorldExtends.Example.c: In function 'TestWorldExtends_Example_eqFunction_453':
TestWorldExtends.Example.c:146:3: error: aggregate value used where a float was expected
   array_alloc_scalar_real_array(&tmp2, 2, (modelica_real)tmp3, (modelica_real)0.0);
   ^

I guess the backend/codegen doesn't like the array equation where LHS is not expanded into its elements as lenghtDirection is an array or 3.

[Per Östlund]

The test model in the description now simulate using the new frontend, so I guess we can consider this issue to be fixed.