I really really like the idea of this. Kind of obvious, weird we didn't think of it earlier.

I personally tend to complement this with class-level attributes that I can easily change (e.g., MyAgent.rationality = "expected_utility"). As a side effect of all this is that if you want to experiment with specific parameters deep down in your agents, you have to pass them first to Model.__init__ and then to the __init__ of your custom agent.

Oh yes this is always a chore.

I would change one thing:

    self.density = self.scenario["density"]
    self.minority_pc = self.scenario["minority_pc"]

What if we can stop doing this? Instead, why not just access scenario parameters directly?

    # Access scenario parameters directly
    self.grid = MultiGrid(width, height, torus=True, rng=self.scenario.rng)
    
    # Create agents based on scenario parameters
    num_agents = int(width * height * self.scenario.density)
    num_minority = int(num_agents * self.scenario.minority_pc)

In this design, it's always explicit what's scenario-based, and what's just a static model variable. You also prevent making errors in the Model init.

Implementation wise, I think you can use a (frozen) dataclass for this.

We could even allow passing an equivalent policy object, that works exactly the same, but now you can semantically separate them.

Anyway, thanks for initiating this, really interesting direction!

What if we can stop doing this? Instead, why not just access scenario parameters directly?
You also prevent making errors in the Model init.

See my point 3. Basically, I am using a dict internally. I realize now that I can make attribute access work via __getattr__ or some related magic. I doubt however that this will prevent typos and stuff like that because of all this works via the dynamic nature of python and thus won't be available to static language analysis tools (like type checking, autocomplete).

Implementation-wise, I think you can use a (frozen) dataclass for this.

That was also on my list of things to check, but again, I am not sure due to its dynamic nature. I don't want to force users to subclass Scenario to make any of this work.

update:

1. attribute style, or dot style access works (and did work for the original commit). Because the keyword arguments are stored in the internal __dict__, they will be found automatically if you use attribute-style access. I enhanced this a bit, so deleting and setting can also use attribute access.
2. Had a quick look at dataclasses. It can be done via make_dataclass, but that still requires the user to do something like

Scenario = make_dataclass(Scenario, [("a", int), ("b", float)])

So rather cumbersome for no apparent benefit that I can see.

We could even allow passing an equivalent Policy object, that works exactly the same, but now you can semantically separate them.

From a policy analysis point of view, I agree. It makes good sense to separate policies and scenarios. However, this is a very specific vocabulary. Scenario is more common and often used as a catch-all for model input. The other option that I am considering is to just call it Experiment.

I think we should explicitly state in the documentation that users must perform any validation or logic on the Scenario before calling super().__init__() in their custom models because doing it afterwards will raise ValueError

I think we should explicitly state in the documentation that users must perform any validation or logic on the Scenario before calling super().init() in their custom models because doing it afterwards will raise ValueError

I am not sure what you mean. Could you elaborate?

I mean doing this straight away will result in ValueError because self.model.running = True

class MyModel(Model):
    def __init__(self, scenario):
        super().__init__(scenario=scenario)
        if self.scenario.density < 0:
            self.scenario.density = 0

Either

1. we can set self.running = False then apply logic or validate scenario OR
2. we can call super().__init__() afterwards

I think either way, we should explicitly mention it in documentation

Could we use the new Model.time variable, to check Model.time > 0 instead of running?

Maybe don't enforce it now, but first think about time progression and run control.

For me, this is a stepping stone to making batch run obsolete. In this, scenarios are expected to be simple data containers that only hang around shortly and so the circular reference should not really be an issue.

Out of curiosity, as I try to understand the direction Mesa is currently going: how could scenarios replace batch_run? Where would the variation of parameter values happen?

Out of curiosity, as I try to understand the direction Mesa is currently going: how could scenarios replace batch_run? Where would the variation of parameter values happen?

See my answer on the mesa 4 discussion. In short, Scenario just encapsulates a single experiment.

A next step is to have some helper functions to create a collection of scenarios. Since there are ample libraries out that for creating experimental designs (e.g., salib, numpy.stats.qmc, ema_workbench), I am inclined to start with a helper function that takes a dataframe or numpy array with a list of columns, which returns an iterable of experiments. I have to think a bit about how to splice in seeds in this, but that is a minor detail.

@mariuzka, I just added two helper functions to scenario.py that might help clarify my intended direction: scenarios_from_dataframe and scenarios_from_numpy.

While adding these two helper functions, I realized that, from a computational experimentation perspective, there is an important difference between an experiment and any specific stochastic realization of the experiment (i.e., an experiment and a specific seed value). Ideally, there is a way of identifying both easily in post-processing. For example, you might want to group by experiment identifier before taking statistics over the stochastic realizations (i.e., replications using different seeds).

Conceptually, a model need not be aware of either the scenario identifier or the experiment identifier. But when running experiments using, e.g., a ProcessPoolExecutor, it's rather useful if this information is encapsulated in the scenario object. For now, I have solved this by simply adding a keyword argument called _experiment_id; however, I am inclined to incorporate this into the Scenario class itself and handle it in a similar manner to _scenario_id. So, if it is passed in the init, we use that; otherwise, we use an internal counter to generate it. Thoughts are welcome.

I just added two helper functions to scenario.py that might help clarify my intended direction: scenarios_from_dataframe and scenarios_from_numpy.

While potentially the way to go, I think it's good to have a broader discussion about A) scenario generation and B) scenario object storage. Can we keep the helper function outside this PR, and discuss them for follow-up work in a separate thread?

Maybe open a new discussion in which we can discuss scenarios and experimentation on a higher level.

Let's just get this merged. I removed the two functions for now.