sbml-qual Mailing List for Systems Biology Markup Language (SBML)

> 
> Another suggestion is to add "logical model simulation algorithm" to the simulation algorithm branch, and inherit two children from it: "synchronous logical model simulation algorithm" and "asynchronous logical model simulation algorithm". As well as to add "type of updating policy" to the characteristic branch, with the descendants: "random updating policy" and "ordered updating policy". The latter can be further specified as "prioritized updating policy" or "constant updating policy". Does this option look good for everyone?
> 
This option sounds the best.

Chris

No worries.  Let me know what I can do to help.  

Chris

On Dec 3, 2012, at 11:01 AM, Claudine Chaouiya <cha...@ig...> wrote:

> Hi Chris,
> 
> No problem!  We'll try our best to add further explanations in the spec, clarifying the semantics. But I will probably need few days to do so...
> best regards
> Claudine
> 
> 
> 
> On 3 déc. 2012, at 15:33, Chris J. Myers wrote:
> 
>> Hi Claudine,
>> 
>> I'm afraid my last message was too "blunt", for which I apologize.  Please let me be clear that I really appreciate all the time and effort that you have put into this specification.  It is very well done.  I think my concerns are easily addressed.  If the ambiguities that I pointed out are addressed, I see no problem with getting the specification given final approval by the editors soon.  Also, I think this package may have potential to be useful to the synthetic biology community that I'm working with for high-level modeling of their genetic devices.  This was one of the reasons I reviewed your specification with such keen interest. 
>>> 
>>> On Sat, 1 Dec 2012 11:52:01 -0700, Chris J. Myers wrote:
>>>> On Dec 1, 2012, at 11:15 AM, Claudine Chaouiya 
>>>> <cha...@ig...> wrote:
>>>>> I am not so sure about the need for further explanations in the 
>>>>> specification... but it does not hurt to add a §, mainly for logical 
>>>>> models representation. 
>>>>> Remind that the current spec probably needs to be refined for Petri 
>>>>> nets; SBML qual has been tested (and implemented) only for logical 
>>>>> models. 
>>>>> 
>>>> The semantics I describe below work perfectly well for Petri nets.  
>>> 
>>> Chris, I don't think Claudine is disagreeing with you about the applicability to PN or the possibility of extending the current text.  She merely said that the current spec is known to the authors to work for logical models.
>>> 
>>> Claudine (and other Qual spec authors), would it perhaps make sense to add some descriptions for Petri Net semantics along the lines of Chris' suggestions?
>> 
>> What I said was not well stated.  Claudine was expressing concerns that qual may not work for Petri nets.  What I was trying to say is that as a Petri net expert, I think it actually does work for ordinary Petri nets.  It is actually fairly cleverly done to allow for both logical and Petri net models, as well as, hybrid logical/Petri net models all in one package.  The semantics that I gave below were not for either one.  They are for the entire qual package which does not need a separate semantics for each.  It can have one unified semantics, which is good since logical and Petri net transitions can co-exist in a qual model.
>> 
>>> 
>>> 
>>>>>> 2) For each transition in the set of selected transitions, the 
>>>>>> simulator computes its resultLevel using the functionTerms.  Note 
>>>>>> that if multiple functionTerms for a transition are true, the 
>>>>>> simulator may choose one arbitrarily to use to set the resultLevel.
>>>>> it is indicated in the "good practices " section that such a 
>>>>> situation (where the resultLevel are different) should be avoided
>>>> 
>>>> I don't agree with this.  I think this is useful for modeling 
>>>> non-deterministic systems.  I don't think this should be 
>>>> discouraged.  Instead, I think it should be clearly stated that this 
>>>> leads to non-determinism which is a very important thing to represent 
>>>> in logical models.
>>> 
>>> This sounds like a technical point that can be decided easily enough -- either the situation is allowed or not, and it is up to the Qual spec designers to decide what is in the scope of this version of Qual.  
>>> 
>> I agree.  My opinion is that can be a useful thing to allow, if the semantics are defined.  However, I can see arguments potentially for not allowing it.
>> 
>>> As far as the wording of the specification is concerned, it sounds to me that the specification should state the interpretation in this situation, not as a best practice but as a matter of the body of the specification.
>>> 
>>>> I think we are having a serious disconnect here.  The issue is that a 
>>>> modeling language MUST have a well-defined semantics.
>>> 
>>> Again, Claudine already said at the beginning that it would not hurt to add additional information.  So I don't think there's a "serious disconnect"; all that's happened here is someone else (Chris's group) read the specification, found missing information, communicated this to the spec authors (perhaps a bit bluntly), and the authors then tried to explain their perspective.
>>> 
>>> So the next step is for the Qual spec authors to consider adding some clarifying information to address the perceived ambiguities, or if they judge that this is not within the scope of this V.1 specification, then to clarify the scope.
>>> 
>> What I meant by "serious disconnect" is that I was afraid that we were not communicating well.  This is likely my fault for not making my point clear.  The point that I'm trying to make is that the qual community can put any semantics they want on their package, but it should be clearly defined in the specification.  This will make for a much more useful package because when people exchange models, the behavior will be preserved from one tool to another.  
>> 
>> Again, I'm sorry about my bluntness in my last message.  
>> 
>> Thanks again for your work on this package.
>> 
>> Cheers,
>> 
>> Chris
>> 
>> 
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel: 
>> BUILD Helping you discover the best ways to construct your parallel projects.
>> http://goparallel.sourceforge.net
>> _______________________________________________
>> sbml-qual mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-qual
> 
> ----------------------------------------------
> Claudine Chaouiya
> Instituto Gulbenkian de Ciência - IGC
> Rua da Quinta Grande, 6
> P-2780-156 Oeiras - PORTUGAL
> 
> http://compbio.igc.gulbenkian.pt/nmd/
> Phone:	(351) 214 46 45 01 
> Email: cha...@ig...
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel: 
> BUILD Helping you discover the best ways to construct your parallel projects.
> http://goparallel.sourceforge.net
> _______________________________________________
> sbml-qual mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-qual

