What is [E] ?

[hmedina]

Follow up from jonathan-laurent/KaTie#12

Taking the model

%agent: Jekyll()    %init: 1 Jekyll()
%agent: Hyde()

Jekyll(), . <-> ., Hyde() @ 1, 1

%mod: [E] = 3 do $ADD 1 Jekyll() ;

%mod: [true] do $SNAPSHOT "snap_".[E].".ka" [true] ; repeat [true]
%mod: [E] = 5 do $SNAPSHOT "snap_final.ka" [true] ; $STOP ;

It produces a trace with 6 steps:

"trace":
    [
        [3,[[0,[0,0],[]]]],
        [1,0,[[[[0,[0,0]]]],[[5,[0,0]],[0,[0,1],[]]],[],[],[]],[-1,1.7935983629643002,1,null]],
        [1,1,[[[[0,[0,1]]]],[[5,[0,1]],[0,[0,0],[]]],[],[],[]],[-1,1.8292313230569146,2,null]],
        [1,0,[[[[0,[0,0]]]],[[5,[0,0]],[0,[0,1],[]]],[],[],[]],[-1,3.9882686236387492,3,null]],
        [2,"$APPLY 1 Jekyll()+",[[],[[0,[1,0],[]]],[],[],[]],[-1,3.9882686236387492,4,null]],
        [1,1,[[[[0,[0,1]]]],[[5,[0,1]],[0,[0,0],[]]],[],[],[]],[-1,4.177341750145077,4,null]],
        [1,0,[[[[0,[1,0]]]],[[5,[1,0]],[0,[1,1],[]]],[],[],[]],[-1,5.16115083587232,5,null]]
    ]

KaTIE's user-readable digest:

{
  "0": [ "_init_", "new(Jekyll.0)" ],
  "1": [ "Jekyll(), . -> ., Hyde()", "del(Jekyll.0) new(Hyde.1)" ],
  "2": [ "Hyde(), . -> ., Jekyll()", "del(Hyde.1) new(Jekyll.2)" ],
  "3": [ "Jekyll(), . -> ., Hyde()", "del(Jekyll.2) new(Hyde.3)" ],
  "4": [ "_pert_", "new(Jekyll.4)" ],
  "5": [ "Hyde(), . -> ., Jekyll()", "del(Hyde.3) new(Jekyll.5)" ],
  "6": [ "Jekyll(), . -> ., Hyde()", "del(Jekyll.4) new(Hyde.6)" ]
}

Note the following:

1. steps 3 & 4 have the same [T] value; this makes sense because step 4, a perturbation, does not advance time
2. steps 3 & 4 do not have the same [E] value;
3. steps 4 & 5 have the same [E] value, but different [T] values;

In table form:

'step_index'	'time'	'sim_event_id'
0	0	0
1	1.7935983629643002	1
2	1.8292313230569146	2
3	3.9882686236387492	3
4	3.9882686236387492	4
5	4.1773417501450769	4
6	5.1611508358723199	5

These values, should they be interpreted as:

• T is the value of time when the step fired
• E is the number of rule applications after this step has fired

[feret]

Your interpretation is consistent.
Although it would make more sense to me to increment the E counter just before applying a real (not a perturbation) event (starting from 0).

In other words,

1. Draw the next potential event
2. Check whether this is an enabled event
3. If so Go to 4) otherwise go to 1)
4. Increment the event counter
5. Apply the event
6. Update the description of potential embeddings
7. Goto 1)

Let me know what you thing, and I will try to figure out where it is in the simulation engine.

[hmedina]

Thank you Jérôme.
I agree incrementing E before applying "real events" makes more sense. It was surprising to me to see the time & event counter not advance concomitantly in larger models. The steps in the trace that hold rule applications, their [E] would mean "this is the n th rule application", rather than "if this were a rule, this would be the n th rule application", which is more transparent.

If we adopt the order of operations you outline, we would see the perturbation step keeping invariant the [T] and [E] fields, correct? In table form:

'step_index'	'time'	current [E]	new [E]
0	0	0	0
1	1.7935983629643002	1	1
2	1.8292313230569146	2	2
3	3.9882686236387492	3	3
4	3.9882686236387492	4	3
5	4.1773417501450769	4	4
6	5.1611508358723199	5	5

That would avoid erroneous reads (like "event 4 has two time values" or "time 3.98 corresponds to two events"), favoring the realization that step 3 was a special kind of step.

In terms of snapshots, currently they contain:

file	time	event	step index
snap_2.ka	1.82923	2	2
snap_3.ka	3.98827	3	4
snap_4.ka	4.17734	4	5

If [E] and [T] are advanced concomitantly, one would not have to worry about snap_3.ka saying event 3 is at time 3.98, when the trace prints a 4 instead for that time stamp's last entry.

Regardless, @jonathan-laurent I think that "sim_event_id" should be renamed, as it reporting from a rule application counter, and not an identifier of trace steps.

[feret]

Please try the branch eventid, and let me know whether I can merge.

[hmedina]

Hi Jérôme! Re-ran the model with the eventid branch, and the results are what we expected:

'step_index', 'time', 'sim_event_id'
0, 0.0, 0
1, 1.7935983629643002, 1
2, 1.8292313230569146, 2
3, 3.9882686236387492, 3
4, 3.9882686236387492, 3
5, 4.177341750145077, 4
6, 5.16115083587232, 5

Before you merge though, will a trace that was written with the old behavior remain valid to a tool build with this new reader?

[feret]

Dear Hector, I cannot answer your question.
Please try your usual pipeline on a small example.
On KaStor, I do not use the event id in the algorithms (only when dumping info about the stories).
On @jonathan-laurent tools, I do not know what is done.

[hmedina]

Well, I'm seeing a stack overflow on one hand, and assertions failing on another, so some work will be required to read old traces. This said, those are not related to this specific change, so it's probably fine to merge into main.

[feret]

@jonathan-laurent What do you think ?
Does it set a problem for your tools ?
What do you prefer ?

[jonathan-laurent]

I am agnostic. Like KaStor, my tools do not use this counter and only report its value when asked to.
What we must do is make sure that the implemented behavior is compatible with the description of [E] in the manual and add proper documentation there if needed.

What are the common usecases for [E] anyway beyond using it as a stopping criterion? In the long run, I think there should be a single concept of event and event_id, which is the one implemented in the causality tools. A rule application counter can be added if needed but it should be properly named and documented.