search

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
112 stars 41 forks source link

Agent "identifiers" are recycled and so do not identify agents #659

Open hmedina opened 1 year ago

hmedina commented 1 year ago

Given the toy model

%agent: Jan()
%agent: Feb(s{a, b, c})
%agent: Mar()

%init: 1 Jan(), Feb(s{a}), Feb(s{b}), Mar()

Feb(s{a})- @ inf
Feb(s{c})+ @ 0.1

%mod: [E] = 0 do $SNAPSHOT [true] ;
%mod: [E] = 1 do $SNAPSHOT [true] ;
%mod: [E] = 2 do $SNAPSHOT [true] ; $STOP ;

The snapshots that are produced by KaSim are:

// Snapshot [Event: 0]
// "uuid" : "831335101"
%def: "T0" "0"

%init: 1 /*1 agents*/ x3:Mar()
%init: 1 /*1 agents*/ x1:Feb(s{a}[.])
%init: 1 /*1 agents*/ x2:Feb(s{b}[.])
%init: 1 /*1 agents*/ x0:Jan()
// Snapshot [Event: 1]
// "uuid" : "831335101"
%def: "T0" "0"

%init: 1 /*1 agents*/ x3:Mar()
%init: 1 /*1 agents*/ x2:Feb(s{b}[.])
%init: 1 /*1 agents*/ x0:Jan()
// Snapshot [Event: 2]
// "uuid" : "831335101"
%def: "T0" "18.3413"

%init: 1 /*1 agents*/ x3:Mar()
%init: 1 /*1 agents*/ x1:Feb(s{c}[.])
%init: 1 /*1 agents*/ x2:Feb(s{b}[.])
%init: 1 /*1 agents*/ x0:Jan()

Note how x1:Feb() means two different agents, one for events [0, 1], a different one for events [2, ...], as distinguished by the internal state of its s site, s{a} vs. s{c} (which are static in this model).

In complex models where there is agent flux (a type of agent is deleted but also created), finding an agent with an "identifier" does not identify that agent. In my Wnt models, I had expected to be able to track bCatenins via these "identifiers", but that is not sound. These integer-marks should not be called or thought of as identifiers until this behavior is corrected.

Instead, one can do trace analysis[^1]. One option is to use KaTie to produce snapshots, as that tool uses true identifiers (it correctly prints x4:Feb(s{c}[.])). Alternatively, one can match for degradation & creation events, to be certain there was no integer-mark recycling between two KaSim-derived snapshots that contain these agents with integer-marks.

[^1]: Requesting snapshots via %mod: can yield corrupted traces, see https://github.com/Kappa-Dev/KappaTools/issues/656; KaSim will not complain when producing the trace, but will be unable to read it, and by extension so will KaTie...

feret commented 1 year ago

Dear Hector,

I think there is a misunderstanding of what is expected from Kappa agent ids. Maybe the terminology had been improperly, but here an id denotes a memory address. Thus, reusing them is something that we want to spare memory (GC). Also in Kappa, the state of the system is defined up to isomorphisms, which means that you cannot track the behavior of an agent thanks to its identifier.

Fortunately, the simulation engine does not rename agents between steps (but that is an implementation choice). Thanks to this you can track an agent by its id. But yes, when an agent is degraded, his former id can be reused and you have no way to make the difference (except replaying the trace).

In the module core/cflow/utilities.mli (* reallocate agent ids to avoid conflict (implicitly called by cut and fill_siphon) ) val make_unambiguous: (trace,trace) unary

If you think this is useful, we can add proper identifiers. I would use a specific site with an internal state ranging over the natural numbers. This id would be allocated uniquely in the initial state and at agent creation. It cannot be tested or modified. It would be displayed in snapshots.

Do you think it would be useful ?

Best Jérôme.

hmedina commented 1 year ago

Hi Jérôme,

To be fair, since none of this is documented, users do not have a right to expect any meaning of these ids, so that part was perhaps wishful thinking on our part.

That said, yes, I do think it would be useful to have identifiers. For my own bond simulator, I added persistent & unique agent identifiers as metadata to an agent object, which are wholly independent of how or where I store the agent. I believe @plucky did something similar for his SiteSim, though I can't find it on GitHub. Given that different simulator engines ended up implementing identifiers, I think that's a clear sign of their desirability. As to how to implement them, I do not have a horse on this race.

Moreover, @jonathan-laurent 's KaTie has implemented a snapshot printer that does produce identifiers that identify, and so we are in a situation where a state or snapshot will use either a "memory address" or an actual "agent identifier" for the same objects depending on whether it was KaSim or KaTie that produced it. That is likely to trip future users of these platforms.

plucky commented 1 year ago

I made SiteSim temporarily ‘private’, because it has become critical code for our research; once the paper is on arXiv I make it public again. SiteSim will morph in due time to a poor man’s full-fledged Kappa simulator in Python.

plucky

On Apr 21, 2023, at 7:33 PM, Hector Medina @.***> wrote:

Hi Jérôme,

To be fair, since none of this is documented, users do not have a right to expect any meaning of these ids, so that part was perhaps wishful thinking on our part.

That said, yes, I do think it would be useful to have identifiers. For my own bond simulator, I added persistent & unique agent identifiers https://github.com/hmedina/BondSimulator/blob/main/src/lib.rs#L133 as metadata to an agent object, which are wholly independent of how or where I store the agent. I believe @plucky https://github.com/plucky did something similar for his SiteSim, though I can't find it on GitHub. Given that different simulator engines ended up implementing identifiers, I think that's a clear sign of their desirability. As to how to implement them, I do not have a horse on this race.

Moreover, @jonathan-laurent https://github.com/jonathan-laurent 's KaTie has implemented a snapshot printer that does produce identifiers that identify, and so we are in a situation where a state or snapshot will use either a "memory address" or an actual "agent identifier" for the same objects depending on whether it was KaSim or KaTie that produced it. That is likely to trip future users of these platforms.

— Reply to this email directly, view it on GitHub https://github.com/Kappa-Dev/KappaTools/issues/659#issuecomment-1518422290, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACG3KJGV7CHFFR3QRTQ6PLXCMKL7ANCNFSM6AAAAAAXGA64OM. You are receiving this because you were mentioned.