Generator and initialising variables of integration

[kerimoyle]

See note here. It would be good to be able to initialise variables of integration from the CellML model and have them carried into the generated model? Currently this is not possible. Thanks @agarny :)

[agarny]

In CellML model, a variable of integration cannot have an initial value. So, I am not sure how we can do what you are after, or am I missing something?

[kerimoyle]

So we do always have to start at x=0? Now I'm confused! For a base variable of time it's not really an issue, but for all others I'd have thought we'd need to allow some kind of initialisation? I realise that the base variable values will (probably?) be set by whatever solver is being used (but not necessarily - I can thing of cases when not), but it seems really strange to have to specify an "initial" condition on a variable but to be forbidden to specify when/where "initial" is being applied ...?

I see that the spec says: (19.6.2) "The conditions when initial values hold are (by design) not defined in a CellML model document." ... so is this what you mean? And what's the "by design" rationale for this? If we have to specify initial conditions and other parametric variables, then how come this one - which seems more fundamental than those - isn't also specified? I'm really confused now ... :|

@nickerso what did you say yesterday in our call about this? It seems different to the quote from the spec?

[agarny]

@nickerso to correct me, but...

In an ideal world (!!), initial conditions (i.e. the initial value of state variables) would not be mentioned in a CellML file, but... for historical reasons they are. Not great, I know, but that's a typical case of where, I guess, we have to live with it now.

When it comes to the variable of integration (VOI), it should simply not be initialised in a CellML file. Full stop. However, this does not mean that a VOI always starts at 0. As you rightly say, to start at 0 would be fine for time, but not for other types of VOI (e.g. length where we might want to go from, say, 10 m to 20 m).

Now, when it comes to code geration, we don't have the VOI as a parameter as such. I mean that we have the states, rates and variables arrays, but no VOI variable as such. It's whenever you need to call computeRates() and computeVariables() that you provide the value of VOI for which you want to compute the solution.

So, yes, I am not quite sure what the problem is here...

[nickerso]

CellML models are a declarative statement of a mathematical model. The value of the VOI (initial, final, middle, etc..) depends entirely on instantiating the model into a computational simulation - this is the role of SED-ML. The same model can be instantiated into many different simulation experiments, each with their own VOI domain of application.

"The conditions when initial values hold are (by design) not defined in a CellML model document."

The "by design" rationale is that it is too difficult to unambiguously define this in a declarative manner. And it is definitely information that belongs to a simulation experiment not the mathematical model.

[kerimoyle]

Then why initialise the variables? I get what you mean, and agree, but it doesn't make sense to me to set one lot and not the other?

On Wednesday, 8 January 2020, David Nickerson notifications@github.com wrote:

CellML models are a declarative statement of a mathematical model. The value of the VOI (initial, final, middle, etc..) depends entirely on instantiating the model into a computational simulation - this is the role of SED-ML. The same model can be instantiated into many different simulation experiments, each with their own VOI domain of application.

"The conditions when initial values hold are (by design) not defined in a CellML model document."

The "by design" rationale is that it is too difficult to unambiguously define this in a declarative manner. And it is definitely information that belongs to a simulation experiment not the mathematical model.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/cellml/libcellml/issues/507?email_source=notifications&email_token=ALFXCNEQBO3KCPA3F5K5EXTQ4U45VA5CNFSM4KDJ3RLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEILABGA#issuecomment-571867288, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALFXCNHCCGGIREQTTW2F34TQ4U45VANCNFSM4KDJ3RLA .

[kerimoyle]

In an ideal world (!!), initial conditions (i.e. the initial value of state variables) would not be mentioned in a CellML file, but... for historical reasons they are. Not great, I know, but that's a typical case of where, I guess, we have to live with it now.

I guess this explains the reason (not the rationale!) for initial conditions being there ... personally I think this is super weird though :(

[agarny]

In an ideal world (!!), initial conditions (i.e. the initial value of state variables) would not be mentioned in a CellML file, but... for historical reasons they are. Not great, I know, but that's a typical case of where, I guess, we have to live with it now.

I guess this explains the reason (not the rationale!) for initial conditions being there ... personally I think this is super weird though :(

Agreed, I have never liked it either, but we didn't have anything like SED-ML back then, so that's the way things were done and how we kept them (since SED-ML only came out may years later).

It's like stimulus protocols. For example, some cardiac cells need a stimulus to generate an action potential. Such a stimulus protocol has nothing to do in a CellML document, not least since we can apply different stimulus protocols to a cell. Yet, you will see that such a stimulus protocol is described in CellML documents.

Bottom line: there are various historical reasons that explain (not justify) the way certain things are in CellML. We are trying to get people to change their ways, but it's clearly a long-term process.