Hi Chris,

No problem!  We'll try our best to add further explanations in the spec, clarifying the semantics. But I will probably need few days to do so...
best regards
Claudine



On 3 déc. 2012, at 15:33, Chris J. Myers wrote:

> Hi Claudine,
> 
> I'm afraid my last message was too "blunt", for which I apologize.  Please let me be clear that I really appreciate all the time and effort that you have put into this specification.  It is very well done.  I think my concerns are easily addressed.  If the ambiguities that I pointed out are addressed, I see no problem with getting the specification given final approval by the editors soon.  Also, I think this package may have potential to be useful to the synthetic biology community that I'm working with for high-level modeling of their genetic devices.  This was one of the reasons I reviewed your specification with such keen interest. 
>> 
>> On Sat, 1 Dec 2012 11:52:01 -0700, Chris J. Myers wrote:
>>> On Dec 1, 2012, at 11:15 AM, Claudine Chaouiya 
>>> <cha...@ig...> wrote:
>>>> I am not so sure about the need for further explanations in the 
>>>> specification... but it does not hurt to add a §, mainly for logical 
>>>> models representation. 
>>>> Remind that the current spec probably needs to be refined for Petri 
>>>> nets; SBML qual has been tested (and implemented) only for logical 
>>>> models. 
>>>> 
>>> The semantics I describe below work perfectly well for Petri nets.  
>> 
>> Chris, I don't think Claudine is disagreeing with you about the applicability to PN or the possibility of extending the current text.  She merely said that the current spec is known to the authors to work for logical models.
>> 
>> Claudine (and other Qual spec authors), would it perhaps make sense to add some descriptions for Petri Net semantics along the lines of Chris' suggestions?
> 
> What I said was not well stated.  Claudine was expressing concerns that qual may not work for Petri nets.  What I was trying to say is that as a Petri net expert, I think it actually does work for ordinary Petri nets.  It is actually fairly cleverly done to allow for both logical and Petri net models, as well as, hybrid logical/Petri net models all in one package.  The semantics that I gave below were not for either one.  They are for the entire qual package which does not need a separate semantics for each.  It can have one unified semantics, which is good since logical and Petri net transitions can co-exist in a qual model.
> 
>> 
>> 
>>>>> 2) For each transition in the set of selected transitions, the 
>>>>> simulator computes its resultLevel using the functionTerms.  Note 
>>>>> that if multiple functionTerms for a transition are true, the 
>>>>> simulator may choose one arbitrarily to use to set the resultLevel.
>>>> it is indicated in the "good practices " section that such a 
>>>> situation (where the resultLevel are different) should be avoided
>>> 
>>> I don't agree with this.  I think this is useful for modeling 
>>> non-deterministic systems.  I don't think this should be 
>>> discouraged.  Instead, I think it should be clearly stated that this 
>>> leads to non-determinism which is a very important thing to represent 
>>> in logical models.
>> 
>> This sounds like a technical point that can be decided easily enough -- either the situation is allowed or not, and it is up to the Qual spec designers to decide what is in the scope of this version of Qual.  
>> 
> I agree.  My opinion is that can be a useful thing to allow, if the semantics are defined.  However, I can see arguments potentially for not allowing it.
> 
>> As far as the wording of the specification is concerned, it sounds to me that the specification should state the interpretation in this situation, not as a best practice but as a matter of the body of the specification.
>> 
>>> I think we are having a serious disconnect here.  The issue is that a 
>>> modeling language MUST have a well-defined semantics.
>> 
>> Again, Claudine already said at the beginning that it would not hurt to add additional information.  So I don't think there's a "serious disconnect"; all that's happened here is someone else (Chris's group) read the specification, found missing information, communicated this to the spec authors (perhaps a bit bluntly), and the authors then tried to explain their perspective.
>> 
>> So the next step is for the Qual spec authors to consider adding some clarifying information to address the perceived ambiguities, or if they judge that this is not within the scope of this V.1 specification, then to clarify the scope.
>> 
> What I meant by "serious disconnect" is that I was afraid that we were not communicating well.  This is likely my fault for not making my point clear.  The point that I'm trying to make is that the qual community can put any semantics they want on their package, but it should be clearly defined in the specification.  This will make for a much more useful package because when people exchange models, the behavior will be preserved from one tool to another.  
> 
> Again, I'm sorry about my bluntness in my last message.  
> 
> Thanks again for your work on this package.
> 
> Cheers,
> 
> Chris
> 
> 
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel: 
> BUILD Helping you discover the best ways to construct your parallel projects.
> http://goparallel.sourceforge.net
> _______________________________________________
> sbml-qual mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-qual

