Chronological Thread 

< Chronological >      < Thread >

---

Thank you for your comments Lucian. I knew you would be interested :).

Certainly the resets in this draft, while sufficient for our basic use
cases, are as yet a trifle incomplete in the more general sense. Quite
right.

We are aware of SBML events and, so far at least, as you allude to in your
feedback, find them heavier duty than we think we need.

Best Regards
Mike


On Saturday, February 11, 2017, Lucian Smith
<lucianoelsmitho AT gmail.com>
wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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.