Kappa-Dev / KappaTools

Tool suite for kappa models. Documentation and binaries can be found in the release section. Try it online at
http://kappalanguage.org/
GNU Lesser General Public License v3.0
113 stars 41 forks source link

useless ambiguity warning may be incorrect #589

Open nilsbecker opened 5 years ago

nilsbecker commented 5 years ago

hi, i get the following warning:

File "kappa7.ka", line 104, characters 7-18:
Warning: Useless molecular ambiguity, the rules is always considered as
         unary.

for the corresponding rule (somewhat simplified) :

'rewiring'
E(x{b}[1/3]), 
E(x{p}[1/4], y[_]), 
E(y[_], x{p}[2/3]), 
E(x{b}[2/4]) 
@ 0.0 {'rewire'}

as i understand the semantics, this warning seems to be wrong.

in the rule pattern, i'm requiring the y sites to be bound, but not to be bound to each other. indeed, the rule is correctly applied to unary compexes where there are intervening elements between the two y sites in the pattern.

but when i replace the rate line with @ 'rewire' i would indeed expect the rule also to apply between pairs of E elements that are in different complexes.

is the warning incorrect?

nilsbecker commented 5 years ago

actually, i tried it out. with a single rate for uni-and bimolecular rule application one gets a totally different result. indeed the warning seems incorrect.

pirbo commented 5 years ago

Yes, we must improve that. Here is the full story: Your rule contains [_]. Kappa internals don't deal with them so the rule is exploded internally into its refinement (that I can't guess because I don't have the full contact map of the model but that you can have a dump of them by running bin/KaSim --compile your model.ka) and I'm pretty sure one of the refinement will look like

'rewiring_refinement4'
E(x{b}[1/3]),  E(x{p}[1/4], y[5]),  E(y[5], x{p}[2/3]),  E(x{b}[2/4]) @ 0.0 {'rewire'}

which is correctly rewritten into

'rewiring_refinement4'
E(x{b}[1/3]),  E(x{p}[1/4], y[5]),  E(y[5], x{p}[2/3]),  E(x{b}[2/4]) @ 'rewire'

but also emits a warning by doing so. And, for sure, the warning in this case should not be there because in the other refinements of the rule, the molecular ambiguity does exist!

It's not obvious to me (given the current code) how to distinguish between "the user entered a rule that must be corrected" and "rule refinement has generated 1 case beyond others where correction is needed"...

nilsbecker commented 5 years ago

i see. one would probably need some way to trace back the refinements to the original rule set and then some logic, in this case to emit the warning only if all of the descendants of a rule have useless ambiguity.