Individual MOVES runs can be executed through the model's graphical use interface (GUI), and multiple runs can be submitted in series through the use of batch files. The execution of MOVES runs can be accomplished using a single computer, or if a user so desires, multiple machines working in tandem. The outputs from such model runs can be analyzed via the GUI, or via external MySQL tools included with the installation of the model. The follow section discusses model execution and output processing in additional detail.
After selections have been made for model options in MOVES, and a county input database has been created (through either the County Data Manager or the external XML importer script process described above), MOVES can be executed for a county scale analysis. For an individual run, this is done simply by clicking on the Execute command under the Action dropdown menu in the main MOVES interface.
In this case, ERG had 32 different runs to execute. We found that using the Multiple Runspec Creator, available under the Tools dropdown menu and pictured in Figure 3-1, was very helpful in generating batch files to allow for execution of multiple model runs, in sequence, outside of the MOVES interface.
Figure 3-1. Multiple RunSpec Creator
ERG edited the batch file produced by the tool to include all of the different runspecs already prepared, following the guidance presented in section 2.3.6.1 of the MOVES User's Guide. We found it necessary to specify a memory heap size in the batch for execution of the model; without it, MOVES ran out of memory during execution. This may or may not be necessary, depending on the configuration of the computer on which MOVES is executed. A sample batch file used for executing our TDM-based MOVES, which includes the specific memory heap syntax execution used for our runs, is shown in Figure 3-2.
Figure 3-2. Sample Batch File for Execution of Multiple MOVES Runs
We found that modeling each individual county took about 30-35 minutes to execute on our servers, using a single MOVES worker setup. Of course, modeling times will vary based on available computing resources, whether multiple MOVES workers were used (see below), the number and type of pollutants and emissions processes modeled, and other factors. In particular, we have found in other MOVES studies that modeling of evaporative hydrocarbon emissions (as opposed to modeling only exhaust emissions) can increase model execution times by an order of magnitude or more. Model setup time was initially on the order of several hours for many of the County Data Manager inputs described in the previous section, although with repeated model iterations the preparation time for the inputs was significantly decreased.
One way to improve model execution times is to take advantage of MOVES master/worker functionality, which allows users to execute their MOVES runs across multiple computers. When used in this way, the Master computer running MOVES creates calculation "bundles" for other computers to process in a shared network directory. The Worker computers use their local MOVES installation to process the bundle. Multiple Worker computers can process MOVES bundles in parallel, thus reducing the time required for model calculations. Users wishing to enable this functionality must have multiple machines available with MOVES installed, be willing to make some changes to the Windows operating system on machines running MOVES, and make appropriate edits to some MOVES configuration files. Model execution times can be greatly decreased by implementing a master/worker MOVES run setup, but the users should be aware of both the benefits and drawbacks when using MOVES in this way.
To execute MOVES across multiple computers, it is first necessary to enable File and Printer Sharing For Microsoft Networks within the operating system of the computer to be used. When this feature is enabled, users can then select a directory located on the machine of the Master computer, and enable file sharing for that directory with read/write access. This will allow other Worker computers to see and process the calculation bundles prepared by the Master. Next, configuration files should be edited on both the Master computer (MOVESconfiguration.txt), as well as any Worker computers (Workerconfiguration.txt), to reflect the location of the Shared Work Folder. In both files, the sharedDistributedFolderPath should be set appropriately. For the Master, this will refer to a local folder, while for the Worker, it will refer to a network shared folder (\\MOVESMASTER in the example below). An example of the MOVESconfiguration.txt and Workerconfiguration.txt files, with the sharedDistributedFolderPath highlighted, is presented in Figure 3-3. Having configured MOVES in this way, a model run on the Master computer can either be executed from either the GUI or the command line. Once the Master has been executed, the Worker program can be executed on other machines, which will begin processing "bundles" automatically as they become available.
Figure 3-3. Sample MOVES Configuration Files
Master Configuration
Worker Configuration
Users should be aware that while a master/worker MOVES setup can be very beneficial in terms of model run time, the system does have some limitations. First of all, only one Worker program can be executed on a single computer at any one time. Per the MOVES User's Guide, "It would be detrimental to performance to operate more than one copy of the MOVES Worker program on a single computer." Secondly, the system does not seems to be fault tolerant - that is, if one of the workers involved in a run fails to process a bundle for some reason (which can occur under a number of conditions: for example, system runs out of disk space, power failure, network disruption) the MOVES run will not complete. In this case, the run will need to be executed again. So long as model runs are closely monitored during execution, however, this drawback can be managed. On the whole, we believe that given appropriate computing resources, most users will benefit from executing MOVES runs across multiple computers using the configuration described here.
In reviewing outputs from MOVES, our interest was in comparing modeled CO, NOx, and VOC emissions to those developed by TTI using MOBILE6 in their inventory 22, as well as comparing emissions produced using the default MOVES drive cycles to the cycles developed using the Kansas City data described in Section 4. To produce outputs from the model, the user can either generate summary reports using the MOVES GUI, or evaluate model outputs directly using MySQL. Both approaches are discussed in additional detail below.
As mentioned, users can select the Produce Summary Report option, available under the Post Processing menu in the main MOVES interface, to generate emissions summaries for each county of interest. Using this option, users can also select output by total MOVES emissions, or by individual emissions process (for example, crankcase running exhaust, evaporative fuel leaks, refueling spillage loss, etc.) as shown in Figure 3-4.
Figure 3-4. MOVES Output Emission Process Selection
Beyond the modeled emissions processes, the Summary Report input dialog, pictured in Figure 3-5, allows the user to summarize model output with a number of parameters. Of particular interest is the selection of Distance as an output, which serves as an effective check to ensure that VMT input by the users passes through the model appropriately; incorrect pass through of VMT, usually due to setting up model options incorrectly, can lead to very different calculated emissions than what the user might expect. An example of the onscreen summary output that be obtained from MOVES is presented in Figure 3-6. Summaries are easily exported for use in Microsoft Excel or other programs using the Produce Tabbed Output option. Additional information on preparation of Summary Reports is available in Section 2.3.5.2 of the MOVES User's Guide.
Figure 3-5. Summary Report Input Dialog Example
Figure 3-6. Summary Report Output Example
Users can also process and analyze output from MOVES outside of the model's interface entirely by using the MySQL Query Browser, which is included with a typical MOVES installation. This requires some familiarity with MySQL query syntax, but has some advantages relative to processing model output via the MOVES GUI.
To create emissions output like the examples below, users can first select the Run MySQL Script on Output Database option (located under the Post Processing menu within the MOVES interface) and choose to execute the DecodeMOVESOutput.sql script 23. This script creates additional decoded MOVES emissions and activity tables in the selected output database. Users can then write custom queries and create detailed summaries of their own using the newly decoded tables in the MySQL Query Browser. We have provided two sample queries in Figures 3-7 and 3-8 that recreate the model outputs presented in Figure 3-6. The first script calculates emissions for Harris County for each source type, while the second returns both VMT and vehicle population used in the model calculations. Users are of course free to aggregrate emissions and activity as they choose by using the GROUP BY function on the wide variety of variables available in the output tables, using MySQL scripts that they create.
Figure 3-7. Sample Query and Output using MySQL Query Browser - Emissions
Figure 3-8. Sample Query and Output using MySQL Query Browser - Activity
Although producing query outputs such as those shown above requires some knowledge of MySQL query syntax, there are several advantages to analyzing the outputs of the MOVES model in this way. First of all, the flexibility inherent in MySQL allows for users to investigate output from the model in a more robust way, when compared to the limited options available in the MOVES GUI Summary Reports. Appendix H of the MOVES User's Guide presents a series of script examples that deal with post processing of MOVES outputs in the MySQL environment. Secondly, analysis of model outputs using the GUI cannot be performed when a MOVES model run is in progress; use of MySQL allows users to examine model outputs while concurrently executing other modeling. Finally, depending on the units selected in the model output options, the Summary Reports available in GUI may not provide enough resolution for proper analysis of data, since these reports present data in whole numbers only. The output available by processing MySQL queries, on the other hand, contains a large number of significant figures.
Figure 3-9 presents a list of things to keep in mind while preparing to execute MOVES runs, and process associated model outputs.
Figure 3-9. MOVES Execution and Output Processing Quick Reference
Model Execution
Model Output Processing
22 We originally limited our analysis to only CO, NOx, and VOC because those were the pollutants modeled in TTI's original MOBILE6 runs.
23 This script can also be executed outside of the MOVES GUI, if desired. In point of fact, running this script is not absolutely necessary at all if a user wishes to perform calculations on the unmodified movesoutput and movesactivityoutput tables
