Questionable warning with annotation(Evaluate = true) in the NF

[casella]

Please check the following model with the NF.

model TestEvaluate
  parameter Real p annotation(Evaluate = true);
end TestEvaluate;

The NF reports:

[1] 23:52:47 Translation Warning
[TestEvaluate: 2:3-2:47]: Parameter p has annotation(Evaluate=true) and no binding.

I don't see why one should get a warning in this case. An error should be obtained when trying to run this model, but unless one wants to do that, there's nothing wrong with it, exactly as in the case of

model TestEvaluate
  parameter Real p;
end TestEvaluate;

which gives no error despite the lack of any binding. Aren't those two cases equivalent?

[perost]

Having annotation(Evaluate = true) means that the modeler has explicitly told the compiler that they want the parameter to be evaluated, so presumably there's a good reason for why the parameter should be evaluated.

The compiler will still try to simulate the model anyway, but without the warning the user wouldn't get any indication that the parameter hasn't been evaluated like the modeler wanted (unless evaluating the parameter is necessary due to it being structural of course).

[casella]

My point is that "Check" is often applied to components that cannot be simulated by themselves, because the lack the proper inputs and/or boundary conditions. In this case one should not check if the model can be simulated, but rather if the mode is syntactically correct, if all lookup goes well, and finally if the model is balanced.

Think of checking a resistor, obviously a resistor by itself cannot be simulated. In this case, the fact that the parameter value (e.g. the resistance) should be irrelevant, since the component cannot be simulated anyway.

In fact, this is already the case for non-evaluated parameters: without the Evaluate annotation, the compiler does not complain that the parameter has no value, even though this would make it impossible to simulate it (see the second example above). This is the appropriate behaviour. We should also get it in case Evaluate = true is set.

[perost]

Replying to casella:

My point is that "Check" is often applied to components that cannot be simulated by themselves, because the lack the proper inputs and/or boundary conditions. In this case one should not check if the model can be simulated, but rather if the mode is syntactically correct, if all lookup goes well, and finally if the model is balanced.

It's just a warning and won't affect the result of the check though, but it tells the user "you should supply a value for this parameter if you want to use the component in a simulation". Don't you think that's useful? We could of course hide the warning when checking a model, but I fail to see why it's an issue.

I also disagree that the second example is equivalent. It can be ok for a parameter to not have a value, the value might for example be supplied when running the simulation. But if the modeler indicates that the parameter should be evaluated it needs to have a value in the model itself for the compiler to be able to do so.

[casella]

Replying to perost:

It's just a warning and won't affect the result of the check though, but it tells the user "you should supply a value for this parameter if you want to use the component in a simulation". Don't you think that's useful?

I don't think so.

Not supplying parameter values in reusable components is a perfectly legitimate practice, because we want to make sure that a value is supplied when simulating the model, so the end user gets an error when trying to simulate a model where all the necessary parameter values have not been supplied.

I don't see the point at harassing a model developer with this warning, that seems to imply that you should better provide a default, to get a "better quality model", because the warning would be gone. Now that will be a really bad modelling practice, because then end users won't notice at all if they forgot to input important parameters in their user model, and get plain wrong results or inexplicable initialization/simulation failures.

BTW, this argument would imply that we should also supply a similar warning in case of no annotation. Which means, the majority of MSL models will generate warnings when checked. I don't think this is appropriate.

We could of course hide the warning when checking a model, but I fail to see why it's an issue.

IMHO perfectly legitimate models should generate no warnings at all.

I also disagree that the second example is equivalent. It can be ok for a parameter to not have a value, the value might for example be supplied when running the simulation. But if the modeler indicates that the parameter should be evaluated it needs to have a value in the model itself for the compiler to be able to do so.

This is true, but the binding can alwas be provided at later stages, e.g. when instantiating the model. I think the main argument is: if it's OK don't warn against it.

[perost]

Replying to casella:

Not supplying parameter values in reusable components is a perfectly legitimate practice, because we want to make sure that a value is supplied when simulating the model, so the end user gets an error when trying to simulate a model where all the necessary parameter values have not been supplied.

The end user will only get an error if the parameter isn't given a value at all (that's not true actually, both your models currently simulate successfully). Giving the parameter a value after the model has been compiled might be fine as long as the parameter isn't structural, but in that case it won't be evaluated like the modeler wanted.

I don't see the point at harassing a model developer with this warning, that seems to imply that you should better provide a default, to get a "better quality model", because the warning would be gone. Now that will be a really bad modelling practice, because then end users won't notice at all if they forgot to input important parameters in their user model, and get plain wrong results or inexplicable initialization/simulation failures.

