Chronological Thread 

< Chronological >      < Thread >

---

Well, to my reading at least, the spec itself is even more vague than the
examples for the 'reset' section.

"a. A ​when​ element SHALL be deemed to be true when the evaluation of the
MathML expression encoded in first child element of the ​when​ element
changes from the boolean expression false to true.
b. If a ​when​ element is deemed to be true, then false, then true again
during the
same ‘instant’ or interval of integration, it SHALL nevertheless be held to
be
false."

Point b doesn't help you the way you want it to. Point a says that it's
not the *value* of the 'when' statement that matters, but rather *the fact
that it changed from false to true*. Point b ignores this, and says that
during any interval of integration, if it was ever false, it will be 'held
to be false', (the meaning of even this phrase is unclear).

Taken literally, this means that you only fire resets between integration
intervals, when:
* the 'when' was 'false' at any instant during the first interval, and
* the 'when' was 'true' for the entirety of the second interval.

'Interval of integration' is not defined anywhere in the spec; it is only
mentioned here. I am not at all sure what it is supposed to mean. There
are a lot of simulators that integrate in chunks; it would be reasonable to
interpret this as being 'chunk'-dependent, i.e. if the simulator only
output values in one-second intervals, all resets would happen on those
chunk boundaries. A reasonable interpretation of everything above, then
would be that for a model with

c=1
when(t>0.5): c=3

a compliant simulator could output:

t c
0 1
1 1
2 3

In the first interval (0-1), the 'when' was false for part of it, so it
counts as being 'false' for the whole time. Then you move on to the next
interval (1-2), and at the end, the 'when' is still true, so it counts as
being true for the whole interval. You then know that you're supposed to
execute the reset value, so c becomes 3 at t=2.

For a different simulator that operated with intervals of 0.1, you'd get:

t c
0.0 1
0.1 1
0.2 1
0.3 1
0.4 1
0.5 1
0.6 1
0.7 3

Those are pretty different results, but both would seem to be compliant by
one reading of the spec.

Also, my interpretation of 'if it was ever false, it counts as always being
false' is an interpolation from the spec, but is by no means the only
possible interpolation. You say true->false->true means 'false', but you
don't say what false->true means, nor true->false, nor false->true->false,
nor false->true->false->true, etc. Since the reset theoretically happens
on transition from false to true, I'm not sure why 't->f->t' is being used
in the first place; I would have imagined that what you meant to say was
something like 'if a 'when' transitions from false to true, but then
transitions back to 'false' before the 'order' attribute would dictate the
reset would take place, the reset does not take place'. On the other hand,
starting off as true, then switching to false then back to true in one
'instant' is indeed another issue: did that final false->true transition
count? Or not? If it was false only for part of an instant, might it
count as being 'true' for the entire 'instant'?


Also, my original issue ('how to simultaneous resets interact?') remains
unclear, both from the spec and from the examples. In my reading of the
spec, there is no way to determine the result of the following CellML:

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

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

more colloquially: when(t>100): A=B, and when (t>100): B=A.

The 'order' values don't help, as they only have to be unique if the
variable is in the same 'connected variable set', which A and B are not.
So there is no way to determine whether after t>100ms, A and B swap values,
or A and B both end up with A's previous value, or A and B both end up with
B's previous value. Nothing is said in the spec to distinguish between any
of these situations.


Other issues:

* I would recommend restricting the 'order' attribute to be non-negative
integers, and require that they be sequential starting at 0. This will
make things much easier on your interpreters, which otherwise have to
search out all values and re-order lists like [4, 18, -5000, 240], which
seems a little silly (and prone to error, either in modeling or in
simulation).

"Processing software concerned with providing numerical solutions to the
mathematical model MAY provide automatic numerical conversion between
variables
which have the same variable unit reduction but different multipliers (see
Interpretation of units ​) by employment of conversion factors."

So, 1kg + 1g is either 1001, or 1.001, or 2, with no way to distinguish
between them? There's no canonical answer? Having an optional
mathematical step in a mathematical standard seems kind of contrary to the
goal of having an exchangeable standard. Is this the way CellML has always
been? I would see the creation of a new spec as a chance to break away
from that, if so, and not the time to start, if not.

"4. A value of ​none​ specifies that the variable has no interface.
5. If the ​interface​ attribute information item is absent, then the
variable has no
interface."

I think you will make everyone's life easier of you make the 'interface'
attribute required. Having two ways to encode the same thing is asking for
trouble, and the absence of something means 'undefined' for some people,
not 'nothing'. The spec itself is indeed unambiguous in this regard; this
is just a suggestion.

-Lucian

On Tue, May 30, 2017 at 6:55 PM, Mike Cooling
<mtcooling.research AT gmail.com>
wrote:

