tableOnFile parameter of a CombiTable2D appears modifiable when using NF

[massimo ceraolo]

Consider the enclosed "Test.mo" along with "Test.TXT"
The table output should be 1 when tableOnFile is false, 0.5 when it is true.
This is what happens when we simulate.

If, instead, we change the tableOnFile value from the Variables Browser and re-simulate, the table output stays unchanged.

To obtain this behaviour one has to set -d=newInst,nfAPI.
Tested from OMEdit Connected to OpenModelica v1.14.0-dev-26504 (64 bit, Win)

[Adeel Asghar]

I haven't tested it yet but just guessing if this is the same issue as was reported in #5377.

[massimo ceraolo]

Unfortunately not: I've verified that "Evaluate all parameters" is unchecked

[Adeel Asghar]

It is always a good idea to post the omeditcommunication.log file so we know which flags are used for the simulation.

I tested a bit and for me tableOnFile is not changeable. I also attached a sample script that simulates the model without any flags and then you can see the Test_init.xml file and look for variable combiTable2D1.tableOnFile and attribute isValueChangeable. Note that it is false.

[massimo ceraolo]

Replying to adeas31:

It is always a good idea to post the omeditcommunication.log file so we know which flags are used for the simulation.

Sorry for this!

In fact, repeating the test here from my home PC I don't see tableOnfile as modifiable. Tomorrow I'll repeat from work and will send you also omeditcommunication.log.
So maybe we will understand what strange setting makes it look as modifiable.

[massimo ceraolo]

I've checked.
tableOnFile (wrongly) appears to be modifiable if you set -d=newInst,nfAPI as Additional Translation Flags.

So it is a NF issue: I'm going to change ticket title and description

[Per Östlund]

The tableOnFile parameter is defined as structural by the NF, because it's used as a condition in an if-equation with only parameter expression conditions. So it gets evaluated everywhere in the model. The OF is less consistent in this regard, and evaluates the parameter in some places but not in others. I take it this isn't the issue, but rather that OMEdit shouldn't allow the parameter to be modified if it's structural?

How does OMEdit decide which parameter are modifiable? Does it look at the _init.xml or does it use some API call?

[Adeel Asghar]

Replying to perost:

The tableOnFile parameter is defined as structural by the NF, because it's used as a condition in an if-equation with only parameter expression conditions. So it gets evaluated everywhere in the model. The OF is less consistent in this regard, and evaluates the parameter in some places but not in others. I take it this isn't the issue, but rather that OMEdit shouldn't allow the parameter to be modified if it's structural?

How does OMEdit decide which parameter are modifiable? Does it look at the _init.xml or does it use some API call?

It looks for isValueChangeable attribute value inside _init.xml file.

[Per Östlund]

Replying to adeas31:

Replying to perost:

The tableOnFile parameter is defined as structural by the NF, because it's used as a condition in an if-equation with only parameter expression conditions. So it gets evaluated everywhere in the model. The OF is less consistent in this regard, and evaluates the parameter in some places but not in others. I take it this isn't the issue, but rather that OMEdit shouldn't allow the parameter to be modified if it's structural?

How does OMEdit decide which parameter are modifiable? Does it look at the _init.xml or does it use some API call?

It looks for isValueChangeable attribute value inside _init.xml file.

Good, tableOnFile has that attribute set to true when using the NF. I'll see if I can figure out where that's coming from and fix it.

[Per Östlund]

Fixed in ​PR #237.

The issue was that the OF kept a BST with all the parameters it marked as structural, and this was used in the "before backend transform" to mark all such parameters as final. The NF has this information available when creating the DAE, so I decided to just cut out the middleman and mark those parameters as final at that stage instead since it's practically free.

This means that structural parameters are now marked as final in the flat model when using the NF, while the OF adds the prefixes immediately after dumping the model. As far as the backend is concerned it's all the same, the only difference is what the users see.

[Per Östlund]

Fixed in 4c6b5ee.