Protected variables are incorrectly written to the result file

[Francesco Casella]

I have some models where I am trying to make the size of the result file more manageable by making protected the internal variables of a model which are not of interest. I can do it in two ways:

• put some variables in a model inside the protected section
• for composite model, declare the sub-models in the protected section, so that their entire contents become protected

In both cases, the corresponding variables are correctly marked as isProtected = "true" hideResult = "false" in the _init.xml file. However, the variables from the first set are correctly not written to the result file, while the variables from the second set are written to the file.

Q1: Why is this happening?

Q2: Shouldn't the simulation runtime use the attributes from the XML file to decide whether or not a variable needs to be saved onto disk?

I can provide the test case privately to any interested developer.

[Rüdiger Franke]

​PR1156 should do it.

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

@perost, can you make sure all variables from protected model instances are not written to file with the new front-end? As of today, the new FE produces wrong generated code.

[Per Östlund]

Replying to casella:

@perost, can you make sure all variables from protected model instances are not written to file with the new front-end? As of today, the new FE produces wrong generated code.

The new frontend currently does not mark elements of a protected class instance as protected, because from the point of view of the instantiation they aren't protected. If they were marked as such the check for access of protected variables wouldn't work correctly. The old frontend did mark such elements as protected, but this didn't cause any problems since it didn't check the visibility during lookup anyway.

But it should be fairly easy to pass protected downward during the conversion to the DAE, so that components become protected if any of their parents' are protected. Then it won't interfere with the instantiation since it's done after, and should have a negligible impact on performance.

Also, in the description you say that you declare sub-models for composite models in the protected section, but I assume you mean sub-model instances?

[Francesco Casella]

Replying to perost:

The new frontend currently does not mark elements of a protected class instance as protected, because from the point of view of the instantiation they aren't protected. If they were marked as such the check for access of protected variables wouldn't work correctly. The old frontend did mark such elements as protected, but this didn't cause any problems since it didn't check the visibility during lookup anyway.

OK.

But it should be fairly easy to pass protected downward during the conversion to the DAE, so that components become protected if any of their parents' are protected. Then it won't interfere with the instantiation since it's done after, and should have a negligible impact on performance.

Good. It's not high-priority as of today, but it could be useful later on

Also, in the description you say that you declare sub-models for composite models in the protected section, but I assume you mean sub-model instances?

Of course.

[Per Östlund]

Replying to casella:

Good. It's not high-priority as of today, but it could be useful later on

I implemented it anyway in e163ff57, because it will save me time when comparing flat models between the old and new frontend.

But I'm not sure what the issues with the old frontend are, so I don't know if this actually solves this particular issue.

[Francesco Casella]

Replying to perost:

But I'm not sure what the issues with the old frontend are, so I don't know if this actually solves this particular issue.

I need the NF to be good enough to flatten my test cases in order to tell