Skip to content

Add rule for allowing fixed parameters to be unbound during translation #3075

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from
Closed

Add rule for allowing fixed parameters to be unbound during translation #3075

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
6ca3f77
Add rule for allowing fixed parameters to be unbound during translation
henrikt-ma Dec 11, 2021
7a1fdb2
Change from recommending diagnostic message to allowing it
henrikt-ma Feb 9, 2022
326a194
Generalize explanation of when not setting 'start' is useful
henrikt-ma May 9, 2022
46cb560
Drop "non-zero" before "defaults"
henrikt-ma Jun 10, 2022
b17cf77
Merge remote-tracking branch 'central/master' into unbound-fixed-para…
henrikt-ma Dec 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 8 additions & 3 deletions chapters/equations.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -753,11 +753,16 @@ \section{Initialization, initial equation, and initial algorithm}\label{initiali
In case of iterative solver failure, it is recommended to specially report those variables for which the solver needs an initial guess, but which only have the default value of the \lstinline!start!-attribute as defined in \cref{predefined-types-and-classes}, since the lack of appropriate initial guesses is a likely cause of the solver failure.
\end{nonnormative}

If a parameter has a modifier for the \lstinline!start!-attribute, does not have \lstinline!fixed = false!, and neither has a binding equation nor is part of a record having a binding equation, the modifier for the \lstinline!start!-attribute can be used to add a parameter binding equation assigning the parameter to that \lstinline!start! value.
In this case a diagnostic message is recommended in a simulation model.
A parameter not having \lstinline!fixed = false! and neither having a binding equation nor being part of a record having a binding equation, is handled in different ways depending on the presence of a modifier for the \lstinline!start!-attribute.
If there is no modifier for the \lstinline!start!-attribute, it is an error unless a parameter value is explicitly provided before solving the initialization problem.
If there is a modifier for the \lstinline!start!-attribute, the modifier can be used to add a parameter binding equation assigning the parameter to that \lstinline!start! value.
In both cases, a diagnostic message is recommended in a simulation model.

\begin{nonnormative}
This is used in libraries to give non-zero defaults so that users can quickly combine models and simulate without setting parameters; but still easily find the parameters that need to be set.
The case of no \lstinline!start!-attribute is useful when no good default value for the parameter is known at the time of translation, or when the modeler wants to force the user of the translated model to make an active choice of parameter value.
Note that the requirement must not be fulfilled by defaulting to something like the default value for the parameter's type, as this would bypass the intention that all parameters should be determined either by the model itself or by the user of the translated model.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would just remove this line, as it seems like such an odd idea to guard against.

Suggested change
Note that the requirement must not be fulfilled by defaulting to something like the default value for the parameter's type, as this would bypass the intention that all parameters should be determined either by the model itself or by the user of the translated model.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is an important point, which is actually not clear in the specification right now. What is meant by "providing start-attribute"? Consider the following example:

type RealStart = Real(start = 10);

model M
    model MM
        Real x;
	parameter RealStart p;
    equation
        x = p;
    end MM;

    MM mm;
end M;

I tried it in MapleSim, Dymola and OpenModelica. It simulates, giving a warning that the default values is used. But is it correct to consider that the start value is given? I scanned through units in MSL. There is only ThermodynamicTemperature that has start value specified on type. But then there is a bunch of types that extend from it. So, if somebody has a parameter of ThermodynamicTemperature type and does not specify the start attribute when that instance is defined (and no modification given at any point later), do we consider that the start-attribute is provided or not? With the sentence that Henrik added, it should not be considered as provided. But it is treated as such right now but at least 3 tools. If that sentence is not correct then it should be stated that it is enough to specify the start on the type, but start values of builtin types should not be considered as "provided".

Copy link
Collaborator Author

@henrikt-ma henrikt-ma May 9, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me, this line is at the heart of the proposal. I don't want this proposal to end up removing the current rule that all parameters must be given a value – either directly or using the start attribute to bypass the rule.

In @eshmoylova's example above, the intention is to consider p as having start-attribute, meaning that the sentence we're discussing here doesn't apply. Hence, I don't understand this comment:

If that sentence is not correct then it should be stated that it is enough to specify the start on the type, but start values of builtin types should not be considered as "provided".

There should be no special rule about being considered "provided". Provide start, and you bypass the mechanism to guard against use of uninitialized parameters. To ensure that parameters are given values by users of a model one must not provide start, neither directly nor via the use of a type alias.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of discussing "modifier for start-attribute" I believe we should:

  • Write "the start-attribute has a value".
  • Remove the default value for the start-attribute in the built-in types such as Real, Integer, ... as it does not really make sense in the light of this section. Claiming that RealStart=Real(start=0) has a modifier for the start-attribute, but Real with RealType start=0; lacks it, seems weird. This is also consistent with this PR removing the "non-zero" text.

We also have to consider the following odd cases for start-attributes (assuming MCP0009 is accepted):

model U
 parameter Real x(final start);
 parameter Real y(start=break);
end U;

Both of them arguably has a modifier for the start-attribute, but neither has a value for the start-attribute.
(Using final on a modifier without providing a value is well-defined semantically, but normally it is used when you already have a value, in order to finalize that.)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would just remove this line, as it seems like such an odd idea to guard against.

I was hoping for some feedback on removing this.

Additionally I realized that apart from being an odd idea, I don't understand what it means.

How do we determine the default value for the parameter's type? The obvious idea would be to use the start-value of the type, but in that case the parameter has a start-value and the sentence does not apply.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of discussing "modifier for start-attribute" I believe we should:

I believe this would need to be discussed in a separate issue to avoid scope creep. Some things to keep in mind when working out such a proposal:

  • It would be easy to state that start = break is not a modifier, but removes an existing modifier.
  • We also need terminology for what is now called the default value of the type, which is where the RealType start = 0 can come into play.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would just remove this line, as it seems like such an odd idea to guard against.

I was hoping for some feedback on removing this.

Additionally I realized that apart from being an odd idea, I don't understand what it means.

I gave feedback above: #3075 (comment)

The purpose is to not break a big hole in the current safety net for ensuring that all parameters must have a value when a model is simulated.


The case of providing a \lstinline!start!-attribute is used in libraries to give non-zero defaults so that users can quickly combine models and simulate without setting parameters; but still easily find the parameters that need to be set.
\end{nonnormative}

All variables declared as \lstinline!parameter! having \lstinline!fixed = false! are treated as unknowns during the initialization phase, i.e.\ there must be additional equations for them -- and the \lstinline!start!-value can be used as a guess-value during initialization.
Expand Down