-
Notifications
You must be signed in to change notification settings - Fork 5
Guidelines for Developing Variants of the MTC Travel Models
Lisa Zorn edited this page Aug 20, 2022
·
4 revisions
Home > TravelModel > Guidelines-for-Developing-Variants-of-the-MTC-Travel-Models
To promote model transparency and to help with future debugging of modeling results, we recommend making the following requirements part of consultant contracts which develop custom (e.g. agency) variants of an MTC model (including custom calibrations, version with alternate input datasets or components, etc.):
- When model development begins, a fork of the MTC model should be made for the development effort; this makes it clear which model version is the basis of the development. Ideally, this fork would be in the agency GitHub organization, but a personal or consultant GitHub organization can be used instead, as long as the repository is public.
- All model code, script, UEC changes or config should be committed to that GitHub fork as work progresses. Do not commit a single giant commit of all changes to files at the end, since this makes it hard to understand how the changes evolved.
- Commits should include useful commit messages (e.g. say what the commit does. For example, "fix bug where X was happening", rather than "update file X"
- At the completion of the work, a pull request should be issued to the MTC repository, to create a new branch for the agency version of the code. The pull request should include a summary of the changes made to the agency variant of the code.
Previously the MTC/ABAG Analytical Modeling Wiki (http://analytics.mtc.ca.gov/foswiki/Main/WebHome)
Please email [email protected] if you find anything missing here.