----------------------------------------------
Claudine Chaouiya
Instituto Gulbenkian de Ciência - IGC
Rua da Quinta Grande, 6
P-2780-156 Oeiras - PORTUGAL

http://compbio.igc.gulbenkian.pt/nmd/
Phone:	(351) 214 46 45 01 
Email: cha...@ig...

Hi Claudine,

I'm afraid my last message was too "blunt", for which I apologize.  Please let me be clear that I really appreciate all the time and effort that you have put into this specification.  It is very well done.  I think my concerns are easily addressed.  If the ambiguities that I pointed out are addressed, I see no problem with getting the specification given final approval by the editors soon.  Also, I think this package may have potential to be useful to the synthetic biology community that I'm working with for high-level modeling of their genetic devices.  This was one of the reasons I reviewed your specification with such keen interest. 
> 
> On Sat, 1 Dec 2012 11:52:01 -0700, Chris J. Myers wrote:
>> On Dec 1, 2012, at 11:15 AM, Claudine Chaouiya 
>> <cha...@ig...> wrote:
>>> I am not so sure about the need for further explanations in the 
>>> specification... but it does not hurt to add a §, mainly for logical 
>>> models representation. 
>>> Remind that the current spec probably needs to be refined for Petri 
>>> nets; SBML qual has been tested (and implemented) only for logical 
>>> models. 
>>> 
>> The semantics I describe below work perfectly well for Petri nets.  
> 
> Chris, I don't think Claudine is disagreeing with you about the applicability to PN or the possibility of extending the current text.  She merely said that the current spec is known to the authors to work for logical models.
> 
> Claudine (and other Qual spec authors), would it perhaps make sense to add some descriptions for Petri Net semantics along the lines of Chris' suggestions?

