Inconsistent behaviour of OMC with ThermoPower models

[Francesco Casella]

I am facing a quite weird situation with the latest nigthly, not sure if the problem is new or if it has been there for a while.

Steps to reproduce (old frontend disabled):

• Load the ThermoPower library in OMEdit
• Open ThermoPower.Test.DistributedParameterComponents.TestWaterFlow1DFV_A
• Flatten the model: there are several instances of inStream(). I understand they should be handled by the front end, why aren't they? If I flatten examples from Modelica.Fluid, which uses inStream extensively, there are none
• Simulate the model: the C compiler complains about implicit declaration of function 'inStream', and eventually the linker fails
• The ​Jenkins report says that the simulation of the model is successful. This is odd, as (in principle) the frontend in Linux and Windows is the same.

@adeas31, @perost, can you please help me to sort this out? This is critical for the next release...

[Per Östlund]

The model works fine if I compile it using OMC directly, which is what Jenkins does. Unfortunately I can't get OMEdit to compile right now, I've tried all my usual tricks but nothing seems to work at the moment.

However, if there is an issue I strongly suspect it has to do with System.getHasStreamConnectors(), which is basically a global variable that the frontends use to detect whether stream connectors are used or not. This is set by the SCode->Absyn translation, so there are two major issues.

The first issue is that it gets set to true if any loaded model uses stream connectors, regardless of whether that model is used by the flattened model or not. The second issue is that anyone can change the flag between the SCode->Absyn translation and the NF, since it's global, which I suspect is the issue here.

I'm currently pushing in a change that fixes both those issues (​#305), by making the NF clear the flag at the start of the instantiation and set it if any calls to inStream or actualStream is encountered while flattening the model. We'll see whether it fixes the reported issue too, but I can't think of anything else that could cause this.

[Per Östlund]

I forgot that inStream calls can be generated even if inStream isn't explicitly used in the model. I've changed it to set the flag when stream connectors are used instead now, rather than stream operators. I opened a new PR (​#306) for that.

[Francesco Casella]

Replying to perost:

I forgot that inStream calls can be generated even if inStream isn't explicitly used in the model.

Do you mean if actualStream only is used?

[Per Östlund]

Replying to casella:

Replying to perost:

I forgot that inStream calls can be generated even if inStream isn't explicitly used in the model.

Do you mean if actualStream only is used?

No, I mean that inStream is part of the equations generated for stream connection sets. Anyway, the PR is merged now, so please check if it fixes the issue for you.

[Francesco Casella]

Replying to perost:

No, I mean that inStream is part of the equations generated for stream connection sets.

You're right, I forgot about that part :)

Anyway, the PR is merged now, so please check if it fixes the issue for you.

Will do.

[Francesco Casella]

Seems to work fine. We'll do more testing on Monday. Thank you!