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: Replicate Capabilities of TM1's SetUpModel.bat #150

Open
2 of 7 tasks
DavidOry opened this issue Jun 17, 2024 · 3 comments
Open
2 of 7 tasks

🚀 Feature: Replicate Capabilities of TM1's SetUpModel.bat #150

DavidOry opened this issue Jun 17, 2024 · 3 comments
Assignees

Comments

@DavidOry
Copy link
Collaborator

DavidOry commented Jun 17, 2024

User Story

As a member of the MTC modeling team, I would like to document the configuration of the modeling system, key inputs, parameters, and other important information when beginning a planning study. MTC currently accomplishes this work with a MS-DOS batch file. See this example used for Plan Bay Area 2050. With the shift to tm2py, the capabilities of the SetUpModel batch file need to be replicated via tm2py methods.

Progress:

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

Priority

Medium

Level of Effort

Low

Resolution Ideas

Three possible ideas:

  1. Create a third configuration file, say project_config.toml, and use it to specify the necessary references needed by the model set up procedure. These could include the relevant versions of tm2py and travel-model-two, the location of the relevant project cards and perhaps tags to grab them, any computer-specific settings to configure the resident passenger Java code, etc. In parameter specific to a scenario can be added to the existing scenario_config.toml. We'll therefore have configuration files specific to the model, the scenario, and the project (defined as a collection of scenarios).
  2. Create a series of Python methods that can be called via a notebook prior to running the model. Each of these methods can accomplish a discrete task, such as copying over the travel-model-two JAR file to the working directory. This option is more attractive if the number of configuration parameters that would be stored in project_config.toml is relatively small. This strategy may also allow MTC to scale the scope of the file as needed when project demands become bespoke.
  3. Modify the existing SetUpModel.bat file to accommodate TM2. While unattractive in that it relies on MS-DOS batch files rather than Python, it is the lowest cost and simplest solution, in that the relevant features of the existing workflow can be brought over to the new workflow.

Project

WSP Task Order Five.

Who should be involved?

Users:
Reviewers:

Risk

The risk here is low as this procedures will not impact any other parts of tm2py. They are only intended to create a logged environment for the model to run on MTC's computers.

Tests

The relevant tests are to launch a series of model runs on MTC's hardware using the procedures to ensure the configuration is working as expected and the logging captures the relevant information.

@DavidOry
Copy link
Collaborator Author

@lmz, @gregerhardt, @FlaviaTsang, @e-lo
Thoughts on the three possible solution pathways?

@DavidOry
Copy link
Collaborator Author

@AshishKuls

Additional requirements per 8/28 chat with @lmz and @FlaviaTsang:

  1. Operate from a command prompt and a configuration file. Desired user experience is as follows: (i) user creates a model directory, (ii) user copies in and edits a set up model configuration file, (iii) users opens up a command prompt with the EMME Python environment, (iv) user calls a setup_model method that lives in tm2py, (v) user creates and runs the tm2py Controller. @i-am-sijia: once created, please link the issue you create here re: allowing the controller to take model steps as an argument to address the restart use case.
  2. All actions taken by the set up method should be recorded in a log file.
  3. The version of tm2py being run should be recorded in the log file.
  4. The model steps should be recorded in the log file.
  5. The set up model configuration file should ask the user for the model year, model major version, project label, scenario number, and scenario version. @lmz: do we then use these to check that the model folder name is consistent?
  6. The input file paths should point separately to network input and land use input. Follow the pattern in the existing setup model batch file.
  7. Failures in the setup should be fatal.

Note: in the existing set up model batch files, the M_DIR contains the persistent, files of records. The modeling machines are transitory and are intended to be erased.

Please edit/clarify as needed. CC @gregerhardt

@AshishKuls AshishKuls mentioned this issue Sep 24, 2024
1 task
@DavidOry
Copy link
Collaborator Author

@AshishKuls: will your procedures solve #79?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

2 participants