id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
2000	Modelica.Fluid.Examples.IncompressibleFluidNetwork	Christian Schubert	Willi Braun	"Hi,

this model gives rise to some interesting questions, when merging alias variables.
First, we have the warning
{{{
Warning: Aliasset with several free start values
Candidate pipe6.mediums[1].p(start = linspace(500000.0, 500000.0, 2)[1])
Candidate pipe8.mediums[2].p(start = linspace(500000.0, 500000.0, 2)[2])
Candidate pipe5.mediums[1].p(start = linspace(500000.0, 500000.0, 2)[1])
Candidate pipe4.mediums[2].p(start = linspace(500000.0, 500000.0, 2)[2])
Candidate pipe10.mediums[1].p(start = linspace(500000.0, 500000.0, 2)[1])
Select value from pipe6.mediums[1].p(start = linspace(500000.0, 500000.0, 2)[1])
}}}
which might be avoided since
{{{
linspace(x,x,n) = x*ones(n)
}}}
and thus
{{{
linspace(500000.0, 500000.0, 2)[1] == linspace(500000.0, 500000.0, 2)[2]
}}}

Next, we have
{{{
Warning: Aliasset with several free start values
Candidate pipe2.m_flows[3](start = 0.0)
Candidate pipe7.m_flows[1](start = 0.0)
Candidate valve1.m_flow(start = valve1.m_flow_start)
}}}
which is interesting for several reasons. First, let's look at their definition
{{{
Modelica.Media.Interfaces.PartialMedium.MassFlowRate pipe7.m_flows[pipe7.n+1]
    (start = fill(pipe7.m_flow_start, size(pipe7.m_flows, 1)), min = -1E+060);
Modelica.Media.Interfaces.PartialMedium.MassFlowRate valve1.m_flow
    (start = valve1.m_flow_start, min = -1E+060);
}}}
with
{{{
parameter Modelica.Media.Interfaces.PartialMedium.MassFlowRate 
    pipe7.m_flow_start = system.m_flow_start;
parameter Modelica.SIunits.MassFlowRate 
    system.m_flow_start = 0;
parameter Modelica.Media.Interfaces.PartialMedium.MassFlowRate 
    valve1.m_flow_start = valve1.m_flow_nominal;
parameter Modelica.Media.Interfaces.PartialMedium.MassFlowRate 
    valve1.m_flow_nominal = 1;
}}}

Why does the first start attribute get evalauted while the second does not?

For me the warning is correct in this case, I am puzzled though how a tool should decide which to take, since both start values have been given explicitly. Is it safe to say: ""Always take the non-zero start value""?

Also, we get
""Warning: Modification or redeclaration of protected elements is not allowed."" which is correct as stated in Modelica Spec 3.3, Chapter 4.1, p. 33. However, it occurs quite frequently in MSL?

What is your opinion?"	enhancement	assigned	normal	Future	Backend	trunk		merging start values	Adrian Pop fcasella Willi Braun Jens Frenkel