The time variable in mesa.Model

[EwoutH]

This discussion is split of from

• model: Automatically increase steps counter #2223

Background

Mesa currently has a _step and _time counter, added in #1942. In #2223 a lot of discussion has taken place about the usefulness of the _time counter.

Questions for discussion

1. Is a dedicated time/clock system necessary for Mesa, or is the current step counter sufficient?
2. If implemented, should it be a core feature or an optional module?
3. How might this affect the simplicity of creating basic models, especially for beginners?
4. What level of granularity and flexibility should the time/clock system offer? (Datetime or not)

[EwoutH]

I summarized my points on this subject in these two comments: #2223 (comment) and #2223 (comment).

[Corvince]

I think time in ABMs is considered in many different senses, but let’s start with the basics. The step counter, which represents the number of times model.step is called, is universally useful for any model. By convention, we interpret this as a tick between two different model states we are interested in observing. This step counter is crucial for both data collection and visualization purposes. One aspect I particularly appreciate is that it isn't inherently tied to any notion of "time" in the traditional sense. While it shares the characteristic of being linearly increasing in a unidirectional manner, that’s where the similarity to time ends.

Time, in contrast, serves a different purpose. It is often a more abstract concept in ABMs, representing the progression of events or changes in the system rather than just a simple count of iterations. Depending on the model, time can be mapped to real-world intervals, like seconds, minutes, or years, or it can remain an abstract concept used to delineate different phases or states within the simulation. The flexibility of how time is represented and utilized makes this so hard to abstract away. But in any case I think a good solution should not part of a standard model, but something added one. Therefore I would remove the current time counter as a reserved keyword and develop something that can be used additionally.

[EwoutH]

It's a good point, of course you can add any variable and do the same things. However, with model.time:

• An user can really on time always being present
• By default, it always increases simultaneously with the step function, even if with another amount
• It saves some lines of code an potential for unintended configuration

All those three things remove complexity and potential failure.

I agree it's an utility function, so it's a nice to have. But it's also a way to allow consistently talk about "real time" (which I think is a useful concepts for real-world ABM).

[Corvince]

Your use cases can be achieved simply by doing

class MyModel(mesa.Model):
    time = 8

    def step():
        self.time += 0.25
        ...

I don't think this suffices to be part of mesa. We can show this approach in one of the examples for staged activation. But for beginners its one less variable to know.

[EwoutH]

I get your point, but only for beginners it isn't a variable they need to know. Because by default it's not needed. But when you want to modify it, you can.

I think the fact that's always available, interlocks with the step update and the reduced lines of code provide values. It feels more integrated.

[Corvince]

Yes but always available and interlocked with step just means beginners may do stumble upon it. Either interactively by inspecting model or via the model API documentation or as the parameters for the step function.

And it saves exactly one line of code, but you still need to add some characters, so it's even less then one line. But I think the biggest downside is that it's part of our public API (for the model.step), so we are also more limited there.

[quaquel]

1. Its more then one line of code because it adds a keyword arguments to step.
2. Time might clash with what a user want's to do and thus is a possible source of confusion
3. It creates technological debt. If we want to add a proper clock with datatime as well, we are limited by the fact that time is already there.
4. It clashes with the use of time in the simulator, again a possible source of confusion in users want to go from simple to more advanced use cases.

All this is in my view is too high a price for a simple convenience that @EwoutH sees but other don't really recognize.

[tpike3]

For what they are worth my thoughts are that we pause this discussion for now and leave step and time as is.

From my experience, I have seen clock time as a fundamental and critical piece of very advanced simulations that were crucial for decision making.

I think this needs to be a part of Mesa, however, more importantly I think we need to determine what Mesa is trying to be. Please see #2228

If this general direction (a robust simulation ecosystem) is what the community adopted, at this time I would say step is the core and then time become an add on library for more advanced users like cProfile or typing so it creates a scaffolded approach for users, similar to how I see Python.

However, if the community wants to be a beginner-moderate simulation library, then I would say get rid of time and focus on accessibility and ease that teaches users core fundamentals of simulations.

If the community decided some other direction, then that would also influence my recommendation.

In short, right now, I am recommending a delay, so Mesa can determine what it wants to be and then that can inform our decision.

[EwoutH]

I think I have a new perspective that might spark some new discussion.

At some point we had quite some trouble with agent management, since it was abstracted away from the model. You needed to go though the schedulers to get to your agents. But they, different schedulers developed, which stored their agents in also different ways.

What I took from that, it that the Model object is the glue that holds everything together and should - in general - keep the ground truth.

So what I'm afraid of with things like DEVS and simulator.time, it that it takes away a ground truth from Mesa again. Because now the Datacollector, Visualisation and such need to detect if there is a simulator or not, and get the time form some place else or not.

Therefor I would propose to keep model.time as the ground truth of time in non-strict-ABM models. So:

• model.steps strictly keeps what you
• model.time keeps a non-discrete time value for all non-strictly-ABM models. If there's a simulator, that simulator updates model.time. If not, we can keep it in sync with model.steps

This way, you can always trust on model.time to be there, if there's a simulator or not. We could let the some components, like the datacollector, choose between using steps as index or time. By default it could be time (for ABM models), but if you want to collect data on non-fixed intervals you can start using model.time. And so on.

[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

[EwoutH]

One challenge I currently have developing new ideas is that we don’t have a consistent way of getting model time.

A solution could be:

1. Adding a time property, that gives model.steps without a simulator defined or model.simulator.time with it.
2. Instantiating a default simulator if no simulator is passed on initialization. That way you can always depend on there being a simulator.

[quaquel]

Conceptually, I prefer having a dedicated simulator. However, I am not yet fully satisfied with the current API. The key problem is that the simulator needs a reference to the model, while the model needs a reference to the simulator. What I do like is that the simulator fully encapsulates the run control, which is currently not well-defined in MESA.

I know some have argued for capturing all information inside the model instance, but, for me, run control is conceptually separate and independent from the model. I thus prefer something like simulator.run(n=10) over model.run(n=10) (where the latter in turn would do self.simulator.run(n=10).