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

[hmedina]

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¹. 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.

Footnotes

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]

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]

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]

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 <#659 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACG3KJGV7CHFFR3QRTQ6PLXCMKL7ANCNFSM6AAAAAAXGA64OM>. You are receiving this because you were mentioned.