Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1511 +/- ##
==========================================
- Coverage 97.38% 97.29% -0.09%
==========================================
Files 188 190 +2
Lines 16536 16846 +310
==========================================
+ Hits 16103 16390 +287
- Misses 433 456 +23 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
reneSchm
left a comment
There was a problem hiding this comment.
Thank you for this addition!
This is not yet a full review, as I have not checked most of the algorithms, but I do have a couple of (high-level?) comments.
| * - `local_breakpoints[node]`: steps at which local_sim must be synchronized. | ||
| * - `mobility_breakpoints[node]`: steps at which mobility_sim must be synchronized. | ||
| */ | ||
| struct TravelTimeSchedule { |
There was a problem hiding this comment.
I have a couple of thoughts on this:
- While using "day" as a unit is not bad, I would prefer being more generic, e.g. use "time period mapped to [0, 1)", as there technically is nothing day-specific here.
- I think this can be a class in its own file. Between the struct and compute_traveltime_schedule there already are 150 lines used for this.
- Using a class, you can make the members private, and use functions for read-only access. You can also move the explanation of what the vectors do there, and the functions would help showing how the vectors should be used.
- Also allows adding size asserts etc.
- compute_traveltime_schedule can be used as or by a constructor.
- Two performance considerations: Would it make sense to some vectors 1-dimensional, for better locality? Do you need the step index, or can you store the step value (i.e. 1/index) to avoid division?
There was a problem hiding this comment.
- Day -> normalized time period
- Scheduler is now a class in an own file (using your ideas incl. asserts etc.)
- Tried to use 1d vectors
- PRecompute the first_depature time instead of the step, so one division less per edge
| const auto grp = static_cast<size_t>(min_idx) / n_comparts; | ||
| const auto beg = static_cast<Eigen::Index>(grp * n_comparts); | ||
| const auto end = beg + static_cast<Eigen::Index>(n_comparts); | ||
| Eigen::Index max_idx; |
There was a problem hiding this comment.
This looks very model specific. It would break from switching the order of age group and compartment. You could perhaps use the Population (or just CustomIndexArray) for taking the correct slice of the population and "correct" these?
It also does not seem like a safe or fast algorithm. What if more than max_iter negative entries exist? Why do up to max_iter searches for max/minCeoff? Consider using map_to_nonnegative on the population slices*.
*We may want to refactor Slices to use Eigen::seq for this.
There was a problem hiding this comment.
yes, thats true. Reimplemented it with the slice and then use map_to_nonnegative.
however, this would still fail if we decide to switch the order of age groups and compartments.
| print_row("C", sim.get_graph().nodes()[2].property); | ||
| std::cout << std::string(62, '-') << "\n"; | ||
|
|
||
| std::cout << "\nSchedule overlap (n_steps=100, sub-step = 0.01 day):\n" |
There was a problem hiding this comment.
This output contains a lot of hard-coded numbers, I think these should either be configurable, or used as explanations for the setup above instead of being printed.
There was a problem hiding this comment.
Removed the hardcoded sub-step numbers (n_steps=100, sub-steps 51-53, ...) from the output
Co-authored-by: reneSchm <49305466+reneSchm@users.noreply.github.com>
…stribution approach
Changes and Information
Please briefly list the changes (main added features, changed items, or corrected bugs) made:
GraphSimulationTravelTimewith explicit transit of travelersIf need be, add additional information and what the reviewer should look out for in particular:
Merge Request - Guideline Checklist
Please check our git workflow. Use the draft feature if the Pull Request is not yet ready to review.
Checks by code author
Checks by code reviewer(s)