Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🚀 Feature (Chorish): Improve Model Runtime with Hardware and Configuration Suggestions #179

Open
7 tasks
DavidOry opened this issue Jan 30, 2025 · 0 comments
Labels
chore overhead: doesn't add additional functionality, change performance, or refactor code performance improving runtimes or other resource usage

Comments

@DavidOry
Copy link
Collaborator

DavidOry commented Jan 30, 2025

User Story

As a model user, I would like a full model run to be complete within 16 hours. This is the standard set forth in the Acceptance Criteria, number 30. I would also like the option of knowing what the trade-offs are for strategies that increase or decrease runtime.

Progress:

  • Sufficiently defined
  • Approach determined
  • Tests developed
  • User story satisfied
  • Doc strings
  • General documentation
  • Passing tests

Priority

Medium

Level of Effort

Defined in Task Order 6

Resolution Ideas

At the end of development Sprint 3, the model runtime was about 70 hours (details here), with nearly all the time devoted to three activities: the resident passenger demand component, roadway assignment, and transit assignment. Each of these tasks scales nicely with additional compute resources. The current work to all parallel assignments (#175) also allows additional compute to be expended. It is therefore useful to understand what the runtime of the current system would be on different hardware configurations.

To inform decisions about precision and/or policy sensitivity, a markdown document will be created to include in the on-line documentation that provides information about configuration changes that can improve runtime. For example, the highway assignment convergence criteria can be relaxed, but doing so reduces the precision of the roadway volumes and assignment. Per @lmz, the documentation should be accessible via the tm2py repository (related: #148). Per @gregerhardt, it would be useful to have some test runs with different configurations on a relatively small project, to understand the impact empirically of relaxing precision.

Project

MTC, Task Order 6

Who should be involved?

Users: @FlaviaTsang, @Ennazus (once on-board)
Reviewers: @lmz, @gregerhardt, @DavidOry

Risk

Low. Some manual configuration will be needed until #178 is complete and testing for #175 is needed. But simple configuration changes should allow for larger runtimes.

Tests

We need to document the runtime on each machine configuration.
We need to document the performance of the test runs that inform the configuration recommendation documentation.

@DavidOry DavidOry added chore overhead: doesn't add additional functionality, change performance, or refactor code performance improving runtimes or other resource usage labels Jan 30, 2025
@DavidOry DavidOry moved this from Backlog to In progress in EMME/ActivitySim Conversion Task Order #6 Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore overhead: doesn't add additional functionality, change performance, or refactor code performance improving runtimes or other resource usage
Projects
Development

No branches or pull requests

1 participant