Skip to content
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.

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

Implicit dv := pre(dv) in initial algorithm? #3472

Open
maltelenz opened this issue Feb 1, 2024 · 7 comments · May be fixed by #3562
Open

Implicit dv := pre(dv) in initial algorithm? #3472

maltelenz opened this issue Feb 1, 2024 · 7 comments · May be fixed by #3562
Labels
clarification Specification of feature is unclear, but not incorrect
Milestone

Comments

@maltelenz
Copy link
Collaborator

maltelenz commented Feb 1, 2024

Consider:

model DiscreteInit2
  Integer i;
initial algorithm
  if time < 1 then
    i := 1;
  end if;
equation
  when false then
    i = pre(i);
  end when;
end DiscreteInit2;

From what I read here about algorithms:

A discrete-time variable v is initialized with pre(v).

and here about when equations:

If a when-clause equation v = expr; is not active during the initialization phase, the equation v = pre(v) is added for initialization.

my interpretation is that the initialization problem to be solved for this model is:

initial algorithm
  i := pre(i);
  if time < 1 then
    i := 1;
  end if;
equation
  i = pre(i);

which, swapping pre(i) => prei for readability, conceptually is similar to (pseudo code):

function f
  input Integer prei;
  input Integer i;
  output Integer i_out;
algorithm
  i_out := prei;
  if time < 1 then
    i_out := 1;
  end if;
end f;

i = f(prei, i);
i = prei;

which reveals that we have a cycle/mutually dependent equations in the variables {i, prei}, turning this into an illegal model.

Is this interpretation correct?

@maltelenz
Copy link
Collaborator Author

Note relation to #2639. I'm trying to get clarity on the initialization-specific aspects in this new issue.

@maltelenz maltelenz added the clarification Specification of feature is unclear, but not incorrect label Feb 5, 2024
@HansOlsson HansOlsson added this to the 2024-1 milestone Feb 15, 2024
@HansOlsson HansOlsson modified the milestones: 2024-1, 2024-2 Mar 25, 2024
@HansOlsson
Copy link
Collaborator

Clearly discrete variables that are not unconditionally assigned should have deterministic value at the start of the initial algorithm to get deterministic results.

However, using pre(dv) will mostly cause loops that cannot be solved (uniquely), unless the variable is assigned a value (independent of its initial value) and in that case the initial value didn't matter. That just seems bad.

For parameters we instead have the special rule that they are initialized to their start-value in initial algorithms, and that seems like a solution that could be generalized to all variables in initial algorithms giving the following benefits:

  • It is deterministic
  • It does not cause loop
  • It unifies the handling in initial algorithms (so the same for parameters, discrete and continuous-time variables)

@HansOlsson
Copy link
Collaborator

  • Does anyone have a preference for pre(dv) over the start-value for initial algorithms?
  • Are there any cases where pre(dv) actually works for initial algorithms?

If not I would propose the change above.

@casella
Copy link
Collaborator

casella commented Aug 9, 2024

dv = pre(dv) looks to me like a steady-state condition, which of course can be hard to solve for in some cases. I think using the start attribute makes a lot more sense.

@henrikt-ma
Copy link
Collaborator

I like the idea of unifying the handling and breaking loops, but it's a non-trivial change of semantics that should be evaluated using test-implementations rather than by listening to gut feelings.

@casella
Copy link
Collaborator

casella commented Aug 13, 2024

I played around with the MWE by @maltelenz and I came to the conclusion that OMC already implements the proposed new semantics 😅:

  • OMC does not complain about the initial algebraic loop, so it is not adding the dv = pre(dv) equation as actually required by the MLS
  • if I set the start attribute for i (e.g., Integer i(start = 3)), I get an initial value of 1 if StartTime = 0, but I get 3 if StartTime = 2, when the equation in the initial algorithm is skipped

This means, the OMC generated code first initializes those discrete variables with their start attributes, and then possibly overwrites their value when executing the initial algorithm. So, we already have a working test implementation, and it's been around for a while 😃

Is there any further tests cases you'd like to analyze with it?

@casella
Copy link
Collaborator

casella commented Aug 13, 2024

keeping @phannebohm and @kabdelhak in the loop, maybe they can further comment about this specific issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Specification of feature is unclear, but not incorrect
Projects
None yet
4 participants