You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
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-twoJAR 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.
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.
The text was updated successfully, but these errors were encountered:
Additional requirements per 8/28 chat with @lmz and @FlaviaTsang:
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 tm2pyController. @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. 🚀 Feature: Add Args to RunController() to Allow Restarting from Iteration X and Component Y #176
All actions taken by the set up method should be recorded in a log file.
The version of tm2py being run should be recorded in the log file.
The model steps should be recorded in the log file.
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?
The input file paths should point separately to network input and land use input. Follow the pattern in the existing setup model batch file.
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.
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 theSetUpModel
batch file need to be replicated viatm2py
methods.Progress:
Priority
Medium
Level of Effort
Low
Resolution Ideas
Three possible ideas:
project_config.toml
, and use it to specify the necessary references needed by the model set up procedure. These could include the relevant versions oftm2py
andtravel-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 existingscenario_config.toml
. We'll therefore have configuration files specific to the model, the scenario, and the project (defined as a collection of scenarios).travel-model-two
JAR
file to the working directory. This option is more attractive if the number of configuration parameters that would be stored inproject_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.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.
The text was updated successfully, but these errors were encountered: