Added default value for ratios parameter

[harmanpa]

Added default value for ratios parameter

[xogeny]

Pete, why do you think this is necessary? I do not like default parameters for generic components because they make it very easy to forget that you need to fill in a value and then you silently get the wrong value because you didn't realize that you needed to change something.

Do you have a compelling justification for why this component should be different?

[harmanpa]

It is an array. A popular Modelica modelling tool comes out with a warning
along the lines of "Cannot determine size(ratios) this is not an error" and
does analysis along the lines of "Model has 10+size(something) unknowns".
We don't, I haven't fully decided whether it is a warning or error that is
given to the user, but the risk is that a model could be created with an
array of unknown size, and expressions that index into it that will only be
valid under certain circumstances, let's say in your model you also had the
equation:

something = ratios[5];

In the context of that model that may or may not be an error. If we use the
model as a component elsewhere and give ratios a size of 4, then we can't
compile it, but feeding back to the user that their submodel is valid until
they actually use it is just confusing. I know this particular model
doesn't fall into that category but we have to issue warnings that it could.

Rather than giving it a value it could have a start value?

thanks

Pete

On 30 April 2013 13:14, Michael Tiller notifications@github.com wrote:

Pete, why do you think this is necessary? I do not like default parameters
for generic components because they make it very easy to forget that you
need to fill in a value and then you silently get the wrong value because
you didn't realize that you needed to change something.

Do you have a compelling justification for why this component should be
different?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5#issuecomment-17223505
.

[xogeny]

Pete, I have to say that I think the "10+size(...)" approach is the right way to go. It is important to recognize that such an analysis looks at both the number of equations and the number of unknowns. You could, as you point out, have a situation where a particular combination leads to a well-posed system. For example, if the number of equations was "12+size(x)" and the number of variables was "12+size(y)" then things work so long as 'x' and 'y' have the same size, but not in other cases. But it is exactly because the expressions for the number of equations and variables don't match that we know there is a problem. So I don't really see a downside to that approach. It is quite nice because in a sense it allows you to check whether the system will always be well-posed over all possible values of parameters. But perhaps I'm misunderstanding your analysis or your concern.

The 'start' attribute approach was exactly what I was thinking. I consider that more of a hint and, as far as I know, a Modelica tool should still warn you about missing values even if a start value is provided. So it doesn't (or at least shouldn't) lead to the situation I was concerned about.

So, in summary, I could live with a start attribute but I think, as a user, it shouldn't be necessary and the tool should be able to check my models properly without.