What I said was not well stated.  Claudine was expressing concerns that qual may not work for Petri nets.  What I was trying to say is that as a Petri net expert, I think it actually does work for ordinary Petri nets.  It is actually fairly cleverly done to allow for both logical and Petri net models, as well as, hybrid logical/Petri net models all in one package.  The semantics that I gave below were not for either one.  They are for the entire qual package which does not need a separate semantics for each.  It can have one unified semantics, which is good since logical and Petri net transitions can co-exist in a qual model.

> 
> 
>>>> 2) For each transition in the set of selected transitions, the 
>>>> simulator computes its resultLevel using the functionTerms.  Note 
>>>> that if multiple functionTerms for a transition are true, the 
>>>> simulator may choose one arbitrarily to use to set the resultLevel.
>>> it is indicated in the "good practices " section that such a 
>>> situation (where the resultLevel are different) should be avoided
>> 
>> I don't agree with this.  I think this is useful for modeling 
>> non-deterministic systems.  I don't think this should be 
>> discouraged.  Instead, I think it should be clearly stated that this 
>> leads to non-determinism which is a very important thing to represent 
>> in logical models.
> 
> This sounds like a technical point that can be decided easily enough -- either the situation is allowed or not, and it is up to the Qual spec designers to decide what is in the scope of this version of Qual.  
> 
I agree.  My opinion is that can be a useful thing to allow, if the semantics are defined.  However, I can see arguments potentially for not allowing it.

> As far as the wording of the specification is concerned, it sounds to me that the specification should state the interpretation in this situation, not as a best practice but as a matter of the body of the specification.
> 
>> I think we are having a serious disconnect here.  The issue is that a 
>> modeling language MUST have a well-defined semantics.
> 
> Again, Claudine already said at the beginning that it would not hurt to add additional information.  So I don't think there's a "serious disconnect"; all that's happened here is someone else (Chris's group) read the specification, found missing information, communicated this to the spec authors (perhaps a bit bluntly), and the authors then tried to explain their perspective.
> 
> So the next step is for the Qual spec authors to consider adding some clarifying information to address the perceived ambiguities, or if they judge that this is not within the scope of this V.1 specification, then to clarify the scope.
> 
What I meant by "serious disconnect" is that I was afraid that we were not communicating well.  This is likely my fault for not making my point clear.  The point that I'm trying to make is that the qual community can put any semantics they want on their package, but it should be clearly defined in the specification.  This will make for a much more useful package because when people exchange models, the behavior will be preserved from one tool to another.  

Again, I'm sorry about my bluntness in my last message.  

Thanks again for your work on this package.

Cheers,

Chris

Hello,

I have some comments and questions:

On Sat, 1 Dec 2012 11:52:01 -0700, Chris J. Myers wrote:
> On Dec 1, 2012, at 11:15 AM, Claudine Chaouiya 
> <cha...@ig...> wrote:
>> I am not so sure about the need for further explanations in the 
>> specification... but it does not hurt to add a §, mainly for logical 
>> models representation. 
>> Remind that the current spec probably needs to be refined for Petri 
>> nets; SBML qual has been tested (and implemented) only for logical 
>> models. 
>> 
> The semantics I describe below work perfectly well for Petri nets.  

Chris, I don't think Claudine is disagreeing with you about the applicability to PN or the possibility of extending the current text.  She merely said that the current spec is known to the authors to work for logical models.

