One issue (and why the tests are failing) is that when using a module-level default_scenario the same scenario instance gets reused across multiple model instantiations, causing failures when creating a second model.

The problem:

# model.py (at module level)
default_scenario = Scenario(...)  # Created once

# Later:
model1 = EpsteinCivilViolence(seed=42)  # scenario.model = model1, model1.running = True
model2 = EpsteinCivilViolence(seed=43)  # Tries to set scenario.model = model2
# ERROR: "Cannot change scenario parameters during model run"
# because scenario.model still points to model1 where running=True

Current workaround: Create a fresh scenario instance inside __init__ if none is provided:

def __init__(self, ..., scenario=None):
    if scenario is None:
        scenario = Scenario(rng=seed, citizen_density=0.7, ...)
    super().__init__(seed=seed, scenario=scenario)

Subclassing might also help with this. Then we could have:

class EpsteinScenario(Scenario):
    citizen_density: float = 0.7
    cop_vision: int = 7
    # ... etc

And then either:

• Users instantiate: EpsteinCivilViolence(scenario=EpsteinScenario(rng=42))
• Or model creates internally: scenario = scenario or EpsteinScenario(rng=seed)

This gives us type hints, default values, and avoids the shared-instance problem.

(but maybe I'm using all this wrong)

One issue (and why the tests are failing) is that when using a module-level default_scenario the same scenario instance gets reused across multiple model instantiations, causing failures when creating a second model.

This is useful for stress-testing the design. In part, this interacts with #3166.

1. The current design is not easy to combine with defaults. The simplest option would be to wrap the defaults in their own dict and then do Scenario(**defaults.copy().update(rng=43)). However, the use of defaults is so common that one might as well just have defined a scenario dataclass instead. Basically, this example is a strong counterargument to my dislike of forcing users to subclass.
2. We might just remove the write protection.
3. We might add a factory method, where you can do something like new.scenario = defaults.from(rng=42) which would return a copy of defaults with the fields that are passed updated.

Thanks. I'm curious what you think about #3168.

I assume this can be updated with #3168 merged.

While thinking about it some more, I am inclined to make scenarios frozen. That is, they simply cannot be changed once created. We can then remove the model attribute and the model.running check. This avoids subtle circular reference bugs.

I have made a bunch of updates. The bigger issue is that the UI side of things is not yet updated to use Scenario.

Ah, I also had some changes ready on my branch (part to develop and test #3168), I will check how they compare.

I stored your work on agent_scenario_property_quaquel and pushed my branch. Do you want to compare them?

No, feel free to continue what you were doing. I was mainly curious to see how much #3168 helped.

In that case I think this PR is ready.

Viz indeed might need to be updated.

One question: I put the rng just in the scenario, do we regard that best practice from now on?

One question: I put the rng just in the scenario, do we regard that best practice from now on?

I don't know yet. It basically means that people are forced to use Scenario. But for Mesa 4, I think it is a good idea to do that anyway.

It might be good to test this against #3178 to see if it works with solara. If I have time today, I'll try that and report back here.

Awesome, thanks!

It might be good to test this against #3178 to see if it works with solara. If I have time today, I'll try that and report back here.

Considering this and the interaction with #3178, what would your preference be that I did with this PR?

I'll try to take a look and see what's going on with #3178 or, otherwise, open a new PR myself to fix it.

I can also confirm that this example now runs locally.