So maybe we should display a different message when checking a model? Or would you prefer the frontend to silently ignore it in that case?

BTW, this argument would imply that we should also supply a similar warning in case of no annotation. Which means, the majority of MSL models will generate warnings when checked. I don't think this is appropriate.

No, parameters without an annotation shouldn't be evaluated (unless they're structural), so not giving them a value is fine as far as the frontend is concerned. But having Evaluate = true and no value means that the frontend won't be able to do what the modeler has asked it to do, i.e. evaluate the parameter.

[casella]

Replying to perost:

The end user will only get an error if the parameter isn't given a value at all (that's not true actually, both your models currently simulate successfully).

This is a problem. According to the Specification, I understand both models should fail, because they lack any binding or initial equation. In case a modifier for the start attribute is present, then the start value can be used as a default, with a warning message (see Section 8.6) but that's not the case here.

Strangely enough Dymola accepts the first model (which it shouldn't), while it correctly fails on the second.

Giving the parameter a value after the model has been compiled might be fine as long as the parameter isn't structural, but in that case it won't be evaluated like the modeler wanted.

This is not my point, please see below.

So maybe we should display a different message when checking a model? Or would you prefer the frontend to silently ignore it in that case?

My advice is that no warning should be issued when checking both models, because there is nothing wrong per se in eiter one, as long as they are given a binding equation when instantiating them.

However, both models should fail when trying to simulate them, because they actually lack a proper binding or initial equation (or even a default value given by a modified start attribute). I'm not 100% sure if this is a job for the frontend or for the backend.

No, parameters without an annotation shouldn't be evaluated (unless they're structural), so not giving them a value is fine as far as the frontend is concerned. But having Evaluate = true and no value means that the frontend won't be able to do what the modeler has asked it to do, i.e. evaluate the parameter.

That's precisely my point. When checking a model, different things should be done than when simulating it. When you are analyzing the correctness of the two models above, there is actually no need at all to evaluate the parameters.

I understand this can be problematic, because in most cases structural parameters should be evaluated in order to be able to instantiate a model and then check it (e.g. the size N of discretized 1D distributed parameter models), so if Evaluate = true is considered equivalent to having a structural parameter, it may not be possible to distinguish among these two cases. I currently have no idea how to sort this out.

[casella]

See #5739

[perost]

Replying to casella:

I understand this can be problematic, because in most cases structural parameters should be evaluated in order to be able to instantiate a model and then check it (e.g. the size N of discretized 1D distributed parameter models), so if Evaluate = true is considered equivalent to having a structural parameter, it may not be possible to distinguish among these two cases. I currently have no idea how to sort this out.

I don't think this is a problem, Evaluate = true really only means: "this parameter might not be structural, but please evaluate it anyway if you can". If the parameter doesn't fulfill the necessary critera, such as having a binding that can be evaluated, then the frontend won't evaluate it.

The issue is rather that the frontend will currently try to evaluate any structural parameters even when checking a model, and will fail if it can't do that. This mostly affects array dimensions I guess, since checkModel can't yet handle unspecified dimensions. I.e. for a model such as:

model M
  parameter Integer n;
  Real x[n] = zeros(n);
end M;

it will fail, instead of saying that the model has n variables and equations. But whether the parameter has an Evaluate-annotation or not doesn't matter in that case.

[casella]

Replying to perost:

I don't think this is a problem, Evaluate = true really only means: "this parameter might not be structural, but please evaluate it anyway if you can". If the parameter doesn't fulfill the necessary critera, such as having a binding that can be evaluated, then the frontend won't evaluate it.

Sounds good. In this case, if the check operation is performed, the compiler shouldn't issue a warning.

The issue is rather that the frontend will currently try to evaluate any structural parameters even when checking a model, and will fail if it can't do that. This mostly affects array dimensions I guess, since checkModel can't yet handle unspecified dimensions. I.e. for a model such as:

model M
  parameter Integer n;
  Real x[n] = zeros(n);
end M;

it will fail, instead of saying that the model has n variables and equations. But whether the parameter has an Evaluate-annotation or not doesn't matter in that case.

Yeah, I understood this is the case. However, it is normally the case that integer parameters such as number of nodes, volumes, elements and the like have some default (e.g. n = 1 or n = 2), corresponding to "simple implementation" or "minimum legal approximation", which can then be used for testing.

To the contrary, physical parameters such as the length of a rod or the mass of a body do not and should not have a default binding, because there is no such thing as a default lenght of a generic rod or default mass of a generic body.

[perost]

The warning is now disabled when checking a model, see 90d88f61.

[casella]

Thanks Per!