Claudine (and other Qual spec authors), would it perhaps make sense to add some descriptions for Petri Net semantics along the lines of Chris' suggestions?

>>> 2) For each transition in the set of selected transitions, the 
>>> simulator computes its resultLevel using the functionTerms.  Note 
>>> that if multiple functionTerms for a transition are true, the 
>>> simulator may choose one arbitrarily to use to set the resultLevel.
>> it is indicated in the "good practices " section that such a 
>> situation (where the resultLevel are different) should be avoided
> 
> I don't agree with this.  I think this is useful for modeling 
> non-deterministic systems.  I don't think this should be 
> discouraged.  Instead, I think it should be clearly stated that this 
> leads to non-determinism which is a very important thing to represent 
> in logical models.

This sounds like a technical point that can be decided easily enough -- either the situation is allowed or not, and it is up to the Qual spec designers to decide what is in the scope of this version of Qual.  

As far as the wording of the specification is concerned, it sounds to me that the specification should state the interpretation in this situation, not as a best practice but as a matter of the body of the specification.

> I think we are having a serious disconnect here.  The issue is that a 
> modeling language MUST have a well-defined semantics.

Again, Claudine already said at the beginning that it would not hurt to add additional information.  So I don't think there's a "serious disconnect"; all that's happened here is someone else (Chris's group) read the specification, found missing information, communicated this to the spec authors (perhaps a bit bluntly), and the authors then tried to explain their perspective.

So the next step is for the Qual spec authors to consider adding some clarifying information to address the perceived ambiguities, or if they judge that this is not within the scope of this V.1 specification, then to clarify the scope.

Best regards,
MH

On Dec 1, 2012, at 11:15 AM, Claudine Chaouiya <cha...@ig...> wrote:

> I am not so sure about the need for further explanations in the specification... but it does not hurt to add a §, mainly for logical models representation. 
> Remind that the current spec probably needs to be refined for Petri nets; SBML qual has been tested (and implemented) only for logical models. 
> 
The semantics I describe below work perfectly well for Petri nets.  Though we have not yet implemented it, we went through it pretty thoroughly and are fairly convinced that it works for ordinary Petri nets.  Ours are not always ordinary, so we will be proposing extensions in the future.

>> 1) The simulator chooses a set of transitions to execute simultaneously.  This set can include a single transition (an asynchronous execution model), all transitions (a synchronous execution model), or some subset of the transitions.
> again, this is a simulation set-up. We will use SED-ML and KISAO
> 
No that is not correct.  This is semantics.  How you choose can be specified using SED-ML and KISAO, but the semantics I give I believe is valid for all possible valid interpretations.

>> 2) For each transition in the set of selected transitions, the simulator computes its resultLevel using the functionTerms.  Note that if multiple functionTerms for a transition are true, the simulator may choose one arbitrarily to use to set the resultLevel.
> it is indicated in the "good practices " section that such a situation (where the resultLevel are different) should be avoided

I don't agree with this.  I think this is useful for modeling non-deterministic systems.  I don't think this should be discouraged.  Instead, I think it should be clearly stated that this leads to non-determinism which is a very important thing to represent in logical models.

>> 
>> NOTE: what to do when multiple functionTerms are true was not defined in the specification, and it should be.  I think it is actually useful sometimes to represent such non-determinism and the usual way of handling this is to say the choice is arbitrary.
> this is clarified in the good practises. If the resultLevels are the same, and this is interpreted as a disjunction.

Not sure what you mean by "disjunction".  I think it is much more clean to say one is chosen arbitrarily as the resultLevel.  Again, interpretation of a model is NOT best practices, this is semantics and it must be formally defined.  You do not leave it to the tool to decide how to interpret a model.  It must be defined.
>> 
>> 3) Next, the simulator updates the level for each qualitative species referenced in the ListOfInputs by reducing the levels of those of those with transitionEffect of type "consumption" by the amount of the resultLevel times the thresholdLevel.  
> this would correspond to a PN model. In logical models, the transitionEffect is "none"

