compilation fails: why?

[m.thorade@…]

Not sure if this is the right place to ask: Thanks for testing the BuildingSystems library, we are looking into improving compatibility these days. One of the models is giving an error that I do not understand:
​https://libraries.openmodelica.org/branches/master/BuildingSystems/files/BuildingSystems_BuildingSystems.Buildings.Constructions.Examples.WallThermal1DNodes.err
Compilation starts, but then starts to produce a lot of errors.
Is that something that has to be fixed in our library? From the message, I have no good idea where to start looking.

[casella]

Matthis, thanks for reporting. This is definitely the right place to do so.

Your library is most probably fine, particularly if it runs with other Modelica tools. The problem here is a the code generation level: some Modelica data structures are not handled correctly and generate broken C code that the C compiler cannot handle.

[Matthis Thorade <m.thorade@…>]

OK, thanks for giving some insight.

The same error appears also in a simpler model:
​https://libraries.openmodelica.org/branches/master/BuildingSystems/files/BuildingSystems_BuildingSystems.HAM.HeatConduction.Examples.MultiLayerHeatConduction1DNodes.err

but not in another even simpler model that should appear here in the next days:
​https://libraries.openmodelica.org/branches/master/BuildingSystems/files/BuildingSystems_BuildingSystems.HAM.HeatConduction.Examples.HeatConduction1DNodes.err

All our examples (should) compile in Dymola, but that does not mean they are correct Modelica, and in this case we are using an array of arrays, that is redeclared somewhere and maybe we can find simpler way to express the same.

[sjoelund.se]

This seems to be... a non-linear system of parameters which for some reason cannot be looked up during code generation? Seems a bit odd.

[sjoelund.se]

So this is an inverse algorithm, but it doesn't expand its dependencies and the backend just hopes the code generator will handle it anyway. The backend or simcode probably needs to scalarize the dependencies so it is possible to store/restore the old values:

$Pbody$lB1$rB$Player$lB2$rB$Pdx$lBtmp3$rB /* body[1].layer[2].dx[UNKNOWN_SUBSCRIPT (* 1:5 *)]*/ = OLD_0;

@Willi: Do you have time to have a look?

[wbraun]

Tried to fix code generation issue in ​Pull Request. Now the example compiles at least, but has some issues with division by zero.

[wbraun]

Now the PullRequest passed the testsuite, but the examples

BuildingSystems.HAM.HeatConduction.Examples.MultiLayerHeatConduction1DNodes
BuildingSystems.Buildings.Constructions.Examples.WallThermal1DNodes

do still not simulate due to initialization issues.

Maybe the new generated code does need some review.

[wbraun]

Both of the reported models started to simulate with this ​PR2249. At the end the issue was that our initialization forgot to initialize algorithms.

[m.thorade@…]

Awesome, thanks! This is one of the basic models, so the fix should help in a couple of places.

[sjoelund.se]

​https://libraries.openmodelica.org/branches/history/master/2018-02-28%2011:14:42..2018-03-01%2012:05:53.html
​https://libraries.openmodelica.org/branches/history/master/2018-03-02%2012:05:51..2018-03-02%2023:30:59.html

So BuildingSystems +9 compile, 5 of which now simulate. With simulation errors such as:

assert            | debug   | BuildingSystems_BuildingSystems.Applications.BuildingTypes.Germany.MultistoreyBuilding1958to1968_functions.c:406: Invalid root: (-1.72286e-15)^(0.4)

(Which I don't know the nominal value of; if it should be "0" or if it's an error)

[wbraun]

hm, the value (-1.72286e-15) is most likely a result of a non-linear an probably should be zero. Maybe it's minimal value is zero then we could adjust after the non-linear solver is done. I will try it, will see what happens.