Simplification: Remove model.running

[rht]

In most cases, models are run with explicit, N number of steps. In case where it has a halting condition, it is easy to override model.run_model like this. E.g. for forest fire
before

    def step(self):
        ...
        # Halt if no more fire
        if self.count_type(self, "On Fire") == 0:
            self.running = False

    def run_model(self):
        while self.running:
            self.step()

after

    def run_model(self):
        while True:
            self.step()
            if self.count_type(self, "On Fire") == 0:
                break

[rht]

This way, people won't have to stop and read what model.running is, what it is used for, etc -- saving time.

[rht]

Based on reading https://juliadynamics.github.io/Agents.jl/stable/comparison/, it seems that Agents.jl considers it a feature to have a boolean model state to tell whether a model has terminated or not. I can't find the relevant termination condition checking in Agents.jl code base (see https://github.com/JuliaDynamics/Agents.jl/blob/7e5c3dcbc7d49993b7155595a8427d2510a7a232/src/simulations/collect.jl#L109).

The table comparison https://juliadynamics.github.io/Agents.jl/stable/comparison/ inaccurately describes that users can only write explicit loops for terminating a simulation. But it is bound to become true if we agree to remove model.running.

@Libbum if I may ask, what is the reason that you have this model termination feature in Agents.jl? I may be missing something about its benefit.

[rht]

OK, I'm answering my own question regarding with Agents.jl termination. The run! has n as an argument, which can be an Int or a function.

The until function handles both cases of n:
https://github.com/JuliaDynamics/Agents.jl/blob/7e5c3dcbc7d49993b7155595a8427d2510a7a232/src/simulations/step.jl#L42-L43

[rht]

IMO, the simulation termination condition should be defined separately from the model step. I think, writing it in run_model is cleaner.

[jackiekazil]

agree

[Corvince]

I think the biggest advantage of the current approach is that the model can be stopped from anywhere and not just from the run model loop itself.

This is for example used by our Frontend, where the stop button sets model.running to false. So we should be extra careful not to shoot ourselves in the foot by removing it.

And I can also imagine models where single agents have the power to stop the model. Right now they just have to set model.running = false
Breaking a while loop from the outside is a much harder problem.

[rht]

Regarding with this.running (

mesa/mesa/visualization/templates/js/runcontrol.js

Line 42 in 5a4248d

this.running = false;

) in the front-end, it is actually not related to model.running. The only interaction with the server is the get_step message in

mesa/mesa/visualization/templates/js/runcontrol.js

Line 54 in 5a4248d

send({ type: "get_step", step: this.tick });

.

The models that have single agents stopping the simulation within the agents step() is probably not that common. Should this be needed, the modeler can define model.running just for this use case.

[rht]

It looks like the ModelController is not leveraging the model's run_model when the "start" button is clicked where it should have. This seems incorrect.

[Corvince]

Ha, you are right, I was misremembering how the server works.

But the start button not triggering run model is by design with the current state. If it works trigger, the model would keep on running and Frontend and backend would quickly be out of sync

[rht]

I think it is actually safer with run_model, because the client is passively waiting for websocket messages from the server anyway. I have seen that currently, the simulation keeps doing step() indefinitely, even though model.running is already False.

There is one use case that needs model.running: when clicking the step button manually in the GUI, without the model.running, the step() keeps happening. But even in latest main branch, the model.step() method doesn't check for model.running.

[Corvince]

Well yes I think there are several tradeoffs to consider. But calling run_model would run the model until the stop condition is reached or even indefinitely. There would be no way to stop the model from the Frontend - you could only stop rendering but there would be no sane way to continue. So the tricky part is not start, but stop.

But just to be clear: I now agree that currently we don't need/use model.running.

So I think it is okay to remove it.

[Corvince]

Sorry for spamming the issue, but model.running is used by the visualization Server. So be sure to be careful with any changes

https://github.com/projectmesa/mesa/blob/main/mesa/visualization/ModularVisualization.py#L206

[rht]

OK, I think a middle ground solution is to not specify model.running = True for examples that never set model.running = False (only few of the examples ever set it to False).
This also means that

mesa/mesa/model.py

Line 32 in e549107

self.running = True

needs to be moved to __new__, because I could imagine people forgetting to do super().__init__() from time to time.

[rht]

This is what Agents.jl does:
https://github.com/JuliaDynamics/InteractiveDynamics.jl/blob/15c271d7de77717864548fc6b999d1c11701d0e1/src/agents/interaction.jl#L47-L52. It looks like in Agents.jl, the step button steps the simulation for all situation. But I'm not sure. cc @Datseris (sorry to include you in this thread, but I really want to know how it is done in Agents.jl)

[Datseris]

Hi,
happy to help, but what is the exact question I should be answering?

Agents.jl considers it a feature to have a boolean model state to tell whether a model has terminated or not.

There is no such thing in Agents.jl. There is no model property such as model.running or anything like that (unless a user manually makes this a model level propery, although this doesn't make much sense). The stepping is function-based, not "class-based". A user provides a function that takes a model and returns a bool. In this case iteration continues until the function returns true.

if I may ask, what is the reason that you have this model termination feature in Agents.jl? I may be missing something about its benefit

Because for some models it is more intuitive, scientifically, to terminate evolution when a condition is met rather than after a pre-defined and arbitrary amount of steps. E.g., in Schelling, terminante when all agents are happy.