Correct.  I'm just saying in this step that if there exists consumption inputs, that the update occurs in this step.  The important thing is inputs are handled before outputs.
>> 
>> QUESTION: what if the result of this step makes a qualitative species level go negative?  Should that be an error?
> this should not happen since the transition would not fire (a functionTerm should define the condition to fire the transition), but again, this corresponds to PN models

Yes, this should not happen in a valid model, but I can easily come up with a model that creates negative qualitative species.  What I'm saying is the specification should say whether or not this is acceptable or an error.

>> 
>> 4) Finally, the simulator updates the level for each qualitative species referenced in the ListOfOutputs by increasing the levels of those with transitionEffect of type "production" by the amount of the resultLevel times the outputLevel, and changing the levels of those with transitionEffect of type "assignmentLevel" to the amount of the resultLevel times the outputLevel.
> no, in a logical model, the transitionEffect of an output is set to "assignementLevel". The rule indicates a value, which does not exceed the maxLevel. The update of the qualitativeSpecies level will then depend on the simulation set-up. It principle it is done step by step, but this is not part of the model.

I'm not talking about simulation of logical models.  I'm talking about simulating qualitative models which can potentially include both production and assignmentLevel.  Nothing disallows this.  Indeed, it makes qual more useful if it can mix.
>> 
>> QUESTION: what if the result of this step makes the qualitative species level exceed the maxLevel?  Should this be an error?
> this may occur for PN. I would interpret this situation as a PN with place capacities, hence the transition is not enabled in this case.

Again, I can make an invalid model that does this.  The question is whether this should be interpreted as an error.

I think we are having a serious disconnect here.  The issue is that a modeling language MUST have a well-defined semantics.  You cannot allow simulators to interpret models, however, they see fit.  This would create chaos and complete defeat the purpose of having a model exchange format.  Say, I build a model in one tool thinking it has one type of interpretation and simulate it there, and send it to my friend who uses a different tool, and it is interpreted completely differently.  This is a problem.  You seem to be comparing this to say simulating ODEs with different solvers.  This is not the same thing.  An ODE does have a well defined answer.  There is a semantics for ODEs.  However, different simulators may attempt to find this answer using different techniques, and they may get different answers do to different ways of approximating the solution.  However, there is an answer they are trying to find.  Without a semantics, there is no way to even know how to go about trying to find this answer.  This is a serious problem with the qual package.  However, it is also a very solvable one.  All I'm asking for is a section that clearly describes what the community agrees is the semantics of their models.

Chris

I am not so sure about the need for further explanations in the specification... but it does not hurt to add a §, mainly for logical models representation. 
Remind that the current spec probably needs to be refined for Petri nets; SBML qual has been tested (and implemented) only for logical models. 

> 1) The simulator chooses a set of transitions to execute simultaneously.  This set can include a single transition (an asynchronous execution model), all transitions (a synchronous execution model), or some subset of the transitions.
again, this is a simulation set-up. We will use SED-ML and KISAO

