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
108 stars 40 forks source link

Provide a more user-friendly format for traces (follow up from #658) #663

Open feret opened 1 year ago

feret commented 1 year ago

It would be better to use a format closer to simple operational semantics. Action should correspond to self-content atomic transformation of graphs + side-effects. (In particular, it requires an action for each bond that is removed explicitly in the rule, even if it occurs in an agent that is degraded).

In case of id conflict, doing

bond removal agent degradation agent creation (with all site implicitly free and internal state to the first value) binding and internal state modification. Seems to be the most appropriate to me and is consistent with the description of the operational semantics in the literature. The main advantage, is that each action can be interpreted independently (the result of each action is a valid state).

hmedina commented 1 year ago

Since this is talking about changing the format, I'll post this related discussion from some years ago: https://github.com/Kappa-Dev/KappaTools/issues/599

feret commented 1 year ago

599 is quite an orthogonal issue.

@jonathan-laurent concerns is about the semantic content of the trace, whereas @hmedina ones is about its disk occupation. Note that a trace storing just the rule id and the embeddings is likely to be even more compact (independently of any on the fly compression treatment).

hmedina commented 1 year ago

For a rule like: A(), B(s{one/two}) @ 0.0 {1.0}, the embedding would store a way of identifying both agents?

That sounds like it would remove the need to use the idiom I'm using (i.e. active_site, explicit bond, and infinite rate usage here). That would streamline work similar to mine, because the "publication model" does not use that idiom, but the model fit for trace analysis does.

feret commented 1 year ago

Yes, it is just the primal way a rule application arises in the simulation. It has three advantages:

jonathan-laurent commented 1 year ago

@hmedina Jérôme is correct that the trace indicates the identity of all agents that are modified or tested by any rule application and an agent being mentioned in a rule means at the very least that a presence test happening.

However, it is true that KaTie currently cannot match an event pattern such as A(), B(s{one/two}). As mentioned in the documentation, event patterns must be rooted in the sense that every mentioned agent is either modified or connected to a modified agent via a sequence of bonds. At the time, this decision was motivated by:

  1. Implementation simplicity.
  2. My (wrong) impression that such action at distance was a modelling antipattern.
  3. The fact that two legitimate semantics can be proposed for matching A(), B(s{one/two}), possibly creating a source of confusion among users. Indeed, for every event modifying B, one could generate a single matching capturing the identity of the A agent that happened to be picked by the simulator when instantiating the underlying rule. Which agent A got picked is kinda arbitrary though and some users might expect as many matchings to be produced as there are A agents in the state before the event.

Thinking about it, I think the first semantics really is more useful and consistent and so I think there is a strong case to be made for allowing agent identity to be determined by tests in KaTie (and presence tests in particular). Any thoughts?

feret commented 1 year ago

@jonathan-laurent I do not get your point about the ambiguity of the semantics. .

The activity of your rule is k |A()|  |B(s{one/two})|. If you expect another one (as in presence of A, B can do this, but independently on the quantity of A()), you should use functional rates.

Could you clarify which semantics (trace distribution, trace replaying interpretation) are you referring two ? and what are the two propositions ?

jonathan-laurent commented 1 year ago

@feret My point was purely about KaTie's trace pattern semantics so this was probably not the right place for this conversation anyway. I do understand that A(), B(s{one/two}) is a valid Kappa rule.