potentially incorrect complex name in KaDE output (SBML format)?

[yarden]

Hi all,

I have been using KaDE to successfully convert Kappa programs into ODEs in SBML format. It works wonderfully in all the cases I've tried. However on this Kappa program I am getting this SBML output that seems to have incorrect, or at least incomplete, species names.

The Kappa program uses agents A and B which have a "head" and "tail" sites. There are rules that explicitly require "head" and "tail" sites to be free, and the program is initialized with free A and B agents:

%init: 1 A(head[.], tail[.])
%init: 1 B(head[.], tail[.])

There are rules that explicitly require A or B to have their sites free in LHS, such as this rule that requires a free B:

BToAIntegrator(site[_],nutr_site[.]),B(head[.],tail[.]) -> BToAIntegrator(site[_],nutr_site[1]),B(head[.],tail[1]) @ 'int_bind_nutr_for_k'

However, in the SBML output, there's no B(head[.], tail[.]) species - only a species with B(tail[.]), leaving the head site state implicit. I'm not sure if that's because of some static analysis that is being done to infer that the rule can be rewritten without reference to head site. But since the program is initialized explicitly with B(head[.], tail[.]) it seems like that species should be in the SBML output. Is this an error or am I misinterpreting the output?

Thank you very much!

[feret]

Hi Yarden, Is there a rule to bind the site head of B ? If not, the site will be removed (It can take only one state: free, and hence contains no information). Best. Jérôme.

…

Le 21 janv. 2021 à 21:33, Yarden Katz ***@***.***> a écrit : Hi all, I have been using KaDE to successfully convert Kappa programs into ODEs in SBML format. It works wonderfully in all the cases I've tried. However on this Kappa program <https://gist.github.com/yarden/7e1ef3dba0924f5bcca2fff1adcf230c> I am getting this SBML output <https://gist.github.com/yarden/8adf6b072f41d6f17b52e990547eece8> that seems to have incorrect, or at least incomplete, species names. The Kappa program uses agents A and B which have a "head" and "tail" sites. There are rules that explicitly require "head" and "tail" sites to be free, and the program is initialized with free A and B agents: %init: 1 A(head[.], tail[.]) %init: 1 B(head[.], tail[.]) There are rules that explicitly require A or B to have their sites free in LHS, such as this rule that requires a free B: BToAIntegrator(site[_],nutr_site[.]),B(head[.],tail[.]) -> BToAIntegrator(site[_],nutr_site[1]),B(head[.],tail[1]) @ 'int_bind_nutr_for_k' However, in the SBML output, there's no B(head[.], tail[.]) species - only a species with B(tail[.]), leaving the head site state implicit. I'm not sure if that's because of some static analysis that is being done to infer that the rule can be rewritten without reference to head site. But since the program is initialized explicitly with B(head[.], tail[.]) is seems like that species should be in there, no? Is this an error or am I misinterpreting the output? Thank you very much! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#631>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACG3M5TQN6CK47A7YQR4Z3S3CFQLANCNFSM4WNO6JJQ>.

[yarden]

Thanks very much, Jérôme. You are of course right that there's no rule that binds the head site of B, so the KaDE output is technically correct. However, KaDE used static analysis to arrive at that conclusion, since in the general case an LHS with B(head[.], tail[.]) could contain more information than one with B(tail[.]). From the user's perspective, the LHS in this program refers to both head and tail being free. That's why it seems counterintuitive to have the ODEs generate equations that don't explicitly refer to that species. I bring this up because I programmatically generate ODEs from Kappa programs and then query for specific species from ODE simulations. As a user, I'd expect B(head[.], tail[.]) to be a species in the ODEs, but not B(tail[.]). I just wonder if it's possible to make KaDE output more fully specified species in order to more closely match the form of the rules. If this creates a headache or raises all kinds of thorny issues, don't worry about it, I just bring it up as a possibility.