Updating Scenario in preparation for replacing batch runner#3493
Updating Scenario in preparation for replacing batch runner#3493
Conversation
Make Scenario the single source of truth for RNG state Scenario now owns the canonical RNG state. Model derives self.rng and self.random from the scenario rather than maintaining parallel `_seed`/`_rng` state, eliminating the broken scenario._seed reference in `Model.__init__`. Key changes: - `Scenario._stdlib_seed` property derives a reproducible integer seed for random.Random from initial_rng_state without advancing the generator - `Model.__init__` always creates a Scenario first (rng= is a convenience shorthand), raises ValueError if both rng and scenario are passed - Removed `Model.reset_rng()`` and the now-dead `_seed`/`_rng` instance vars from Model - replication_id defaults to None to distinguish base scenarios from replication 0; scenario_id uses None as sentinel so id=0 is preserved - Fixed docstring references to removed `_seed` attribute - Updated tests to use `scenario.initial_rng_state` instead of `model._rng`
remove none as an option because now covered by the class
|
Performance benchmarks:
|
EwoutH
left a comment
There was a problem hiding this comment.
Thanks for working on this. I think you’re looking in the right direction.
| scenario_id: A unique identifier for this scenario, auto-generated starting from 0 | ||
| rng: Random number generator or seed value | ||
| experiment_id: Identifies the design point (e.g., row in a QMC sample matrix) | ||
| replication_id: Identifies the stochastic replication within a design point |
There was a problem hiding this comment.
Could you elaborate on why we now need 3 different id variables? Are there other options?
There was a problem hiding this comment.
Based on my experience with the workbench, there are no clean other options.
- We need scenario_id as a link to the original experiment matrix (e.g., from numpy.qmc, or salib)
- We need a replication_id for reproduction. Only by knowing this can you reproduce the exact results for a given experiment.
- We need a high entropy starting RNG value for high quality random number generation (and no 42 is not a high entropy starting value because this has 30
0in front of it.
I also fail to see what the problem is. Scenario_id and replication_id are in principle generated by Mesa itself so the user need not worry about them at all.
| "initial_rng_state": self.initial_rng_state, | ||
| } | ||
|
|
||
| def spawn_replications(self, n: int) -> list["Scenario"]: |
There was a problem hiding this comment.
Would this make sense as a Class method? Like we do with Agent.create_agents() I believe?
There was a problem hiding this comment.
No it cannot be a class method. spawn_replication takes a base scenario instance with the scenario-specific user-provided arguments and creates n versions of it, each with a unique, independent, seeded numpy generator.
|
Performance benchmarks:
|
EwoutH
left a comment
There was a problem hiding this comment.
Cleans up the model nicely. Thanks.
This PR updates the
Scenarioclass and how it is used insideModel. It is inspired by ideas in #3483.Modeljust uses these.Model.__init__is updated to take either a Scenario subclass or instance. (supersedes ENH: Accept Scenario as class or instance in Model init #3450)model.So what are the API implications from this?