id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5252	Misleading and incomplete output regarding conflicting start and nominal attributes	Francesco Casella	Lennart Ochel	"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."	defect	new	blocker	2.0.0	Backend				Karim Adbdelhak Andrea Bartolini Vitalij Ruge