Are discrete inputs allowed in Modelica?

[casella]

Follow-up of ticket OpenModelica/OpenModelica#12531 by @BasilioPV. Consider the following MWE:

model DiscreteIssue
  discrete input Real In(start=1);
  discrete output Real Out(start=0);
equation
  when In>1 then
    Out=1;
  end when;
end DiscreteIssue;

As I understand, this model is not legal in Modelica because of the provision in Sect. 4.5.3:

If a Real variable is declared with the prefix discrete it must in a simulation model be assigned in a when-clause, either by an assignment or an equation.

On the other hand, the FMI 2.0.4 standard explicitly allows the discrete input combination.

In view of the MA supporting open coordinated standards, could we amend the MLS to make this model legal, so it could be exported as an FMU?

BTW,

If a Real variable is declared with the prefix discrete it must in a simulation model be assigned in a when-clause, either by an assignment or an equation.

looks very German to me, shouldn't it better be

If a Real variable in a simulation model is declared with the prefix discrete, it must in be assigned in a when-clause, either by an assignment or an equation.

[HansOlsson]

If a Real variable is declared with the prefix discrete it must in a simulation model be assigned in a when-clause, either by an assignment or an equation.

That is correct.

On the other hand, the FMI 2.0.4 standard explicitly allows the discrete input combination.

The "discrete" have different meaning.

Modelica is (in contrast to FMU) a language where you combine different models - this means that we need to consider how a model works as a sub-model and as a base-class etc. Enforcing that a variable is "discrete" in all those cases would require additional rules that are complicated to get right - and without those rules different tools would interpret "discrete" differently.

The better solution would be to remove "discrete" in the Modelica Language - as it isn't really needed Similarly Modelica also have Clocked variables, but there isn't any primitive to say that a variable is on a clock (in contrast to FMI) as the idea is that it is deduced from the variable.

The goal in Modelica is instead that the same sub-model (such as add-block) can be used in continuous time and clocked.

In view of the MA supporting open coordinated standards, could we amend the MLS to make this model legal, so it could be exported as an FMU?

If you just remove "discrete" it can be exported as an FMU.

If a Real variable is declared with the prefix discrete it must in a simulation model be assigned in a when-clause, either by an assignment or an equation.

looks very German to me, shouldn't it better be

If a Real variable in a simulation model is declared with the prefix discrete, it must in be assigned in a when-clause, either by an assignment or an equation.

Likely an improvement.

[BasilioPV]

Thanks @HansOlsson, then as far I understand, there is no benefit in any case to declare a "discrete input" into Modelica.

[henrikt-ma]

I don't share the desire to eliminate discrete from Modelica. I find it the concept of variability very helpful for developing models with meaningful semantics, in the same way that I find it very useful to add type annotations that can both make the intent of working code easier for a human to understand, and enable the compiler to direct me to the right place in the code in case of a type error.

I have long desired that discrete in Modelica would only mean that the variable must be solved so that it gets a discrete-time solution. Being assigned in a when-clause would then be just one of the valid ways that a discrete variable can be determined. I don't see any real difficulty in implementing this more general requirement.

Regarding blocks that can operate both in discrete-time and non-discrete-time, my claim is that the missing feature in Modelica is the ability to use a function as a block. This would both fill the gap of not having a way to express that a block in Modelica does not contain stateful dynamics, and allow us to take advantage of the variability rules for function calls when making block-oriented models.

[HansOlsson]

I don't share the desire to eliminate discrete from Modelica. I find it the concept of variability very helpful for developing models with meaningful semantics, in the same way that I find it very useful to add type annotations that can both make the intent of working code easier for a human to understand, and enable the compiler to direct me to the right place in the code in case of a type error.

I have long desired that discrete in Modelica would only mean that the variable must be solved so that it gets a discrete-time solution. Being assigned in a when-clause would then be just one of the valid ways that a discrete variable can be determined. I don't see any real difficulty in implementing this more general requirement.

That would also be possible, but I don't know how much time it will take and how to prioritize it.

However, the difficulty to me would be that we would need further details for discrete variability, so that if we have a+b=c; and b is a parameter and c (declared/deduced) to be discrete then a must be discrete (and additional clarifications regarding system of equations, and if-clauses). The same would apply to the case a+b=if time<1 then c else 0;

In some sense this seems similar to clocked equations (with a very odd "event clock"). Thus it would seem logical if we used (roughly) the same rules for this as for clocked partitions. However, we can also turn continuous-time partitions (including code using discrete-time variables) into a discretized partition, so it must still be somewhat different.

I thus see this question as answered, and that as a separate possible extension.

Regarding blocks that can operate both in discrete-time and non-discrete-time, my claim is that the missing feature in Modelica is the ability to use a function as a block. This would both fill the gap of not having a way to express that a block in Modelica does not contain stateful dynamics, and allow us to take advantage of the variability rules for function calls when making block-oriented models.

Yes, that would be very useful (considerably higher in priority for me). I answered that in a separate issue.