> Thanks, Lucian, for the comments.
>
> >I would strongly recommend *not* making a formal difference between 'x>y'
> and 'x>=y', or at least not giving examples that rely on there being a
> difference between them.. a notoriously difficult situation to distinguish
> between...
>
> We have described the algorithm for a forward Euler, where it would be
> easy to distinguish between them (with attendant disadvantages due to that
> integration method of course). For a more sophisticated (and common,
> hopefully :) ) integrator, exact compliance depends on the algorithm and I
> think it is fair to say that solutions would 'tend' to be 'correct' more
> than actually be 'correct' (and in practice this is just fine). At present,
> if you read carefully (notice the examples follow our 'forward Euler'
> algorithm) you will see that actually we have side-stepped specifying the
> result that exactly for a more sophisticated integrator.
>
> Being able to specify those cases in the first place is consistent with
> piecewises - which incidentally have left the behaviour even more implicit
> since, I think, the late nineties.
>
> >Also, when the 'order' attribute matters, put it into the example.
>
> I'm prepared to be corrected in the event that we made a mistake somewhere
> but I believe that is exactly what we did - if it wasn't there, it didn't
> matter.
>
> > If the order attribute never matters in the examples you have created,
> say that explicitly.
>
> There is no explicit explanation on that point because following the rules
> in the spec 'order' doesn't work like that (the relevant clauses are
> 19.11.2 and 19.11.3.e). I think this might be the root cause of your
> concern here. More broadly, the ordering of statements has no effect in
> CellML at all, and is distinct from any 'order' attributes.
>
> >reset A when B>3, A = B
> >reset B when B>3, B = 1
>
> >is the same as
>
> >reset B when B>3, B = 1
> >reset A when B>3, A = B
>
> Following the spec and the examples, those two cases are identical
> (assuming A and B are not connected - we later also have an explicit
> example further on where such variables are connected and then order
> attribute does come into play).
>
> >can't tell from the examples
>
> I should clarify that the examples appendix is not designed to teach, from
> the ground up, about resets. Such a document might well be valuable too but
> that isn't it :). It was designed to confirm / clarify various situations
> that arise from following the rules in the specification. My recommendation
> is to start with the spec first (which by it's nature as a normative
> document is not the easiest to process at times), then go through the
> examples.
>
> Best Regards,
> Mike
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, May 31, 2017 at 11:59 AM, Lucian Smith
> <lucianoelsmitho AT gmail.com>
> wrote:
>
>> I would strongly recommend *not* making a formal difference between 'x>y'
>> and 'x>=y', or at least not giving examples that rely on there being a
>> difference between them. This is a notoriously difficult situation to
>> distinguish between, and makes certain types of simulation approaches
>> impossible to accomplish. Whenever I accidentally put situations like that
>> into the SBML Test Suite, I'm always asked to take them back out again.
>>
>> Also, when the 'order' attribute matters, put it into the example. If
>> the order attribute never matters in the examples you have created, say
>> that explicitly. I can't tell from the examples you give if:
>>
>> reset A when B>3, A = B
>> reset B when B>3, B = 1
>>
>> is the same as
>>
>> reset B when B>3, B = 1
>> reset A when B>3, A = B
>>
>> (i.e. if the hidden 'order' attributes are different) or not.
>>
>> -Lucian
>>
>> On Tue, May 30, 2017 at 4:13 PM, Mike Cooling <
>> mtcooling.research AT gmail.com>
>> wrote:
>>
>>> Dear CellML Community,
>>>
>>> The 'Specification Writing Group' is proud to present an updated draft
>>> Specification for CellML 2.0.
>>>
>>> This second draft aims primarily to clarify the semantics of the
>>> new-in-2.0 'reset rules'. The appropriate section of the specification has
>>> been adjusted and the new Release Notes now include an Appendix containing
>>> reset rule examples with expected model behaviour.
>>>
>>> The exclusion of integrals was also reconsidered. At this time, support
>>> for integrals is not part of CellML 2.0. This decision could be revised
>>> with community needs.
>>>
>>> We invite community feedback on the May 2017 draft Specification.
>>>
>>> The explanatory release note (May 2017 draft) can be found here:
>>> https://drive.google.com/open?id=0B7o2fHkRhadEQ3c4bnFXRlpBSUk
>>>
>>> The specification itself (May 2017 draft) can be found here:
>>> https://drive.google.com/open?id=0B7o2fHkRhadEVTBacExBb0tnTDg
>>>
>>>
>>> Best Regards,
>>>
>>> Mike Cooling
>>> on behalf of the CellML 2.0 Specification Writing Group
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Mike Cooling
>>> <mtcooling.research AT gmail.com>
>>> Date: Thu, Feb 9, 2017 at 10:51 AM
>>> Subject: CellML 2.0 Draft Specification
>>> To:
>>> cellml-discussion AT lists.cellml.org
>>>
>>>
>>> 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 - May 2017 version, Mike Cooling, 05/31/2017
  • Re: [cellml-discussion] CellML 2.0 Draft Specification - May 2017 version, Lucian Smith, 05/31/2017
    • Re: [cellml-discussion] CellML 2.0 Draft Specification - May 2017 version, Mike Cooling, 05/31/2017
      • Re: [cellml-discussion] CellML 2.0 Draft Specification - May 2017 version, Lucian Smith, 05/31/2017

---

Archive powered by MHonArc 2.6.18.