Ambiguous behaviour if component has transitions to multiple regimes

[sebjameswml]

Jen discovered a problem with the component description which is this:
If you have a component with an OnCondition transition, which has as its target the default regime (call it Regime_1) and an OnEvent transition which has the target Regime_2, then if the OnCondition evaluates true at the same time as the OnEvent transition being triggered, the system will never transition into Regime_2. This wasn't quite the behaviour expected by Jen when she laid her component out. Example model:

toyModel.tar.gz

[sebjameswml]

The question really is "does SpineML define the order in which transitions should be processed?"

[mondus]

No, as far as I am aware this is the same in NineML and transitions must be deterministic.

[ajc158]

IIRC transitions are processed simultaneously - i.e state changes from one
do not affect the others - in the case of regime changes the behaviour is
that it is the user's responsibility to ensure that multiple transitions do
not target divergent regimes. As this example has divergent regimes
targeted (same regime and other regime) it is not supported by the spec.
That means that the simulator is actually working as intended and the
component is invalid, but the question is whether we want to change this.

On 29 Jul 2016 4:38 p.m., "mondus" notifications@github.com wrote:

No, as far as I am aware this is the same in NineML and transitions must be
deterministic.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFid1tgthNd-p4m_gVLbxm3qkKj193OXks5qah3sgaJpZM4JYTlI
.

[mondus]

"the simulator is actually working as intended " the point is that different simulators may interpret transitions in different orders (as intended within their own simulator) so having non deterministic transitions is something which the user should not specify in the component.

[sebjameswml]

We should throw a runtime error in SpineML_2_BRAHMS if there are transitions to divergent regimes. In this case the error could be thrown if, within a single timestep, the "nextRegime" is updated more than once.

Also helpful would be a warning/error in SpineCreator.

[ajc158]

I'm pretty sure I currently flag this, but I've made it a non fatal issue
with just a warning

On 29 Jul 2016 5:11 p.m., "Seb James" notifications@github.com wrote:

We should throw a runtime error in SpineML_2_BRAHMS if there are
transitions to divergent regimes. In this case the error could be thrown
if, within a single timestep, the "nextRegime" is updated more than once.

Also helpful would be a warning/error in SpineCreator.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFid1jnR-bjiwJvKl0fYyowQjGxdh7EHks5qaiYggaJpZM4JYTlI
.

[ajc158]

We can't warn in SpineCreator as we can't necessarily know that multiple
transitions will be triggered simultaneously, so a warning would not cover
all bases

On 29 Jul 2016 5:18 p.m., "Alex Cope" a.cope@sheffield.ac.uk wrote:

I'm pretty sure I currently flag this, but I've made it a non fatal issue
with just a warning

On 29 Jul 2016 5:11 p.m., "Seb James" notifications@github.com wrote:

We should throw a runtime error in SpineML_2_BRAHMS if there are
transitions to divergent regimes. In this case the error could be thrown
if, within a single timestep, the "nextRegime" is updated more than once.

Also helpful would be a warning/error in SpineCreator.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFid1jnR-bjiwJvKl0fYyowQjGxdh7EHks5qaiYggaJpZM4JYTlI
.