Chronological Thread 

< Chronological >      < Thread >

---

Congratulations on getting a draft spec out! I know how hard that can be
;-)

Most of the changes look pretty good to me, but I will say that I think
your new 'reset' construct needs a lot more semantic clarification, and has
a lot of room for additional semantics, should you want it.

It is fairly obvious that the 'reset' construct is the CellML equivalent of
the SBML 'event'. Now, the SBML event has a ton more semantics than the
'reset' construct, probably more than you want. But a lot of semantics
have been worked out in SBML, and I think you would do well to look at the
SBML events to figure out what you want to steal from it, and what you want
to leave.

First, there are some basic semantics that are unclear in the CellML spec
that *must* be cleared up before it can be robust. The main thing is 'what
happens when two resets for two different variables are triggered at the
same time?'

<reset variable=”A” order=”1”>
<when order=”1”>
<math xmlns="http://www.w3.org/1998/Math/MathML";>
<apply><gt/><ci>B</ci><cn cellml:units=”ms”>100</cn></apply>
</math>
<math xmlns="http://www.w3.org/1998/Math/MathML";>
<cn cellml:units=”ms”>3</cn>
</math>
</when>
</reset>
<reset variable=”B” order=”1”>
<when order=”1”>
<math xmlns="http://www.w3.org/1998/Math/MathML";>
<apply><gt/><ci>B</ci><cn cellml:units=”ms”>100</cn></apply>
</math>
<math xmlns="http://www.w3.org/1998/Math/MathML";>
<cn cellml:units=”ms”>3</cn>
</math>
</when>
</reset>

Here, we have two resets. In Antimony's syntax:

at(B>100): A=3
at(B>100): B=3

First, you need to say whether both resets will always fire, or whether one
can cancel the other: if the second reset fires first, the condition for
the first no longer holds: does it still fire?

Secondly, say you have the following:

at(B>100): A=B
at(B>100): B=3

What value of 'B' should be used in this scenario for the first reset?
Will A equal 100, or will it equal 3?

If you haven't gotten far in your implementation yet, I might suggest
changing the syntax here to be trigger-specific at the top level instead of
variable-specific at the top level: this will reduce confusion for your
modelers. In other words, create a syntax where you can say:

at(B>100): A=B, B=3

and nicely lump everything together. You still have to define what happens
when your modelers split everything up anyway, but it gives them an easier
and more intuitive path for when they have conditions where several things
respond at once (which I will say is the situation I normally encounter
myself, though I don't do a lot of modeling directly.)

As you wrestle with that, you should consider (if you haven't already)
giving your modelers more control over the behavior of 'reset', much like
SBML's events:
* Resets that happen after a delay. This has been useful in SBML for some
time, and there are a wide variety of models that use it for various
scenarios.
* Allow the user to define what order assignments happen: in the above
scenarios, instead of the spec declaring a single method for resolution,
you could leave that in the hands of your users/modelers.
* Allow the user to define whether to use the state of the model at the
time the model was triggered when evaluating the math, or whether to use
the state of the model at the time the math is being assigned.
* Allow the user to define whether a reset is 'persistent': i.e. whether
the condition must remain true until it is carried out or not. Chris
Meyers is the one who introduced this modeling concept to the SBML
community: it's a fairly common one in 'petri net' type models, and others.
* Allow the user to define whether a trigger is considered to be true or
false at the start of the model's evaluation.
* Allow the user more flexibility in the 'order' attribute: i.e. allow it
to be evaulated, and/or simply be a reference to another model variable.
* Allow the user to define a random behavior by allowing a way to have two
resets happen in a random order with respect to each other (as opposed to
an undefined order).

All of the above are allowed by SBML Events; you can read about them in the
SBML L3 spec (I think I summarized them in my Antimony translation paper,
too). Again, each ability opens up a type of modeling that may or may not
be useful for your users (you'd have to make that determination yourself),
and simultaneously imposes a burden on your simulator writer(s). That sort
of cost/benefit analysis should inform whether to allow or disallow each of
the above situations.

(I suppose another issue is translation: how much you care about allowing
arbitrary SBML models to be translated to CellML, and allowing arbitrary
CellML models to be translated to SBML.)

Good luck! And I'd be happy to answer any questions you may have, and/or
to talk more at the next HARMONY about some of these issues.

-Lucian

On Wed, Feb 8, 2017 at 1:51 PM, Mike Cooling
<mtcooling.research AT gmail.com>
wrote:

> Dear CellML Community,
>
> The '2.0 Specification Writing Group' is proud to present a draft
> specification for CellML 2.0.
>
> Unlike the CellML 1.x specifications, the CellML 2.0 specification is
> written in a formal, "normative" style. It consists largely of a list of
> interlocking rules. This makes it difficult to meaningfully 'skim' the
> document, so for your convenience we present a Release Note highlighting
> the differences between CellML 1.1 and CellML 2.0. We recommend starting
> with that Note which can be found here:
>
> https://drive.google.com/open?id=0B7o2fHkRhadEeG10cDlIZkNsQk0
>
> The specification itself can be found here:
>
> https://drive.google.com/open?id=0B7o2fHkRhadEUnp4Zkx4ZTRkZXc
>
> We invite community feedback on this draft specification. We are also
> seeking more information, specifically, on the usefulness of the ability to
> include definite integrals in the mathematics (currently not in CellML
> 2.0). If you can provide details of models that need that feature, or wish
> to provide any other feedback on the Specification, please do so via this
> mailing list, or, if you prefer, directly to my email address.
>
> Best Regards,
> Mike Cooling, on behalf of the CellML 2.0 Specification Writing Group.
>

---

• [cellml-discussion] CellML 2.0 Draft Specification, Mike Cooling, 02/09/2017
  • Re: [cellml-discussion] CellML 2.0 Draft Specification, Lucian Smith, 02/11/2017
  • Message not available
    • Re: [cellml-discussion] CellML 2.0 Draft Specification, Mike Cooling, 02/11/2017
  • Re: [cellml-discussion] CellML 2.0 Draft Specification, Peter Hunter, 02/20/2017
  • Message not available
    • Re: [cellml-discussion] CellML 2.0 Draft Specification, Mike Cooling, 02/22/2017
      • Re: [cellml-discussion] CellML 2.0 Draft Specification, Peter Hunter, 02/22/2017

---

Archive powered by MHonArc 2.6.18.