5.1.5.3. Misuse: Indirect change of state variables

Description: Resets applied at \((x, t, p)\) can only change the variables in \(x\). This includes state variables, and variables which have been initialised using the initial_value attribute and whose value is not determined through any of the mathematical equations given. This example shows the valid case of where the mathematical equation may - depending on the implementation - covertly change a state variable.

Note that:

  • all elements are in the same component;

  • the order values of resets are not shown; and

  • the units of variables are not shown.

component: IndirectlyChangeStateVariables
  ├─ math:
  │   ├─ ode(A, t) = 1
  │   └─ B = A
  │
  ├─ variable: A initially 1
  │
  └─ variable: B
      └─ reset:
          ├─ when B == 2
          └─ then B = 1

See CellML syntax

<variable name="t" units="dimensionless" />
<variable name="A" units="dimensionless" initial_value="1"/>
<variable name="B" units="dimensionless" />

<math>
    <apply><eq/>
        <diff>
            <ci>A</ci>
            <bvar>t</bvar>
        </diff>
        <cn cellml:units="dimensionless">1</cn>
    </apply>
</math>

<reset variable="B" test_variable="B">
    <test_value>
        <cn units="cellml:dimensionless">1</cn>
    </test_value>
    <reset_value>
        <cn units="cellml:dimensionless">2</cn>
    </reset_value>
</reset>

This is similar to the previous case, but now the situation could perhaps be solvable:

  • Initially, both A and B are 1.

  • As the solution progresses, the solved value for A is given as the value for B because of the equality \(B=A\) in the maths block.

  • When B == 2, the reset is triggered and B is reset to 1.

Thus it’s unclear whether different implementations and solvers would show consistent behaviour, and this kind of model formulation is better avoided.

t

0.0

…

1

A

1

…

2

?

B

1

…

2

1 → 2

(In addition, determining whether a situation like this does or does not have a solution has the potential to be difficult.)

5.1.5.3.1. Suggestions

Since the issue arises in the interpretation of the reset and mathematics into code, that is where the solution lies also. In most implementations the equality \(=\) will be converted to an assignment (e.g.: B := A) before the system is solved. In turn, this means that the system is not over-defined, and solution is possible. Allowing this type of situation would mean solvers need to recognise potential situations like this and add statements which decide which direction of the assignment should be followed:

if (some condition):
    then: assign the value of A to B
    else: assign the value of B to A