> 2) For each transition in the set of selected transitions, the simulator computes its resultLevel using the functionTerms.  Note that if multiple functionTerms for a transition are true, the simulator may choose one arbitrarily to use to set the resultLevel.
it is indicated in the "good practices " section that such a situation (where the resultLevel are different) should be avoided
> 
> NOTE: what to do when multiple functionTerms are true was not defined in the specification, and it should be.  I think it is actually useful sometimes to represent such non-determinism and the usual way of handling this is to say the choice is arbitrary.
this is clarified in the good practises. If the resultLevels are the same, and this is interpreted as a disjunction.
> 
> 3) Next, the simulator updates the level for each qualitative species referenced in the ListOfInputs by reducing the levels of those of those with transitionEffect of type "consumption" by the amount of the resultLevel times the thresholdLevel.  
this would correspond to a PN model. In logical models, the transitionEffect is "none"
> 
> QUESTION: what if the result of this step makes a qualitative species level go negative?  Should that be an error?
this should not happen since the transition would not fire (a functionTerm should define the condition to fire the transition), but again, this corresponds to PN models
> 
> 4) Finally, the simulator updates the level for each qualitative species referenced in the ListOfOutputs by increasing the levels of those with transitionEffect of type "production" by the amount of the resultLevel times the outputLevel, and changing the levels of those with transitionEffect of type "assignmentLevel" to the amount of the resultLevel times the outputLevel.
no, in a logical model, the transitionEffect of an output is set to "assignementLevel". The rule indicates a value, which does not exceed the maxLevel. The update of the qualitativeSpecies level will then depend on the simulation set-up. It principle it is done step by step, but this is not part of the model.
> 
> QUESTION: what if the result of this step makes the qualitative species level exceed the maxLevel?  Should this be an error?
this may occur for PN. I would interpret this situation as a PN with place capacities, hence the transition is not enabled in this case.
> 
> Please let me know if you see any problems with the way I've described the semantics.  I think it encapsulates all possible executions regardless of which type of execution model you use.  I feel it is critical to add this to the specification.  If you look at the SBML core specification, you will see similar descriptions for Events, etc.
> 
> Cheers,
> 
> Chris
> 
> On Nov 29, 2012, at 2:29 AM, Claudine Chaouiya <cha...@ig...> wrote:
> 
>> well, I was probably not clear enough in my answer... this is not part of the model. The same logical model can be simulated under synchronous or asynchronous update. Sure the result will differ, this is why I think this information should be indeed available somewhere. In the future, we should use SED-ML for this  "simulation set-up"...
>> best
>> Claudine
>> 
>> On 29 nov. 2012, at 02:09, Chris J. Myers wrote:
>> 
>>>>> 
>>>>> 3) My understanding of the semantics is that any transition can be chosen randomly to execute at any point during the simulation.  After selecting a transition, the simulator computes its resultLevel using the functionTerms.  It then updates the QS in the ListOfInputs by reducing the levels of those with transitionEffect "consumption" by an amount of thresholdLevel times resultLevel.  It then updates the QS in the ListOfOutputs by increasing the levels of those with transitionEffect "production" by an amount of outputLevel times resultLevel, and changing the levels of those with transitionEffect "assignmentLevel" to that of resultLevel times outputLevel.  Am I missing anything?
>>>> this will depend on the simulator... I understand a model as a specification of the evolution rules of the components. For example in GINsim, we can consider a synchronous dynamics where updates occur simultanously or an asynchronous ones similar to Petri net evolutions (each update being performed concurrently)...
>>> 
>>> This should be made clear though in a semantics section.  I would assume there are as you say two semantics (synchronous and asynchronous).  Therefore, the semantics section should precisely define both, so that this is NOT simulator dependent.  For models to be exchanged, it is important that two tools can agree on what the model is saying.  
>>> 
>>> Cheers,
>>> 
>>> Chris
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Keep yourself connected to Go Parallel: 
>>> VERIFY Test and improve your parallel project with help from experts 
>>> and peers. http://goparallel.sourceforge.net
>>> _______________________________________________
>>> sbml-qual mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbml-qual
>> 
>> ----------------------------------------------
>> Claudine Chaouiya
>> Instituto Gulbenkian de Ciência - IGC
>> Rua da Quinta Grande, 6
>> P-2780-156 Oeiras - PORTUGAL
>> 
>> http://compbio.igc.gulbenkian.pt/nmd/
>> Phone:	(351) 214 46 45 01 
>> Email: cha...@ig...
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel: 
>> VERIFY Test and improve your parallel project with help from experts 
>> and peers. http://goparallel.sourceforge.net
>> _______________________________________________
>> sbml-qual mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-qual
> 
> 
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel: 
> VERIFY Test and improve your parallel project with help from experts 
> and peers. http://goparallel.sourceforge.net
> _______________________________________________
> sbml-qual mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-qual