Refactor/#55 add simulation meta object#61
Merged
GUVWAF merged 18 commits intomeshtastic:masterfrom Apr 6, 2026
Merged
Conversation
Member
|
Thanks again for the huge effort. I like the idea. |
Contributor
Author
|
Thanks for all the effort reviewing code! I expected I'd need to rebase this work and upcoming work once some PRs were merged, it's no problem. I'll go take a look now. I'd have to double-check what I have planned, but I think I'm getting close to all the parts I was planning on reworking & adding to, and this/upcoming work getting merged would be really helpful. Though, I'm not in a rush. |
…n running Minimally functional. This will let us keep all discrete event sim configuration and state in one place, while hiding irrelevant complexity for the user. This also makes testing changes that could impact the simulation easier, because rather than having to match changes in loraMesh.py and the full discrete sim test, we can just make changes within the sim meta-object and run the test. This commit is still a bit WIP with some unused code, but further planned changes will fix this and clean things up.
Previously the user created their own simpy environment but never used it besides passing it to this constructor. Just have the DiscreteEventSim constructor make its own environment. Also make sure our broadcast pipe and run_graph_updates process is using our internal environment.
This again simplifies where sim management logic happens, and is a step toward using batchSim.py as an example of using DiscreteEventSim for running multiple simulations and comparing results.
This gathers all sim state that is global to the sim, and mutates throughout the simulation, into one place. This does not include "initial condition" state like the Config or node configs, which can be considered constant for the simulation. This also does not include the nodes, which are more like the simulation's actors and have their own internal state. This will make it easier to work on global sim state later (such as adding a connectivity matrix or other precomputed data), and refactor other parts of the sim.
…es in one place This holds all write-only data structures used to monitor a simulation for later reporting. This collects data about the sim, but does not alter simulation state or have any impact on simulation progress. This should make it easier to pass around a single bundle of data tracking structures and operate on them, or add more as necessary.
…oraMesh.py and batchSim.py This more fully uses the SimulationResults class. It holds all first-order simulation results, like message counter and list of generated messages. It also is a natural place to calculate second-order sim data like various averages and rates. This lets us avoid manually re-calculating things in different areas, and instead lets us get all our metrics automatically when the simulation finishes. If there's something new we want to measure, we can just add whatever monitoring data structures are necessary, and add any extra calculations to the `finalize` method of SimulationResults. This also updates loraMesh.py and batchSim.py to directly use the results rather than do their own calculations. The test is updated as well. Rates are inconsistently labelled. Within SimulationResults we keep all rates as the raw ratio, and if the user wants a percentage we expect them to scale and round the ratio as desired. We'll want to update some variable names to be clearer about this, which I'll save for another commit. The SimulationResults class needs many of its own tests, which I'm also leaving for another commit.
This calculated value is a rate, so put that in the name for clarity.
zandi
force-pushed
the
refactor/#55-add-simulation-meta-object
branch
from
6d27578 to
a3a73e7
Compare
Contributor
Author
|
force-pushed to rebase onto master. I want to do a few more improvements before having another go at merging. |
…up from DiscreteEventSim DiscreteEventSim now must be explicitly given a list of node configs to use, it does not come up with them. The user can define node configs however they wish based on the simulation they want to run, but we preserve default behavior in default_generate_node_list. We make a temporary 'find_random_position_nodeconf' function so we can randomly place nodes using just configs, not full instantiated nodes. Remove this once we refactor all uses of 'find_random_position' to deal only in configs, not full node objects. We also clean up parse_params in loraMesh.py so we always return a set of node configs, rather than maybe returning a list of None for other code to handle.
find_random_position works just fine when given a list of NodeConfig objects, or node objects. Clarify that expectation with a docstring and variable renames. Would be nice to refactor it further but other parts like lib/interactive.py use it and I want to focus refactoring work other places and leave interactive sim relatively untouched.
…eed to be provided as parameters the list of nodes and packets are already provided as first-order results, so we don't need to also provide them as parameters. Just pull from the existing results dictionary.
GUVWAF
approved these changes
Apr 6, 2026
Member
GUVWAF
left a comment
GUVWAF
left a comment
There was a problem hiding this comment.
Tested again after the latest changes, and looks good to merge to me. Thanks again!
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
2 participants
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.
Big changes. There's more things I'd like to do (smaller refactors, more tests for SimulationResults class) but this felt like a big enough change to submit on its own.
The simulation meta-object lets us keep more of the setup, running, and data collecting part of the sim in one place. The user just has to give it the overall config and a set of node configs and it can handle everything else, including collecting sim results and calculating things from them like various rates. loraMesh.py and batchSim.py are updated to use it, and the previous "full sim" unit test has basically been moved into a test of the DiscreteEventSim class.
This should make it much easier to do things like run multiple simulations at once, or run identical simulations with only a single variable changed to precisely compare potential changes or misc. setup differences.