Standardized order of events in a step and defining the first step

[EwoutH]

This discussion is split of from

• model: Automatically increase steps counter #2223

Background

There's a potential benefit in standardizing the order of events within a model step and determine what constitutes the first step in a simulation.

Points to consider

1. Step Sequence: Defining a clear order for events within a step (e.g., when counters increment, when agent actions occur, when data is collected).
2. First Step Definition:
   • Should the initial state (after __init__) be considered step 0 or step 1?
   • Implications for data collection and analysis.
3. Consistency: Ensuring consistent behavior across different model types and schedulers.
4. Documentation and Conventions: Clearly communicating the chosen conventions to users.

Questions for discussion

1. What should be the standard order of operations within a step?
2. How should we define and number the initial state and first step?
3. How might different step numbering conventions affect model analysis and interpretation?
4. Should Mesa enforce a strict convention, or allow flexibility for different use cases?

[EwoutH]

On the order of steps

I think it's beneficial to have a "default" order things are normally done in a Mesa step. That makes it easier to teach and more consistent. My proposed standard order would be:

def step():
    self._advance_time()              # Time is increased at the beginning of the step
    self.agents.shuffle().do("step")  # Do things during the step
    self.datacollector.collect()      # Collect data at the end of the step

This way, a new day begins, you do stuff during the day, and at the end of the day you evaluate and collect your data.

[quaquel]

I agree with this and it is also how it is done in ABMSimulator and DEVSSimulator.

[EwoutH]

On the count of steps

For me, this makes the most sense:

• Time starts at 0, and the Model (and often Agent) init is performed
• If wanted, data can be collected, to capture the initial state during or after the init.
• Then, the first step starts, increasing the count to 1 at the beginning of the step.
• After stepping N times, the time is also N.

This means, if you collect data at the end of the step, you get row 1 to N. If you also collect in the init you get row 0 to N.

[EwoutH]

@rht I’m curious, that’s your perspective on this?

[rht]

There was a past similar discussion/confusion on this. I had to excavate the threads to find it.

[rht]

This one: #1768, this was a problem on not being able to merge the model vars DF and agent vars DF. Does your convention solve this problem?

[EwoutH]

I think standardizing it will help already, as well as tracking time in the model instead of the scheduler. It removes a lot of the potential ways in which it could go wrong.

I also - personally - really like step 0 being the init, and step 1 to N being step 1 to N.

[rht]

How does your convention compare with numerically solving differential equations, where you have the initial conditions at t0

t0 = 0
t = t0
y = y0
# Evolve y, t by 1 step
y += f(x, t) * dt
# this must happen after the previous line, for Euler's method instead of backward Euler's method
t += dt

If you instead use the Runge-Kutta method, the t += dt must happen last as well.

[rht]

Right, you would like the time increase in the middle:

It's more accurate as:

def step():
    self._steps += 1
    self.agents.shuffle().do("step") 
    self._time += deltat
    self.datacollector.collect()

The first 3 lines can be done in the wrapped step.

If datacollection is done using signals, this is actually easy. Incrementing time will fire a signal. The datacollection listens to this signal and in response collects.

But that the data collector is triggered using signal, but the clock is updated via wrapped step, seems too non-consistent to me. If possible, both should have the same trigger mechanism. I assume this is only because the concept of signal hasn't been integrated into the library yet.

[quaquel]

1. As argued in The time variable in mesa.Model #2228, I would drop time from model for now and concentrate on step only. In the default ABM case they are the same anyway.
2. If time is kept, I would advocate for incrementing step and time together. So one of the two following options

def step():
    self._step_ += 1
    self._time  += 1

   # user specific step logic goes here

  self.datacollector.collect()

def step():
    # user specific step logic goes here
    
    self._step_ += 1
    self._time  += 1
    self.datacollector.collect()

3. We currently don't use signals so what is or what is not consistent is a moot discussion. Depending on what we agree here, we can set it up anyway we want. One possibility, however, would be to let the datacollector listen for a signal that model.step is incremented, in response to which it does a collection round.

[rht]

I also - personally - really like step 0 being the init, and step 1 to N being step 1 to N.

I'm fine with this, for step only. Time has to be updated the last, just before data collection. Given the constraint, I prefer to drop time for now.

[rht]

As per #2247 (reply in thread), I'm fine with combining the update of step & time together, before everything else is updated. It would correspond to backward differentiation in SD. But maybe this is the reason why NetLogo lets user place tick at anywhere they want, because there in general, any ABM would sometimes update the time first, then sometimes last?

[rht]

But maybe this is the reason why NetLogo lets user place tick at anywhere they want, because there in general, any ABM would sometimes update the time first, then sometimes last

Scratch this. No speculation of the decision of the NetLogo's creator. What is concrete is that the clock is updated first in Zeigler's framework.

[EwoutH]

We're having a call on this subject. Note that some of the discussion continues there:

• Call on time integration in Mesa (Tuesday 27 aug 14:30 CEST) #2247