Opened 6 years ago
Last modified 6 years ago
#5252 new defect
Misleading and incomplete output regarding conflicting start and nominal attributes
Reported by: | Francesco Casella | Owned by: | Lennart Ochel |
---|---|---|---|
Priority: | blocker | Milestone: | 2.0.0 |
Component: | Backend | Version: | |
Keywords: | Cc: | Karim Adbdelhak, Andrea Bartolini, Vitalij Ruge |
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 by , 6 years ago
Cc: | added |
---|
by , 6 years ago
Attachment: | TestPriorities.mo added |
---|
comment:2 by , 6 years ago
Milestone: | 1.14.0 → 2.0.0 |
---|
I guess this will have to wait until 2.0.0