Opened 5 years ago
Last modified 5 years ago
#5252 new defect
Misleading and incomplete output regarding conflicting start and nominal attributes
Reported by: | casella | Owned by: | lochel |
---|---|---|---|
Priority: | blocker | Milestone: | 2.0.0 |
Component: | Backend | Version: | |
Keywords: | Cc: | Karim.Abdelhak, Andrea.Bartolini, vitalij |
Description
Please consider the following test case (also attached)
package TestPriorities type Pressure = Real(start = 1e5, nominal = 1e6); model M parameter Pressure pstart = 2e5; parameter Pressure pnom = 3e5; Pressure p1; Pressure p2(start = pstart, nominal = pnom); equation p1 = p2; p1 + log(p1) = 2e5; end M; model Test M m1; M m2(pstart = 5e5, pnom = 6e5); end Test; end TestPriorities;
In both m1 and m2 the expected behaviour is that the start and nominal value of p2 are chosen, namely 2e5 and 3e5 for m1 and 5e6, 6e5 for m2
By simulating Test with the LOG_NLS_V simulation flag, it is possible to check that these values are indeed chosen, so OMC is working as expected.
However, the following notification is issued
[1] 19:44:16 Symbolic Warning The model contains alias variables with conflicting start and/or nominal values. It is recommended to resolve the conflicts, because otherwise the system could be hard to solve. To print the conflicting alias sets and the chosen candidates please use -d=aliasConflicts.
This statement is both inaccurate and misleading.
If the conflicting start/nominal attribute have different confidence number, the intended behaviour is to use the one with a lower number, as explained in Section 8.6.2 of the specification. This is what every modeller would expect. Manually propagating start and nominal values to resolve the conflict in this case would a completely unnecessary, very tedious and definitely not according to an object-oriented declarative modelling paradigm.
For example, it is intended that the start/nominal attributes of internal model variables, which are set by parameters such as pstart and pnom, override the default values of connector variables they are connected to, which have lower priority. Manually resolving this conflict would be a very dumb thing to do.
A warning should only be issued if there are conflicting start/nominal attributes with the same confidence number.
If I turn on the -d=aliasConflicts flag, I only get output regarding the nominal attributes
[1] 19:26:50 Translation Warning Alias set with conflicting nominal values * Candidate: m2.p2(nominal = m2.pnom = 600000.0, confidence number = 2) * Candidate: m2.p1(nominal = 1000000.0, confidence number = 7) => Select value from m2.p2(nominal = m2.pnom = 600000.0) for variable: m2.p1 [2] 19:26:50 Translation Warning Alias set with conflicting nominal values * Candidate: m1.p2(nominal = m1.pnom = 300000.0, confidence number = 2) * Candidate: m1.p1(nominal = 1000000.0, confidence number = 7) => Select value from m1.p2(nominal = m1.pnom = 300000.0) for variable: m1.p1
First and foremost, this should be a notification, not a warning, unless the selected value has the same confidence number of some other conflicting alias. Second, the same output should also be issued for the start attributes, not only for the nominal attributes.
Attachments (1)
Change History (3)
comment:1 Changed 5 years ago by casella
- Cc Karim.Abdelhak vitalij added
Changed 5 years ago by casella
comment:2 Changed 5 years ago by casella
- Milestone changed from 1.14.0 to 2.0.0
I guess this will have to wait until 2.0.0