Ability to control the allowed state transitions during a simulation#284
Open
Ability to control the allowed state transitions during a simulation#284
Conversation
…between two iterations
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #284 +/- ##
==========================================
+ Coverage 59.06% 59.54% +0.47%
==========================================
Files 129 130 +1
Lines 6738 6845 +107
==========================================
+ Hits 3980 4076 +96
- Misses 2758 2769 +11 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
See : #283
PopulationTripspreviously allowed all state transitions at every simulation step, with transitions driven only by utility differences. This makes all forms of behavioral adjustment happen on the same timescale, even though some changes are much easier than others in reality.This PR adds an explicit way to stage behavioral adaptation over iterations. It allows us to reproduce simplified adjustment dynamics, for example by allowing mode changes first, then destination changes, then full daily programme changes, while we work toward a more complete transition-cost model (see #196).
Changes
Added a new staged behavior-change API to
PopulationTripsParameters:BehaviorChangeScopeFULL_REPLANNINGDESTINATION_REPLANNINGMODE_REPLANNINGBehaviorChangePhase(start_iteration, scope)behavior_change_phasesget_behavior_change_scope(iteration)Implemented scope-aware behavior in
PopulationTripsandStateUpdater:FULL_REPLANNINGDESTINATION_REPLANNINGMODE_REPLANNINGThe restriction now applies both:
from -> totransitionsThis means restricted phases do not just limit newly generated states; they also enforce that only allowed transitions are actually reachable.
Stay-home behavior is also defined explicitly:
FULL_REPLANNINGMODE_REPLANNINGandDESTINATION_REPLANNINGRefactored candidate-generation logic out of
PopulationTrips.run_model()into a dedicated helper module:population_trips_candidates.pyAdded tests for:
PopulationTripsrunExample
This means:
1-4: full replanning5-7: mode replanning only, from the active states at iteration 4 (no destination changes, no motive sequence changes).8-10: destination + mode replanning, from the active states at iteration 7 (no motive sequence changes).11-12: full replanning againIf
behavior_change_phasesis omitted, all iterations use by defaultBehaviorChangeScope.FULL_REPLANNING.