Incremental KaSa: Static Analysis of Kappa Models at Edit Time (supplementary resources)
|
This website provides some supplementary resources about the following paper:
|
Incremental Kasa: Static Analysis of Kappa Models at Edit Time
|
@InProceedings{feret:CMSB2026b,
title = "Incremental KaSa: Static Analysis of Kappa Models at Edit Time.",
booktitle = "Twenty fourth International Workshop on Static Analysis and Systems Biology (SASB'26)",
series = "LNCS/LNBI",
publisher = "springer",
volume = "????",
pages = "??-??"
note = "to appear, Supplementary information available at \url{www.di.ens.fr/~feret/Incremental-KaSa-tool-paper}",
author = "Rebecca Ghuidini and J{\'e}r{\^o}me Feret"}
git clone https://github.com/Kappa-Dev/KappaTools.git cd KappaTools git checkout incremental-KaSaThe file README.md contains all the information to compile the tools and to run the benchmarks.
We illustrate a typical usage of our incremental analyzer: A modeler is revising a part of a larger model that describes the behavior of some membrane receptors.
Two types of protein are concerned:
Ligand instances (EGF) will be colored blue circles and receptor instances (EGFR) green hexagons.
Each instance of receptor has four binding sites, one in white to connect with ligand instances, one in blue to bind at the same site of other receptor instances, and the third one in yellow to bind to the fourth one in pink of other receptor instances.
EGF(r[.]),EGFR(l[.]) -> EGF(r[1]),EGFR(l[1])
EGFR(l[_],r[.]),EGFR(l[_],r[.]) -> EGFR(l[_],r[1]),EGFR(r[_],l[1])
EGFR(r[_],c[.]),EGFR(r[_],n[.]) -> EGFR(r[_],c[1]),EGFR(r[_],n[1])
A key property in this model part is that it is impossible to chain three receptor instances. The modeler introduces a fictitious rule as follows:
EGFR(r[1]),EGFR(r[1],c[2]),EGFR(n[2]) -> EGFR(r[1]),EGFR(r[1],c[2]),EGFR(n[2])to assess this property. He expects the analyzer to detect that this fictitious rule can never be applied, which is true.
The modeler then considers rules to break the links between protein instances.
EGF(r[1]),EGFR(l[1]) -> EGF(r[.]),EGFR(l[.])
EGFR(r[1]),EGFR(r[1]) -> EGFR(r[.]),EGFR(r[.])
EGFR(c[1]),EGFR(n[1]) -> EGFR(c[.]),EGFR(n[.])
Unfortunately, with these new rules, the fictitious rule is no longer detected to be unreachable. Thus, either the analysis is not precise enough (due to the abstraction), or the property of interest is not satisfied anymore.
The modeler uses the incremental analyzer to check the result of the analysis when one of the four unbinding rules is discarded. In this way, the property of interest is recovered when the second rule is discarded.
The modeler replaces it with the following one:
EGFR(r[1],c[.],n[.]),EGFR(r[1],c[.],n[.]) -> EGFR(r[.],c[.],n[.]),EGFR(r[.],c[.],n[.])
The reader is still alerted that the fictitious rule is unreachable. This proves that the expected property is satisfied in the (corrected) model.
Now we provide both versions of the model:
Launch the KaSa agent with the wrong model:
./bin/KaSaIncremental --current-chapter examples/incremental_analysis/use_case/wrong_model.kaThen at prompt type the following instruction:
update file examples/incremental_analysis/use_case/correct_model.ka as examples/incremental_analysis/use_case/wrong_model.ka
or copy paste the following models:
To test the GUI, open the file examples/incremental_analysis/simple_example.kawith the button
This model contains four agent types: A, B, C and D. The initial state contains the agents D and B. The agent A can be created by the rule 'create.A.if.D', if an agent D is present. The contact map shows the four types of agents. If the "high accuracy" contact map is chosen, we see that the agent C can never be formed. To solve this, we can add the initial state:
%init: 100 C(c{u})
If we do that, the analysis is updated incrementally and the warning "dead agent" disappears.
By disabling the checkboxes in front of the rules or initial states, we can see how the result of the analysis changes when some rules are removed. For example, when disabling the rule 'bind.A_A', the model cannot form any unbounded polymers anymore. And when disabling the first initial state of the agent D, the agents D and A become unreachable.
.\_build\install\default\bin\KaSaIncremental.exeinstead of
./bin/KaSaIncremental.
The CLI can be lauched with an example model by running:
./bin/KaSaIncremental --current-chapter examples/incremental_analysis/simple_example.ka
The analysis prints the constraints that were calculated by the reachability analysis. For example, it says that C cannot occur in the model. This can be fixed by adding the inital state:
%init: 100 C(c{u}) in the file examples/incremental_analysis/simple_example.ka
and updating the analysis.
The analysis can be updated by typing:
update file examples/incremental_analysis/simple_example.ka
in the interactive agent. After this, the analysis says "all agents may occur in the model". Rules can be disabled by their label, for example:
disable 'create.A.if.D'
Subsequently, they can be enabled again:
enable 'create.A.if.D'
The command help prints more information about available commands.
You may launch the scripts from the root of the repository by prompting the following instructions:
Warning the second script takes about 8 hours on an apple M4 Max chip.
git clone https://github.com/Kappa-Dev/KappaTools.git cd KappaTools git checkout incremental-KaSa ./examples/benchmarks/incremental-KaSa/script_disable_and_add_rules -i ./examples/benchmarks/incremental-KaSa/script_compare_working_set_size -i
(When the -i option is used, the tools are built automatically with all the dependencies.)
You may launch the scripts from the root of the repository by prompting the following instructions:
Warning the second script takes about X hours on an apple M4 Max chip.
git clone https://github.com/Kappa-Dev/KappaTools.git cd KappaTools git checkout incremental-KaSa opam install . --update-invariant --deps-only dune build make all ./examples/benchmarks/incremental-KaSa/script_disable_and_add_rules -e ./examples/benchmarks/incremental-KaSa/script_compare_working_set_size -e