Motor Vehicle Emission Simulator 

Highway Vehicle Implementation 

(MOVES-HVI) Demonstration Version 

Software Design and Reference Manual


Draft 
Motor Vehicle Emission Simulator


Highway Vehicle Implementation 


(MOVES-HVI) Demonstration Version


Software Design and Reference Manual


Draft 


Assessment and Standards Division 

Office of Transportation and Air Quality 

U.S. Environmental Protection Agency 

EPA420-P-07-001 

February 2007 
A Note about the Capitalization and Naming 

Conventions Used in this Document 

Because object orientation is central to the design of the MOVES software, this 

document often refers to classes and objects. The class names used in MOVES are often 

formed from several English words which are run together without spaces, e.g. 

“EmissionCalculator”, “RunSpecEditor”, etc. MOVES follows the widely-used Java 

naming convention of capitalizing each word in these run-together names, and this 

convention is also used in this document. 

Because databases are also central to MOVES, this document includes many 

references to databases, tables, and fields. It is our intention that database and table 

names follow the same naming convention as classes in MOVES. The names of fields 

within these tables also use this scheme, except that they begin with a lower case letter 

(unless they begin with an acronym). E.g. there is a “MOVESDefault” database which 

contains an “EmissionRate” table and this table contains a field named “meanBaseRate”. 

We’ve applied the same naming convention to file and directory names as well because 

they are somewhat analogous to tables and databases. 

Acronyms, such as “VMT” (from “vehicle miles traveled”) or “AC” (from “air 

conditioning”) are capitalized in all contexts, even when they begin a field name, even 

though this is not standard programming practice. Thus there is a field named 

“ACPenetrationFraction”. A table of acronyms used in this document is contained in 

Appendix A. 

There are undoubtedly instances where this document fails to fully comply with 

these conventions. In some contexts it seems natural to use ordinary English, e.g. 

“emission rate”, interchangeably with a class name, e.g. “EmissionRate”, and we have 

not attempted to be highly rigorous in this regard. The Windows operating system is not 

case sensitive and MySQL is also rather forgiving in this respect. We hope our readers 

will be as well. 

2
Table of Contents 

A Note about the Capitalization and Naming Conventions Used in this Document.......... 2 

1. Introduction..................................................................................................................... 6 

2. MOVES Software Components...................................................................................... 9 

3. Computer Hardware and System Software Requirements............................................ 11 

3.1. Details on JAVA Platform Requirements.............................................................. 11 

3.2. Details on MySQL Platform Requirements........................................................... 12 

3.3. Details on Shared File Directory Platform Requirements ..................................... 13 

4. MOVES Computer Platform Configuration ................................................................. 14 

5. MOVES Software Licensing ........................................................................................ 17 

6. Installation Overview.................................................................................................... 18 

7. Processing Overview .................................................................................................... 20 

8. Data and Control Flow.................................................................................................. 21 

9. Functional Design Concepts ........................................................................................ 26 

9.1. Geographic Locations............................................................................................ 26 

9.2. Time Periods.......................................................................................................... 28 

9.3. Characterizing Emission Sources (Vehicle Classification) ................................... 29 

9.4. Emission Pollutants................................................................................................ 33 

9.5. Emission Processes................................................................................................ 33 

9.6. Vehicle Fuel Classifications .................................................................................. 34 

9.7. Emission Source Activity ...................................................................................... 35 

9.8. Modeling Vehicle Inspection/Maintenance Programs........................................... 40 

10. MOVES Functional Specifications............................................................................. 42 

10.1. Graphical User Interface (GUI) / Run Specification Editor ................................ 42 

10.2. Application Program Interface and Master Looping Mechanism ....................... 42 

10.3. Input Data Manager ............................................................................................. 43 

10.4. Database Pre-Aggregation ................................................................................... 44 

10.5. Mesoscale Lookup Table Link Producer (LTLP)................................................ 56 

10.6. Total Activity Generator (TAG) for Macroscale................................................. 57 

10.7. Total Activity Generator (TAG) for Mesoscale Lookup..................................... 68 

3
10.8. Running OperatingModeDistributionGenerator (OMDG) for Macroscale......... 76 

10.9. Running OperatingModeDistributionGenerator (OMDG) for Mesoscale Lookup

...................................................................................................................................... 83 

10.10. Source Bin Distribution Generator (SBDG)...................................................... 90 

10.11. Meteorology Generator...................................................................................... 95 

10.12. Start OperatingModeDistributionGenerator (StartOMDG)............................... 97 

10.13. Tank Temperature Generator (TTG) ................................................................. 99 

10.14. Tank Fuel Generator (TFG)............................................................................. 108 

10.15. Evaporative OperatingModeDistributionGenerator (EvapOMDG) ................ 113 

10.16. Alternative Vehicle Fuels and Technologies (AVFT) Strategy....................... 115 

10.17. Energy Consumption Calculator (ECC) .......................................................... 120 

10.18. Distance Calculator.......................................................................................... 127 

10.19. Methane (CH4) and Nitrous Oxide (N2O) Calculator..................................... 130 

10.20. Atmospheric CO2 and CO2-Equivalent Calculator......................................... 132 

10.21. Criteria Pollutant Running EmissionCalculator (CREC) ................................ 134 

10.22. Criteria Pollutant Start EmissionCalculator (CSEC)....................................... 146 

10.23. Basic Running PM EmissionCalculator .......................................................... 154 

10.24. Sulfate PM EmissionCalculator (SEC)............................................................ 159 

10.25. Basic Start PM EmissionCalculator................................................................. 161 

10.26. Basic Brake and Tire Wear Emission Calculators........................................... 162 

10.27. CriteriaAndPMExtendedIdleEmissionCalculator............................................ 163 

10.28. Permeation Calculator...................................................................................... 170 

10.29. Liquid Leaking (LL) Calculator ...................................................................... 174 

10.30. Tank Vapor Venting (TVV) Calculator........................................................... 177 

10.31. Result Data Aggregation and Engineering Units Conversion ......................... 185 

10.32. Post-Processor for Mesoscale Lookup............................................................. 189 

10.33. Post-Processing Script Execution .................................................................... 190 

10.34. Summary Reporter........................................................................................... 192 

10.35 GREET Model Interface ............................................................................. 195 

10.36 Future Emission Rate Creator (FERC) ............................................................. 199 

10.37 I/M Coverage Table Editor............................................................................... 203 

4
10.38 Estimating the Uncertainty of MOVES Results ............................................... 204 

11. MOVES-HVI Input and Default Databases.............................................................. 209 

11.1. Use of Data Types.............................................................................................. 210 

11.2. Functional Types of Tables: .............................................................................. 210 

11.3. Database Tables and Their Use ......................................................................... 211 

11.4. Where to Find More Detailed MOVES Database Documentation.................... 219 

12. MOVES-HVI Output Databases............................................................................... 221 

12.1. MOVESRun Table............................................................................................. 223 

12.2. MOVESError Table........................................................................................... 224 

12.3. The MOVESActivityOutput and MOVESOutput Tables ................................. 224 

Appendix A. Table of Acronyms................................................................................... 229 

Appendix A. Table of Acronyms................................................................................... 229 

5
1. Introduction 

The Highway Vehicle Implementation of EPA’s Motor Vehicle Emission 

Simulator (MOVES-HVI) is the second major “implementation” of MOVES. The first 

was termed MOVES2004. MOVES2004 can be used to estimate and project national 

inventories at the county level for energy consumption, N2O, and CH4 from highway 

vehicles. MOVES-HVI retains much of the functionality of MOVES2004 but has not 

updated it significantly. The GREET model interface incorporated in MOVES2004 has 

been disabled in this version because it is no longer operational. EPA hopes to restore 

this functionality in a future version of MOVES-HVI. 

The initial “Demonstration Version” of MOVES-HVI is only intended to 

demonstrate the significant features added to MOVES to estimate criteria pollutant 

emissions (gaseous hydrocarbons, carbon monoxide, oxides of nitrogen and particulate 

matter) from highway vehicles. This version is suitable only for demonstration purposes; 

none of its numerical value results should be considered to be realistic. EPA plans to 

make available subsequent versions of MOVES-HVI which will produce more realistic 

estimates of these criteria pollutant emissions. 

Future implementations of MOVES are planned to estimate pollutants from

additional mobile sources such as aircraft, locomotives, and commercial marine activity, 

estimate non-highway mobile source emissions, and operate at smaller scales. 

Two documents can be considered precursors to this one: The first is a report 

published in October 2002 entitled Draft Design and Implementation Plan for MOVES. 

This plan includes extensive background on the impetus for MOVES, an analysis of the 

“use cases” MOVES is intended to address, and the conceptual design for the model. 

The second was the MOVES2004 Software Design Reference Manual (SDRM) dated 

November, 2004. 

Both documents are available on the MOVES website 

(www.epa.gov/otaq/ngm.htm) and the reader is encouraged to consult them if additional 

background is desired. The draft plan underwent formal peer review and public 

stakeholder review; the comments resulting from this process were summarized in 

Appendix I of the MOVES2004 SDRM. A preliminary version of the MOVES2004 

6
SDRM was peer-reviewed, and the comments from this process were summarized in 

Appendix II of the released draft version. Because this document has the same purpose, 

structure, scope and formatting conventions relative to MOVES-HVI as the previous 

MOVES 2004 SDRM had relative to MOVES2004, EPA does not plan for it to undergo 

formal peer review. Comments from the public are welcome. 

The overall purpose of this Software Design and Reference Manual, is, together 

with the MOVES-HVI User Guide, to answer questions pertaining to the MOVES 

software. The User Guide is tailored to the beginning user and to getting started quickly 

using the model. It focuses on operation of the MOVES Graphical User Interface (GUI). 

This Software Design and Reference Manual intended to answer more substantive 

questions about the model software and document the calculations the model performs. It 

also provides more detail on configuring, installing, and running the MOVES program 

than the User Guide. 

 Chapter 2 identifies the major software and database components which make up 

MOVES-HVI. At this general level the MOVE Software is considered to consist of 8 

components. 

Chapter 3 covers the hardware and system software required to run each major 

component. 

Chapter 4 covers configuration of the MOVES software, which can be run on a 

single computer or a network of computers. 

Chapter 5 covers MOVES software licensing. 

Chapter 6 discusses the MOVES installation process in somewhat greater detail 

than the MOVES User Guide or the Readme file included in the installation package 

itself.

Chapter 7 provides a “processing overview” of MOVES. 

Chapter 8 diagrams and discusses the flow of data and control between more 

detailed components of MOVES. At this level the MOVES-HVI software is divided 

into about 25 components. 

Chapter 9 discusses the functional design concepts of MOVES. 

7
Chapter 10 documents the functionality of most of the individual components of

MOVES, their inputs, the calculations they perform, and the outputs they produce. 

Almost half of this document consists of this single chapter. 

Chapter 11 provides some top level documentation of the tables in the MOVES 

Input Database and contains more detailed documentation of the flow of data in MOVES 

by indicating which MOVES components read and write these tables in the MOVES 

Execution Database. 

Chapter 12 documents the structure of the MOVES Output Database. 

Other documents supplement the MOVES-HVI User Guide and the MOVES_HVI 

Software Design and Reference Manual. Those most closely related to the software are: 

The MOVES Program Suite Distribution includes a README file more 

briefly explaining the process of installing all MOVES-related components, 

and where to get assistance or report problems with the MOVES 

installation process. 

Detailed documentation on the MOVES input database is included in a 

README directory within the database itself. 

Technical documentation explaining the data sources and methods used to 

estimate the default fleet, activity, and emission data underlying MOVESHVI is contained in technical reports separately downloadable from the 

EPA web site. 

Documentation produced by Argonne Laboratories covering the GREET 

model is contained in the GREET directory within the model itself. 

8
2. MOVES Software Components 

MOVES is written in JavaTM and the MySQL relational database management 

system, a product of MySQL AB. Its principal user inputs and outputs, and several of its 

internal working storage locations, are MySQL databases. A “default” input database, 

covering 3222 counties of the United States and which supports model runs for calendar 

years 1990 and 1999 - 2050 is included with the model. 

MOVES has a “master – worker” program architecture which enables multiple 

computers to work together on a single model run. A single computer can still be used to 

execute MOVES runs by installing both the master and worker components on the same

computer. 

Looking at this architecture in greater detail, the MOVES software application 

consists of eight components, each described briefly here. 

MOVES Graphical User Interface (GUI) and Master Program: This is a Java 

program which manages the overall execution of a model run. Its MOVES GUI (also 

sometimes referred to as the run specification editor) may be used to create, save, load, 

and modify a run specification or RunSpec, and to initiate and monitor the status of a 

model run. A basic command line interface may be employed (in lieu of the GUI) by 

users (or by other computer programs) to execute the model without interacting with the 

MOVES GUI. If MOVES is installed on a computer network several model runs may be 

executed concurrently by different copies of the MOVES Master Program. 

MOVES Worker Program: This is also a Java program. At least one executing 

copy of this program is needed to complete a MOVES run. It may execute on the same

computer as the MOVES Master Program, or on other computer(s) having access to the 

SharedWork file directory. 

Default input database, normally named “MOVESDefault”: this MySQL 

database must reside on the same computer as the MOVES Master Program. A version 

of this database is included in the MOVES Installation Package. 

SharedWork: This is a file directory or “folder” which is accessible to all 

executing copies of the MOVES Master program and the MOVES Worker program. It is 

9
not a MySQL database but simply a file directory or “folder” provided by the file 

services of a software operating system. 

Optional user input databases: These MySQL databases are normally located 

on the same computer as the MOVES Master Program. They may contain any of the 

same tables that are in the default input database and are used to add or replace records as 

desired by the user. 

The MOVESExecution database: This MySQL database is created by the 

MOVES Master Program. It is used for temporary working storage and does not interact 

directly with the user. It must be on the same computer as the master program. 

MOVES output databases: MySQL databases are named by the user and 

produced by MOVES model program runs. While normally located on the same 

computer as the MOVES Master program, they could be located on any MySQL server 

accessible to it. 

MOVESWorker database: This MySQL database is used as working storage by 

the MOVES Worker Program. It does not interact directly with the user. It is on the same

computer as the MOVES Worker program.

10
3. Computer Hardware and System Software 

Requirements

The MOVES application software components require a computer hardware and 

software “platform” upon which to operate. The hardware platform can consist of a 

single computer system or a network of computers. 

Computer(s) used to run either of the MOVES application programs should have 

at least 256MB of RAM. (Having additional memory is highly recommended, and is 

now relatively inexpensive). Execution run time performance is a constraint with 

MOVES so high speed processor(s), at least 1-2 GHz and preferably faster, are highly 

recommended. The MOVESDefault database distributed with MOVES requires 

approximately 300MB of disk storage. MOVES Worker and Output databases are also 

often voluminous, so several gigabytes of disk space should be available on all machines 

used to run either MOVES program. Extensive users of MOVES will want to use the 

highest performance microcomputer systems that they can afford. 

3.1. Details on JAVA Platform Requirements 

The MOVES GUI/Master and the MOVES Worker are Java programs and for 

operation require a Java RunTime Environment (also sometimes referred to as the “Java 

Virtual Machine”). The Java Software Development Kit (SDK) includes the Run Time

Environment. This version of MOVES2004 uses version 1.4.2 of the Java SDK, 

produced by SUN Microsystems Inc. The MOVES Program Suite Distribution includes 

an installation package for this Java version, suitable for installation on WINDOWS NT, 

WINDOWS 2000, and WINDOWS XP systems. MOVES does not operate successfully 

on versions of WINDOWS that predate WINDOWS 2000. Users should not attempt to 

operate either MOVES program with other versions. While Java is available for other 

software operating systems, such as LINUX, UNIX, etc. and porting MOVES to such 

software operating systems should not be difficult, EPA has not tested such 

configurations and is not prepared to support them. Sun’s main web site for information 

related to Java is http://java.sun.com/ . 

Several extensions to Java are also required by MOVES and are included in the 

MOVES Installation Package. These include JUnit and JFCUnit, which facilitate 

11
software testing, and JavaHelp used to construct the on-line help facility in MOVES. The 

ANT software build utility is also included. 

3.2. Details on MySQL Platform Requirements

The MySQL database management software has a client-server architecture. The 

MOVES GUI/Master, the MOVES Command Line interface/Master, and MOVES 

Worker programs function as MySQL clients and require access to MySQL server(s). 

Since both programs require a MySQL database to be located on the same computer 

(MOVESExecution and MOVESWorker), all computers that run any of these MOVES 

components must also operate a MySQL server. Additional computers operating MySQL 

servers can also be utilized; e.g., for MOVES Output databases. 

This version of MOVES uses MySQL version 5.0.27. The MOVES-HVI 

Program Suite Distribution includes an installation package for this MySQL version, 

suitable for installation on WINDOWS NT, WINDOWS 2000 and WINDOWS XP 

systems. The demo version of MOVES-HVI will continue to operate with MySQL 

version 4.0.21, this will not be true of future versions. Users should not attempt to 

operate either MOVES program with other versions. While MySQL is available for other 

software operating systems, such as LINUX, UNIX, etc. and porting MOVES to such 

software operating systems should not be difficult, EPA has not tested such 

configurations and is not prepared to support them. MOVES-HVI does not operate 

successfully with versions of WINDOWS which predate WINDOWS 2000. 

The MySQL installation includes a command line MySQL client program. The 

MOVES Program Suite Distribution also includes an installation package for the MySQL 

Query Browser which is a GUI MySQL client program. Either of these MySQL client 

programs can be used to help construct MOVES input databases or to analyze the 

contents of MOVES output databases. Other data base management software, such as 

Microsoft ACCESS can also be used via an ODBC driver. Appendix B of the MOVESHVI User Guide explains how this can be accomplished. 

Additional information about MySQL is available at the MySQL web site 

(http://www.mysql.com/) operated by MySQL AB. 

12
3.3. Details on Shared File Directory Platform Requirements 

The SharedWork file directory may be located on a computer that runs the 

MOVES Master Program or the MOVES Worker Program or on a separate “file server” 

computer. All that is necessary is that the MOVES GUI and Master program and at least 

one MOVES Worker program have access to this shared file directory with permission to 

create, modify and delete files. In the simplest case, diagrammed early in the next 

section, all MOVES Application Software components may reside on a single computer. 

In this case the SharedWork directory is simply on this computer’s local hard drive. All 

files created by MOVES in this directory are temporary, but because the files can be 

numerous and large, at least 1GB of disk space should be available. 

13
4. MOVES Computer Platform Configuration 

All MOVES application components may be installed on a single computer 

system as shown in the following Figure 4-1. 

MOVES may also be configured so that several computers work together to 

execute model simulation runs. This can significantly improve execution time 

performance of large simulations. (Improvements diminish, however, as more worker 

computers are added. The number of worker computers needed to approach the minimal 

execution time for a model run depends on the specific nature of the run.) 

For several computers to work together on a MOVES run, all that is necessary is 

for the computers to have access to the SharedWork directory. For one computer this file 

directory can be on its local hard drive; other computers must access the SharedWork 

directory via a computer network. Of course, the platform requirements of each MOVES 

14
component must still be satisfied by the computer(s) on which it is installed. A variety of 

network configurations are possible. The principal consideration is that each Master/GUI 

Program must have the MOVESDefault database on its computer and that each Worker 

Program must be able to create a MOVESWorker database on its computer. 

Two text files, MOVESConfiguration.txt, and WorkerConfiguration.txt, versions 

of which are built by the MOVES installation program, are used by the MOVES 

Master/GUI program and the MOVES Worker program to locate their databases and the 

SharedWork directory. The default configuration is: 

Figure 4-2 shows a typical Multiple Computer configuration. 

15
16
5. MOVES Software Licensing 

EPA distributes a complete installation package for MOVES as open source 

software. EPA asserts a copyright to the MOVES application but allows MOVES to be 

used pursuant to the GNU General Public License (GPL), which is widely used for the 

distribution of open source software. 

Restrictions apply to use of MOVES pursuant to the GPL. For example, the 

program may not be sold, even in modified form, for commercial profit without obtaining 

a commercial license to MySQL from MySQL AB and, if redistributed in modified form, 

must be identified accordingly and source code included. Distribution of modified 

versions of the program also requires compliance with the GPL unless commercial 

licenses are obtained. The terms of the GPL are explained in detail at 

http://www.gnu.org/licenses/. 

17
6. Installation Overview 

The software installation process has been significantly improved for MOVESHVI. The MOVES-HVI Program Distribution Suite contains all software components 

necessary to install and use MOVES-HVI on microcomputer systems based on the 

WINDOWS NT, WINDOWS 2000, and WINDOWS XP software operating systems. 

The MOVES Program Suite Distribution is available for download from the EPA web 

site. Because of its size (approximately 200mb) it is highly desirable to have a high 

speed connection to the Internet to obtain this download. 

The MOVES Program Suite Distribution includes a README file that 

summarizes the information provided in the remainder of this section. 

In order to install and run several of the MOVES-related software components 

you must have administrative rights to the computer system(s) involved. Organizations 

are increasingly restricting these rights to a limited number of individuals. If you do not 

have these rights, you need to obtain them, or enlist the help of someone who does. 

Assuming you have these rights and have obtained the MOVES Program Suite 

Distribution the first actual installation step is to install Java version 1.4.2 that MOVES 

requires or verify that it has already been installed. The MOVES Program Distribution 

Suite includes a separate installation package for this version of Java. EPA intends this 

Java installation package to be used only for computers that do not already have 

Java installed. If you are running older versions of Java you will need to upgrade to this 

version. This can be a complicated situation because this may affect preexisting Java 

applications on your computer, and EPA cannot provide support for this. Conversely, if 

you are already running a later version of Java, MOVES may not operate correctly with 

it. In this kind of situation you may wish to install MOVES on a different computer. If it 

is appropriate to run the Java version 1.4.2 installation package provided by EPA, just 

double-click on the installer installation program (j2sdk-1_4_2_03-windows-i586-p.exe 

provided in the java 1.4.2 directory) and follow the installer’s instructions. 

The second actual installation step is to install the MySQL database management 

system software that MOVES requires or verify that it has already been installed. The 

demonstration version of MOVES-HVI operates with MySQL version 5.0.27 and EPA’s 

18
Distribution includes a separate installation package for this. EPA intends this MySQL 

installation package to be used only for computers that do not already have MySQL 

installed. If you are running older versions of MySQL you will need to upgrade to this 

version. This can be a complicated situation because this may affect preexisting MySQL 

applications on your computer, and EPA cannot provide support for this. Conversely, if 

you are already running a later version of MySQL, MOVES may not operate correctly 

with it. In this kind of situation you may wish to install MOVES on a different computer. 

If it is appropriate to run the MySQL installation provided by EPA you can read and 

follow the instructions in InstallMySQL5.doc: 

All other required MOVES-HVI components can be installed by running the 

MOVESInstallationPackage.jar file included in the MOVES-HVI Program Installation 

Suite. This graphical “wizard-style” program guides the user through the process of 

installing the MOVES application. It was prepared with the IZPACK open source 

installation packaging tool. You will need to know the location where MySQL has been 

installed. Assuming you accepted the default location this is “c:\mysql”. This 

installation creates three desktop icons. One executes the MOVES GUI and master 

program, a second executes the MOVES Worker Program, and a third icon can be used to 

“Uninstall” MOVES. The MOVES installation keeps track of components it installs and 

this “Uninstall” feature can be used to remove all those components, including the Java 

extensions needed for MOVES. It does not remove components which have been 

modified or which have been installed in some other fashion. 

Users who desire a graphical client program to use with MySQL should execute 

the installation package for the MySQL Query Browser by following the steps in the 

README file. The MySQL Query Browser is a product of MySQL AB and replaces the 

earlier MySQL Control Center which EPA distributed with MOVES2004. 

Users who desire to use Microsoft Access or another DBMS to prepare or query 

MySQL tables via ODBC connections should execute the installation package for 

MySQL Connection ODBC by following the steps in the README file. 

19
7. Processing Overview 

The following diagram illustrates the overall flow of processing in MOVES in a 

way which illustrates the division of work between the MOVES Master and Worker 

programs. 

MOVES Processing Overview Diagram 

Worker

TotalActivityGenerator, 

WellToPumpProcessor,

OperatingModeDistributionGenerator, 

AVFTControlStrategy, 

FuelEngineStartCalculator

.

.

. 

MasterLoopables

TotalActivityGenerator, 

WellToPumpProcessor, 

OperatingModeDistributionGenerator,

AVFTControlStrategy, 

FuelEngineStartCalculator

.

.

MOVESWindow RunSpec

Master

MOVESDefault

MOVESExecution MOVESWorker

MOVESOutput

MYSQL

EmissionCalculatorOutboundBundler()

EmissionCalculatorInboundUnBundler()

MOVESInstantiator.performInstantiation

MasterLoopables MasterLoop

USERInput

Typical Processing Steps: 

Before beginning a model run any desired User Input datatabases (shown near the 

bottom left of the diagram) must be prepared. (The diagram does not attempt to show 

this intial step, which is only required if the user wishes to deviate from the default 

database inputs.) The components accessed via the “Pre-Processing Menu” in the 

MOVES GUI can be used to produce User Input Databases for particular purposes. A

button in the MOVES graphical user interface, represented in the diagram by its 

MOVESWindow, can also be used to create an empty User Input database to which users 

can add the table records they need. 

20
A run specification, or RunSpec, is loaded or produced by using the MOVES 

graphical user interface (MOVESWindow). 

The user initiates execution of the actual model run via the “Action” menu item of 

MOVESWindow. 

The MasterLoop, within the MOVES Master program, then merges any User 

Input databases identified in the RunSpec with the MOVESDefault database to produce 

the MOVESExecution database. Most data not needed to fulfill the RunSpec is discarded 

or “filtered” in this process. 

The MasterLoop then uses the MOVESExecution database to produce files 

containing work “bundles” in the SharedWork directory. 

MOVES Worker program(s) perform these bundles of work, using their 

MOVESWorker databases for temporary storage. They place files containing the 

completed work back into the SharedWork directory. 

The MasterLoop retrieves these completed work files and processes them into a 

MOVES output database. The name of the output database is specified in the Run Spec. 

The “Post Processing” menu in the MOVESWindow allows for additional, 

optional processing steps to be performed on the output database. 

8. Data and Control Flow 

Figure 8-1 illustrates the logical flow of data and control within the MOVES 

software. While generally more detailed than the diagram in the previous section, it does 

not attempt to illustrate the division of work between the MOVES Master and Worker. 

21
Figure 8-1 MOVES Logical Level Data Flow Diagram 

The graphical conventions used in this diagram are: 

22
Cylinders represent databases. 

Boxes with curved ends (simplified cylinders) represent data files. 

Rectangles open on the right hand side represent temporary data storage 

elements. 

Round-cornered rectangles represent processes that operate on and produce 

data. 

Square boxes represent interfaces external to the system. 

Solid line arrows represent data flow. 

Dashed line arrows represent control flow. 

The “RTC” notation on an arrow indicates that the control flow “runs to 

completion” before any of the data is processed by subsequent steps. 

In order to illustrate the specifics of MOVES, several databases envisioned by the general 

MOVES design have been combined into the MOVESDefault and MOVESExecution 

databases illustrated here. Chapter 11 contains a more detailed discussion of these. 

The following text attempts to lead the reader through the diagram. The first 

occurance of each diagram block is bolded. 

The User normally executes the MOVES GUI program, which may access and 

update files containing Saved Run Specifications and AVFT Strategy Definitions. A 

simple MOVES Command Line Interface is available as an alternative to execute an

existing run specification or RunSpec. 

The Command Line Interface passes a selected Run Spec directly to the MOVES 

Application Program Interface (API), whereas the MOVES GUI Program allows the 

user to select, edit, and save run specifications, and/or operate any Pre-Processor Menu 

Items before passing control to the MOVES API. These pre-processors typically use the 

MOVESDefault database and Text Files for Data Import to create User Input 

Databases which can be included in the run specification. MOVES-HVI includes two 

operative pre-processors: the Future Emission Rate Creator (FERC) external control 

strategy and the IM Program Coverage Table Editor. EPA hopes the GREET model 

interface, which functions as a pre-processor, will be operational in future versions of 

MOVES-HVI. 

Once control is passed to the MOVES API, it manages the actual model run. 

Control is first passed to the Input Data Manager, which merges the MOVESDefault

23
database with any User Input Databases specified by the RunSpec, producing the 

MOVESExecution database. 

A Database Pre-aggregation function was added to MOVES to reduce execution 

time performance at the expense of some added approximation in the calculations. This 

function is executed next if called for by the run specification. 

If the run specification specifies that the run will be performed at the “Mesoscale 

Table Lookup” scale the database is adapted for this at this stage by the Lookup Table 

Link Producer. 

The Master Loop then manages execution of the generators, internal control 

strategies, and calculators. MOVES-HVI includes a Total Activity Generator (TAG),

several Operating Mode Distribution Generators (OMDGs), a 

SourceBinDistributionGenerator (SBDG), a Meteorology Generator, a Tank Fuel 

Generator, and a Tank Temperature Generator. It includes one internal control 

strategy: the Alternative Vehicle Fuels and Technologies (AVFT) Strategy. All 

generators and control strategies receive input from tables in the MOVESExecution 

database and place their output there as well. Tables written by Generators are termed 

“Core Model Input Tables” or “CMITs” and have an important role in the design of 

MOVES. Additional detail as to which tables are used by each generator and control 

strategy is contained in Chapters 10, 11, and 12. 

Emission Calculators are the most central or “core” portion of MOVES model. 

They consume much of its execution time and so the MOVES software design provides 

for portions of them to be run by the MOVES Worker Program. They receive input from

the MOVESExecution database (some of which has been produced or altered by the 

generators and the control strategies). The CMIT tables within the MOVESExecution 

database provide their principal input data, but other tables may also be used by emission 

calculators for specialized calculations. The emission calculators output their results to 

databases on worker machines that are further processed to become the MOVESOutput 

Database. MOVES-HVI includes approximately 20 EmissionCalculators which 

calculate distance traveled and the emission results for various pollutants resulting from

various emission processes. These are documented further in Chapter 10. 

24
After all Generators, Internal Control Strategies and Emission Calculators needed 

to produce the results required by the run specification have executed, several more 

processing steps are required. Result Aggregation and Engineering Units Conversion

functions are performed on the MOVESOutput database. For mesoscale table lookup an 

integrated Post-Processor for Mesoscale Lookup is then executed to produce an 

additional emission rate table in the output database. 

Following the model run, the MOVES GUI can be used to invoke additional 

“post-processing” functions to operate on MOVESOutput databases. MOVES-HVI 

includes two such post-processing functions. Post-Processing Script Execution, runs a 

selected MySQL script against the MOVESOutput database specified by the run 

specification. Several post processing scripts are provided with the model and users may 

add to these if further customization of MOVES output is desired. A Summary 

Reporter has been added to this version of MOVES which allows the user to further 

aggregate the output results, produce summary on-screen or printed reports, and/or tabseparated variable ASCII files of selected results. These are suitable for importing into 

other software, such as spreadsheets, for further display and analysis. 

25
9. Functional Design Concepts 

The functional scope of this MOVES version can be characterized as follows: 

Geography: The entire U.S. (plus Puerto Rico and the U.S Virgin Islands) at 

the county level. There are options to run at a more aggregate state or 

national level. By modifying the database, counties can be divided into 

zones. 

Time Spans: Energy/emission output by hour of the day, and month for 

calendar years 1990 and 1999 through 2050, with options to run at more 

aggregate month or year levels. 

Sources: All highway vehicle sources, divided into 13 “use types” 

Outputs and Pollutant Emissions: Energy consumption (characterized as 

total energy, petroleum-based energy and fossil fuel-based energy), N2O, 

CH4, Atmospheric CO2, CO2 equivalent, total gaseous hydrocarbons, CO, 

NOx, and several forms of particulate matter (PM). 

Emission Processes: running, start, extended idle (e.g. heavy-duty truck 

“hoteling”), well-to-pump, brakewear, tirewear, evaporative permeation, 

evaporative fuel vapor venting, and evaporative fuel leaks. 

Understanding how MOVES operates and why the input and output databases are 

set up as they are requires an understanding of some basic functional design concepts. 

Fundamental aspects of the MOVES design are geographic locations, time periods, 

emission sources, emission pollutants, emission processes, vehicle fuels, and emission 

source activity. 

9.1. Geographic Locations 

The default geographic modeling domain in MOVES-HVI is the entire United 

States of America. This domain is divided first into “states.” In this context the District 

of Columbia, Puerto Rico, and the U.S.Virgin Islands are considered to be “states”, so the 

nation has 53 states in the default MOVES database. 

“States” are divided into “counties.” In the default MOVES database these 

correspond to the 3222 political subdivisions of the states in 1999. Counties must belong 

to a single state. While the county-level subdivisions of some states have changed 

slightly over time, the MOVES database is set up to store only a single set of counties. 

The database could be adapted relatively easily to a different set of counties, but it would 

be a significant structural change to MOVES to allow the set of counties to depend upon 

the calendar year. 

26
In the general MOVES design framework, “counties” may be further divided into 

“zones,” but in the default database each county is consists of a single zone. Zones are 

intended to play a distinct role in future versions of MOVES that operate at smaller 

scales. 

 “Zones,” and thus “counties” in the default database, are further divided into 

“links.” In this version of the MOVES default database each county is divided into five 

links; four of these represent actual roadways and one represents locations not on the 

county’s roadway network. This set of roadtypes has been reduced, relative to those in 

the default database distribution with MOVES2004 which had a total of 13 roadtypes. 

The five roadtypes in this version of MOVES are: 

1 Locations which are off of the highway network 

2 Rural restricted access roadways (i.e. freeways and interstates)

3 Rural roads to which vehicle access is unrestricted 

4 Urban restricted access roadways (i.e. freeways and interstates) 

5 Urban roads to which vehicle access is unrestricted 

Each of these roadtypes is a combination of one or more of the 13 roadtypes used in the 

database distributed with MOVES2004. The set of roadtypes used in MOVES is driven 

by the database and changing this set does not require changes to the MOVES program

itself.

Running, tirewear, brakewear, and some evaporative process emissions are 

considered to occur on the four “real roadway” roadtype locations, while its other 

emission processes (i.e. start, extended idling, well-to-pump, and most evaporative 

emissions) are associated with the “off network” link locations. (Emission processes are 

discussed in a subsequent section.) 

In this version of MOVES at macroscale, a link is a combination of a road type 

and a county or zone. Road types, while not in themselves geographic locations, help to 

define links at the macroscale. This version of moves can also be run in a “mesoscale 

table lookup” mode in which a link represents all highway segments in the county or 

zone which have the same roadtype and average speed. In future versions of MOVES, 

27
when modeling at smaller scales, links may represent segments of actual roadways and 

road types will serve only to classify links. 

Finally, the general MOVES geographic framework envisions that zone locations 

may be overlaid by a set of “grids,” or grid cells. There may be multiple grid cells in a 

zone and multiple zones in a grid cell, but grids and grid cells play no role in this version. 

9.2. Time Periods 

MOVES describes time in terms of calendar years, 12 months of the year, 

portions of the seven-day week which are termed “Days” (but which may include more 

than one 24 hour period), and 24 hours of the day. This arrangement appears simple but 

there are several subtleties to keep in mind: 

A “Day” in MOVES is really best thought of as a “portion of the week”. It does 

not have to represent a single 24 hour period. It may represent several 24-hour periods, 

or even the entire week. The default database for this version of MOVES-HVI divides 

the week into a 5-day “weekday” portion and a 2-day “weekend” portion. While 

calendar years in MOVES are intended to represent actual historical years, the finer time 

period classifications (months, portions of the week, and hours) are best thought of as 

being “generic” time classifications. For example MOVES does not attempt to model 

the fact that a holiday occurs on a weekend in one year but occurs on a weekday in 

another. 

Another reason why MOVES should not normally be considered to model 

historical time periods smaller than a calendar year is the disconnection between “weeks” 

and “months.” For example, there is no way to specify data for more than one week in a 

single historical month, such as May 2004, in a single MOVES database. The database is 

designed to store information about the year 2004 and about all weeks in May. Along the 

same lines, MOVES does not attempt to model facts such as that a given month may 

contain more weekend days in some years than others. MOVES does account for the 

different number of days in each month, dividing this by 7 to determine the number of 

weeks it is considered to contain, and MOVES does account for leap years. 

In order to model an actual historical time period, data corresponding to the 

unique time period could be supplied by the user, and the user could make this 

28
association outside the model. Depending on the accuracy and detail desired, multiple 

model runs might be necessary. 

In most portions of the model the month, portion of the week, and hour time

periods are simply categories, and do not even have an assumed sequence. Because 

estimation of evaporative emissions is based on an hourly “diurnal” temperature cycle all 

24 hourly categories of the day must be included in the run specification when estimating 

evaporative emissions, and this area of the model does assume an hourly time sequence. 

9.3. Characterizing Emission Sources (Vehicle Classification) 

A long-standing challenge in the generation of on-road mobile source emission 

inventories is the disconnect between how vehicle activity data sources characterize 

vehicles and how emission and fuel economy regulations characterize vehicles. The crux 

of this issue is that there is a fundamental difference between factors influencing how 

vehicles are used, and their fuel consumption and emission performance. An example of 

this is how vehicles are characterized by the Highway Performance Monitoring System 

(HPMS) – by a combination of the number of tires and axles – and EPA’s weight-based 

emission classifications such as LDV, LDT1, LDT2 etc. 

This disconnect is fundamental to matching activity data and emissions data, and 

generally requires some “mapping” of activity data to emission data. The MOBILE 

series of models have traditionally grouped vehicles according to the EPA emission 

classifications, and provided external guidance on mapping these categories to the 

sources of activity data, such as HPMS. MOVES is designed to take these mappings into 

account internally, such that the casual user of MOVES will not have to deal with 

external mapping. Doing this, however, requires some complexity in the design. 

Vehicles are characterized both according to activity patterns and energy/emission 

performance, and are mapped internal to the model. Thus the model uses data for both 

the activity and energy/emission methods of characterization. On the activity side, 

vehicles are grouped into “Source Use Types,” or “Use Types”, which are expected to 

have unique activity patterns. Because the HPMS is a fundamental source of activity 

information, the MOVES use types are defined as subsets of the HPMS vehicle 

classifications. These use types are shown in Table 9-1. 

29
Table 9-1. MOVES Source Use Type Definitions 

HPMS Class MOVES use type Description 

Passenger Cars 21. Passenger Car 

Other 2-axle / 4-tire 

Vehicles 

31. Passenger Truck 

Minivans, pickups, SUVs and other 

2-axle / 4-tire trucks used primarily

for personal transportation

32. Light Commercial Truck 

Minivans, pickups, SUVs and other 

trucks 2-axle / 4-tire trucks used 

primarily for commercial 

applications. Expected to differ 

from passenger trucks in terms of 

annual mileage, operation by time 

of day

Single Unit Trucks 

51. Refuse Truck 

Garbage and recycling trucks 

Expected to differ from other single 

unit trucks in terms of drive 

schedule, roadway type 

distributions, operation by time of 

day

52. Single-Unit Short-Haul 

Truck 

Single-unit trucks with majority of 

operation within 200 miles of home 

base 

53. Single-Unit Long-Haul 

Truck 

Single-unit trucks with majority of 

operation outside of 200 miles of 

home base 

54. Motor Home 

Buses 

41. Intercity Bus 

Buses which are not transit buses or 

school buses, e.g. those used 

primarily by commercial carriers for 

city-to-city transport. 

42. Transit Bus Buses used for public transit. 

43. School Bus School and church buses. 

Combination Trucks 

61. Combination Short-Haul 

Truck 

Combination trucks with majority 

of operation within 200 miles of 

home base 

62. Combination Long-Haul 

Truck 

Combination trucks with majority

of operation outside of 200 miles of 

home base 

Motorcycles 11. Motorcycle 

Activity patterns which may differ between the use types are: annual mileage, 

distribution of travel by time of day or day of week, driving schedule (i.e. real time 

30
speed/accel profile), average speeds, and distribution of travel by roadway type. For 

example, refuse trucks are separated out because their activity patterns are expected to 

vary significantly from other single-unit trucks, and accurately accounting for these 

vehicles requires accounting for their unique activity. 

Source use types are the principal method of vehicle characterization seen by the 

MOVES user. The user selects which use type and fuel combinations to model in the

user interface, and results are best reported by use type.1 However, emission rates 

contained in the model are not broken down by use type, for two (related) reasons: first, 

emission and fuel consumption data are not gathered according to use types or other 

activity-based classifications (e.g. HPMS). Second, the factors that influence fuel 

consumption and emission production are different from how vehicles are used. For 

example, with regard to fuel consumption, loaded vehicle weight is a predominant 

influence; a 2000 lb. compact car and 5000 lb. SUV will have very different fuel 

consumption levels, although these vehicles may have similar use patterns. It is 

necessary to account for these differences in fuel consumption and emission generation 

separately from activity patterns. To do this, the MOVES design has implemented the 

concept of “Source Bins.” Unique source bins are differentiated by characteristics that 

significantly influence fuel (or energy) consumption and emissions – and because these 

vary by pollutant, they are allowed to vary by pollutant in MOVES. Table 9-2 shows the 

source bins fields used in MOVES, which vary by pollutant. Energy source bins are 

defined by fuel type, engine type, model year group, loaded weight and engine size. For 

most other polluants, source bins are defined by fuel type, engine type, model year group, 

and regulatory class. The definition of model year group can vary by pollutant-process. 

1

 Because Source Classification Codes (SCCs) have been and are used extensively in emission inventories 

MOVES2004 also offers the option of reporting results by SCC. There are currently 144 SCCs for mobile

sources formed by the intersection of the 12 HPMS road types with the 12 vehicle classifications used in

PART5 and NMIM. This scheme is not native to MOVEs, however, and the MOVEs modeling team

discourages continued use of this classification scheme. 

31
Table 9-2a. MOVES Source Bin Definitions (other than ModelYearGroup) 

Fuel Type 

(All Pollutants) 

Engine Technology 

(All Pollutants) 

Loaded 

Weight 

(Energy) 

Engine 

Size

(Energy) 

Regulatory Class 

(All pollutants except 

energy and evap 

permeation) 

Gas 

Diesel 

CNG 

LPG 

Ethanol (E85)

Methanol (E85)

Gas H2

Liquid H2

Electric 

Conventional IC (CIC)

Advanced IC (AIC) 

Hybrid - CIC Moderate 

Hybrid - CIC Full 

Hybrid - AIC Moderate 

Hybrid - AIC Full

Fuel Cell 

Hybrid - Fuel Cell

Electric 

Null 

< 500 (for motorcycles)

500-700 (for motorcycles)

> 700 (for motorcycles)

<= 2000 lbs 

2001-2500 

2501-3000 

3001-3500 

3501-4000 

4001-4500 

4501-5000 

5001-6000 

6001-7000 

7001-8000 

8001-9000 

9001-10,000 

10,001-14,000 

14,001-16,000 

16,001-19,500 

19,501-26,000 

26,001-33,000 

33,001-40,000 

40,001-50,000 

50,001-60,000 

60,001-80,000 

80,001-100,000 

100,001-130,000 

>=130,001 

Null 

< 2.0 liters 

2.1-2.5 liters 

2.6-3.0 liters 

3.1-3.5 liters 

3.6-4.0 liters 

4.1-5.0 liters 

> 5.0 liters 

Null 

Motorcycle

LDV 

LDT 

HD gasoline GVWR <= 14K lbs 

HD gasoline GVWR > 14K llbs. 

LHDD 

MHDD 

HHDD 

Urban Bus 

Table 9-2b. MOVES Source Bin Definitions (ModelYearGroup) 

Model Year Group 

Energy CH4, N2O HC - Evap HC, CO, 

NOx, PM 

start, running

HC, CO, 

NOx, PM 

extended idle 

Sulfate PM 

(ratios to 

energy) 

1980 and earlier

1981-85 

1986-90 

1991-2000 

2001-2010 

2011-2020 

2021 and later

1972 and earlier

1973 

1974 

1975 

. 

. 

. 

1999 

2000 

2001-2010 

2011-2020 

2021 and later

1970 and earlier

1971-1977 

1978-1995 

1996-2003 

2004 

2005 

. 

. 

2019 

2020 

2021 and later

1980 and earlier

1981-1982 

1983-1984 

1985 

1986-1987 

1988-1989 

1990 

1991-1993 

1994 

1995 

. 

. 

2019 

2020 

2021 and later

1980 and earlier

1981-85 

1986-90 

1991-2000 

2001-2006 

2007-2010 

2011-2020 

2021 and later

1980 and earlier

1981 and later

32
Source bins are defined independently from use types, but are mapped to use 

types internal to MOVES by the SourceBinDistributionGenerator. 

9.4. Emission Pollutants 

MOVES estimates two fundamentally different kinds of results: energy 

consumption and mass emissions. For convenience, all these quantities are considered to 

be “emissions.” “Energy emissions” estimated by MOVES-HVI are total energy 

consumption, fossil fuel energy consumption, and petroleum fuel energy consumption. 

The more familiar mass emissions estimated by MOVES-HVI are total gaseous 

hydrocarbons (THC), carbon monoxide (CO), oxides of nitrogen (NOx), sulfate 

particulate matter, tire wear particles under 2.5 microns, brake wear particles under 2.5 

microns, methane (CH4), nitrous oxide (N2O), carbon dioxide (CO2) on an atmospheric 

basis, and the “CO2-equivalent” of CO2 combined with N2O and CH4. 

9.5. Emission Processes 

On-road vehicles consume energy and produce mass emissions through several 

mechanisms or pathways, which are known within MOVES as “emission processes,” or

just “processes,” and are accounted for and reported (if desired by the user) separately. 

The MOVES mechanisms for “pump-to-wheel” energy consumption are limited to 

operation of the engine and emissions from the tailpipe. The MOVES mechanisms for 

gaseous emissions, however, include other processes such as fuel evaporation, tire wear 

and brake wear, which merit treatment as separate emission processes. In addition to all 

these “pump-to-wheel” energy and exhaust emission processes MOVES also includes a 

“well-to-pump” emission process. The processes for MOVES-HVI are as follows: 

Running Exhaust, meaning the energy consumed or the tailpipe emissions 

produced during vehicle operation over freeways and surface streets while 

the engine is fully warmed up. 

Start Exhaust, meaning the additional energy consumed or tailpipe emissions 

produced during the period immediately following vehicle start-up. An 

important note is that this quantifies the energy consumed or emissions 

produced in addition to the “running” energy/emissions produced 

immediately following start-up. Start emissions represent the incremental 

emissions produced following vehicle start-up, after accounting for the 

baseline running emissions. 

33
Extended Idle, meaning energy consumed or tailpipe emissions produced 

during long periods of engine idling off of the roadway network. This 

process applies only to combination long-haul trucks in the current version 

of MOVES-HVI, and is meant to account for the issue of overnight 

“hoteling” at truck stops, although it could eventually be applied to idling 

of passenger vehicles in drive-thru lanes, etc. 

Evaporative Fuel Permeation, meaning the migration of hydrocarbons 

through the various elastomers in a vehicle fuel system.

Evaporative Fuel Vapor Venting, meaning the expulsion into the atmosphere 

of fuel vapor generated from evaporation of fuel in the tank. Also includes 

evaporation into the atmosphere of fuel which has “seeped” to the surface

of vehicle parts. 

Evaporative Fuel Leaking, meaning the “gross” leaking of fuel, in liquid 

form, from the vehicle. This is assumed to subsequently evaporate, outside 

the vehicle, into the atmosphere. 

Brakewear, meaning the formation of particles of brake components which are 

formed during operation of vehicle brakes. 

Tirewear, meaning the formation of tire material particles during vehicle 

operation 

Well-To-Pump, meaning the energy and emissions produced from processing 

and distributing vehicle fuel from raw feedstock to the fuel pump. These 

energy use and emission rates are produced by a version of Argonne 

National Laboratory’s GREET model. MOVES-HVI has not been 

expanded in this area relative to MOVES2004 and so only reports the wellto-pump energy consumption and greenhouse gas emissions. It should be 

noted that well-to-pump emissions have a different relationship to locations 

than those of the other processes. MOVES associates well-to-pump results 

with the locations (e.g. Counties and RoadTypes) whose activity caused the 

emissions; the emissions are not produced at these locations as they are for 

the other processes. 

An additional process, manufacture/disposal, would account for energy and 

emissions from vehicle production and disposal. This is not yet included in MOVES. 

9.6. Vehicle Fuel Classifications 

The top level vehicle fuel classifications are listed in Table 9-2, above, in the 

context of their role in vehicle source bin classification. Implicit in this source bin 

classification scheme is that a particular vehicle is designed to operate on one kind of 

fuel. The MOVES term for this top-level classification of vehicle fuels is “fuel type”.

MOVES-HVI considers the following fuel types: 

Gasoline 

34
Diesel Fuel 

Compressed Natural Gas (CNG) 

Liquid Propane Gas (LPG) 

Ethanol (E85) 

Methanol (M85) 

Gaseous Hydrogen 

Liquid Hydrogen 

Electricity 

To facilitate modeling the effects of alternative fuels on greenhouse gas 

emissions, MOVES further divides these top level fuel types into fuel subtypes. In the 

default MOVES database, for example, the gasoline fuel type has three subtypes: 

conventional, reformulated, and gasohol (E10). Diesel fuel has three subtypes: 

conventional, biodiesel, and Fischer-Tropsch diesel. Fuel subtypes represent alternative 

ways of meeting the demand for a general type of fuel. MOVES assumes that vehicles 

designed to operate on a top level fuel type may be operated on any of its subtypes 

depending upon the fuel supply at a particular time and geographic location. 

This fuel classification scheme was expanded further in MOVES-HVI to further 

divide fuel subtypes into more specific “fuel formulations” which may be thought of as a 

batch of fuel having specific values of measurable properties such as RVP, sulfur content, 

and oxygenate content. This additional breakdown is necessary because these fuel 

characteristics affect the emissions of pollutants added in MOVES-HVI and vary within a 

fuel subtype. MOVES assumes that vehicles designed to operate on a top level fuel type 

may be operated on any formulation of any of its fuel subtypes depending upon the fuel 

supply at a particular time and geographic location. 

9.7. Emission Source Activity 

The cornerstone of estimating mobile source energy usage and emission 

inventories is vehicle activity. Vehicle activity centers on two fundamental questions: 

what is the total amount of vehicle activity, and how is this activity subdivided into 

modes that are unique in regards to energy consumption and emissions. The first 

35
question is quantified in MOVES by the metric Total Activity. Total Activity, as the 

name implies, is the total amount of vehicle activity for source use types in the given 

location and time which the user has selected in the run specification. The basis of total 

activity depends on the emission process, as shown in Table 9-3. In MOVES-HVI the 

Total Activity Generator estimates Total Activity for all emission processes except wellto-pump. A simplified version of the TAG is used for runs involving mesoscale table 

lookup. 

Table 9-3. Total Activity Basis by Process 

Emission Process Total Activity Basis Description 

Running

Tire wear 

Brake wear 

Source Hours Operating (SHO) Total hours, of all sources within 

a source type, spent operating on

the roadway network for the 

given time and location of the 

run spec. The same as number 

of sources * per-source hours 

operating 

Evaporative Fuel 

Permeation, Vapor Venting 

and Leaking 

Source Hours Total hours, of all sources within 

a source type for the given time

and location of the run spec. 

This is equivalent to the 

population of the source type 

times the number of hours in the 

time period. 

Start Number of Starts Total starts, of all sources within 

a source type, for the given time 

and location of the run spec. 

The same as number of sources 

* per-source starts 

Extended Idle Extended Idle Hours Total hours, of all sources within 

a source type, spent in extended 

idle operation for the given time 

and location of the run spec. 

Well-To-Pump Pump-To-Wheel Energy

Consumed 

Total energy consumed, of all 

sources within a source type, for 

the given time and location of 

the run spec. The sum of 

running, start and extended idle. 

The second piece of activity characterization is to define how this total activity 

may be subdivided into operating modes which produce unique energy consumption and 

36
emission rates. The operating mode concept is central to MOVES multi-scale analysis 

capability, and has been expanded in MOVES-HVI. In the MOVES design these 

operating modes are allowed to vary by emission process and pollutant, and for some

pollutant-processes Total Activity is not further divided into multiple operating modes. 

For the running emission process for all pollutants except CH4 and N2O, the total 

source hours operating (SHO) activity basis is broken down into operating modes 

representing ranges of vehicle speed and vehicle specific power (VSP). The operating 

modes used for the running emission process are shown in Tables 9-4 and 9-5. 

Table 9-4. Operating Mode Bin Definitions for Running Energy Consumption) 

Braking (Bin 0)

Idle (Bin 1) 

VSP \ Instantaneous Speed 0-25mph 25-50 >50 

< 0 kW/tonne Bin 11 Bin 21 - 

0 to 3 Bin 12 Bin 22 - 

3 to 6 Bin 13 Bin 23 - 

6 to 9 Bin 14 Bin 24 - 

9 to 12 Bin 15 Bin 25 - 

12 and greater Bin 16 Bin 26 Bin 36 

6 to 12 - - Bin 35 

< 6 - - Bin 33 

37
Table 9-5. Operating Mode Bin Definitions for Running THC, CO, NOx 

Braking (Bin 0)

Idle (Bin 1) 

VSP \ Instantaneous Speed 0-25mph 25-50 >50 

< 0 kW/tonne Bin 11 Bin 21 

0 to 3 Bin 12 Bin 22 

3 to 6 Bin 13 Bin 23 

6 to 9 Bin 14 Bin 24 

9 to 12 Bin 15 Bin 25 

12 and greater Bin 16 

12 to 18 Bin 27 Bin 37 

18 to 24 Bin 28 Bin 38 

24 to 30 Bin 29 Bin 39 

30 and greater Bin 30 Bin 40 

6 to 12 Bin 35 

< 6 Bin 33 

The start exhaust process emissions of THC, CO, and NOx are distinguished into 

operating modes which represent the length of time the engine was off prior to starting as 

follows: 

Table 9-6. Operating Modes for Start Process – THC, CO, and NOx 

opModeID minSoakBound 

in minutes 

maxSoakBound 

in minutes 

101 null 6 

102 6 30 

103 30 60 

104 60 90 

105 90 120 

106 120 360 

107 360 720 

108 720 null 

The evaporative processes (fuel tank vapor venting, fuel permeation and liquid 

leaking) have three operating modes: “operating”, “hot soaking” and “cold soaking” 

where “hot soaking” is considered to be time (Source Hours) when the engine is not 

38
operating, but has not yet cooled to a point where it is near the temperature it would be if 

it had not been operating. 

The brake wear process divides its Source Hours Operating activity basis into 

periods where the vehicle brakes are being applied and all other operating time, during 

which no brake wear emissions are considered to occur. 

Other pollutant-processes are modeled without breakdown of their activity basis 

into more detailed operating modes. 

39
9.8. Modeling Vehicle Inspection/Maintenance Programs 

The approach to modeling the effect of vehicle inspection/maintenance (I/M) 

programs on emissions in MOVES has been simplified relative to that taken in 

MOBILE6. MOVES EmissionCalculators use only two kinds of data to estimate these 

effects: 

1. I/M Coverage Data: Information about what pollutant-processes are “covered” 

by I/M programs in various Counties and Calendar Years. This coverage information is 

allowed to vary by pollutant-process (only certain pollutant-processes are considered to 

be affected by any I/M program), county, year, fueltype (only gasoline-fueled vehicles 

are generally considered to be covered), regulatory class, and model year. This 

information is stored in the IMCoverage table in the MOVES database. The table also 

contains a single “I/M Adjustment Factor” value in each record. This may be considered 

to represent, in a single number, the degree of effectiveness of the I/M. A value of 1.0 

means that the I/M is fully effective. A value of 0.0 has the same effect as if there were 

no I/M Coverage (and so does not need to be stored). Because the I/M Coverage 

information is keyed to both Calendar Year and vehicle model year, the effect of 

programs not inspecting very new or very old vehicles can be taken into account. 

However, most of the other factors considered by MOBILE6 in estimating the 

effectiveness of particular vehicle inspection/maintenance programs, such as the 

frequency of vehicle inspections, the extent of technician training, etc. are not considered 

in MOVES except as they may contribute to the I/M Adjustment Factor values. MOVES 

includes, as one of its “pre-processing menu items” a graphical interface which can be

used to display and change the I/MCoverage information, including I/M Adjustment 

Factor values, relative to the current Run Specification. This is documented in the 

MOVES-HVI User Guide. 

2. Emission Rate Data: Two emission rates are stored in the emission rate tables 

in the MOVES database, one rate is used by EmissionCalculators when emission 

processes are not “covered” by an I/M program. The other “with I/M rate” is used when 

an emission process is “covered” by an I/M program with an I/M adjustment factor of 

1.0. For intermediate values of the I/M Adjustment Fractor an intermediate emission 

40
rate is used, e.g. a value halfway in between the two rates is used if the I/M adjustment 

factor is 0.5. Some emission calculators, e.g. the ones which calculate tire and brake 

wear particulate emissions, do not use the I/M Coverage Table or the “with I/M rate” 

information. Whether or not an EmissionCalculator considers I/M program effects is a 

function of the particular Emission Calculator. 

41
10. MOVES Functional Specifications 

This chapter explains the functions, including calculations, performed by each 

portion of the MOVES software, as shown in figure 8-1, or indicates where such 

information can be found. 

10.1. Graphical User Interface (GUI) / Run Specification Editor 

The MOVES Graphical User Interface (GUI) is used to produce and modify 

MOVES run specifications. Its functionality is described in detail in the MOVES-HVI 

User Guide. Components whose principal functionality is evident from the GUI, such as 

the I/M Coverage Table Editor, are also documented in the User Guide. 

10.2. Application Program Interface and Master Looping Mechanism 

This basic component manages the overall execution of a MOVES model run. It 

includes an application program interface (API) callable by either the command line 

interface, or the MOVES GUI. This component invokes, directly or indirectly, the Input 

Data Manager, any required Database Preaggregation, and, when performing a mesoscale 

table lookup run, the Lookup Table Link Producer. These components execute before the 

master looping mechanism is invoked. 

Once these components have run to completion, a master looping mechanism is 

executed. InternalControlStrategy, Generator, and EmissionCalculator objects have 

“signed up” with this MasterLoop to execute over portions of the modeling domain. (The 

modeling domain is defined by a RunSpec in terms of the emission processes, geographic 

locations and time periods being modeled.) 

If uncertainty estimation is being performed in the run, which involves running 

multiple iterations, the looping process manages these iterations. 

The MasterLooping mechanism uses a pool of control “threads” to bundle 

Emisson Calculator input data (and SQL scripts to be run on the data) for portions of the 

modeling domain and place them in the SharedWork directory. Another thread of control 

is established to unbundle the results placed in the SharedWork directory by MOVES 

Worker program(s). This thread also leads to the performance of the final result 

aggregation and units conversion functions. If a mesoscale table lookup run is being 

42
performed, an integrated post-processor is also invoked to create an additional table of 

emission rates in the output database. 

This software component is obviously rather complicated and consists of a 

number of Java classes. Programmer level documentation is required to understand this 

component in greater detail. 

10.3. Input Data Manager 

The InputDataManager generates the MOVESExecution database from the

MOVESDefault database, removing (or “filtering”) records where possible based on the 

needs of the run specification (RunSpec). The InputDataManager runs to completion 

before any InternalControlStrategy objects, Generators or Calculators begin the MOVES 

model calculations. The MOVES GUI and RunSpecs specify a list of “user input 

databases” to be used in addition to the default database to construct the 

MOVESExecution database. 

The InputDataManager filters input records based on the following RunSpec 

criteria: year, month, link, zone, county, state, pollutant, emission process, day, hour, day 

and hour combination, roadtype, pollutant-process combination, sourceusetype, fueltype, 

fuelsubtype, and monthgroup. This filtering is specified in a table-specific manner and 

need not be applied to every table having these key fields. Filtering is not performed on 

particular table columns where doing so would interfere with correct result calculation. 

(The exact table columns to filter are specified in the Java code for the InputDataManager 

class in the “tablesAndFilterColumns” array.) The reasons for not filtering a particular 

table by all possible criteria are documented with program source code comments. 

Input databases have the same table contents and structure as the MOVESDefault 

database, but need not contain all tables. If a table is present, however, it must contain all 

the table columns. Records from user input databases add to or replace records in the 

MOVESDefault database. If the same record (i.e. a record having the same values of all 

primary key fields but generally different non-key field values) is present in more than 

one input database, the record from the user input database listed last is the one which 

ends up in MOVESExecution. 

43
The InputDataManager addes a field to core model input tables in the 

MOVESExecution Database to indicate that the records came from a user input database 

so that Generators may avoid deleting such records.

MOVES verifies that all input tables present in user input databases contain the 

required columns. The MOVES GUI also checks that the same database is not specified 

for both input (either as the default input database or an additional input database) and for 

output, and ensures that MOVESExecution is not used as either an input or an output 

database. Otherwise, however, it remains the responsibility of the user to ensure that the 

ordered application of any additional input databases called for in the run specification to 

the MOVESDefault database results in a MOVESExecution database that is accurate, 

complete and consistent. 

10.4. Database Pre-Aggregation 

To improve execution run time performance, when geographic selections are 

made at the state or national level, MOVES “preaggregates” the MOVESExecution 

database so that each state selected, or the entire nation, appears in the database as if it 

were a single county. These geographic performance shortcuts are specified by the 

“STATE” and “NATION“ GeographicSelectionType values produced by the 

“Macroscale Geographic Selection” GUI screen and stored in MOVES run specifications. 

No database preaggregation is performed when geographic selections are made at the 

County level. County selections may still be used to produce results for broad 

geographic areas if the user can endure their execution time performance. Geographic 

preaggregation is not allowed for Mesoscale Lookup calculations. 

Options are also available to improve execution run time performance by 

“preaggregating” time periods in the MOVESExecution database. These options are 

specified by the “Time Aggregation Level” item in the MOVES GUI and MOVES 

RunSpec. This can assume the following values: 

HOUR - no time period aggregations are performed. This is required for 

evaporative emission calculations. 

DAY - combine all hours of the day 

44
MONTH - combine all portions of the week (though the default MOVES database 

may not divide the week into smaller portions). 

YEAR - combine months of the year 

All of these computational shortcuts (except COUNTY and HOUR) involve 

compromises to the accuracy of the results. 

The MOVES GUI adjusts the levels of geographic and time period detail 

specified for the output if necessary so that levels of output detail which can no longer be 

produced due to data preaggregation are not requested by the RunSpec. 

10.4.1. Sequence of the Database Pre-Aggregation Operations: 

After creation of the MOVESExecution database by the input data manager the 

geographic and time period preaggregation operations are performed as follows: 

a. If the GeographicSeletionType = NATION, the model creates an average county 

which represents the entire nation. To do this the MOVESExecution database is 

aggregated to a level where the nation consists of a single representative state and this 

“state” consists of a single “county”, and a single “zone”. For macroscale there is a 

single “link” for each road type in the RunSpec. 

b. If the GeographicSeletionType = STATE, then the MOVESExecutionDatabase is

aggregated to a level where each state selection in the RunSpec consists of a single 

“county” and a single “zone”. For macroscale there is a single “link” in each such 

state for each road type in the RunSpec. 

c. if the Time Aggregation Level value is DAY, MONTH, or YEAR, all data pertaining 

to the 24 separate hours of the day in the MOVESExecution database is aggregated 

into a single “pseudo-hour” representing the entire day. Time period preaggregation 

is not allowed if evaporative emissions are being estimated. 

d. if the Time Aggregation Level value is MONTH, or YEAR, all data pertaining to any 

day-based portions of the week in the MOVESExecution database is further 

aggregated into a single “pseudo-day” representing the entire week. If the Default 

MOVES Database divides the week into a 5 weekday portion and a 2 weekend day 

portion, MONTH or YEAR data preaggregation would remove this distinction. 

45
e. if the Time Aggregation Level value is YEAR, all data pertaining to the 12 separate 

months of the year in the MOVESExecution database are further aggregated into a 

single “pseudo-month” representing the entire year. 

f. Following any of the pre-aggregation operations performed in steps a. thru e., the set 

of ExecutionLocations used by the MasterLoop is recalculated based on the 

aggregated database. 

g. If the DAY, MONTH, or YEAR aggregations have been performed all information 

derived from the run specification used throughout the remainder of the run is made 

consistent with the aggregated time periods. 

These operations run to completion before any MOVES MasterLoopable objects 

(ControlStategy objects, Generators, and EmissionCalculators), are invoked. 

10.4.2. How the Pre-aggregated Results are Reported 

If either of the geographic computational shortcuts is taken, the output database 

produced does not contain any “real” county (or perhaps even “real” state) level detail, 

even though such detail is generally present in the MOVESDefault and user input 

databases. Instead, additional “pseudo” values of stateID, countyID, etc. appear in the 

output records when a geographic computational shortcut is taken. 

If any one of the time period calculation shortcuts is taken, there may be only 

single representative “hour”, “day” or “month” time periods for the MasterLoop to loop 

over, (though no MasterLoopable objects currently sign up below the Month level), and 

the output database produced may not contain any “real” hour, day, or month level detail, 

even though such detail will generally be present in the MOVESDefault and user input 

databases. Instead “pseudo” time period-identifying values will now be present in the 

MOVEExecution and MOVESOutput databases. 

10.4.3. Algorithms Used to Perform the NATION and STATE Pre-Aggregations 

Table 10-1 describes the database aggregation algorithms used on a table-by-table 

basis for the NATION and STATE cases. Tables not listed contain no geographic 

identifiers and are therefore not affected by these aggregations. While some of these 

table aggregations are simple summations, others are “activity-weighted”. For these 

activity-weighted summations to be performed entirely correctly, something approaching 

46
the full execution of the control strategies and generators would have to be performed 

which would defeat the purpose of the pre-aggregation. So, instead, these “activityweighted” aggregations involve compromise and simplification. Specifically, the activity 

weighting is based entirely upon “startAllocFactor” values in the Zone table. The 

variable startAllocFactor is the factor used within MOVES to allocate the total number of

starts from the national to the county / zone level. In the default MOVES database for 

MOVES-HVI this allocation is based on vehicle miles traveled (VMT), hence the use of 

startAllocFactor for the pre-aggregation weightings is in essence a VMT weighting. 

More details on startAllocFactor and its derivation can be found in the report 

“MOVES2004 Highway Vehicle Population and Activity Data”. 

Table 10-1. Database Aggregation Algorithms 

MOVES 

Database Table

GeographicSelectionType

= NATION

GeographicSelectionType

= STATE

State Single Record, stateID=0,

stateName=Nation, 

stateAbbr=US 

No action required. Already filtered by

stateID 

County Single Record, countyID = 0. 

stateID=0, countyName=Nation, 

altitude=L 

barometric pressure and GPAFract 

are activity-weighted. 

Single record per stateID, 

countyID=stateID*1000, 

countyName = stateName, 

altitude = L 

barometric pressure and GPAFract are 

activity-weighted. 

Zone Single Record, 

zoneID=0, countyID=0., 

startAllocFactor = 1.0 

idleAllocFactor = 1.0 

SHPAllocFactor = 1.0 

Single record per stateID, 

zoneID=stateID*10000, 

countyID= stateID*1000 

startAllocFactor = sum of old factors for 

state. 

Same for idleAllocFactor and 

SHPAllocFactor 

Link Single record for each roadTypeID 

in RunSpec. 

linkID=roadTypeID, 

countyID = 0.

zoneID = 0. 

linkLength = NULL 

linkVolume = NULL 

grade = weighted national average 

Single record for each stateID - roadTypeID 

in RunSpec. 

linkID= stateID * 100000 + roadTypeID, 

countyID = stateID*1000, 

zoneID = stateID*10000 

linkLength = NULL 

linkVolume = NULL 

grade = weighted state average 

CountyYear Single record for each yearID, 

countyID = 0

Single record per stateID - yearID 

combination. countyID = stateID*1000. 

47
ZoneMonthHour Single record for each monthIDhourID combination in old table. 

(These have been filtered.) 

Calculate activity-weighted national 

average temperature and relative 

humidity. 

heatIndex and specific humidity are 

recalculated by Met generator. 

Single record for each combination of new 

zoneID, month and hour. (These have been 

filtered.) 

Calculate activity-weighted state average

temperature and relative humidity. 

heatIndex and specific humidity are 

recalculated by Met generator. 

OpMode 

Distribution 

(contents would be from user input.) 

Aggregate to national level roadType 

linkIDs, weighting by activity. 

(contents would be from user input. ) 

Aggregate to state level roadType linkIDs, 

weighting by activity. 

ZoneRoadtype Single record for each roadTypeID. 

SHOAllocFactor = sum of old 

SHOAllocFactors 

Single record for each new zoneID, 

roadTypeID combination. SHOAllocFactor 

= sum of old SHOAllocFactors 

FuelSupply 

(Default values 

are considered.) 

Activity-weighted aggregation of all 

old counties to single new county. 

Since the fuel supply is in terms of 

fuel formulations, there may be 

many fuel formulations in the 

aggregate. 

Activity-weighted aggregation of all old 

counties in state to single new county. 

Since the fuel supply is in terms of fuel 

formulations, there may be many fuel 

formulations in the aggregate. 

IMCoverage The NATION is considered to have 

IMCoverage with unknown (NULL) 

inspection frequencies, activityweighted average IMAdjustFract 

values, and model year ranges which 

range from the earliest to the latest 

present at any location, for a given 

year, polProcess,fueltype and 

regclass. This is obviously an 

approximation. 

Each STATE is considered to have 

IMCoverage with unknown (NULL) 

inspection frequencies, activity-weighted 

average IMAdjustFract values, and model 

year ranges which range from the earliest to 

the latest present at any location in the state, 

for a given year, polProcess,fueltype and 

regclass. This is obviously an 

approximation. 

SHO (contents would be from user input.) 

Combine all links having same

roadtype. SHO and distance are 

simple summations. 

(contents would be from user input.) 

Combine all links within state having same 

roadtype. SHO and distance are simple

summations. 

SourceHours (contents would be from user input.) 

Combine all zones. starts field is a 

simple summation. 

(contents would be from user input.) 

Combine all zones within state. starts field 

is a simple summation. 

Starts (contents would be from user input.) 

Combine all zones. starts field is a 

simple summation. 

(contents would be from user input.) 

Combine all zones within state. starts field 

is a simple summation. 

Extended 

IdleHours 

(contents would be from user input.) 

Combine all zones. 

extendedIdleHours field is a simple 

summation. 

(contents would be from user input.) 

Combine all zones within state. 

extendedIdleHours field is a simple 

summation. 

48
SCCRoadType 

Distribution 

Combine all zones, 

SCCRoadTypeFractions are activityweighted. 

Combine all zones in state,

SCCRoadTypeFractions are activityweighted. 

AverageTank

Temperature

(contents would be from user input.) 

Combine all zones, 

averageTankTemperature values are 

activity-weighted. 

(contents would be from user input.) 

Combine all zones in state,

averageTankTemperature values are 

activity-weighted. 

SoakActivity 

Fraction 

(contents would be from user input.) 

Combine all zones, 

soakActivityFraction values are 

activity-weighted. 

(contents would be from user input.) 

Combine all zones in state,

soakActivityFraction values are activityweighted. 

ColdSoakTank 

Temperature

(contents would be from user input.) 

Combine all zones, 

coldSoakTankTemperature values 

are activity-weighted. 

(contents would be from user input.) 

Combine all zones in state,

coldSoakTankTemperature values are 

activity-weighted. 

ColdSoakInitial

HourFraction 

(contents would be from user input.) 

Combine all zones, 

coldSoakInitialHourFraction values 

are activity-weighted. 

(contents would be from user input.) 

Combine all zones in state,

coldSoakInitialHourFraction values are 

activity-weighted. 

AverageTank

Gasoline 

(contents would be from user input.) 

Combine all zones, ETOHVolume 

and RVP values are activityweighted. 

(contents would be from user input.) 

Combine all zones in state, ETOHVolume 

and RVP values are activity-weighted. 

10.4.4. Algorithms Used to Perform the Time Period Pre-Aggregations 

Table 10-2 describes the database aggregation algorithms used on a table-by-table 

basis for the DAY (Portion of the Week), MONTH, and YEAR time period preaggregations. These must operate correctly whether or not one of the STATE or 

NATION aggregations has been performed. The MONTH-level preaggregation assumes 

that the DAY level has been performed and the YEAR-level assumes that the MONTH 

level has been performed. Tables not listed contain no time period identifiers and are 

therefore not affected by these aggregations. 

While some of these table aggregations are simple summations, others are 

“activity-weighted”. All activity-based weighting is in essence based on VMT, using 

allocations of VMT at the level necessary for the desired aggregation. For these activityweighted summations to be performed entirely correctly, something approaching the full 

execution of the control strategies and generators would have to be performed which 

49
would defeat the purpose of the pre-aggregation. So instead these “activity-weighted” 

aggregations involve some compromise and simplification. Specifically, the activity 

weighting used for the DAY aggregation is based upon the values in the 

HourVMTFraction table; the weighting used for the MONTH aggregation is based upon 

the values in the DayVMTFraction table; and the activity weighting used for the YEAR 

aggregation is based upon the values in the MonthVMTFraction table. Because these 

activity fractions themselves depend upon other dimensions of the model, which do not 

always appear in the tables being aggregated, several variations of each aggregation are 

utilized, some of which are approximations: 

For aggregating hours into Days, three activity-weighting variations are used. 

(The third and fourth are approximations.) 

HourWeighting1: is based directly on the HourVMTFraction table itself, which is 

used to aggregate tables sharing its sourceTypeID, roadTypeID, and dayID primary 

keys. 

HourWeighting2: uses RoadTypeDistribution to aggregate HourVMTFraction over 

Roadtype. This is used to aggregate tables having sourceTypeID and dayID, but not 

roadTypeID. 

HourWeighting3: is a simple weighting by hourID used to aggregate tables sharing no 

keys with HourVMTFraction except hourID. It is produced from HourWeighting2 by 

using the data for the passenger car source type, and giving equal weight to all 

portions of the week. 

HourWeighting4: is produced from HourWeighting2 by using the data for the 

passenger car source type. This is used to aggregate tables sharing no keys with 

HourVMTFraction except dayID and hourID. 

For aggregating days (periods of the week) into Months, three activity-weighting 

variations are needed. The third is an approximation. 

50
DayWeighting1: is based on the DAYVMTFraction table, with MonthID removed by 

using weights from MonthVMTFraction. Its key fields are sourceTypeID, 

roadTypeID, and dayID. 

DayWeighting2: is based on DayWeighting1, with roadTypeID removed by using 

information from RoadTypeDistribution. Its key fields are sourceTypeID and dayID. 

DayWeighting3: is based on DayWeighting2, and uses the distribution for 

sourceTypeID = 21 for all sourceTypes. 

For aggregating months into years, only one activity-weighting is needed, and it is an 

approximation: 

MonthWeighting: based on MonthVMTFraction information for passenger cars only. 

The analogous technique is used to aggregate month groups into years. (Monthgroups 

are used in some MOVES Database tables and were intended to represent seasons of the 

year. As the MOVES default database is currently populated, however, monthgroups 

correspond exactly to months. 

51
Table 10-2. Description of Time Period Aggregations to Be Performed 

MOVES Database 

Table

Aggregation of Hours to 

DAY (Portion of the 

week)

Aggregation of Days 

(Portions of the week) to 

MONTH 

(assumes DAY 

aggregation.)

Aggregation of Months 

to YEAR 

(assumes MONTH 

aggregation.)

HourOfAnyDay Single Record, hourID=0, 

hourName = “Entire day”.

DayOfAnyWeek Single record. 

dayID=0. 

dayName = “Whole 

Week”; noOfRealDays=7 

HourDay Record for each dayID, 

hourDayID = dayID; 

hourID=0 

Single record. dayID=0. 

hourID=0. 

MonthOfAny

Year 

Single record. 

MonthID = 0

noOfDays = 365 

monthGroupID=0 

MonthGroup

OfAnyYear 

Single record. 

MonthGroupID=0 

monthGroupName = 

“Entire Year”.

HourVMT 

Fraction 

Record for each 

SourceType- RoadTypeDay combination. 

HourVMTFraction = 1.0 

Record for each 

SourceType- RoadType 

combination. 

HourVMTFraction = 1.0 

DayVMT 

Fraction 

Record for each 

SourceType-MonthRoadType combination. 

DayVMTFraction = 1.0 

Record for each 

SourceType-RoadType 

combination. 

DayVMTFraction = 1.0 

MonthVMT 

Fraction 

monthVMTFraction = 1.0

AvgSpeed 

Distribution 

Activity-weighted average 

avgSpeedFraction using 

HourWeighting1 

Activity-weighted 

average 

avgSpeedFraction using 

DayWeighting1 

52
OpMode 

Distribution 

(contents would be 

from user input.) 

Activity-weighted average 

opModeFraction using 

HourWeighting1 

Activity-weighted 

average opModeFraction 

using DayWeighting1

SourceType 

Hour 

Hour-level 

idleSHOFactors are 

summed 

Activity-weighted 

average idleSHOFactor 

using DayWeighting2

SHO 

(contents would be 

from user input.) 

Simple summation of SHO 

and distance 

Simple summation of 

SHO and distance 

Simple summation of 

SHO and distance 

SourceHours Simple summation of 

sourceHours 

Simple summation of 

sourceHours 

Simple summation of 

sourceHours 

Starts 

(contents would be 

from user input.) 

Simple summation of 

starts 

Simple summation of 

starts 

Simple summation of 

starts 

Extended 

IdleHours 

(contents would be 

from user input.) 

Simple summation of 

extendedIdleHours 

Simple summation of 

extendedIdleHours 

Simple summation of 

extendedIdleHours 

ZoneMonthHour Activity-weighted average 

temperature and 

relHumidity using 

HourWeighting3. 

MetGenerator will 

recalculate heatIndex and 

specific humidity. 

Activity-weighted 

average temperature and 

relHumidity using 

MonthWeighting. 

MetGenerator will 

recalculate heatIndex and 

specific humidity. 

MonthGroup

Hour 

Activity-weighted 

ACActivity terms using 

HourWeighting3. 

Activity-weighted 

ACActivity terms using 

MonthGroupWeighting. 

SampleVehicleTrip Set hourID = 0 for all trips Set dayID = 0 for all 

trips. Assumes vehIDs 

are unique across dayIDs. 

SampleVehicleDay Set dayID = 0 for all 

vehicle days. Assumes 

vehIDs are unique across 

dayIDs. 

StartsPerVehicle 

(contents would be 

from user input.) 

hourDayID = dayID 

Simple summation of 

startsPerVehicle 

hourDayID = 0. 

Simple summation of 

startsPerVehicle 

53
FuelSupply Activity-weighted 

marketshare using 

MonthGroupWeighting. 

(Note: default values 

produced by

DefaultDataMaker, must 

be considered.) 

AverageTank

Temperature 

(contents would be 

from user input.) 

Activity weighted 

averageTankTemperature 

using HourWeighting4. 

Activity weighted 

averageTankTemperature 

using DayWeighting3. 

Activity weighted 

averageTankTemperature 

using MonthWeighting 

SoakActivity 

Fraction 

(contents would be 

from user input.) 

Activity-weighted 

soakActivityFraction using 

HourWeighting2 

Activity weighted 

average 

soakActivityFraction 

using DayWeighting2. 

Activity weighted 

average 

soakActivityFraction 

using MonthWeighting 

10.4.5. Calculation Inaccuracies Introduced by the Database Pre-Aggregations: 

The simplified activity-weighted aggregations introduce the following 

approximations relative to having MOVES perform its calculations individually for each 

real county-location and for each hour of the day: 

- Start-based activity, while appropriate for the start process, represents an 

approximation for other processes whose activity basis (SHO, etc.) may not exactly 

correspond to start activity. 

- Direct user input to the CMIT tables may override the Zone.startAllocFactor values. 

Any effect on activity of direct user input to the CMIT tables is not taken into 

account. 

- Control strategies may eventually be added to MOVES which adjust activity levels.

Any such effects are not included. 

- The potentially significant non-linear relationships of the emissions calculations to 

temperature and humidity are ignored. This may be especially serious at the national 

level. 

- Activity weighted hourly averages are used when combining hourly temperature, 

humidity, AC activity information, and any user supplied average tank temperature 

values for the hours of the day, but differences in hourly activity levels between the 

54
passenger car source use type and other source use types are ignored in this 

calculation, as are differences in hourly activity levels by day of the week. 

- The distribution of passenger car VMT to the periods of the week is used for all 

source types when aggregating any user-supplied average tank temperature data to the 

month level. 

- Differences in monthly activity patterns between passenger cars and other source 

use types are ignored when calculating weighted average annual temperature, 

humidity, ACActivity, fuelSubtype marketshares, average fuel tank temperatures and 

soakactivityfractions. 

- When calculating annual data from monthly data, all years are considered to be nonleap years. 

An initial analysis of the sensitivity of MOVES results to levels of pre-aggregation was 

presented in the report “MOVES2004 Validation Results”. While MOVES2004 did 

produce different results depending on the level of aggregation selected by the user, the 

magnitude of difference for energy consumption did not appear to be very large. For 

example, the difference in total energy results between a run where state / month preaggregation was selected was about 2 percent higher than the same run where nation / 

year pre-aggregation was selected. 

55
10.5. Mesoscale Lookup Table Link Producer (LTLP) 

This component is invoked when executing runs which specify the “Mesoscale 

Lookup” Scale. It reconstructs the contents of the Link table and populates the 

LinkAverageSpeed table based on the contents of the AverageSpeedBin and Zone tables. 

It is invoked early during the run execution after the InputDataManager has constructed 

the MOVESExecution database. It simplifies this situation that geographic 

preaggregation is not allowed in conjunction with Mesoscale Lookup. Within the 

MOVES program code it is implemented within a component called the 

GeographicExecutionLocationProducer which produces the list of locations looped over 

by the Master Looping mechanism.

The current default “Link” table has a record for each combination of county and 

road type. The LTLP populates the Link table with unique links for every combination 

of averageSpeedBinID value in the AverageSpeedBin table, each zoneID in the RunSpec, 

and each roadTypeID in the RunSpec. 

a. The linkID is generated to be a unique value. (Current macroscale linkID * 100 + 

averageSpeedBinID.) 

b. The zoneID and roadTypeID fields are populated appropriately. 

c. The countyID field is populated based on the zoneID. 

d. The linkLength, linkVolume and grade fields are not used and are set to Null. 

The LTLP also populates the LinkAverageSpeed table with a single record for 

each of the new linkIDs. The average speed value used is the avgBinSpeed value from

the AverageSpeedBin table for the AvgSpeedBin represented by the Link. 

56
10.6. Total Activity Generator (TAG) for Macroscale 

This generator calculates total activity pursuant to the run specification for each 

source use type in MOVES-HVI using the MOVESExecution database. This activity

includes Start activity (number of starts), Extended Idle Hours, and Source Hours in 

addition to source hours operating (SHO). This activity information is categorized by 

time span, geographic location, source type and age. The product of the TAG is four core 

model input tables produced in MOVESExecution containing these results: SHO, Starts, 

ExtendedIdleHours, and SourceHours. The TAG also calculates an intermediate form of

distance traveled information which is stored in the SHO table. This version of the TAG 

is not used for the Mesoscale Lookup scale. 

The algorithm used to calculate total activity for a given time and location by 

source type and age is divided into ten steps (numbered 0 thru 9) referred to as TAGs 

(total activity generator steps) in this document. Each TAG step references the 

MOVESExecution database and implements a simple mathematical formula. The primary 

function of the TotalActivityGenerator is to convert commonly-available activity data

such as vehicle miles traveled (VMT), age distribution, vehicle populations, sales and 

VMT growth rates, etc. to the MOVES activity parameters of source hours, source hours 

operating, starts, and extended idle hours. Externally-provided VMT is thus the primary 

driver of total activity. Steps 1-3 calculate allocations of total VMT by vehicle age and 

source type. Step 4 grows VMT. Steps 5 and 6 allocate VMT by time, space, vehicle age 

and source type. Step 7 converts the allocated VMT to the MOVES activity parameters 

of source hours operating (SHO), number of starts, and extended idle hours. Step 8 

allocates activity to zones (e.g. counties for the default case), and Step 9 re-calculates 

distance for output reporting purposes. A brief description of each of the TAGs is shown 

in table 10-3. The HPMS acronym used in the table refers to the Highway Performance 

Management System. 

Table 10-3. Overview of TAG Calculations 

Step Description 

TAG-0 Determine the base year Determine the appropriate base year to use in 

growth calculations 

57
TAG-1 Calculate Base Year Vehicle 

Population 

Establish base-year vehicle population in

modeling domain by use type, age 

TAG-2 Grow Vehicle Population to Analysis 

Year 

If analysis year is in future, establish analysis 

year population through growth and scrappage 

2a Age 0

2b Age 1 through 29

2c Age 30 and higher

TAG-3 Calculate Analysis Year Travel 

Fraction 

Calculation travel fraction across domain as 

function of age mix and annual miles traveled, 

by use type and age 

3a Calculate total population within 

HPMS vehicle class

3b Calculate fraction within HPMS 

vehicle class

3c Compute travel fraction

TAG-4 Calculate Analysis Year VMT If analysis year is in future, establish analysis 

year aggregate VMT across domain from base 

year VMT and growth 

TAG-5 Allocate Analysis Year VMT By

Roadway Type, Use Type, Age 

Allocate aggregate VMT to roadway type, use 

type and age 

TAG-6 Allocate Annual VMT to Hour by

Roadway Type, Use Type, Age 

Allocate annual VMT to hourly VMT 

TAG-7 Convert to Total Activity Basis By

Process 

Convert to total activity basis at domain level: 

SHO, Starts, Extended Idle Hours, Source

Hours Parked (a portion of Source Hours) 

7a Calculate average speed 

7b Convert to SHO

7c Calculate Starts

7d Convert SHO to Exetended Idle Hours

7e Calculate Source Hours Parked (SHP)

TAG-8 Allocate Total Activity to Location Allocate total activity to locations using 

geographic allocation factors 

8a Allocate SHO to Links

8b Allocate Starts to Zones

8c Allocate Extended Idle Hours to Zones

8d Allocate SHP to Zones

8e Calculate Source Hours by Zone and 

Roadway

TAG-9 Calculate Distance Traveled Calculate SHO.distance from SHO and 

average speeds 

Some overall considerations when performing these calculations are: 

58
1. The TotalActivityGenerator signs up for the Master Loop at the Year level which 

means the calculations are performed individually for each year at each location (i.e. link) 

for each emission process requiring SHO, start, extended idle hour, or source hour 

activity information. 

2. The MOVES design allows the user to provide some or all of the values in core model 

input tables such as SHO, Starts, ExtendedIdleHours and SourceHours. The 

InputDataManager places any such user-supplied values in the MOVESExecution 

database before the TotalActivityGenerator is activated. The TotalActivityGenerator 

does not replace such user-supplied values. 

3. When the Total Activity Generator encounters a missing value when performing a 

calculation, the result of the calculation is considered as missing. Records for which the 

results are missing are not represented by a value of zero but are left out of the database. 

Detailed descriptions of the calculations in each TAG step follow. Each of the 

variables used in the TAG calculations either exists in the MOVESExecution database or 

is calculated by a previous TAG step. All of the database variables are described in the 

database documentation included in the database. The table in which each variable can 

be found is indicated in parentheses in the “Input Variables”portion of each TAG step 

description. 

10.6.1. TAG-0: Determine the Base Year 

Before any calculations can be done, the appropriate base year must be 

determined using the year of analysis and the isBaseYear information in the Year table. 

Input Variables: 

isBaseYear (Year) 

calendar year (from RunSpec)

Output Variable: 

baseYear 

Calculation:

yearID = calendar year 

IF isBaseYear(yearID) = "Y", then baseYear=yearID. 

ELSE 

59
baseYear = maximum value of yearID which is less than the calendar year and 

for which isBase(Year)= "Y”

10.6.2. TAG-1: Calculate Base Year Vehicle Population By Age. 

Input Variables: 

sourceTypePopulation (SourceTypeYear) 

ageFraction (SourceTypeAgeDistribution)

baseYear (from previous step) 

Output Variable: 

sourceTypeAgePopulation, (in new SourceTypeAgePopulation table)

Calculation:

yearID=baseYear 

sourceTypeAgePopulation (yearID, sourceTypeID, ageID) = 

sourceTypePopulation (yearID, sourceTypeID) * 

ageFraction (yearID, sourceTypeID, ageID) 

10.6.3. TAG-2: Grow Vehicle Population from Base Year to Analysis Year 

NOTE: This step is only required if the analysis year is in the future relative to the base 

year. For future projection, these TAG-2 steps are repeated in every year until the 

analysis year is reached.

TAG-2a: Age Zero (New Vehicles) 

This calculation applies only to ageID=0. 

Input Variables: 

sourceTypeAgePopulation, from previous step, 

for ageID=0 and yearID=yearID-1 

salesGrowthFactor (SourceTypeYear) 

migrationRate (for yearID and yearID-1) (SourceTypeYear) 

Output Variable: 

sourceTypeAgePopulation (for ageID=0 in current yearID) 

Calculation:

sourceTypeAgePopulation (yearID, sourceTypeID, ageID=0) = 

[sourceTypeAgePopulation (yearID-1, sourceTypeID, ageID=0) / 

migrationRate (yearID-1, sourceTypeID)] * 

salesGrowthFactor (yearID, sourceTypeID) * 

migrationRate (yearID, sourceTypeID) 

Note: the full equation would divide through by age=0 survival rate to derive new 

sales in previous years prior to scrappage, and multiply by the same term to account 

for scrappage in the first year. Since scrappage is the same in all years, they cancel 

each other out, and these terms are excluded from the equation. 

TAG-2b: Ages 1 through 29 

This calculation loops through AgeID=x, where x is 1 through 29. 

Input Variables: 

60
sourceTypeAgePopulation (for ageID=x and yearID=yearID-1) 

survivalRate (for AgeID=x) (SourceTypeAge) 

migrationRate (SourceTypeYear) 

Output Variable: 

sourceTypeAgePopulation (for ageID=1 through 29 in current yearID) 

Calculation:

sourceTypeAgePopulation (yearID, sourceTypeID, ageID=x) = 

sourceTypeAgePopulation (yearID-1, sourceTypeID, ageID=x-1) *

survivalRate (sourceTypeID, ageID=x-1) * 

migrationRate (yearID, sourceTypeID) 

TAG-2c: Age 30 

This calculation is for Age 30, which includes years 30 and higher. 

Input Variables: 

sourceTypeAgePopulation (for ageID=29 & 30 and yearID=yearID-1)

survivalRate (for ageID=29 & 30) (SourceTypeAge)

migrationRate (SourceTypeYear) 

Output Variable: 

sourceTypeAgePopulation (for ageID=30 in current yearID) 

Calculation:

sourceTypeAgePopulation (yearID, sourceTypeID, ageID=30) =

sourceTypeAgePopulation (yearID-1, sourceTypeID, ageID=29) *

survivalRate (sourceTypeID, ageID=29) * 

migrationRate (yearID, sourceTypeID) + 

sourceTypeAgePopulation (yearID-1, sourceTypeID, ageID=30) *

survivalRate (sourceTypeID, ageID=30) * 

migrationRate (yearID, sourceTypeID) 

10.6.4. TAG-3: Calculate Analysis Year Travel Fraction

TAG-3a: Calculate total population within Highway Performance Management System 

(HPMS) vehicle class. 

Input Variables: 

sourceTypePopulation (for each sourceTypeID within HPMSVtypeID) 

(SourceTypeYear) 

HPMSVtypeID (HPMSVtype) 

Output Variable: 

HPMSVtypePopulation

Calculation:

HPMSVTypePopulation (yearID, HPMSVtypeID) = 

Sum of [SourceTypeAgePopulation (yearID, sourceTypeID, ageID)] 

over all ageID,

for all sourceTypeID within each HPMSVtypeID. 

TAG-3b: Calculate fraction within HPMS vehicle class 

Input Variables: 

sourceTypeAgePopulation (from step 2) 

HPMSVtypePopulation (from previous step) 

61
Output Variable: 

fractionwithinHPMSVtype 

Calculation:

fractionwithinHPMSVtype (yearID, sourceTypeID, ageID) = 

sourceTypeAgePopulation (yearID, sourceTypeID, ageID) /

HPMSVTypePopulation (yearID, HPMSVtypeID, sourceTypeID) 

TAG-3c: Compute travel fraction 

Input Variables: 

fractionwithinHPMSVtype (from previous step) 

relativeMAR (SourceTypeAge) 

Output Variable: 

travelFraction 

Calculation:

travelFraction (yearID, sourceTypeID, ageID) = 

(fractionwithinHPMSVtype (yearID, sourceTypeID, ageID=x) *

relativeMAR (sourceTypeID, ageID=x)) / 

Sum of [fractionwithinHPMSVtype (yearID, sourceTypeID, ageID=x) * 

relativeMAR (sourceTypeID, ageID=x)] over all ageID and for all 

sourceTypeID within each HPMSVtype. 

10.6.5. TAG-4: Calculate Analysis Year VMT 

Determine the total VMT within each HPMS vehicle type, accounting for VMT 

growth. This calculation is repeated in every yearID until the analysis year is reached.

TAG-4a: Base year. 

In the base year, the analysisYearVMT is the same as the HPMSBaseYearVMT. 

Input Variables:

HPMSBaseYearVMT (yearID=BaseYear) (HPMSVtypeYear) 

Output Variable:

analysisYearVMT 

Calculation:

analysisYearVMT (yearID, HPMSVTypeID) = 

HPMSBaseYearVMT (yearID, HPMSVTypeID)

TAG-4b: All years following the base year. 

In the any years following the base year, the analysisYearVMT is calculated from the 

previous year's value for analysisYearVMT. 

Input Variables:

analysisYearVMT (yearID-1) 

VMTGrowthFactor (HPMSVtypeYear) 

Output Variable:

analysisYearVMT 

62
Calculation:

analysisYearVMT (yearID, HPMSVTypeID) = 

analysisYearVMT (yearID-1, HPMSVTypeID) * 

VMTGrowthFactor (yearID, HPMSVTypeID) 

10.6.6. TAG-5: Allocate Analysis Year VMT by Roadway Type, Use Type, Age

Input Variables: 

analysisYearVMT (from previous step) 

roadTypeVMTFraction (RoadTypeDistribution) 

travelFraction (from step 3) 

Output Variable: 

annualVMTbyAgeRoadway 

Calculation:

annualVMTbyAgeRoadway (yearID, roadTypeID, sourceTypeID, ageID) = 

analysisYearVMT (yearID, HPMSVTypeID) * 

roadTypeVMTFraction (roadTypeID, sourceTypeID) * 

travelFraction (yearID, sourceTypeID, ageID)

10.6.7. TAG-6: Allocate Annual VMT to Hour 

Input Variables: 

annualVMTbyAgeRoadway (from previous step) 

monthVMTFraction (MonthVMTFraction) 

dayVMTFraction (DayVMTFraction) 

hourVMTFraction (HourVMTFraction) 

noOfDays (MonthOfAnyYear) 

Output Variable: 

VMTbyAgeRoadwayHour

Calculation:

VMTbyAgeRoadwayHour (yearID, roadTypeID, sourceTypeID, ageID, 

monthID, dayID, hourID) = 

annualVMTbyAgeRoadway (yearID, roadTypeID, sourceTypeID, ageID) * 

monthVMTFraction (sourceTypeID, isLeapYear, monthID) * 

dayVMTFraction (roadTypeID, sourceTypeID, monthID, dayID) * 

hourVMTFraction (roadTypeID, sourceTypeID, dayID, hourID) 

/ (noOfDays/7)

10.6.8. TAG-7: Convert to Total Activity Basis 

Tag-7a: Compute average speed by roadway type 

Input Variables: 

avgBinSpeed (AvgSpeedBin) 

averageSpeedFraction (AverageSpeedDistribution)

Output Variable: 

averageSpeed

Calculation:

averageSpeed (roadTypeID, sourceTypeID, dayID, hourID) = 

Sum of [avgBinSpeed(avgSpeedBin) * 

63
averageSpeedFraction(roadTypeID, sourceTypeID, dayID, hourID, 

avgSpeedBin)] over all avgSpeedBin 

Tag-7b: Convert VMT to SHO 

Input Variables: 

VMTbyAgeRoadwayHour (from step 6) 

averageSpeed (from previous step) 

Output Variable: 

SHObyAgeRoadwayHour

Calculation:

SHObyAgeRoadwayHour (yearID, roadTypeID, sourceTypeID, ageID, 

monthID, dayID, hourID) = 

VMTbyAgeRoadwayHour(yearID, roadTypeID, sourceTypeID, ageID, 

monthID, dayID, hourID) /

averageSpeed (roadTypeID, sourceTypeID, dayID, hourID)

Tag-7c: Calculate Starts 

Preliminary Calculation 

For each combination of sourceTypeID, hourID, and dayID 

startsPerVehicle = (number of records in INNER JOIN of SampleVehicleDay 

and SampleVehicleTrip with non null keyOnTimes) 

/ 

(number of records in SampleVehicleDay) 

This calculation excludes “Marker Trips”. 

Input Variables: 

startsPerVehicle (sourceTypeID, hourID, dayID)

sourceTypeAgePopulation (yearID, sourceTypeID, ageID) (from step 2) 

Output Variable: 

startsByAgeHour 

Calculation:

startsByAgeHour (yearID, sourceTypeID, ageID, dayID, hourID) = 

sourceTypeAgePopulation (yearID, sourceTypeID, ageID) * 

startsPerVehicle (sourceTypeID, hourID, dayID)

64
Tag-7d: Convert SHO to Extended Idle Hours 

Input Variables: 

SHObyAgeRoadwayHour (from step 7b)

idleSHOFactor (SourceTypeHour) 

Output Variable: 

idleHoursbyAgeHour

Calculation:

idleHoursbyAgeHour (yearID, sourceTypeID, ageID, monthID, dayID, HourID) 

= 

(Sum over 24 hours and over all Roadtypes (SHObyAgeRoadwayHour(yearID, 

roadTypeID, sourceTypeID, ageID, monthID, dayID, hourID))) * 

idleSHOFactor(sourceType, dayID, hourID) 

Tag-7e: Calculate Source Hours Parked (SHP) 

Input Variables: 

SHObyAgeRoadwayHour (yearID, roadTypeID, sourceTypeID, ageID, 

monthID, dayID, hourID) (from step 7b)

sourceTypeAgePopulation (yearID, sourceTypeID, ageID) (from step 2) 

noOfRealDays (DayOfAnyWeek)

Output Variable: 

SHPbyAgeHour (yearID, sourceTypeID, ageID, monthID, dayID, hourID)

Calculation:

SHPbyAgeHour = sourceTypeAgePopulation * noOfRealDaysSum over roadtypes(SHObyAgeRoadwayHour) 

10.6.9. TAG-8: Allocate Total Activity to Location 

Tag-8a: Allocate SHO to Links 

Input Variables: 

SHOByAgeRoadwayHour (from step 7b)

SHOAllocationFactor (ZoneRoadwayType)

Output Variable: 

SHO (SHO)

This result populates the SHO field in SHO table. 

Calculation:

SHO(yearID, zoneID, roadTypeID, sourceTypeID, ageID, monthID, dayID, 

hourID) = 

SHOByAgeRoadwayHour(yearID, roadTypeID, sourceTypeID, ageID, 

monthID, dayID, hourID) * 

SHOAllocationFactor( zoneID, roadTypeID) 

Tag-8b: Allocate Starts to Zones 

Input Variables: 

startsByAgeHour (from step 7c) 

65
startAllocFactor (Zone) 

Output Variable: 

Starts (Starts) 

Result of TAG-8b populates “starts” field of Starts Table 

Calculation:

starts(yearID, zoneID, sourceTypeID, ageID, monthID, dayID, hourID) = 

startsByAgeHour(yearID, sourceTypeID, ageID, dayID, hourID) * 

startAllocFactor(zoneID)) 

Tag-8c: Allocate Extended Idle Hours to Zones 

Input Variables: 

idleHoursByAgeHour (from step 7d) 

idleAllocFactor (Zone) 

Output Variable: 

extendedIdleHours(ExtendedIdleHours)

Result of TAG-8c populates “extendedIdleHours” field of ExtendedIdleHours 

Table 

Calculation:

extendedIdleHours(yearID, zoneID, sourceTypeID, ageID, monthID, dayID,

hourID) = 

idleHoursByAgeHour(yearID, sourceTypeID, ageID, monthID, dayID, hourID) 

* idleAllocFactor(zoneID) 

Tag-8d: Allocate SHP to Zones 

Input Variables: 

SHPByAgeHour (from step 7e) 

SHPAllocFactor (Zone) 

Output Variable: 

SHP (in an intermediate table)

Calculation:

SHP(yearID, zoneID, sourceTypeID, ageID, monthID, dayID, hourID) = 

SHPByAgeHour(yearID, sourceTypeID, ageID, monthID, dayID, hourID) * 

SHPAllocFactor(yearID, zoneID) 

Tag-8e: Calculate Source Hours by Zone and Roadway 

Input Variables: 

SHP (from step 8d)

SHO (from step 8a) 

Output Variable: 

sourceHours(SourceHours) result of this step populates sourceHours field in 

SourceHours table 

Calculation:

sourceHours(yearID, zoneID, roadTypeID <> OffNetwork, sourceTypeID,

ageID, monthID, dayID, hourID) = SHO(yearID, zoneID, roadTypeID,

sourceTypeID, ageID, monthID, dayID, hourID) 

66
sourceHours(yearID, zoneID, roadTypeID = OffNetwork, sourceTypeID, ageID, 

monthID, dayID, hourID) = SHP(yearID, zoneID, sourceTypeID, ageID,

monthID, dayID, hourID) 

10.6.10. TAG-9: Calculate Distance Traveled Corresponding to Source Hours 

Operating 

If the “Distance Traveled” output is requested by the RunSpec, (which also 

implies that some pollutant has been selected for the Running process), the distance field 

in the SHO table is calculated. Otherwise this distance field is output by this generator as 

NULL. The method used to produce this distance information involves multiplying the 

number of source hours operating (SHO) by the average vehicle speed associated with 

them. These average speeds have been calculated in Step 7a.

Input Variables: 

SHO from step 8a

averageSpeed from step 7a 

Output Variable: 

distance (in SHO table) 

Calculation:

distance (yearID, monthID, linkID (zoneID with roadTypeID), hourID, dayID,

ageID, aourceTypeID ) = 

SHO((yearID, monthID, linkID (zoneID with roadTypeID), hourID, dayID, 

ageID, sourceTypeID ) * averageSpeed(roadTypeID, sourceTypeID, dayID,

hourID)

67
10.7. Total Activity Generator (TAG) for Mesoscale Lookup 

This version of the TAG is used for the Mesoscale Lookup scale and is a 

simplified version of the “Macroscale” TAG described in the preceding section. The 

TAG can be simplified for Mesoscale lookup calculations because only running activity 

is needed and because artificial VMT values can be used. Because emissions are 

reported in grams/mile or other “per distance” units, the absolute values of VMT and 

SHO don’t matter for this use case, but their proportional allocations among sourcetypes, 

ages, and time periods must be maintained. 

This generator calculates total activity pursuant to the run specification for each 

source use type in MOVES-HVI using the MOVESExecution database. This activity

includes Source Hours in addition to source hours operating (SHO). This activity 

information is categorized by time span, geographic location, source type and age. This 

TAG produces two core model input tables in MOVESExecution containing these 

results: SHO, and SourceHours. The TAG also calculates an intermediate form of

distance traveled information which is stored in the SHO table. 

Some overall considerations when performing these calculations are: 

1. The TotalActivityGenerator signs up for the Master Loop at the Year level which 

means the calculations are performed individually for each year at each location (i.e. link) 

for each emission process requiring SHO or source hour activity information. 

2. The MOVES design allows the user to provide some or all of the values in core model 

input tables such as SHO, and SourceHours. The InputDataManager places any such 

user-supplied values in the MOVESExecution database before the 

TotalActivityGenerator is activated. The TotalActivityGenerator does not replace such 

user-supplied values. 

3. When the Total Activity Generator encounters a missing value when performing a 

calculation, the result of the calculation is considered as missing. Records for which the 

results are missing are left out of the database. 

68
The steps for the Mesoscale Lookup TAG are summarized here and described in more 

detail below.

1) Travel fractions by Age & SourceType are determined using population growth 

and relative mileage accumulations.

2) Travel fractions are treated as VMT and allocated to specific months, days & 

hours using factors that vary by roadType & sourceType. 

3) SHO is set to equal the hourly VMT. The same SHO is used for each link of a 

roadtype. 

4) Source Hours are set equal to SHO. 

5) Distance is calculated from the SHO and the link speed. 

By way of general background information, a number of database fields that are 

important for the Macroscale TAG are not used in Mesoscale Lookup: 

HPMSBaseYearVMT 

VMTGrowthFactor 

roadTypeVMTFraction

averageSpeedFraction 

idleSHOFactor 

SHOAllocationFactor 

startAllocFactor 

idleAllocFactor 

Detailed descriptions of the calculations in each TAG step follow. Each of the 

variables used in the TAG calculations either exists in the MOVESExecution database or 

is calculated by a previous TAG step. All of the database variables are described in the 

database documentation included in the database. The table in which each variable can 

be found is indicated in parentheses in the “Input Variables” portion of each TAG step 

description. 

69
10.7.1. TAG-0: Determine the Base Year 

Before any calculations can be done, the appropriate base year must be 

determined using the year of analysis and the isBaseYear information in the Year table. 

Input Variables: 

isBaseYear (Year) 

calendar year (from RunSpec)

Output Variable: 

baseYear 

Calculation:

yearID = calendar year 

IF isBaseYear(yearID) = "Y", then baseYear=yearID. 

ELSE 

baseYear = maximum value of yearID which is less than the calendar year for 

which isBase(Year)= "Y” 

10.7.2. TAG-1: Calculate Base Year Vehicle Population By Age. 

Input Variables: 

sourceTypePopulation (SourceTypeYear) 

ageFraction (SourceTypeAgeDistribution)

baseYear (from previous step) 

Output Variable: 

sourceTypeAgePopulation, (in new SourceTypeAgePopulation table)

Calculation:

yearID=baseYear 

sourceTypeAgePopulation (yearID, sourceTypeID, ageID) = 

sourceTypePopulation (yearID, sourceTypeID) * 

ageFraction (yearID, sourceTypeID, ageID) 

10.7.3. TAG-2: Grow Vehicle Population from Base Year to Analysis Year 

NOTE: This step is only required if the analysis year is in the future relative to the base 

year. For future projection, these TAG-2 steps are repeated in every year until the 

analysis year is reached.

TAG-2a: Age Zero (New Vehicles) 

This calculation applies only to ageID=0. 

Input Variables: 

sourceTypeAgePopulation, from previous step, 

for ageID=0 and yearID=yearID-1 

salesGrowthFactor (SourceTypeYear) 

migrationRate (for yearID and yearID-1) (SourceTypeYear) 

70
Output Variable: 

sourceTypeAgePopulation (for ageID=0 in current yearID) 

Calculation:

sourceTypeAgePopulation (yearID, sourceTypeID, ageID=0) = 

[sourceTypeAgePopulation (yearID-1, sourceTypeID, ageID=0) / 

migrationRate (yearID-1, sourceTypeID)] * 

salesGrowthFactor (yearID, sourceTypeID) * 

migrationRate (yearID, sourceTypeID) 

Note: the full equation would divide through by age=0 survival rate to derive new 

sales in previous years prior to scrappage, and multiply by the same term to account 

for scrappage in the first year. Since scrappage is the same in all years, they cancel 

each other out, and these terms are excluded from the equation. 

TAG-2b: Ages 1 through 29 

This calculation loops through AgeID=x, where x is 1 through 29. 

Input Variables: 

sourceTypeAgePopulation (for ageID=x and yearID=yearID-1) 

survivalRate (for AgeID=x) (SourceTypeAge) 

migrationRate (SourceTypeYear) 

Output Variable: 

sourceTypeAgePopulation (for ageID=1 through 29 in current yearID) 

Calculation:

sourceTypeAgePopulation (yearID, sourceTypeID, ageID=x) = 

sourceTypeAgePopulation (yearID-1, sourceTypeID, ageID=x-1) *

survivalRate (sourceTypeID, ageID=x-1) * 

migrationRate (yearID, sourceTypeID) 

TAG-2c: Age 30 

This calculation is for Age 30, which includes years 30 and higher. 

Input Variables: 

sourceTypeAgePopulation (for ageID=29 & 30 and yearID=yearID-1)

survivalRate (for ageID=29 & 30) (SourceTypeAge)

migrationRate (SourceTypeYear) 

Output Variable: 

sourceTypeAgePopulation (for ageID=30 in current yearID) 

Calculation:

sourceTypeAgePopulation (yearID, sourceTypeID, ageID=30) =

sourceTypeAgePopulation (yearID-1, sourceTypeID, ageID=29) *

survivalRate (sourceTypeID, ageID=29) * 

migrationRate (yearID, sourceTypeID) + 

sourceTypeAgePopulation (yearID-1, sourceTypeID, ageID=30) *

survivalRate (sourceTypeID, ageID=30) * 

migrationRate (yearID, sourceTypeID) 

10.7.4. TAG-3: Calculate Analysis Year Travel Fraction

71
TAG-3a: Calculate total population within Highway Performance Management System 

(HPMS) vehicle class. 

Input Variables: 

sourceTypePopulation (for each sourceTypeID within HPMSVtypeID) 

(SourceTypeYear) 

HPMSVtypeID (HPMSVtype) 

Output Variable: 

HPMSVtypePopulation

Calculation:

HPMSVTypePopulation (yearID, HPMSVtypeID) = 

Sum of [SourceTypeAgePopulation (yearID, sourceTypeID, ageID)] 

over all ageID,

for all sourceTypeID within each HPMSVtypeID. 

TAG-3b: Calculate fraction within HPMS vehicle class 

Input Variables: 

sourceTypeAgePopulation (from step 2) 

HPMSVtypePopulation (from previous step) 

Output Variable: 

fractionwithinHPMSVtype 

Calculation:

fractionwithinHPMSVtype (yearID, sourceTypeID, ageID) = 

sourceTypeAgePopulation (yearID, sourceTypeID, ageID) /

HPMSVTypePopulation (yearID, HPMSVtypeID, sourceTypeID) 

TAG-3c: Compute travel fraction 

Input Variables: 

fractionwithinHPMSVtype (from previous step) 

relativeMAR (SourceTypeAge) 

Output Variable: 

travelFraction 

Calculation:

travelFraction (yearID, sourceTypeID, ageID) = 

(fractionwithinHPMSVtype (yearID, sourceTypeID, ageID=x) *

relativeMAR (sourceTypeID, ageID=x)) / 

Sum of [fractionwithinHPMSVtype (yearID, sourceTypeID, ageID=x) * 

relativeMAR (sourceTypeID, ageID=x)] over all ageID and for all 

sourceTypeID within each HPMSVtype. 

10.7.5. TAG-4: (reserved) 

10.7.6. TAG-5: Allocate Analysis Year VMT by Roadway Type, Use Type, Age

Because VMT is divided out at the end, real VMT is not needed and is removed from this 

calculation. However, the model does need the distribution of VMT among sourcetypes 

& ages. RoadType distinctions are needed for the next step. 

72
Input Variables: TravelFraction(yearID, sourceTypeID, ageID) 

Output Variable: AnnualVMTbyAgeRoadway

Calculation:

AnnualVMTby AgeRoadway(YearID, roadTypeID, sourceTypeID, AgeID) = 

TravelFraction(YearID, sourceTypeID, AgeID)

10.7.7. TAG-6: Temporally Allocate Annual VMT to Hour 

Input Variables: 

annualVMTbyAgeRoadway (from previous step) 

monthVMTFraction (MonthVMTFraction) 

dayVMTFraction (DayVMTFraction) 

hourVMTFraction (HourVMTFraction) 

noOfDays (MonthOfAnyYear) 

Output Variable: 

VMTbyAgeRoadwayHour

Calculation:

VMTbyAgeRoadwayHour (yearID, roadTypeID, sourceTypeID, ageID, 

monthID, dayID, hourID) = 

annualVMTbyAgeRoadway (yearID, roadTypeID, sourceTypeID, ageID) * 

monthVMTFraction (sourceTypeID, isLeapYear, monthID) * 

dayVMTFraction (roadTypeID, sourceTypeID, monthID, dayID) * 

hourVMTFraction (roadTypeID, sourceTypeID, dayID, hourID) 

/ (noOfDays/7)

10.7.8. TAG-7: Convert to Total Activity Basis 

Tag-7: Convert VMT to SHO 

Because “Distance” is calculated from SHO and is divided out in the end, the actual SHO 

doesn’t matter. But the proportional distribution of SHO among ages, sourcetypes and 

times must be preserved. This step sets SHO = VMT. 

Input Variables: 

VMTbyAgeRoadwayHour (from step 6) 

Output Variable: 

SHObyAgeRoadwayHour

Calculation:

SHObyAgeRoadwayHour (yearID, roadTypeID, sourceTypeID, ageID, 

monthID, dayID, hourID) = 

VMTbyAgeRoadwayHour(yearID, roadTypeID, sourceTypeID, ageID, 

monthID, dayID, hourID) 

73
10.7.9. TAG-8: Allocate Total Activity to Location 

Tag-8a: Allocate SHO to Links 

This step assigns SHO to multiple links of the same zone/roadtype. Because 

geographic aggregation is forbidden for Lookup Output, allocation to Zones can be 

uniform. Similarly, allocation to links is not important as long as the distribution among 

ages, sourcetypes & times is preserved. So we set SHO(link) = SHO(roadType). 

Input Variables: 

SHOByAgeRoadwayHour (from step 7)

Link(linkID, countyID, zoneID, roadTypeID) (Created by the LTLP) 

Output Variable: 

SHO (SHO)

This result populates the SHO field in SHO CMIT table. 

Calculation:

SHO(yearID, linkID, sourceTypeID, ageID, monthID, dayID, hourID) = 

SHOByAgeRoadwayHour(yearID, roadTypeID, sourceTypeID, ageID, 

monthID, dayID, hourID)

Tag-8b: Calculate Source Hours by Zone and Roadway 

Input Variables: 

SHO (from step 8a)

LinkAverageSpeed(linkID) 

Output Variable: 

sourceHours(SourceHours) result of this step populates sourceHours field in 

SourceHours table 

Calculation:

sourceHours(yearID, linkID, sourceTypeID, ageID, monthID, dayID, hourID) = 

SHO(yearID, linkID, sourceTypeID, ageID, monthID, dayID, hourID)

10.7.10. TAG-9: Calculate Distance Traveled Corresponding to Source Hours 

Operating 

The method used to produce this distance information involves multiplying the 

number of source hours operating (SHO) by the average vehicle speed associated with 

the Link. 

Input Variables: 

SHO from step 8a

averageSpeed from step 7a 

Output Variable: 

74
distance (in SHO table) 

Calculation:

distance (yearID, monthID, linkID (zoneID with roadTypeID), hourID, dayID,

ageID, aourceTypeID ) = 

SHO((yearID, monthID, linkID (zoneID with roadTypeID), hourID, dayID, 

ageID, sourceTypeID ) * averageSpeed(linkID) 

75
10.8. Running OperatingModeDistributionGenerator (OMDG) for 

Macroscale 

The OperatingModeDistributionGenerator is used for the running and brakewear 

emission processes and is only relevant for pollutant-processes which have multiple 

operating modes. For these pollutant-processes the OMDG calculates the distribution of 

operating modes for each source type on each roadway type modeled using data from the 

MOVESExecution database. The resulting distributions are added to the 

OperatingModeDistribution core model input table. This version of the OMDG is used at 

Macroscale.

The method used to generate these operating mode distributions in MOVES is a 

refinement of the method described in section 7.1.3 of the Draft Design and 

Implementation Plan for MOVES. The task of the OMDG is to produce operating mode 

distributions, in terms of a set of VSP-and-speed-range-based operating modes, for each 

combination of source type, road type, hour of the day, and day of the week using as 

input average speed distribution information for each such combination. Driving 

schedules representing typical operation at different average speeds for each source type 

operating on each road type play an intermediate role in translating average speed 

information into VSP distributions. Each average speed bin used in the input average 

speed distributions is represented by a pair of “bracketing” driving schedules one of 

which has a slightly higher average speed and one of which has a slightly lower average 

speed. VSP is calculated on a second by second basis for the source use type operating 

over these two schedules and the results are weighted appropriately to represent the 

average speed distribution. A full discussion of the operating mode definitions and the 

use of vehicle specific power (VSP) and driving schedules in MOVES is contained in a 

separate report, MOVES2004 Energy and Emissions Inputs, downloadable from the 

MOVES web site. 

This algorithm is divided into seven steps referred to as OMDGs (operating mode 

distribution generator steps) in this document. Most OMDGs reference the 

MOVESExecution database and all implement a simple mathematical formula. Steps 1-3 

take on-road driving schedules stored in the MOVESExecution database and determine 

76
the mix of these schedules to use based on the mix of average speeds and roadway types. 

These driving schedules may each consist of multiple “snippets” or sections of driving 

which are disconnected in time. Step 4 calculates VSP; Step 5 determines the operating 

mode bin (based on speed and VSP); and Steps 6 and 7 determine the overall mix of 

operating mode bins based on the mix of roadway types and average speed. 

A brief description of each of the eight OMDGs is shown in table 10-4:

Table 10-4. Overview of Calculation Steps 

Step Description 

OMDG-1 Determine bracketing drive schedules 

OMDG-2 Determine proportions for bracketing drive schedules 

OMDG-3 Determine distribution of drive schedules, including a sub-step to reflect 

separation of ramp and non-ramp freeway driving 

OMDG-4 Calculate second-by-second vehicle specific power (VSP) 

OMDG-5 Determine operating mode bin for each second 

OMDG-6 Calculate operating mode fractions for each drive schedule 

OMDG-7 Calculate overall operating mode fractions 

The Operating Mode Distribution Generator signs up for the Master Loop at the 

Year level which means that it executes for each year in the run specification for each 

Link location for the running emission process. 

The MOVES design allows the user to directly provide some or all of the 

operating mode distribution values in core model input tables such as 

OpModeDistribution. The InputDataManager places these user-supplied values in the 

MOVESExecution database OpModeDistribution table before the Operating Mode 

Distribution Generator is activated. The Operating Mode Distribution Generator does not 

replace any such user supplied values. 

When the Operating Mode Distribution Generator encounters a missing value 

when performing a calculation, the result of the calculation is considered as missing. 

Records for which the results are missing are not represented by a value of zero but are 

left out of the database. 

The detailed descriptions of the calculations in each OMDG step are as follows: 

Each of the variables used in the OMDG calculations either exists in the

77
MOVESExecution database or is calculated by a previous OMDG step. All of the 

MOVESExecution variables are described in the database documentation. 

10.8.1. OMDG-1: Determine bracketing drive schedules 

Each average speed bin lies between (is bracketed) by the average speeds of two 

drive schedules. This step determines which two drive schedules bracket the average 

speed bin and stores the identity and average speeds of the two bins. This is done for 

each source type, and roadway type for each average speed bin. 

Input Variables: 

AvgBinSpeed (avgSpeedBinID) from the AvgSpeedBin table. 

AverageSpeed(driveScheduleID) from the DriveSchedule table. 

Output Variables: 

BracketScheduleLo (sourceTypeID, roadTypeID, avgSpeedBinID)

LoScheduleSpeed (sourceTypeID, roadTypeID, avgSpeedBinID)

BracketScheduleHi (sourceTypeID, roadTypeID, avgSpeedBinID)

HiScheduleSpeed (sourceTypeID, roadTypeID, avgSpeedBinID)

Calculation:

For each sourceTypeID, roadTypeID, and avgSpeedBinID:

The output variables are determined using table DriveSchedule, where for each 

combination of sourceTypeID, roadTypeID, avgSpeedBinID,

bracketScheduleLo and bracketScheduleHi are determined as the drive 

schedules associated with the source type and road type with the next

lowest and next highest average speeds compared to the value of

avgBinSpeed. loScheduleSpeed and hiScheduleSpeed are the values of

averageSpeed for the bracket schedules. The DriveScheduleAssoc table

contains the information as to which driveScheduleID's are associated with 

which sourceTypeID's and which roadTypeID's. 

10.8.2. OMDG-2: Determine proportions for bracketing drive schedules 

This step determines the proportion of each of the bracketing drive schedules such 

that the combination of the average speeds of drive schedules equals the nominal average 

speed of each average speed bin. The results are then weighted by the fraction of all 

operating time that are represented by the time spent in that average speed bin. This is 

done for each source type, roadway type, day of week and hour of day. 

Input Variables: 

AvgBinSpeed (avgSpeedBinID) from the AvgSpeedBin table. 

AvgSpeedFraction (sourceTypeID, roadTypeID, hourDayID, avgSpeedBinID)

from the AvgSpeedDistribution table. 

with 

BracketScheduleLo (sourceTypeID, roadTypeID, avgSpeedBinID)

78
loScheduleSpeed (sourceTypeID, roadTypeID, avgSpeedBinID) 

bracketScheduleHi (sourceTypeID, roadTypeID, avgSpeedBinID)

hiScheduleSpeed (sourceTypeID, roadTypeID, avgSpeedBinID)

Output Variable: 

loScheduleFraction (sourceTypeID, roadTypeID, hourDayID, avgSpeedBinID) 

hiScheduleFraction (sourceTypeID, roadTypeID, hourDayID, avgSpeedBinID) 

Calculation:

For each sourceTypeID, roadTypeID, hourDayID and avgSpeedBinID: 

loScheduleFraction = 

( hiScheduleSpeed – avgBinSpeed) /

(hiScheduleSpeed – loScheduleSpeed) 

If bracketScheduleHi=bracketScheduleLo (meaning the average speeds of the

“Lo and “Hi” schedule is the same):

loScheduleFraction = 1 

hiScheduleFraction = (1 – loScheduleFraction)

Weight the results by the fraction of all speeds that are represented by that 

average speed bin. 

loScheduleFraction = loScheduleFraction * avgSpeedFraction 

hiScheduleFraction = hiScheduleFraction * avgSpeedFraction 

10.8.3. OMDG-3: Determine distribution of drive schedules 

This step includes a preliminary sub-step which accounts for the effect of ramp 

driving. The rampFraction field in the RoadType table indicates the fraction of time on 

each roadway type which is spent on ramps. The “isRamp” field in the 

DriveScheduleAssoc table determines whether a schedule is to be associated with ramp 

driving or with driving on roadways exclusive of ramps. The MOVESDefault database 

provided with the MOVES-HVI Demo Version has no ramp activity (zero ramp fraction). 

User attempting to modify the database in this area should keep in mind several 

data constraints: There must always be at least one driving schedule not indicated as a 

ramp which is associated with each combination of source type and roadway type in the 

DriveScheduleAssoc table. Then additionally, for every ramp fraction which is greater 

than zero in the RoadType table, there must be exactly one driving cycle which is 

indicated as a ramp for each source type using that roadtype. (Conversely Ramp 

fractions can be zero even if there is an associated ramp driving schedule; in this case the 

ramp schedule is simply not used.) 

OMDG-3a: Determine distribution of ramp schedules 

This step accounts for ramps, based on the input field RampFraction, contained in 

table RoadType. For any driving schedule which is associated with the source type and 

roadway type which has an IsRamp value of "Y", the ramp fraction is added into 

79
DriveScheduleFraction for that driving schedule. This is done for each source type, 

roadway type, day of week and hour of day. 

Input Variables: 

RampFraction(roadTypeID) 

driveScheduleID (sourceTypeID, roadTypeID, isRamp=Y) 

Output Variable: 

DriveScheduleFraction (sourceTypeID, roadTypeID, hourDayID, 

driveScheduleID) 

Calculation:

driveScheduleFraction = RampFraction(roadTypeID) 

OMDG-3b: Determine distribution of non-ramp schedules 

This calculation adjusts for the RampFraction on the given roadway. This step 

determines the distribution of drive schedules which represents the sum of all of the 

average speed bins. This is done for each source type, roadway type, day of week and 

hour of day for all driving schedules which are associated with the source type and 

roadway type which have an IsRamp value of "N". 

Input Variables: 

loScheduleFraction (sourceTypeID, roadTypeID, hourDayID, avgSpeedBinID) 

HiScheduleFraction (sourceTypeID, roadTypeID, hourDayID, AvgSpeedBinID)

RampFraction(roadTypeID)

driveScheduleID (sourceTypeID, roadTypeID, isRamp=N) 

Output Variable: 

DriveScheduleFraction (sourceTypeID, roadTypeID, hourDayID,)

Calculation:

For each sourceTypeID, roadTypeID, hourDayID and driveScheduleID:

driveScheduleFraction = 

[(Sum Of loScheduleFraction over all cases where bracketScheduleLo =

driveScheduleID) + (Sum Of hiScheduleFraction over all cases where 

BracketScheduleHi = 

driveScheduleID)] * (1-rampFraction) 

10.8.4. OMDG-4: Calculate second-by-second vehicle specific power (VSP) 

This step calculates the vehicle specific power (VSP) for each drive schedule for 

each source type. This is done for each source type, drive schedule and second. 

Input Variables: 

Speed (driveScheduleID, second) from the DriveScheduleSecond table. 

rollingTermA (sourceTypeID) from the SourceUseType table. 

rotatingTermB (sourceTypeID) from the SourceUseType table. 

dragTermC (sourceTypeID) from the SourceUseType table. 

sourceMass (sourceTypeID) from the SourceUseType table. 

80
Output Variable: 

VSP (sourceTypeID, driveScheduleID, second) 

Accel (sourceTypeID, driveScheduleID, second) 

Calculation:

For each sourceTypeID, driveScheduleID and second:

Preliminary Calculations: 

speed (meters/second) = speed (mph) * 0.447 m/s per mph.

accel (meters/second2)= speed (t) – speed (t-1), with speed in meters/second. 

VSP = 

[ rollingTermA*speed

+ rotatingTermB * speed2

+ dragTermC * speed3

+ sourceMass * speed * accel ] 

/ sourceMass

(speed in meters/second, accel in meters/second2

) 

10.8.5. OMDG-5: Determine operating mode bin for each second 

This step accounts for VSP, speed and accel. The VSP value for each second is 

compared to the upper and lower bounds for the operating mode bins and a bin ID is 

assigned to each second. This is done for each source type, drive schedule and second.

Input Variables: 

VSPLower(opModeID) from the OperatingMode table. 

VSPUpper(opModeID) from the OperatingMode table. 

SpeedLower(opModeID) from the OperatingMode table. 

SpeedUpper(opModeID) from the OperatingMode table. 

BrakeRate1Sec(opModeID) from the OperatingMode table.

BrakeRate3Sec(opModeID) from the OperatingMode table.

Speed (sourceTypeID, driveScheduleID, second) from DriveScheduleSecond 

with 

VSP (sourceTypeID, driveScheduleID, second) from OMDG-4

accel (sourceTypeID, driveScheduleID, second) from OMDG-4 

Output Variable:

opModeIDbySecond (sourceTypeID, driveScheduleID, second) 

Calculation:

For each sourceTypeID, driveScheduleID and second:

An opModeID is assigned for each second in each drive schedule based on 

where the VSP, speed and accel values in that second falls. VSP and speed

are compared against the VSP and speed bounds to determine to appropriate 

bins. Then the braking (ID=0) and idle bins (ID=1) should be assigned 

based on accel and speed, respectively. This sequence is important since 

there is overlap in the definitions between the non-braking/idle bins and the 

braking/idle bins. 

81
10.8.6. OMDG-6: Calculate operating mode fractions for each drive schedule 

Once all the seconds in each operating mode bin are known, the distribution of the 

bins is determined. The sum of the operating mode fractions sums to one for each source 

type and drive schedule combination. This is done for each source type and schedule.

Input Variables: 

opModeIDbySecond (sourceTypeID, driveScheduleID, second)

Output Variable: 

OpModeFractionbySchedule (sourceTypeID, driveScheduleID, opModeID) 

Calculation:

For each sourceTypeID, driveScheduleID and opModeID:

OpModeFractionbySchedule = 

(Number of Seconds in opModeID during DriveSchedule) /

(Total number of seconds in DriveSchedule)

10.8.7. OMDG-7: Calculate overall operating mode fractions 

This step calculates the overall operating mode fractions by weighting the 

operating mode fractions of each drive schedule by the drive schedule fractions. This is 

done for each source type, road type, day of the week, hour, and operating mode. 

Input Variables: 

OpModeFractionbySchedule (sourceTypeID, driveScheduleID, opModeID) 

DriveScheduleFraction (sourceTypeID, roadTypeID, hourDayID, 

driveScheduleID) 

Output Variable: 

OpModeFraction (sourceTypeID, roadTypeID, hourDayID, polProcessID,

opModeID) 

Calculation:

For each sourceTypeID, roadTypeID, hourDayID and opModeID: 

OpModeFraction = 

Sum of OpModeFractionbySchedule*DriveScheduleFraction over all 

DriveSchedules 

The Results of OMDG-7 populate the OpModeDistribution table of the Execution Location 

Database. 

The opModeFraction in the OpModeDistribution table is: 

opModeFraction (sourceTypeID, linkID, hourDayID, polProcessID, 

opModeID) 

The value of linkID needed for this table is determined from roadTypeID and 

zoneID. 

82
10.9. Running OperatingModeDistributionGenerator (OMDG) for 

Mesoscale Lookup 

The OperatingModeDistributionGenerator is used for the running, and brakewear 

emission processes and is only relevant for pollutant-processes which have multiple 

operating modes. For these pollutant-processes the OMDG calculates the distribution of 

operating modes for each source type on each roadway type modeled using data from the 

MOVESExecution database. The resulting distributions are added to the 

OperatingModeDistribution core model input table. This version of the OMDG is used 

for Mesoscale Lookup and takes advantage of the duplication of LinkAverageSpeeds 

produced by the LookupTableLinkProducer. Some calculations that are done at the 

roadtype level for Macroscale must be done at the link level for Mesoscale Lookup. 

The method used to generate these operating mode distributions in MOVES is a 

refinement of the method described in section 7.1.3 of the Draft Design and 

Implementation Plan for MOVES. The task of the OMDG is to produce operating mode 

distributions, in terms of a set of VSP-and-speed-range-based operating modes, for each 

combination of source type, link, hour of the day, and period of the week using as input 

average speed information for each link. Driving schedules representing typical 

operation at different average speeds for each source type operating on each road type 

play an intermediate role in translating average speed information into VSP distributions. 

Each average speed bin used as a link average speed is represented by a pair of 

“bracketing” driving schedules one of which has a slightly higher average speed and one 

of which has a slightly lower average speed. VSP is calculated on a second by second 

basis for the source use type operating over these two schedules and the results are 

weighted appropriately to represent the link average speed. A full discussion of the 

operating mode definitions and the use of vehicle specific power (VSP) and driving 

schedules in MOVES is contained in a separate report, MOVES2004 Energy and 

Emissions Inputs, downloadable from the MOVES web site. 

This algorithm is divided into seven steps referred to as OMDGs (operating mode 

distribution generator steps) in this document. Most OMDGs reference the 

MOVESExecution database and all implement a simple mathematical formula. Steps 1-3 

83
take snippets of actual on-road driving schedules stored in the MOVESExecution 

database, and determine the mix of these schedules to use based on the mix of average 

speeds and roadway types; Step 4 calculates VSP, Step 5 determines the operating mode 

bin (based on speed and VSP), and Steps 6 and 7 determine the overall mix of operating 

mode bins based on the mix of roadway types and average speed. Each OMDG 

calculation step is also described table 10-4 in the immediately prior chapter. 

The Operating Mode Distribution Generator signs up for the Master Loop at the 

Year level which means that it executes for each year in the run specification for each 

Link location for the running emission process. 

The MOVES design allows the user to directly provide some or all of the 

operating mode distribution values in core model input tables such as 

OpModeDistribution. The InputDataManager places these user-supplied values in the 

MOVESExecution database OpModeDistribution table before the Operating Mode 

Distribution Generator is activated. The Operating Mode Distribution Generator does not 

replace any such user supplied values. 

When the Operating Mode Distribution Generator encounters a missing value 

when performing a calculation, the result of the calculation is considered as missing. 

Records for which the results are missing are not represented by a value of zero but are 

left out of the database. 

The detailed descriptions of the calculations in each OMDG step are as follows: 

Each of the variables used in the OMDG calculations either exists in the

MOVESExecution database or is calculated by a previous OMDG step. The 

MOVESExecution variables are described in the database documentation. 

10.9.1. OMDG-1: Determine bracketing drive schedules 

Each average speed bin lies between (is bracketed) by the average speeds of two 

drive schedules. This step determines which two drive schedules bracket the average 

speed bin and stores the identity and average speeds of the two bins. This is done for 

each source type, and roadway type for each average speed bin. 

Input Variables: 

AvgBinSpeed (AvgSpeedBinID) from the AvgSpeedBin table. 

84
AverageSpeed(driveScheduleID) from the DriveSchedule table. 

Output Variables: 

BracketScheduleLo (sourceTypeID, roadTypeID, AvgSpeedBinID)

LoScheduleSpeed (sourceTypeID, roadTypeID, AvgSpeedBinID)

BracketScheduleHi (sourceTypeID, roadTypeID, AvgSpeedBinID)

HiScheduleSpeed (sourceTypeID, roadTypeID, AvgSpeedBinID)

Calculation:

For each sourceTypeID, roadTypeID, and AvgSpeedBinID:

The output variables are determined using table DriveSchedule, where for each 

combination of sourceTypeID, roadTypeID, AvgSpeedBinID,

BracketScheduleLo and BracketScheduleHi are determined as the drive 

schedules associated with the source type and road type with the next

lowest and next highest average speeds compared to the value of

AvgBinSpeed. LoScheduleSpeed and HiScheduleSpeed are the values of

AverageSpeed for the bracket schedules. The DriveScheduleAssoc table 

contains the information as to which driveScheduleID's are associated with 

which sourceTypeID's and which roadTypeID's. 

10.9.2. OMDG-2: Determine proportions for bracketing drive schedules 

This step determines the proportion of each of the bracketing drive schedules such 

that the combination of the average speeds of drive schedules equals the average speed of 

the average speed bin. This calculation also takes advantage of the fact that the LTLP 

only uses the speeds in the AvgSpeedBin table. 

Input Variables: 

AvgBinSpeed (avgSpeedBinID) from the AvgSpeedBin table. 

with 

BracketScheduleLo (sourceTypeID, roadTypeID, avgSpeedBinID)

LoScheduleSpeed (sourceTypeID, roadTypeID, avgSpeedBinID)

BracketScheduleHi (sourceTypeID, roadTypeID, avgSpeedBinID)

HiScheduleSpeed (sourceTypeID, roadTypeID, avgSpeedBinID) 

Output Variable: 

LoScheduleFraction (sourceTypeID, roadTypeID, avgSpeedBinID)

HiScheduleFraction (sourceTypeID, roadTypeID, avgSpeedBinID)

Calculation:

For each sourceTypeID, hourDayID and avgSpeedBinID:

IF (BracketScheduleLo=BracketScheduleHi)

 loScheduleFraction=1.0 

ELSE 

loScheduleFraction = 

( hiScheduleSpeed – avgBinSpeed) /

(hiScheduleSpeed – loScheduleSpeed) 

hiScheduleFraction = (1 – loScheduleFraction)

85
10.9.3. OMDG-3: Determine distribution of drive schedules 

This step includes a preliminary sub-step which accounts for the effect of ramp 

driving. The rampFraction field in the RoadType table indicates the fraction of time on 

each roadway type which is spent on ramps. The “isRamp” field in the 

DriveScheduleAssoc table determines whether a schedule is to be associated with ramp 

driving or with driving on roadways exclusive of ramps. The MOVESDefault database 

provided with the Demonstration version of MOVES-HVI has no ramp activity 

(rampFraction = 0.0). 

Users attempting to modify the database in this area should keep in mind several 

data constraints: There must always be at least one driving schedule not indicated as a 

ramp which is associated with each combination of source type and roadway type in the 

DriveScheduleAssoc table. Additionally, for every ramp fraction which is greater than 

zero in the RoadType table, there must be exactly one driving cycle which is indicated as 

a ramp for each source type using that roadtype. (Conversely Ramp fractions can be zero 

even if there is an associated ramp driving schedule; in this case the ramp schedule is 

simply not used.) 

At Macroscale, the distribution of ramp and non-ramp schedules is determined for 

each roadtype; at Mesoscale Lookup, although the ramp fraction is assigned to all links of 

a given roadtype, the calculation must be done for each link.

OMDG-3a: Determine distribution of ramp schedules 

This step is accounts for freeway and interstate ramps, based on the input field 

RampFraction, contained in table RoadType. 

Input Variables: 

RampFraction(roadTypeID) 

driveScheduleID (sourceTypeID, roadTypeID, isRamp=Y) 

Output Variable: 

DriveScheduleFraction (sourceTypeID, hourDayID, driveScheduleID) 

Calculation:

driveScheduleFraction = rampFraction(roadTypeID)

OMDG-3b: Determine distribution of non-ramp schedules 

This calculation adjusts for the RampFraction on the given roadway. This step 

determines the distribution of drive schedules which represents the average speed bin for 

86
the links. Since the LTLP assigns only the averageSpeeds in the AvgSpeedBin table, this 

is simpler than for Macroscale. 

Input Variables: 

LoScheduleFraction (sourceTypeID, roadTypeID, hourDayID, avgSpeedBinID) 

HiScheduleFraction (sourceTypeID, roadTypeID, hourDayID, avgSpeedBinID) 

RampFraction(roadTypeID)

driveScheduleID (sourceTypeID, roadTypeID, isRamp=N) 

Output Variable: 

DriveScheduleFraction (sourceTypeID, avgSpeedBinID, driveScheduleID) 

Calculation:

For each sourceTypeID, avgSpeedBinID, and driveScheduleID:

driveScheduleFraction = 

[loScheduleFraction (if bracketScheduleLo = driveScheduleID) +

hiScheduleFraction (if bracketScheduleHi = driveScheduleID)] * (1-

RampFraction)

10.9.4. OMDG-4: Calculate second-by-second vehicle specific power (VSP) 

This step calculates the vehicle specific power (VSP) for each drive schedule for 

each source type. This is done for each source type, drive schedule and second. 

Input Variables: 

speed (driveScheduleID, second) from the DriveScheduleSecond table. 

rollingTermA (sourceTypeID) from the SourceUseType table. 

rotatingTermB (sourceTypeID) from the SourceUseType table. 

dragTermC (sourceTypeID) from the SourceUseType table. 

sourceMass (sourceTypeID) from the SourceUseType table. 

Output Variable: 

VSP (sourceTypeID, driveScheduleID, second) 

accel (sourceTypeID, driveScheduleID, second) 

Calculation:

For each sourceTypeID, driveScheduleID and second:

Preliminary Calculations: 

speed (meters/second) = speed (mph) * 0.447 m/s per mph.

accel (meters/second2)= speed (t) – speed (t-1), with speed in meters/second. 

VSP = 

[ rollingTermA*speed

+ rotatingTermB * speed2

+ dragTermC * speed3

+ sourceMass * speed * accel ] 

/ sourceMass

(speed in meters/second, accel in meters/second2

) 

87
10.9.5. OMDG-5: Determine operating mode bin for each second 

This step accounts for VSP, speed and accel. The VSP value for each second is 

compared to the upper and lower bounds for the operating mode bins and a bin ID is 

assigned to each second. This is done for each source type, drive schedule and second.

Input Variables: 

VSPLower(opModeID) from the OperatingMode table. 

VSPUpper(opModeID) from the OperatingMode table. 

speedLower(opModeID) from the OperatingMode table. 

speedUpper(opModeID) from the OperatingMode table. 

brakeRate1Sec(opModeID) from the OperatingMode table.

brakeRate3Sec(opModeID) from the OperatingMode table.

speed (sourceTypeID, driveScheduleID, second) from DriveScheduleSecond 

with 

VSP (sourceTypeID, driveScheduleID, Second) from OMDG-4

accel (sourceTypeID, driveScheduleID, Second) from OMDG-4 

Output Variable:

opModeIDbySecond (sourceTypeID, driveScheduleID, second) 

Calculation:

For each sourceTypeID, driveScheduleID and second:

An opModeID is assigned for each second in each drive schedule based on 

where the VSP, speed and accel values in that second falls. VSP and speed

are compared against the VSP and speed bounds to determine to appropriate 

bins. Then the braking (ID=0) and idle bins (ID=1) should be assigned 

based on accel and speed, respectively. This sequence is important since 

there is overlap in the definitions between the non-braking/idle bins and the 

braking/idle bins. 

10.9.6. OMDG-6: Calculate operating mode fractions for each drive schedule 

Once all the seconds in each operating mode bin are known, the distribution of the 

bins can be determined. The sum of the operating mode fractions sums to one for each 

source type and drive schedule combination. This is done for each source type and drive 

schedule. 

Input Variables: 

opModeIDbySecond (sourceTypeID, driveScheduleID, second)

Output Variable: 

OpModeFractionbySchedule (sourceTypeID, driveScheduleID, opModeID) 

Calculation:

For each sourceTypeID, driveScheduleID and opModeID:

opModeFractionbySchedule = 

(Number of seconds in opModeID during driveSchedule) / 

(Total number of seconds in driveSchedule)

88
10.9.7. OMDG-7: Calculate overall operating mode fractions 

This step calculates the overall operating mode fractions by weighting the 

operating mode fractions of each drive schedule by the drive schedule fractions. This is 

done for each source type, link, day of the week, hour of the day and operating mode. 

The opmodeFractions created should vary only by sourceType, roadType, and link speed. 

They should be the same for each zone, day, and hour. 

Input Variables: 

OpModeFractionbySchedule (sourceTypeID, driveScheduleID, opModeID) 

DriveScheduleFraction (sourceTypeID, roadTypeID, avgtSpeedBinID, 

driveScheduleID) 

Link(linkID, countyID, zoneID, roadTypeID) 

LinkAverageSpeed(linkID, hourDayID, sourceTypeID)

Output Variable: 

OpModeFraction (sourceTypeID, linkID, hourDayID, polProcessID,

opModeID) 

Calculation:

For each sourceTypeID, linkID, hourDayID and opModeID: 

opModeFraction = 

Sum of OpModeFractionbySchedule*DriveScheduleFraction over all 

DriveSchedules where the roadTypeID of the Link equals the roadTypeID

of the driveScheduleFraction and the averageSpeed of the Link equals the 

averageSpeed of the avgSpeedBinID. 

The Results of OMDG-7 populate the OpModeDistribution table of the Execution Location 

Database. 

The OpModeFraction in the OpModeDistribution table is: 

OpModeFraction (sourceTypeID, linkID, hourDayID, polProcessID, 

opModeID) 

89
10.10. Source Bin Distribution Generator (SBDG) 

The Source Bin Distribution Generator produces the distribution of source bins by 

source type and model year. This information provides the mapping between the activity 

elements of MOVES (total activity and operating modes), which are based on source use 

type, and the emission rates, which are based on source bin. The SBDG takes as input 

fleet distributions of source bin categories (e.g. weight class, engine size, fuel type etc.) 

by model year. 

Data about the characteristics of the existing and projected vehicle fleet are stored 

in several of the tables within the MOVESExecution database as shown in table 10-5. 

The Source Bin Distribution Generator uses information in the first seven of these tables 

to populate the last two: SourceBin and SourceBinDistribution which are core model 

input tables. 

Table 10-5. Tables used by SourceBinGenerator 

Table Name Key Fields Additional Fields Notes

SourceTypePolProcess sourceTypeID 

polProcessID

isSizeWeightReqd 

isRegClassReqd 

isMYGroupReqd 

Indicates which 

pollutant-processes the 

source bin distributions 

may be applied to and 

indicates which 

discriminators are 

relevant for each 

sourceType and 

polProcess 

FuelEngFraction sourceTypeModelYearID 

fuelTypeID 

engTechID 

fuelEngFraction Joint distribution of 

vehicles with a given 

fuel type and engine 

technology. Sums to 

one for each sourceType 

& modelYear 

SizeWeightFraction sourceTypeModelYearID 

fuelTypeID 

engTechID 

weightClassID 

engSizeID 

sizeWeightFraction Joint distribution of 

engine size and weight. 

Sums to one for each 

sourceType, modelYear 

and fuel/engtech 

combination. 

90
RegClassFraction sourceTypeModelYearID 

fuelTypeID 

engTechID 

regClassID 

regClassFraction Fraction of vehicles in a 

regulatory class. Sums 

to one for each 

sourceType, modelYear 

and fuel/engtech 

combination. 

PollutantProcessModel

Year 

polProcessID

modelYearID 

modelYearGroupID Defines model year 

groups. 

ModelYearGroup modelYearGroupID shortModYrGroupID 

modelYearGroupName 

Defines short model 

year group Ids. 

SourceTypeModelYear sourceTypeModelYearID modelYearGroupID 

modelYearID 

sourceTypeID 

Decodes ID field into 

modelYearID and 

sourceTypeID 

SourceBin SourceBinID engSizeID 

fuelTypeID 

engTechID 

regClassID 

modelYearGroupID 

weightClassID 

List of sourceBins 

SourceBinDistribution SourceTypeModelYearID 

polProcessID

sourceBinID

sourceBinActivityFract

ion 

Stores source bin 

distributions. 

The SourceBinGenerator uses information from the run specification to determine 

which sourcetypes, modelyears, fuel-types, pollutants and processes are relevant, and 

limits the Generator action to the relevant sources. 

 “Source bin discriminators” refer to characteristics that are used to distinguish the 

source bins. The MOVES source bin discriminators are: 

fuelType* 

modelYearGroup 

engTech* 

regClass 

engSize* 

weight Class* 

 (* fuelType and engTech are distinct but highly correlated, and, thus, handled

together; similarly engSize and weightClass are handled together) 

a. Because it would be awkward to have all these separate fields in each database table 

related to source bins, this information is combined into a single unique BIGINT 

91
identifier 1ffttrryysssswwww00, where the digits represent the bin discriminators as 

follows: 

Leading 1 (1) 

Fuel (ff) 

EngineTech (tt)

Regulatory Class (rr)

Model Year Group (yy)

Engine Size (ssss) 

Engine Weight (wwww)

Extra zeros (00) 

With the exception of the ModelYear group, each bin discriminator is coded as

for the discriminator ID (see the database attribute table), with leading zeros 

added as needed. ModelYear group is coded using the 

shortModYrGroupID as defined in the database table ModelYearGroup.

The ordering of the subfields within this identifier is essentially arbitrary. The 

SourceBin table contains both the individual fields and the combined source bin identifier 

and can be used to “decode” the combined identier values. 

b. The SourceTypePolProcess table identifies which discriminators are relevant for each 

source type and pollutant/emission process (polProcess). If a discriminator is not 

relevant for a given source type & polProcess, the discriminator ID is set to 0 (which 

means that the discriminator value doesn’t matter) and the fraction of vehicles to 

which this value of this discriminator applies is set to 1 for all model years. 

c. The SourceBinGenerator “signs up” with the MOVES MasterLoop at the PolProcess 

level which means it executes only once for each relevant process (running exhaust, 

start exhaust, and extended idle exhaust). 

d. For each RunSpec-required source type, polProcess, fuel type and model year (as 

implied by the selected year and the largest valid ageID), and for each 

relevant/existing combination of sourcebin discriminators (as determined by the input 

tables), the sourceBinActivityFraction is calculated as follows: 

sourceBinActivityFraction = fuelEngFraction *regClassFraction 

*sizeWeightFraction

e. The SourceBinDistribution table lists the sourceBinActivityFractions for each 

sourceBin, sourceType, modelYear and polProcess. The set of such records for a 

given sourceType, modelyear, and polProcess constitute a source bin distribution 

which sums to unity. 

92
f. The SourceBin table provides a list of unique source bins that have a 

SourceBinActivityFraction > 0 in at least one source bin distribution. The SBDG adds 

sourceBinID records to this table if necessary, but does not duplicate records already 

present. 

g. If data is not available for all the model years implied by the calendar year in the run 

specification, source bin distributions for the missing years prior to the first populated 

for the same sourceType and polProcess are generated which are equal to the 

distribution from that first populated model year. Source bin distributions are also 

generated for missing model years after the last populated for the same sourceType 

and polProcess which are equal to the distribution from that last populated model 

year. Years extrapolated are only those earlier than the earliest model year for which 

data is provided or later than the latest model year for which data is provided. 

h. If any data is already present in the CMIT SourceBinDistribution table for a 

combination of sourceType and polProcess, which would mean that the user had 

entered this information directly, this Generator does not produce 

SourceBinDistribution output for that combination. 

The approach to performing the calculation steps implied by these specifications 

is shown in table 10-6: 

93
Table 10-6. SourceBin Generator Calculation Steps 

Step/Query Description

1 populate sb_fractions Select data from the SourcBinGenerator tables to fill a temporary table 

with identifying and distribution records for each relevant combination 

of sourceType, pollutant-process and bin identifier. 

2_1 sb_fractions update 

regulatory class. 

For each record, for pollutant-processes that do not require regulatory 

class information, set regClassID to 0 and regClass Fraction to 1. 

2_2 sb_fractions update MY 

GroupID 

For each record, for pollutant-processes that do not require model year 

group information, set MYGroupID to 0. 

2_3 sb_fractions update size 

and weight 

For each record, for pollutant-processes that do not require size and 

weight information, set engSizeID and weightClassID to 0 and 

sizeWeightFraction to 1. 

2_5 calculate sb_fractions For each record, calculate sb_fractions as the product of 

fuelEngFraction, emisTechFraction, and sizeWeightFraction. 

2_7 populate sb_fractions no 

dups 

Remove duplicate records from sb_fractions; save as a second 

temporary table, “sb_fractions no dups”.

4 populate SourceBin Select unique sourceBinIDs with fractions >0 to fill SourceBin table. 

4_5 generate bin IDs Generate sourceBinIDs from bin discriminators. 

5 append source bin 

distributions 

Use SourceBin table and “sb_fractions no dups” to fill

SourceBinDistribution table. 

94
10.11. Meteorology Generator 

Basic meteorological parameters such as temperature, humidity and heat index are 

stored in the MOVESExecution database table ZoneMonthHour. This generator uses the 

temperature and relative humidity information in the ZoneMonthHour Table and 

performs the necessary calculations to populate the heatIndex and specific humidity (or 

humidity ratio) fields in this table. 

This generator subscribes to the MOVES master loop mechanism at the process 

level for the running and extended idling emission processes. 

The Meteorological Generator uses the temperature and relative humidity data in 

the ZoneMonthHour table to populate the Heat Index column. 

For each RunSpec-required zone, month and hour, the Heat Index is calculated by 

following the algorithm:

HI = -42.379 + 2.04901523*T + 10.14333127*RH + -0.22475541*T*RH + 

-6.83783 *0.001*T*T + -5.481717 * 0.01 * RH*RH + 

1.22874*0.001*T*T*RH + 8.5282*0.0001*T*RH*RH + 

-1.99*.000001*T*T*RH*RH 

where HI is the heat index, T is temperature in degrees F, and RH is the relative 

humidity in percent. This formula is a recent heat index algorithm used by the 

National Weather Service. 

The MetGenerator has been expanded in MOVES-HVI to also calculate the

specific humidity field of the ZoneMonthHour table. The equations used to convert from

relative humidity in percent to specific humidity (or humidity ratio) in units of grains of 

water per pound of dry air were taken from CFR section 86.344-79. 

95
Inputs: 

TF is the temperature in degrees F. (from temperature field in ZoneMonthHour) 

 Pb is the barometric pressure. (from barometricPressure field in County) 

 Hrel is the relative humidity (from relHumidity field in ZoneMonthHour)

( )[ ]

( ) ( )

( ) ( )

⎥

⎥

⎦

⎤

⎢

⎢

⎣

⎡

+

+ + −

⎥

⎥

⎦

⎤

⎢

⎢

⎣

⎡

+

+ + −

=

=

⎟

⎠

⎞ ⎜

⎝

⎛ =

= −

−=

+−=

0

3

0 0

0

0

3

0 0

0

00219.01

.000588.02437.3 0000000117 /

00219.01

.000588.02437.3 0000000117 /

0

10*557.6527

10*167.218*92.29

100

)/(*8.4347

27.647

27332 9

5

T

T T TT

T

T T TT

db

db

rel

V

specificorratio humidity VbV

K

K F

K

K

P

P H P

H PPP

T T

TT

96
10.12. Start OperatingModeDistributionGenerator (StartOMDG) 

The StartOMDG signs up with the master loop mechanism at the Zone level. Its 

substantive calculations are independent of geographic location and depend in time only 

upon hour and day. 

The operating modes used for the start process of the criteria pollutants represent ranges 

of the amount of time vehicles have been parked before being started and are listed near 

the end of section 9.7. 

The steps of this calculation can be logically specified as follows: 

1. Compute the soak length of each trip in the SampleVehicleTrip table. This 

equals the keyOnTime of the trip minus the keyOffTime of the previous trip. 

Trips having no prior trip (priorTripID = NULL) are disregarded in the 

calculation. 

2. Assign a start opModeID to the trip by comparing its soak length with the 

minSoakBound and maxSoakBound values in the OperatingMode table. 

3. Then for each sourceTypeID and hourDayID, the opModeFraction of each 

opModeID equals: 

the count of records having the opModeID 

divided by 

the number of keyOnTime records. 

Trips having no prior trip are excluded from both the numerator and the 

denominator of this ratio. 

Steps 1 through 3 are performed at most once for each model run. 

97
4. During each Zone level iteration of the StartOMDG masterloopable, the 

operating mode distribution (which is by sourceTypeID, hourDayID and 

opModeID) resulting from steps 1-3 is stored into the OpModeDistribution CMIT 

for the off-highway-network link location in the zone for each pollutant whose 

start process emissions are required by the run specification and whose 

calculation requires an operating mode distribution. (Estimating the start process 

emissions of the “greenhouse gas” pollutants in MOVES2004 does not require an 

operating mode distribution, whereas estimating the start process emission of the 

“criteria” pollutants added in MOVES-HVI does involve using an operating mode 

distribution.) 

Records already existing in the CMIT are not overwritten. 

98
10.13. Tank Temperature Generator (TTG) 

10.13.1. Functional Characteristics 

The TTG signs up at the ZONE master looping level. It must execute before the Evap 

Operating Mode Distribution Generator. 

The TTG uses the Sample Vehicle and SampleVehicleTrip tables, in conjunction with 

ambient temperature information in the ZoneMonthHour table, and temperature effect 

information from the TankTemperatureRise table to calculate the contents of the 

AverageTankTemperature, SoakActivityFraction tables, ColdSoakTankTemperature and 

ColdSoakInitialHourFraction tables which are CMITs. 

No records are added to the AverageTankTemperature table for a combination of 

tankTemperatureGroupID, zoneID, and monthID if any record pertaining to this 

combination is already present. No records are added to the SoakActivityFraction table 

for a combination of sourceTypeID, zoneID, and monthID if any records are already 

present for it. No records are added to the ColdSoakInitialHourFraction table for a 

combination of sourceTypeID, zoneID, and monthID if any records are already present 

for it. 

Because Mesoscale Lookup does not compute the emissions of parked cars, some TTG 

steps are skipped to reduce computing time when Mesoscale Lookup is selected. 

10.13.2. Detailed Calculation Steps 

TTG-1 Calculate ColdSoakTankTemperature 

Inputs: 

- Temperature (zoneMonthHour) 

Output: 

- coldSoakTankTemperature (zoneID, monthID, hourID). This is saved in 

the ColdSoakTankTemperature CMIT. 

Preliminary Calculation: 15minuteTemperature - Create intermediate table of 

temperatures in 15 minute time steps, with key fields hourID, timeStep (1 through 

4 with 1 representing the top of the hourID). Within each hourly temperature, set 

99
time step 1 to the corresponding value from zoneMonthHour. Then perform

linear interpolation with hourID+1 timeStep 1 to fill in hourID TimeStep 2-4 . 

For the “highest” hour ID interpolate (default = 24) with the “lowest” hour ID 

(default = 1). 

Preliminary Calculation: 15minuteTankTemperature - Performed on the 15 

minutes temperature table produced in the preliminary calculation. 

15minuteTankTemperate and tempDelta need to be calculated at each time step 

before performing calculations on the next time step. 

- for hourID =1, timeStep=1 

15minuteTankTemperature 

= 15minuteTemperature (hourID=1, timeStep=1) 

tempDelta 

= 15minuteTemperature – 15minuteTankTemperature 

- for all other hourID, timeSteps: 

 15minuteTankTemperature 

= 1.4*SUM(tempDelta hourID=1, timeStep=1 through 

most recent hourID, timeStep)+ 15minuteTankTemperature 

(hourID 1, timeStep 1) 

tempDelta 

= 15minuteTemperature - 15minuteTankTemperature 

Calculation: coldSoakTankTemperature (hourID) = 15minuteTankTemperature 

(hourID, timeStep=1) 

TTG-2 Create sampleVehicleTripByHour 

Trips in the sampleVehicleTrip table may span the top of the next hourDayID. This step 

is needed to parse the trips into segments for which the start and finish are within the 

same hourID. “Marker Trips”, which have a keyOffTime, but null value of keyOnTime 

are ignored in this calculation. 

Inputs: 

- SampleVehicleTrip 

Outputs: 

100
- Intermediate table SampleVehicleTripByHour (vehicleID, tripID, 

hourDayID, endOfHour, keyOnTime, KeyOffTime, startOfTrip, 

endOfTrip) 

Preliminary calculation: calculate “endOfHour” for each record not representing 

a “Marker Trip” = next highest multiple of 60 

Calculation: Create a new “trip” record when keyOffTime for a trip > 

endOfHour. The tripID will remain the same, but the hourID will increment 

accordingly. The fields “startOfTrip” or “endOfTrip” will be added to table to 

identify whether the trip record is an actual trip start or trip end. The specific 

steps are as follows: 

- Set startOfTrip=1 for each existing trip in SampleVehicleTrip 

- Records need to be split when keyOffTime > endOfHour 

o New keyOffTime for existing record = endOfHour 

o Create new record for tripID, with hourID = hourID+1 and 

endOfHour = endOfHour + 60 

o keyOnTime for new record = endOfHour (hourID-1) + 1 

o keyOffTime is the same as original record, unless it is > 

endOfHour – in which case repeat these steps until a record is

created where keyOffTime < endOfHour 

- “endOfTrip” = 1 for record where keyOffTime<endOfHour (i.e. last 

split). 

TTG-3 Create hotSoakEventByHour 

Inputs: 

- SampleVehicleTripByHour (vehicleID, tripID, hourDayID, 

endOfHour, keyOnTime, KeyOffTime, startOfTrip, endOfTrip) 

Output: 

- Intermediate table hotSoakEventByHour (vehicleID, tripID, 

hourDayID, endOfHour, hotSoakBegin, hotSoakEnd, startOfSoak, 

endOfSoak) 

Calculation:

- Select records from sampleVehicleTripByHour where endOfTrip=1 

- hotSoakBegin = keyOffTime of TripID; startOfSoak=1 

- if keyOnTime of “next trip” (define by priorTripID=TripID and 

startOfTrip=1) < endOfHour for TripID, then hotSoakEnd = 

keyOnTime of next trip; endOfSoak=1 

- Otherwise, if there is a next trip 

o hotSoakEnd = endOfHour for TripID; endOfSoak=0 

o Create new record for tripID, with hourID = hourID+1 and 

endOfHour = endOfHour + 60 

101
o hotSoakBegin for new record = endOfHour (hourID-1) + 1 

o hotSoakEnd is the same as original record, unless it is > 

endOfHour – in which case repeat these steps until a record is

created where keyOffTime < endOfHour; at which point set 

endOfSoak=1 

- Otherwise, if there is no next trip 

o hotSoakEnd = endOfHour for TripID; endOfSoak=0 

o Repeat these steps until hourID=24 is reached 

 Create new record for tripID, with hourID = hourID+1 

and endOfHour = endOfHour + 60 

 hotSoakBegin for new record = endOfHour (hourID-1) 

+ 1 

 hotSoakEnd = endOfHour for TripID; endOfSoak=0 

TTG-4 Calculate Hot Soak and Operating Tank Temperature by Parsed Trip 

This step computes operating tank temperatures for the beginning and end times of the 

parsed trips in sampleVehicleTripByHour, and for each minute for hot soaks (necessary 

because hot soak is modeled as a decay function). The calculations must be performed in 

tandem since the initial temperature for each trip is a function of the final temperature 

from the preceding hot soak, and vice versa. 

Inputs: 

- sampleVehicleTripbyHour (TTG-2) 

- hotSoakEventByHour (TTG-3) 

- hourlyColdSoakTankTemperature (TTG-1) 

- temperature (ZoneMonthHour) 

- tankTemperatureRiseTermA (TankTemperatureRise) 

- tankTemperatureRiseTermB (TankTemperatureRise) 

Outputs: 

- intermediate table operatingTemperature, which adds the fields 

keyOnTemp and keyOffTemp to sampleVehicleTripByHour; and adds 

key field tankTemperatureGroup 

- intermediate table hotSoakTemperature, which stores the tank 

temperatures for each hot soak event minute-by-minute; and adds key 

field tankTemperatureGroup 

Calculation: operatingTemperature 

For each vehicle: 

102
for first (non-marker) trip in sampleVehicleTripByHour: 

- keyOnTemp = hourlyColdSoakTemperature for that hour (linking of 

hourDayID in sampleVehicleTripByHour and hourID in 

hourlyColdSoakTemperature required) 

- keyOffTemp = keyOnTemp + [(tankTemperatureRiseTermA + 

tankTemperatureRiseTermB * (95-

hourlyColdSoakTemperature))/(1.2)]*(( keyOffTime – 

keyOnTime)/60) 

for subsequent trips: 

if startOfTrip=0 (i.e. continuation of a TripID in a new hour): 

- keyOnTemp = keyOffTemp from previous segment (defined as the 

same TripID in the previous hour) 

- keyOffTemp calculated as above 

if startOfTrip=1 (i.e. new trip) 

- keyOnTemp = final soakTankTemperature from hotSoakTemperature 

where TripID of hotSoakTemperatures = priorTripID of 

operatingTemperature (i.e. the record in which hotSoakTime = 

keyOnTime for Trip ID) 

- keyOffTemp calculated as above 

Repeat with each new vehicle 

Calculation: SoakTemperature this intermediate table expands 

hourlySoakEventByHour to store the hot soak tank temperature for each hot soak 

event minute-by-minute. Construct hotSoakTemperature as follows: 

- key fields vehicleID, tripID, hourDayID from

hourlySoakEventByHour 

- using values of hotSoakBegin and hotSoakEnd for a given tripID, 

expand records to minute-by-minute with key field hotSoakTime (i.e. 

initial hotSoakTime = hotSoakBegin, final hotSoakTime = 

hotSoakEnd) 

- coldSoakTemperature = hourlyColdSoakTemperature for the hour 

- initialTankTemperature = keyOffTemp for Trip ID where 

endOfTrip=1, from operatingTemperature table 

- For initial record in each hot soak event (defined by tripID): 

o soakTankTemperature = initialTankTemperature

o tempDelta = temperature (this is ambient temperature from

zoneMonthHour for that hour) – soakTankTemperature 

o opModeID = 150 if soakTankTemperature > 

coldSoakTemperature + 3, otherwise end 

103
- For subsequent records in the same event: 

o soakTankTemperature = 1.4*SUM(tempDelta from initial 

record through most recent record)/60+ 

initialTankTemperature 

o tempDelta = temperature (this is ambient temperature from

zoneMonthHour for that hour) – soakTankTemperature 

o opModeID = 150 if soakTankTemperature > 

coldSoakTemperature + 3, otherwise end 

TTG-5 Calculate averageTankTemperature CMIT 

This step is not required for mesoscale lookup. 

Inputs: 

- operatingTemperatures 

- hotSoakTemperatures 

- hourlyColdSoakTankTemperature 

Output: 

- averageTankTemperature CMIT (zoneID, monthID, hourDayID, 

tankTemperatureGroupID, opModeID, averageTankTemperature) 

Calculation:

- averageTankTemperature, for a given hourDayID: 

o for opModeID=151 (cold soak) = hourlyColdSoakTankTemp 

for that hour 

o for each zoneID, monthID, hourDayID, and 

tankTemperatureGroupID averageTankTemperature can be 

calculated from the OperatingTemperature table as: 

averageTankTemperature = 

SUM((keyOffTime-keyOnTime) * (keyOnTemp + 

keyOffTemp)/2.0) 

/ 

 SUM(keyOffTime-keyOnTime) 

o for opModeID=150 (hot soak) = average of all 

soakTankTemperatures for trips with the same hourDayID 

TTG-6 Calculate soakActivityFraction CMIT 

Inputs: 

- intermediate table HotSoakTemperature 

- SampleVehicleDay table 

104
Outputs: 

- SoakActivityFraction CMIT 

Calculation:

Fraction of cold soaking = cMinutes / (cMinutes + hMinutes) 

Fraction of hot soaking = hMinutes/ (cMinutes + hMinutes) 

 Where: 

cMinutes, on a dayID = total minutes of cold soaking for all vehicles in 

SampleVehicleDay = (60 * number of sample vehicles existing on the 

dayID) – oMinutes – hMinutes 

oMinutes, on a dayID = total minutes of vehicle operation in the 

hourDayID = sum (keyOffTime-keyOnTime) for all trips in the 

hourDayID from VehicleTripByHour 

hMinutes, on a dayID = total minutes of vehicle hot soaking in the 

hourDayID = count of records in HotSoakTemperature in the hour 

TTG-7: Calculate Cold Soak Initial Hour Fractions 

This step is not required for mesoscale lookup 

Inputs:

o SampleVehicleTrip table 

o SampleVehicleDay table 

o VehicleTripByHour(TTG-2) 

o HotSoakTemperature(TTG-4) 

Outputs: 

o ColdSoakInitialHourFraction CMIT table 

Calculations: 

First, make an intermediate table, ColdSoakInitialHourMinutes: 

 Key fields: 

 zoneID 

 monthID 

 tankTemperatureGroupID 

 vehID 

 dayID 

 hourID 

 initialHourID

 Data field: 

 coldSoakInitialHourMinutes 

105
X = 60. 

Y = 0. 

2. The first record is a VehicleTrip. (This may be the only record 

in the hour or there may be any number of subsequent hot 

soaks, and trips, the last of which may or may not run to the 

end of the hour.) 

X = keyOnTime of this first record – endOfHour + 60 

Y = 60-X-(number of HotSoakTemperature records) – 

sum(keyOffTime-keyOnTime) for all trips in the hour. 

Reset Initial Hour for subsequent calculations to be the current 

hour. 

3. The first record is a hot soak minute (This may be the only 

record, or there may be any number of subsequent trips and hot 

soak minutes, the last of which may or may not run to the end 

of the hour.) 

X = 0 

Y = 60-(number of HotSoakTemperature records) – 

sum(keyOffTime-keyOnTime) for all trips in the hour. 

Reset InitialHour for subsequent calculations to be the current 

hour. 

 Next Hour 

The produce ColdSoakInitialHourMinutes as follows: 

For each tankTemperatureGroupID 

For each vehID and dayID in SampleVehicle

 Initial Hour = 1 

 For Each Hour 

Write two records into coldSoakInitialHourMinutes, one for 

minutes of cold soaking which began in the initial hour, which we 

will denote as X , and one for minutes of cold soaking which began 

in the current hour, which we will denote as Y. The idea here is 

that all minutes of cold soaking in the current hour must either be 

an extension of cold soak periods which began at some single prior 

hourID, or must have begun in this hour. This single prior hourID 

is what has been denoted above as Initial Hour. 

Find the earliest record pertaining to the vehicle, day, and hour in 

either VehicleTripByHour (TTG-2), based on keyOnTime, or in 

HotSoakTemperature (TTG-4) based on hotSoakTime. There are 

three possibilities: 

1. There is no first record because there are no records. 

106
Next Vehicle - Day 

Next TankTemperatureGroup 

TTG-7 can now produce the ColdSoakInitialHourFraction table by summing the 

ColdSoakInitialHourMinutes table across tankTemperatureGroups and sampleVehicles 

within SourceType, and normalizing to distributions which sum to unity. 

The format of the ColdSoakInitialHourFraction table remains:

 Key Fields: 

 sourceTypeID 

 zoneID 

 monthID 

 hourDayID 

 initialhourDayID 

 Data Field: 

 coldSoakInitialHourFraction 

ignoring the detail that hourIDs and dayIDs are combined into hourDayIDs 

coldSoakInitialHourFraction = 

(sum of all minutes for vehIDs belonging to sourceTypeID in the zoneID, 

monthID, and dayID having the hourID and initialHourID) / 

(sum of all minutes for vehIDs belonging to sourceTypeID in the zoneID, 

monthID and dayID having the hourID) 

The calculation deliberately ignores the tankTemperatureGroup distinction, giving 

them all equal weight. 

This key assumption behind this approach is that vehicles are soaking at all times when 

they are not hot soaking or operating. The predominant model of time embodied in the 

previous calculations, which this approach seeks to make rigorous, is that the world 

begins on the first hour of the day, and ends at the end of the day. E.g. there is no effort 

in the cold soak tank temperature calculations to “wrap-around” from the last hour of the 

day to the first hour of the day, and doing so now would result in a temperature 

discontinuity. (The single exception to this is that the TAG does consider some history 

from previous “real-world sampling days”, by allowing soak times for the first trip to be

longer than if they had begun at midnight. This exception is quite limited and 

corresponds exactly to the use of the “marker trips” which are used for this single 

purpose. ) 

107
10.14. Tank Fuel Generator (TFG) 

10.14.1. Functional Characteristics 

This component executes at the County master looping level. 

This component uses the fuel supply information from the MOVES database 

(which pertains to Fuel Formulations dispensed to sourceUseTypes in proportion to their 

FuelSupply marketShares) to produce the AverageTankGasoline table. It accounts for 

the effects of “comingling” ethanol with non-ethanol gasoline and for the “weathering” 

effect on RVP for in-use fuel. 

The AverageTankGasoline table produced by this component is a CMIT. Any 

records already present in the MOVESExecution database, are not overwritten. This is 

done on an individual record basis. 

10.14.2. Detailed Calculation Steps 

TFG-1a: Calculate Average Pump Gasoline and Ethanol Blend Type 

Inputs: 

marketShare from FuelSupply (county, fuelYear, monthGroup, 

fuelFormulation) 

ETOHvolume from FuelFormulation (fuelFormulation) 

RVP from FuelFormulation (fuelFormulation) 

fuelSubTypeID from FuelFormulation 

fuelTypeID from FuelSubType 

Outputs: 

averageRVP (county, fuelYear, monthGroup) 

tankAverageETOHVolume (county, fuelYear, monthGroup) This is stored as 

the ETOHVolume field of AverageTankGasoline. 

Calculations: 

averageRVP = For all FuelFormulations in county, fuel year & monthGroup 

where fuelType = “gasoline” (ie fuelTypeID = 1)) 

(Sum (RVP*marketshare)) / (Sum (marketshare)) 

tankAverageETOHVolume = For all Fuel Formulations in county, fuel year & 

monthgroup where fuelType = “gasoline” (ie fuelTypeID = 1)) 

(Sum (ETOH Volume*marketshare)) / (Sum (marketshare)) 

108
TFG-1b: Calculate Ethanol Market Share and Ethanol BlendType 

Inputs: 

marketShare from FuelSupply (county, fuelYear, monthGroup, 

fuelFormulation) 

fuelSubTypeID from FuelFormulation 

fuelTypeID from FuelSubType 

Outputs: 

gasoholMarketShare (countyID, fuelYearID, monthGroupID) 

ethanolBlendType (county, fuelYear, monthGroup) 

Calculation:

gasoholMarketShare: For all FuelFormulations in county, fuelyear & 

monthgroup where ETOHVolume >= 4

gasoholMarketShare =Sum (marketShare)

lowETOHRVP: For all FuelFormulations in county, fuel year & monthgroup 

WHERE fuelType = “gasoline” (ie fuelTypeID = 1) and ETOHVolume <4 

IF ( sum (marketshare) = 0, 

lowETOHRVP=AverageRVP 

ELSE 

lowETOHRVP=(Sum (RVP*marketshare)) / (Sum

(marketshare)) 

highETOHRVP: For all FuelFormulations in county, fuel year & 

monthgroup WHERE fuelType = “gasoline” (ie fuelTypeID = 1)) and 

ETOHVolume >= 4 

IF gasoholMarketShare = 0, 

highETOHRVP = AverageRVP 

ELSE 

highETOHRVP =(Sum (RVP*marketshare)) / 

gasoholMarketShare 

ethanolBlendType: 

IF absolute value (highETOHRVP –lowETOHRVP) <= 0.2, 

ethanolBlendType =“Match” 

ELSE ethanolBlendType = “Splash” 

109
TFG-1c: Calculate Commingled Tank Fuel RVP 

Inputs: 

gasoholMarketShare (countyID, fuelYearID, monthGroupID) from TFG-1b 

averageRVP (countyID, fuelYearID, monthGroupID) from TFG-1a 

Commingling Lookup (stored in program)

LookupMarketShare 

Commingling 

RVP Factor 

0.0 1.000 

0.1 1.016 

0.2 1.028 

0.3 1.035 

0.4 1.039 

0.5 1.040 

0.6 1.038 

0.7 1.034 

0.8 1.027 

0.9 1.018 

1.0 1.000 

Outputs: 

commingledRVP (countyID, fuelYearID, monthGroupID) 

Calculation:

comminglingFactor (countyID, fuelyearID, monthgroupID) = lookup from 

table using smallest value of “LookupMarketShare” that is greater than or 

equal to the gasoholMarketShare.

commingledRVP = averageRVP * comminglingFactor

TFG-2: Weathered RVP 

TFG-2a: Calculate “EvapTemp” by zoneID, MonthGroupID 

Inputs: 

temperature (zoneID, hourID monthgroupID) 

zoneID from masterloopcontext

Outputs: 

zoneEvapTemp (zoneID, monthgroupID) 

Calculation : 

110
zoneMin(zoneID, monthgroupID) = MIN (temperature(zoneID, 

monthgroupID, hourID)) 

zoneMax (zoneID, monthgroupID) = MAX(temperature(zoneID, 

monthgroupID, hourID) 

zoneEvapTemp = 

IF zoneMax <40 or zoneMax-zoneMin <=0, (zoneMin+zoneMax)/2 

ELSE zoneEvapTemp(zoneID, monthGroupID) = 

 -1.7474+1.029*zoneMin+ 0.99202* (zoneMax-zoneMin)-

0.0025173*zoneMin* (zoneMax-zoneMin) 

TFG-2b: Calculate ratio of weathering loss for gasoline by Zone, Year & Month at 

actual ambient temperatures relative to a diurnal swing of 72-96 F

Inputs: 

zoneEvapTemp (zoneID, monthgroupID) from previous step 

commingledRVP (countyID, fuelYearID, monthgroupID) from TFG-1c

zone(countyID, zoneID) 

Outputs: 

ratioGasolineRVPLoss(zoneID, fuelYearID, monthgroupID) 

Calculation : 

ratioGasolineRVPLoss =MAX (0, [-2.4908 + 0.026196 * zoneEvapTemp + 

0.00076898 * zoneEvapTemp * commingledRVP]/[-0.0860 + 0.070592 * 

commingledRVP ] ) 

TFG-2c: Calculate weathering loss for average fuel for standard temperatures 

Inputs: 

ethanolBlendType (county, fuelYear, monthGroup) from TFG-1a 

gasoholMarketShare (countyID, fuelYearID, monthGroupID) from TFG-1b 

Outputs: 

avgWeatheringConstant (countyID, fuelYearID, monthGroupID) 

Calculations: 

IF ethanolBlendType = “Match”, avgWeatheringConstant = 0.049 – 0.0034 * 

gasoholMarketShare 

ELSE avgWeatheringConstant = 0.049 – 0.0116 * gasoholMarketShare 

111
TFG-2d: Calculate weathered RVP for county-average fuel adjusted for zone 

temperatures 

Inputs: 

ratioGasolineRVPLoss (zoneID, fuelYearID, monthgroupID) from TFG-2b 

avgWeatheringConstant (countyID, fuelYearID, monthGroupID) 

from previous step 

commingledRVP (countyID, fuelYearID, monthGroupID) from TFG-1c

zone(countyID, zoneID) 

Outputs: 

tankAverageGasolineRVP(zoneID, fuelYearID, monthgroupID) 

Calculation : 

tankAverageGasolineRVP (zoneID) = commingledRVP(countyID) * (1 – 

ratioGasolineRVPLoss (zoneID) * avgWeatheringConstant (countyID)) 

This is stored as the RVP field of AverageTankGasoline

112
10.15. Evaporative OperatingModeDistributionGenerator 

(EvapOMDG) 

The evaporative operating mode distribution generator populates the core model 

OpModeDistribution table for the evaporative processes (Tank Vapor Venting, Fuel 

Liquid Leaking and Fuel Permeation) While the Permeation process does not 

distinguish emission rates by these operating modes it applies the temperature adjustment 

separately by operating mode and therefore needs this operating mode distribution to 

weight values together. 

Inputs to this calculation are the SHO and SourceHours tables and the 

SoakActivityFraction table produced by the TTG. Its only output is the 

OpModeDistribution table. 

Since the operating mode distributions for the principal evaporative processes depend 

upon ambient temperature and therefore upon monthID, but the 

OperatingModeDistribution table does not include monthID as a key field, it is logically 

necessary, apart from any performance considerations, for this MasterLoopable 

component to execute at or below the MONTH level, and as implemented it does sign up 

at the MONTH level. This means, as regards locations, that it executes for each Link. 

The algorithm used is intended to operate correctly if some vehicle operation is allocated 

to the off-network roadtype. 

For links which represent actual highways the operating mode distribution is always 

“100% operating”. If running for mesoscale lookup this is all that needs to be done. 

When links which represent off highway locations are included in the run specification, 

this OMDG determines fractions for “operating”, and for the other evaporative process 

operating modes, which in the current database are “hot soaking” and “cold soaking”, 

which sum to unity as follows: 

113
1. Determine the fraction of operating as a ratio of SHO in the SHO table to sourceHours 

in the SourceHours table. Since these tables have the same structure, and since this 

component is executing for a single linkID and monthID, this calculation is 

straightforward. The ageID, which is present in the SHO and SourceHours tables but not 

in OperatingModeDistribution, just needs to be summed out. If the source hours 

denominator is missing or zero, then no output distribution is produced. 

2. Convert the soakActivityFractions for the operating modes other than “operating” 

(currently “hot soaking” and “cold soaking”) to opModeFractions which take into 

account the fraction of operating. 

opModeFractionopModeID = soakActivityFractionopModeID

* (1.0-fraction of operating) 

The special treatment of the “operating” mode is “hard-coded” into this generator. The 

other modes, however, are treated in a general fashion, e.g.. the TTG does not assume

that there are only two other modes, or that these modes have certain names. 

114
10.16. Alternative Vehicle Fuels and Technologies (AVFT) Strategy 

The Alternative Vehicle Fuels & Technologies Strategy is the first 

implementation of an internal control strategy. This control strategy allows the user to 

input penetration rates (i.e. sales fractions) by model for a broad range of advanced 

technologies, through model year 2050. It is thus a key element in the ability of MOVES 

to perform “what-if” analysis. 

The AVFT has two components. One component is incorporated into the 

MOVES GUI and allows the user to create specifications for replacement inputs for the 

FuelEngFraction table and, indirectly, the SizeWeightFraction and RegClassFraction 

tables. A second portion, the actual InternalControlStrategy MasterLoopable object, 

uses these specifications to produce these replacement tables prior to the running of the 

SourceBinGenerator. This causes changes to the SourceBinDistributions and the 

eventual MOVES output. 

The user has the option to save the specifications (AVFTspecs) for the 

replacement input tables. Most of the content of these specifications is the data to fill a 

large FuelEngFraction table in the MOVES database. The user is able to save the 

AVFTSpecs and to load and modify a saved AVFTSpec. A RunSpec may have an 

associated AVFTSpec; but AVFTspecs may also exist independently of RunSpecs. 

10.16.1. Functional Characteristics of the AVFT GUI Component: 

a. “Strategies” appears on the RunSpec Navigation List immediately after “Manage 

Input Data Sets”. “Alternative Vehicle Fuels & Technologies” is a sub-section. 

Control Strategies are not required, thus the initial status icon for Strategies (and its 

sub-sections) is the green check or the yellow squiggles depending on whether the 

Run Spec currently includes a control strategy that modifies the default data. 

b. An AVFT file management panel appears when the user selects “Alternative Vehicle 

Fuels & Technologies” from the navigation list. The panel includes: 

The name of the associated AVFTSpec (if one exists), or an indicator that no 

AVFTSpec exists and that default Fuel/Technology fractions are being used. The 

115
name displayed changes in response to the buttons below. No more than one 

AVFTSpec may be associated with a given RunSpec. 

A “New” button to create a new AVFTSpec. (This has the same effect as returning to 

default and editing.) 

An “Edit” button to view & modify the associated AVFTSpec. 

An “Import” button to load/associate an existing AVFTSpec. This allows the user to 

browse for exported AVFTSpecs and to select one. 

An “Export” button allows the user to save a AVFTSpec independent of the RunSpec. 

(Note: Saving the RunSpec itself includes saving the associated AVFTSpec. 

Executing the RunSpec after editing an AVFTSpec but without saving includes 

execution of the new AVFTSpec.) 

A “Delete” button to remove an associated AVFTSpec and revert to MOVES 

defaults. 

A “Cancel” button to close the panel without changes. 

c. An AVFT Edit panel appears next to the AVFT file management panel when the user 

selects “Edit” or “New” in that panel. The Edit panel contains a description button 

and a details subpanel. 

Description Button: The user may (optionally) enter a short text description of the 

spec. 

Details Panel:

1. The user may select a SourceType from a drop down list of all SourceTypes. The 

panel then displays a table of the Fuel/Engine Technology fractions from the 

associated AVFTSpec (or MOVES default DB FuelEngFraction table) for that 

SourceType for model years 2001-and-later. (The default FuelEngFraction table 

need not include all model years and the AVFTSpec may include similarly limited 

model years. The panel shows the model years provided and allows users to add 

additional years if desired (see below). In any case, the MOVES 

116
SourceBinGenerator extrapolates needed future years by repeating values for the 

last year provided.) 

2. Fuel/EngineTechnologies are listed as columns. Model years are listed as rows. 

The first value in each row is the model year. Fractions are sorted into categories 

as listed in the in the FuelEngTechAssoc table for that SourceType. The 

categories are displayed in the order indicated by the CategoryDisplayOrder field 

of the FuelEngTechAssoc table. Within a category, fractions are listed in 

ascending order by FuelTypeID*100 +EngTechID. The final value in each row is 

the sum of all FuelEngFractions for that source/type model year (so the user can 

see if the values sum to 1 as desired.) This panel normally fills the entire screen, 

with scroll bars to display any portions that don’t fit. 

3. The initial view displays fractions aggregated in the categories listed in the 

FuelEngTechAssoc table for that SourceType. The user can display or hide 

detailed views that display the fractions for individual Fuel/EngineTechnology 

combinations. Categories with only one member are not considered “aggregate” 

(ie, they may be modified in all views and there is no “detailed view” to display 

or hide). Columns of aggregate fractions should be labelled with the category 

name. Columns of non-aggregrate fractions should be labeled with the name of 

the FuelType and the Engine Technology. 

4. The user may select an “Add Model Years” button that adds one or more model 

year rows at the bottom. The user has an option to specify how many rows to add 

with this feature but the sytem currently will not add model years beyond 2050. 

In each new row, the model year field is the next consecutive model year. The 

initial values for the FuelEngFractions in the new row equal those of the previous 

model year. 

5. The user may replace any (non-aggregate) fraction in the table. Category 

aggregate fractions are grayed-out to indicate that they must be modified in a 

detail view. Fractions must be between 0 and 1, inclusive. The GUI does not 

allow the user to enter values <0 or >1. 

117
6. The user may manually assure that the fractions sum to 1 for a sourcetype/model 

year or may choose a “Normalize” button that will keep the proportions of the 

input fractions but adjust so they sum to 1. The AVFTSpec does not “Export” 

and the RunSpec does not “Save” or “Execute” until all sourcetypes/model years 

sum to 1. Error messages are provided to the user as needed. 

7. If the FuelEngTechAssoc table lists only one FuelType/EngineTechnology 

combination for the SourceType (currently true for motorcycles), there is no 

action for the user to take. The GUI displays the appropriate detail screen (which 

should have only one Fuel/EngineTechnology column), and displays a message: 

“Only one FuelType/EngineTechnology combination is supported for 

(SourceType Name). No alternate values allowed.” 

10.16.2. Functional Characteristics of the AVFT MasterLoopable 

a. The AVFT processor is MasterLoopable; executing after the InputDataManager and 

before the Generators. It is instantiated under the same conditions as the 

SourceBinGenerator and executes at the emission process master loop level. 

b. The AVFT FuelEngFractions are processed to replace the default fractions in 

FuelEngFractions in the Execution Location Database. In particular, if the 

specification provides inputs for a given SourceType/ModelYear, those inputs replace 

all values for that SourceType/ModelYear. Empty records in both the original and 

replacement tables (ie, records for which the implied fuelEngFraction =0) are taken 

into account. 

c. The default RegClassFractions and SizeWeightFractions are modified such that the 

aggregate (across FuelType/EngineTechnology) RegClassFractions for the 

SourceType/ModelYear remain the same after application of the AVFT. The new 

RegClassFractions and SizeWeightFractions conserve the original fractions for 

vehicles with unchanged FuelEng characteristics and proportionally distribute the 

remaining fractions among the “changed vehicles”. 

This calculation is specified in detail below for RegClassFraction. The algorithm for 

SizeWeightFractions is analogous, except the individual Regulatory Classes are 

replaced by combinations of EngSizeID and WeightClassID. 

118
Compute New Reg Class Fractions 

For each source type and model year, and for each supported FuelEngTech 

combination (i), either there exists an original FuelEngFraction(i) and a 

NewFuelEngFraction(i), or it is implied that the FuelEngFraction(i) or

NewFuelEngFraction(i) =0. 

Compute DeltaFuelEngFraction(i) as NewFuelEngFraction(i)-

FuelEngFraction(i). 

Compute ProportionOfNew(i) as 

IF DeltaFuelEngFraction(i)>=0 

Proportion =0 

ELSE 

ProportionOfNew = 

DeltaFuelEngFraction(i) / 

Sum (over all i where DeltaFuelEngFraction <0)

(DeltaFuelEngFraction(i)). 

Compute PortionOld(i) as 

IF NewFuelEngFraction(i)=0, 

PortionOld(i) =0 

ELSE PortionOld = Min (1, 

FuelEngFraction(i)/NewFuelEngFraction(i)) 

For each SourceType & Model Year there is a set of original 

RegClassFractions(i,j), where Ai@ indicates the associated FuelEng combination 

and Aj@ indicates the RegClass. These are used with the results of the above 

calculations to create NewRegClassFractions(i,j,). 

For each j 

For each i 

Compute NewRegClassFraction(i,j) as: 

IF NewFuelEngFraction(i)= 0, 

NewRegClassFraction(i,j) =0 

(Doesn=t need to be in database)

ELSE 

NewRegClassFraction(i,j) = 

PortionOld(i) * RegClassFraction (i,j) + 

[1-PortionOld(i)) * 

(Sum(over all i) (ProportionOfNew(i) 

*RegClassFraction(i,j))]

119
10.17. Energy Consumption Calculator (ECC) 

The energy consumption calculator calculates energy consumption (total, 

petroleum-based and fossil-based) for four processes: running, start, extended idle and 

well-to-pump, for each source type on each roadway type in MOVES2004. It uses input 

from CMITs produced by the total activity, operating mode distribution, source bin, and 

meteorology generators, and calculates the quantities of energy consumed in the form of 

the MOVES output database. 

Note: This functional calculator is actually implemented as two MOVES 

EmissionCalculator classes: an “EnergyConsumptionCalculator” for the running, start, 

and extended idle processes, and a “WellToPumpProcessor” which “chains” onto the 

EnergyConsumptionCalculator if theWellToPump process is required. 

10.17.1. Overview of Calculation Steps 

Table 10-7. Overview of Emission Consumption 

Calculator 

Step 

ECCP-1 Preliminary calculations 

ECCP-1a Calculate petroleum and fossil energy fractions 

ECCP-1b Convert age to model year for analysis year 

ECCP-2 Calculate adjustments 

ECCP-2a Calculate air conditioning adjustment 

ECCP-2b Calculate temperature adjustment 

ECCP-2c Calculate fuel adjustment 

ECCP-3 Calculate running energy consumption 

ECCP-4 Calculate start energy consumption 

ECCP-5 Calculate extended idle energy consumption 

ECCP-6 Calculate well-to-pump energy consumption 

ECCP-6a Calculate pump-to-wheel energy consumption 

ECCP-6b Interpolate well-to-pump factor by 

FuelSubType in analysis year 

ECCP-6c Calculate well-to-pump factor by FuelType in 

analysis year 

ECCP-6d Calculate well-to-pump energy consumption 

120
The level of aggregation for each calculation is dictated by the key fields of the 

input and output variables. The result of energy quantities in steps 2, 3, 4 and 5 are at the 

level dictated by the MOVES2004 output database design: calendar year, month, day, 

hour, county, zone, link, pollutant, process, source type, fuel type, model year, and road 

type. 

If the EnergyConsumptionCalculator encounters a missing value when 

performing a calculation, the result of the calculation is considered as missing. Records 

for which the results are missing are not represented by a value of zero but are left out of 

the database. 

The EnergyConsumptionCalculator signs up for the Master Loop at the year level 

which means that it executes for each location (link) for each calendar year. It signs up

for the running, start and extended idle processes to the extent they are called for by the 

run specification. 

10.17.2. Detailed Steps 

ECCP-1: Preliminary Calculations 

Step 1a: Calculate petroleum and fossil energy fractions by fuel type 

Since petroleum and fossil energy fractions vary by fuel subtype, this step is required 

to aggregate these fractions up to the fuel type level. 

Input Variables: 

MarketShare (County, Year, MonthGroup, FuelSubType,) 

From FuelSupply table 

Note: If record not found in database, default value of 1.0 is used if

fuelSubtypeID ends with 0, otherwise default value of 0.0 is used.

FuelSubtypePetroleumFraction (FuelSubType)

From FuelSubtype table 

FuelSubtypeFossilFraction (FuelSubType) 

From FuelSubtype table 

Output Variable: 

PetroleumFraction (County, Year, Month, FuelType) 

FossilFraction (County, Year, Month, FuelType) 

Calculation:

PetroleumFraction= 

∑=

no ofFuelSubTypeswithinFuelType

n

.

1

MarketShar *e FuelSubtypePetroleumFraction

FossilFraction = 

121
∑=

no ofFuelSubTypeswithinFuelType

n

.

1

MarketShar *e FuelSubtypeFossilFraction 

Step 1b: Convert Age to Model Year For Analysis Year 

Input Variables: 

YearID 

AgeID 

Output Variable: 

ModelYearID 

Calculation:

ModelYearID = YearID - AgeID 

ECCP-2: Calculate adjustments 

Step 2a: Calculate air conditioning adjustment 

Preliminary calculation (1): ACOnFraction 

This step calculates the fraction of time the AC compressor is engaged, as a 

function of Heat Index 

 Input Variables: 

HeatIndex (Zone, Month, Hour) 

From ZoneMonthHour table 

ACActivityTermA (MonthGroup, Hour) 

From MonthGroupHour table

ACActivityTermB (MonthGroup, Hour) 

From MonthGroupHour table

ACActivityTermC (MonthGroup, Hour) 

From MonthGroupHour table

 Calculation:

ACOnFraction (Zone, Month, Hour) = 

(ACActivityTermA+ACActivityTermB*HeatIndex 

+ACActivityTermC*HeatIndex2

) 

If ACOnFraction<0, set to 0 

If ACOnFraction>1, set to 1 

Preliminary calculation (2): ACActivityFraction 

This step calculates the overall A/C activity fraction, which accounts for the A/C 

on fraction, the penetration of A/C in the fleet and the fraction of those A/C systems that 

are functioning. 

Input Variable 

ACOnFraction (Zone, Month, Hour) from previous calculation 

122
ACPenetrationFraction (SourceType, ModelYear) 

From SourcetypeModelYear table 

FunctioningACFraction (SourceType, Age)

From SourceTypeAge table 

Calculation

ACActivityFraction (Zone, Month, Hour, SourceType, ModelYear) =

ACOnFraction 

* ACPenetrationFraction

*FunctioningACFraction 

Calculate AC Adjustment 

Input Variables: 

ACActivityFraction (Zone, Month, Hour, SourceType, ModelYear) 

From previous calculation 

FullACAdjustment (PolProcess, SourceType, OpMode) 

From FullACAdjustment table 

Calculation:

ACAdjustment (Zone, Month, Hour, SourceType, ModelYear, PolProcess, 

OpMode) = 1 + ((FullACAdjustment –1)*ACActivityAdjustment) 

Step-2b: Calculate temperature adjustment 

Input Variables: 

Temperature (Zone, Month, Hour) 

From ZoneMonthHour table 

TempAdjustTermA (PolProcess, SourceType, FuelType) 

From TemperatureAdjustment table 

TempAdjustTermB (PolProcess, SourceType, FuelType) 

From TemperatureAdjustment table 

TempAdjustTermC (PolProcess, SourceType, FuelType) 

From TemperatureAdjustment table 

Note: If temp adjustment terms are not found in database, default values of 0.0 

are used. 

Output Variables: 

TempAdjustment (PolProcess, Zone, Month, Hour, SourceType, FuelType) 

Calculation:

TempAdjustment = 

1 + TempAdjustTermA * (Temperature-75)

+ TempAdjustTermB * (Temperature-75)2

Step 2c: Calculate fuel adjustment 

Input Variables: 

FuelAdjustment (SourceType, PolProcess, FuelSubType) 

MarketShare (County, Year, MonthGroup, FuelSubType) 

Output Variable: 

FuelAdjustmentbyType (County, Year, MonthGroup,SourceType, PolProcess, 

FuelType) 

123
Calculation:

FuelAdjustmentbyType = 

∑=

no ofFuelSubTypeswithinFuelType

n

.

1

MarketShar *e FuelAdjustment

ECCP-3: Calculate running energy consumption 

Step 3a: Aggregate Base Emission Rates to SourceType/ Fuel Type/Model Year/ 

Operating Mode level 

Input Variables: 

MeanBaseRate (SourceBin, PolProcess, OpMode) 

From EmissionRate table 

SourceBinActivityFraction (SourceType, ModelYear, SourceBin, PolProcess) 

From SourceBinDistribution Table 

Calculation:

MeanBaseRatebyType (SourceType, FuelType, ModelYear, PolProcess,

OpMode) = 

∑ =

No SourceBinswithinFuelType ModelYear

SourceBin

SourceBinActivityFraction MeanBaseRate

. ,

1

*

Step 3b: Aggregate emission rates to SourceType level, Apply A/C Adjustment 

Input Variables: 

MeanBaseRatebyType (SourceType, FuelType, ModelYear, PolProcess,

OpMode) From previous calculation 

OpModeFraction (SourceType, Link, HourDay, PolProcess, OpMode) From

OPModeDistribution table 

ACAdjustment (Zone, Month, Hour, SourceType, ModelYear PolProcess,

OpMode) From ECCP- 2a 

Calculation:

Total Energy: 

SourceTypeEnergy (Zone, Month, HourDay, SourceType, FuelType, 

ModelYear, Link, PolProcess) = 

∑ =

No OpModeBins

OpModeBin

OpModeFraction MeanBaseRatebyType ACAdjustment

.

1

* *

Step 3c: Calculate Total Energy 

Input Variables: 

124
SourceTypeEnergy (Zone, Month, HourDay, SourceType, FuelType, 

ModelYear, Link, PolProcess) from previous calculation 

SCCVtypeFraction(SourceType, ModelYear, FuelType, SCCVtype) 

From SCCVtypeDistribution table 

SHO (SourceType, Age, Link, Hour, Day, Month, Year) 

From SHO Table 

IMOBDAdjustment (SourceType, County, Year, Age, FuelType) 

From IMOBDAdjustment table. 

Note: If IMOBD adjustment value not found in database, a default value of 1.0 

is used. 

TempAdjustment (ECCP-2b, existing code) 

FuelAdjustment (ECCP-2c, existing code) 

PetroleumFraction (ECCP-1a, existing code) 

FossilFraction (ECCP-1a, existing code) 

Calculation:

Total Energy

EmissionQuant = SCCVtypeFraction * 

∑ =

No SourceTypes

SourceBin

SHO SourceTypeEnergy FuelAdjustment TempAdjustment IMOBDAdjustment

.

1

* * * *

Petroleum Energy: 

EmissionQuant = 

EmissionQuant (Running, Total Energy) 

* PetroleumFraction 

Fossil Energy: 

EmissionQuant = 

EmissionQuant (Running, Total Energy) 

* FossilFraction

ECCP-4 & 5: Calculate start and extended idle energy consumption 

The equations are exactly the same as is done for ECCP-3 above. The only 

difference is that, under Step c, “SHO” is replaced by “Starts” for Start and 

“ExtendedIdleHours” for Extended Idle. 

ECCP-6: Calculate total, petroleum, and fossil energy consumption for well-to-pump (WTP) 

For all pollutants, well-to-pump energy and emissions are calculated as a function of 

pump-to-wheel total energy consumption (i.e. the sum of running, start and extended 

idle energy) 

Step-6a: Calculate total pump-to-wheel(PTW) energy consumption 

Inputs: 

EmissionQuant(...FuelType, PolProcess = TotalEnergy; Running, Start, 

Extended Idle) 

Outputs: 

125
PTWEmissionQuant (FuelType, Total Energy) 

Calculation:

PTWEmissionQuant = 

EmissionQuant (Running, Total Energy) 

+ EmissionQuant (Start, Total Energy) 

+ EmissionQuant (Extended Idle, Total Energy) 

Step-6b: Interpolate well-to-pump factorby FuelSubType in analysis year 

Inputs: 

WTPFactor (Pollutant, FuelSubType for next highest and next lowest in WTP

factor database, relative to YearID) 

 (Note : WTPFactor represents the field EmissionRate located in the 

GreetWellToPump table of the MOVES database.)

Outputs: 

WTPFactor (Pollutant, FuelSubType, YearID)

Calculation:

Linear interpolation using “bracketing” years in WTP database:

WTPFactor = WTPFactor (LoYearID) + 

(WTPFactor (HiYearID) – WTPFactor (LoYearID)) * 

((YearID – LoYearID) / (HiYearID – LoYearID))

Step-6c: Calculate well-to-pump factor by FuelType in analysis year 

Inputs Variables: 

WTPFactor (Step 6a) 

MarketShare (County, Year, MonthGroup, FuelSubType,) 

Output Variables: 

WTPFactorbyFuelType(Pollutant, FuelType, YearID) 

Calculation:

WTPFactorbyFuelType = 

∑=

no ofFuelSubTypeswithinFuelType

n

.

1

MarketShar *e WTPFactor

Step-6d: Calculate well-to-pump energy consumption 

Inputs: 

PTWEmissionQuant (Step 6a) 

WTPFactorbyFuelType (Step 6c) 

Outputs: 

EmissionQuant (PolProcess = Well-To-Pump; Total Energy, Petroleum Energy, 

Fossil Energy) 

Calculation:

EmissionQuant = 

PTWEmissionQuant * WTPFactorbyFuelType 

126
10.18. Distance Calculator 

The TotalActivityGenerator produces distance information in the SHO table. The 

DistanceCalculator reports vehicle travel distance information based on these SHO table 

values, if requested by the RunSpec, in the MOVESActivityOutput table of the MOVES 

output database. 

10.18.1. Algorithm Overview

The “total” distance in the SHO table must be disaggregated to the often more 

detailed level of the MOVES output. This is a “calculator-like” function and so is 

performed by an EmissionCalculator class despite the fact that “distance” is not a 

“pollutant”. 

This calculator is instantiated whenever distance output is requested by the 

RunSpec, which implies that some pollutant-process involving the running process has 

been selected, and signs up for the “Running Exhaust” emission process at the “Year” 

level of the MasterLoop, the same level at which the TAG operates. 

 10.18.2. Distance calculation 

If the “Distance Traveled” output is requested by the RunSpec, (which also 

implies that some pollutant has been selected for the Running process), the distance field 

in the SHO table is calculated by the TotalActivityGenerator (TAG). Otherwise distance 

is output by that generator as NULL. 

Within the distance calculator itself, there is a single calculation step: 

DC-1 : Allocate Distance to Finest MOVES Output Level 

Input Variables: 

SCCVtypeID(SCC) from SCC table 

SCCVtypeFraction(sourceTypeModelYearID, fuelTypeID, SCCVtypeID)

From SCCVtypeDistribution table 

sourceBinActivityFraction (sourceTypeModelYearID, polProcessID, 

sourceBinID) from SourceBinDistribution table 

distance(sourceTypeID, linkID, ageID, yearID, monthID, hourDayID)

from SHO table 

Output Variable: 

127
MOVESActivityOutput.distance(runID, yearID, monthID, dayID, hourID, 

stateID, countyID, zoneID, linkID, sourceTypeID, fuelTypeID,

modelYearID, roadTypeID, SCC)

Conceptual Calculation: 

MOVESActivityOutput.distance = 

 SCCVtypeFraction* distance * 

[sum over all sourceBins in fuelTypeID (sourceBinActivityFraction)] 

Several detailed considerations must be kept in mind as these calculations are 

performed. 

One consideration is just that model years are converted to ageID values by the 

relationship: modelYearID = yearID - ageID. 

Another consideration is that SHO table values are reduced by the 

SCCVtypeFraction, because the raw MOVESOutput data is for SCC-SourceUseType 

intersections. This factor is looked up in the SCCVtypeDistributionTable based on 

sourceTypeID, modelYearID, and fuelTypeID. In general this yields multiple values of 

SCCVtype and SCCVtypeFraction. These values of SCCVtype are used in combination 

with RoadType to determine SCC values from the SCC table. 

The most significant complexity is that SHO table distance values are reduced by 

a fraction representing the portion of this “total” activity occurring for the specific 

fuelTypeID. This is accomplished by determining the portion of the 

SourceBinDistribution which involves the given fuelTypeID. 

The table 10-8 illustrates the structural differences between the input to this 

calculation and the output it must produce: 

128
Table 10-8. Structural Differences between DistanceCalculator Input/Output 

Key Field SHO.distance Most detailed 

MOVESOutput

MOVESOutputRowID Yes, autoincremented 

runID Yes, but constant for a run

yearID Yes Yes 

monthID Yes Yes 

dayID Yes Yes 

hourID Yes Yes 

stateID Yes, but redundant with county

countyID Yes, but redundant with zone 

zoneID Yes Yes 

roadTypeID Yes Yes 

pollutantID Yes, but constant for this calculation 

processID Yes, but constant for this calculation 

sourceTypeID Yes Yes 

fuelTypeID No Yes 

modelYearID as ageID Yes 

SCC No Yes 

A final consideration is that, since non-key attributes in addition to “distance” 

may be added to the MOVESActivityOutput table in the future (e.g. number of starts) 

which may be produced by other calculators, the Distance Calculator creates 

MOVESActivityOutput records to report its results if they don’t already exist, but just 

updates the distance attribute in the appropriate records if they already exist. 

129
10.19. Methane (CH4) and Nitrous Oxide (N2O) Calculator 

MOVES includes two EmissionCalculator classes, 

CH4N2OrunningStartCalculator and CH4N2OWTPCalculator, which calculate Methane 

(CH4) and Nitrous Oxide (N2O) emissions for three processes (running, start, and well-topump) for each source type on each roadway type modeled. These calculators use input 

from CMITs produced by the total activity and source bin distribution generators, and 

calculate the quantities of these emissions in the form required by the MOVESOutput 

database. 

These calculators subscribe to the MasterLoop at the year level, which means they 

are executed once for each location (linked) for each year. 

When these EmissionCalculators encounter a missing input value in the MOVES 

database, the result of the calculation are considered as missing. Such results are left out 

of the database and are not represented in the MOVES output by a value of zero or some

other numeric value or character. 

The calculation steps are described below. These steps are the same for CH4 and 

N2O. 

10.19.1. Step 1: Calculate Running Emissions 

Input: 

SHO (SourceType, Age, Link, Hour, Day, Month, Year) 

SourceBinActivityFraction (SourceType, ModelYear, PolProcess , SourceBin) 

MeanBaseRate (PolProcess, SourceBin, OpMode) 

Output: 

EmissionQuant (SourceType, Pollutant, Process, FuelType....see MOVES 

output database design) 

Calculation:

EmissionQuant = SHO * SourceBinActivityFraction * MeanBaseRate 

10.19.2.Step 2: Calculate Start Emissions 

Input: 

Starts (SourceType, Age, Zone, Hour, Day, Month, Year) 

SourceBinActivityFraction (SourceType, ModelYear, PolProcess , SourceBin) 

MeanBaseRate (PolProcess, SourceBin, OpMode) 

Output: 

130
EmissionQuant (SourceType, Pollutant, Process, FuelType....see MOVES 

output database design) 

Calculation:

EmissionQuant = Starts * SourceBinActivityFraction * MeanBaseRate 

10.19.3. Step 3: Calculate Well-To-Pump Emissions 

Step 3a: Calculate well-to-pump factor by FuelType in analysis year 

Inputs Variables: 

EmissionRate from GREETWellToPump (Year, Pollutant, 

FuelSubType) 

 MarketShare (County, Year, MonthGroup, FuelSubType,) 

Output Variables: 

WTPFactorbyFuelType(Year, Pollutant, FuelType) 

Calculation:

WTPFactorbyFuelType = 

∑=

no ofFuelSubTypeswithinFuelType

n

.

1

MarketShar *e WTPFactor

Step 3b: Calculate Well-To-Pump Emissions 

Input: 

PTWEmissionQuant for total energy (Step 6a of Total Energy Calculator) 

WTPFactorbyFuelType for CH4/N2O (Step 3a above)

Output: 

EmissionQuant (SourceType, Pollutant, Process, FuelType....see MOVES 

output database design) 

Calculation:

EmissionQuant = PTWEmissionQuant * WTPFactorbyFuelType 

131
10.20. Atmospheric CO2 and CO2-Equivalent Calculator 

10.20.1. General Description 

This task involves performs the calculation of two pollutants: Atmospheric CO2 and CO2

Equivalent for all of the exhaust emission processes: Start, Running and Extended Idling. 

The calculations depend on the previous calculation of Total Energy, CH4 and N2O in 

their respective calculators. So this calculator is “chained” to those. 

10.20.2. Detailed Calculation Steps 

Step 1: Calculate CO2 and CO2-Equivalent from Total Energy 

Preliminary Calculation: Compute Carbon Content and Oxidation Fraction by 

FuelType 

Inputs: 

 CarbonContent (grams per KJ) by fuel subtype 

 OxidationFraction by fuel subtype 

 MarketShare (County, Year, MonthGroup, FuelSubType) From FuelSupply table 

Outputs:

 CarbonContent by FuelType 

 OxidationFraction by FuelType 

Calculations: 

CarbonContent by FuelType 

MarketShar *e CarbonCont (ent )

.

1

eFuelSubtyp

no ofFuelSubTypeswithinFuelType

n

∑=

132
OxidationFraction by FuelType = 

∑=

no ofFuelSubTypeswithinFuelType

n

.

1

MarketShar *e OxidationFraction(FuelSubtype)

Calculate Atmospheric CO2 from Total Energy 

Inputs: 

 Total Energy (KJ) 

 CarbonContent by FuelType (previous calculation) 

 Oxidation Fraction by FuelType (previous calculation) 

Output: 

 Atmospheric CO2 (grams) 

Calculation:

Atmospheric CO2 = Total Energy * Oxidation Fraction * Carbon Content * (44/12) 

Step 2: Calculate CO2 Equivalent 

Inputs: 

 Atmospheric CO2, CH4, N2O (grams) 

 100 year Global Warming Potentials by pollutant (GWP) 

Output: 

 CO2 Equivalent (grams) 

Calculation:

CO2 Equivalent = CO2 * GWPCO2 + CH4 * GWPCH4 + N2O * GWPN2O 

133
10.21. Criteria Pollutant Running EmissionCalculator (CREC) 

10.21.1. General Description 

This EmissionCalculator signs up with the MOVES master looping mechanism at the 

Year level for the running process, which means that a single execution produces results 

for one Link and one Year. 

The logical steps of the calculation can be described as follows: 

CREC-1 Calculate emission rates which account for I/M programs 

This step has two substeps: 

The first substep calculates an intermediate IMAdjustment table from the contents 

of the IMCoverage table for a particular zone and year. It puts the information 

into a usable form. The form of the IMCoverage table, in particular the use of 

model year ranges as non-key fields and the presence of information only where 

I/M programs exist, was highly constrained by overall table size considerations. 

To be used in subsequent steps the information needs to be into a more usable 

form, which this substep accomplishes. 

The second sub-step combines information from the EmissionRateByAge table 

and the IMAdjustment table produced in the first substep to produce an 

intermediate EmissionRateWithIM table. The function here is to weight the 

meanBaseRate and meanBaseRateIM fields together using the IM fractions 

calculated in the previous substep. 

CREC-2 Calculate fuel-supply-weighted fuel adjustment factors 

This step has two substeps: 

The first substep uses the FuelAdjustment and County tables to produce an 

intermediate CountyFuelAdjustment table specific to the county containing the 

link being executed. It resolves the GPA and non-GPA fuel adjustment factors 

into a single factor based on the GPAFract value in the County table. It is still at 

the fuelFormulation level. 

The second substep uses CountyFuelAdjustment and the FuelSupply table to 

produce an intermediate FuelSupplyAdjustment table of fuel adjustment factors at 

the fuelTypeID level. 

CREC-3 Calculate temperature adjustment factors 

This step uses the TemperatureAdjustment table along with temperature 

information from the ZoneMonthHour table to produce an intermediate 

METAdjustment table. 

134
CREC-4 Calculate air conditioning (AC) adjustment factors 

This step involves four substeps. 

The first substep uses the ACActivity terms from the MonthGroupHour table and 

the heat index information from the ZoneMonthHour table to calculate the 

fraction of time the AC compressor is engaged. 

The second substep calculates the AC activity fraction, which accounts for the AC 

on fraction from the first substep, the penetration of AC in the fleet (from the 

SourceTypeModelYear table) and the fraction of those AC systems that are 

functional (from the SourceTypeAge table.) 

The third substep calculates operating-mode-weighted FullACAdjustment factors 

from the contents of the FullACAdjustment table and the 

OperatingModeDistribution table. 

The fourth substep uses the results of the second and third substeps to calculate 

the AC adjustment factors used in subsequent calculations. 

CREC-5 Weight emission rates by source bin 

This step applies the source bin distributions to the EmissionRateWithIM table 

produced in step 1, storing the results in a SBWeightedEmissionRate table. 

FuelType distinctions from the source bin classification are preserved but other 

source bin discriminators are aggregated out. The modelYearID distinction 

contained in the EmissionRateWithIM table is preserved in 

SBWeightedEmissionRate, effectively subsuming the role of modelYearGroupID 

as a source bin discriminator. 

CREC-6 Weight emission rates by operating mode 

This step applies the operating mode distributions to the 

SBWeightedEmissionRate table calculated in the previous step, to produce an 

intermediate FullyWeightedEmissionRate table. 

CREC-7 Apply fuel, temperature, and opmode-weighted-AC adjustment factors to 

weighted emission rates 

This step applies the fuel supply adjustment factors from step 2, the temperature 

adjustment factors from step 3, and the ACAdjustment factors from step 4 to the 

results of step 6. 

CREC-8 Calculate and Apply Humidity Correction Factor to NOx running 

emissions 

This step calculates a multiplicative correction factor based on the specific 

humidity value in ZoneMonthHour and a fuel type-dependent coefficient and applies it to 

any NOx emission results from step 7. 

135
CREC-9 Multiply fully weighted and adjusted emission rates by source hours 

operating (SHO) activity 

This step multiplies the result of step 8 by the activity from the SHO table. Since 

SHO is stored by Link, the results of this step are specific to a Link and a 

Roadtype and are essentially now at the level of the MOVESOutput when 

reported by sourceTypeID. 

CREC-10 Convert results by source type into results by SCC 

This step is performed only when the run specification requests output by SCC 

code. 

The SCCVTypeDistributions and the SCCRoadType distributions are applied to 

the results of step 9 in a single processing step. 

10.21.2. Detailed Calculation Steps 

CREC-1: Calculate emission rates which account for I/M programs 

CREC 1-a: Complete I/M adjustment fraction information 

Input Variables: 

begModelYearID, endModelYearID, IMAdjustFract (IMCoverage table)

countyID, zoneID, yearID (from Master Loop Context). 

ageID (AgeCategory table) 

regClassID (RegulatoryClass table) 

Output Variable: 

IMAdjustFract (in intermediate IMAdjustment table) 

Calculation:

For zoneID, yearID in Master Loop Context, 

for running process (which is also the Master Loop Context process)

 of all pollutants in runSpec which this calculator calculates 

for all ageID in AgeCategory table, 

for all regClassID values in RegulatoryClass except regClassID=0 

modelYearID = yearID-ageID 

IMAdjustFract (zoneID, yearID, polProcessID, modelYearID, ageID, 

fuelTypeID, regClassID) 

= IMAdjustFract if IMCoverage record exists

with begModelYearID <= modelYearID <= endModelYearID 

= 0.0 otherwise 

CREC 1-b: Combine I/M and non I/M rates 

Input Variables: 

meanBaseRate and meanBaseRateIM (EmissionRateByAge table) 

fuelTypeID, regClassID (from SourceBin table) 

modelYearGroupID (from PollutantProcessModelYear table) 

IMAdjustFract (from step 1-a)

136
Output Variable: 

meanBaseRate (in new intermediate table EmissionRateWithIM) 

Calculation:

For all records in join of IMAdjustment Table to EmissionRateByAge table 

WHERE 

IMAdjustment.polProcessID=EmissionRateByAge.polProcessID 

IMAdjustment.fuelTypeID = SourceBin.fuelTypeID AND 

IMAdjustment.regClassID = SourceBin.regClassID AND

IMAdjustment.modelYearID= PollutantProcessModelYear.modelYearID AND 

IMAdjustment.polProcessID = PollutantProcessModelYear.polProcessID AND 

PollutantProcessModelYear.modelYearGroupID = 

SourceBin.modelYearGroupID AND

EmissionRateByAge.sourceBinID=SourceBin.sourceBinID AND

EmissionRateByAge.ageGroupID=AgeCategory.ageGroupID AND

IMAdjustment.ageID=AgeCategory.ageID

meanBaseRate (zoneID, yearID, polProcessID, modelYearID, sourceBinID, 

opModeID) = meanBaseRate + (IMAdjustFract * (meanBaseRateIMmeanBaseRate)) 

if meanBaseRate < 0.0 then set meanBaseRate = 0.0 (since IMAdjustFract might 

be greater than 1.0.) 

CREC-2: Calculate fuel-supply-weighted Fuel Adjustment Factors 

CREC 2-a: Combine GPA and non GPA fuel adjustment factors 

Input Variables: 

fuelAdjustment and fuelAdjustmentGPA (from FuelAdjustment table)

GPAFract (from County table) 

countyID (from MasterLoop Context)

Output Variable: 

fuelAdjustment (in intermediate CountyFuelAdjustment table) 

Calculation:

For countyID from Master Loop Context,

For all records in FuelAdjustment 

for running process (which is also the Master Loop Context process)

 of all pollutants in runSpec which this calculator calculates 

fuelAdjustment (countyID, polProcessID, fuelMYGroupID, sourceTypeID,

fuelFormulationID ) 

= fuelAdjustment + GPAFract*(fuelAdjustmentGPA-fuelAdjustment)

NOTE: An internal MOVES model component, the DefaultDataMaker, has set fuelAdjustment=1

for cases which are not populated in fuelAdjustment. 

137
CREC 2-b: Aggregate county fuel adjustments to fuel type 

Input Variables: 

fuelAdjustment (from CountyFuelAdjustment table from step 2-a)

marketShare (from FuelSupply table) 

fuelSubTypeID (from FuelFormulation table) 

fuelTypeID (from FuelSubtype table)

monthID (from MonthOfAnyYear table) 

yearID (from MasterLoopContext) 

fuelYearID (from Year table)

modelYearID ( from PollutantProcessModelYear table) 

Output Variable: 

fuelAdjustment (in intermediate FuelSupplyAdjustment table) 

Calculation:

For all records in join of CountyFuelAdjustment and FuelSupply where 

CountyFuelAdjustment.countyID=FuelSupplycountyID and 

Year.yearID = yearID from MasterLoopContext and 

Year.fuelYearID = FuelSupply.fuelYearID and 

FuelSupply.monthGroupID = MonthOfAnyYear.monthGroupID and 

CountyFuelAdjustment.monthGroupID=FuelSupply.monthGroupID and

CountyFuelAdjustment.fuelFormulationID=FuelFormulation.fuelFormulationID and 

FuelFormulation.fuelSubtypeID=FuelSubType.fuelSubtypeID and 

 PollutantProcessModelYear.polProcessID= 

CountyFuelAdjustment.polProcessID and 

PollutantProcessModelYear.fuelMYGroupID= 

CountyFuelAdjustment.fuelMYGroupID

fuelAdjustment (countyID, yearID, monthID, polProcessID, modelYearID,

 sourceTypeID, fuelTypeID )

= sum (fuelAdjustment * marketShare) over all fuel formulations in each fuel

type. 

CREC-3: Calculate temperature adjustment factors 

Input Variables: 

tempAdjustTermA, tempAdjustTermB (from TemperatureAdjustment table) 

temperature (from ZoneMonthHour table) 

zoneID (from MasterLoop context)

Output Variable: 

temperatureAdjustment (in intermediate METAdjustment table) 

Calculation:

For zoneID in Master Loop Context, 

For running process (which is also the Master Loop Context process) 

 of all pollutants in runSpec which this calculator calculates 

For all records in cross join of ZoneMonthHour and TemperatureAdjustment

temperatureAdjustment(zoneID, monthID, hourID, polProcessID, fuelTypeID)

= 1.0 + tempAdjustTermA * (temperature-75) + tempAdjustTermB

(temperature-75)2 

138
CREC-4: Calculate Air Conditioning (AC) Adjustment Factors 

CREC 4-a: Calculate AC On Fraction 

Input Variables: 

heatIndex (zoneID, monthID, hourID) 

From ZoneMonthHour table 

ACActivityTermA (monthGroupID, hourID)

From MonthGroupHour table

ACActivityTermB (monthGroupID, hourID) 

From MonthGroupHour table

ACActivityTermC (monthGroupID, hourID) 

From MonthGroupHour table

Output Variable: 

ACOnFraction (in intermediate ACOnFraction table) 

Calculation:

From join of ZoneMonthHour and MonthGroupHour tables where 

MonthGroupHour.monthGroupID = MonthOfAnyYear.monthGroupID and 

MonthOfAnyYear.monthID = ZoneMonthHour.monthID and 

MonthGroupHour.hourID = ZoneMonthHour.hourID

ACOnFraction (zoneID, monthID, hourID) =

(ACActivityTermA+ACActivityTermB*heatIndex

+ACActivityTermC*heatIndex2

) 

If ACOnFraction<0, set to 0 

If ACOnFraction>1, set to 1 

CREC 4-b: Calculate AC Activity Fraction 

Input Variables: 

ACOnFraction (zoneID, monthID, hourID) from previous calculation 

ACPenetrationFraction (sourceTypeID, modelYearID) from

SourceTypeModelYear table

functioningACFraction (sourceTypeID, ageID) from SourceTypeAge table 

Output Variable: 

ACActivityFraction (in intermediate ACActivityFraction table) 

Calculation:

From join of ACOnFraction, SourceTypeModelYear and SourceTypeAge tables 

where 

yearID = yearID value from master loop context 

SourceTypeModelYear.sourceTypeID = SourceTypeAge.sourceTypeID and 

SourceTypeModelYear.modelYearID = yearID - SourceTypeAge.ageID

ACActivityFraction (zoneID, monthID, hourID, sourceTypeID, modelYearID) 

 = ACOnFraction * ACPenetrationFraction * functioningACFraction 

139
CREC 4-c: Weight FullACAdjustment Factors by Operating Mode 

Input Variables: 

FullACAdjustment (polProcessID, sourceTypeID, opModeID) from

FullACAdjustment table 

opModeFraction (sourceTypeID, hourDayID, linkID, polProcessID, opModeID) 

from OpModeDistribution Table 

linkID from master loop context

Output Variable: 

weightedFullACAdjustment (in intermediate WeightedFullACAdjustment table) 

Calculation:

For all records in join of FullACAdjustment and OpModeDistribution 

using polProcessID, sourceTypeID, and opModeID

where linkID = value from master loop context and hourDayID is in the run 

specification 

weightedFullACAdjustment (sourceTypeID, polProcessID, linkID, hourDayID )

 = sum (fullACAdjustment * opModeFraction)

CREC 4-d: Calculate AC Adjustment Factor 

Input Variables: 

ACActivityFraction (zoneID, monthID, hourID, sourceTypeID, modelYearID) 

From step 4-b 

weightedFullACAdjustment (sourceTypeID, polProcessID, linkID, hourDayID)

From WeightedFullACAdjustment table 

Output Variable: 

ACAdjustment (in intermediate ACAdjustment table) 

Calculation:

For all records in join of ACActivityFraction and WeightedFullACAdjustment 

where 

WeightedFullACAdjustment.linkID=Link.linkID and 

 Link.zoneID=ACActivityFractioin.zoneID and

 WeightedFullACAdjustment.hourDayID=HourDay.hourDayID and 

 HourDay.hourID=ACActivityFraction.hourID and 

 WeightedFullACAdjustment.sourceTypeID=ACActivityFraction.sourceTyp

eID 

ACAdjustment (zoneID, monthID, hourID, dayID, sourceTypeID, 

modelYearID, polProcessID)

 = 1 + ((weightedFullACAdjustment –1)*ACActivityFraction)

CREC-5: Weight emission rates by source bin 

Input Variables: 

140
meanBaseRate (from EmissionRateWithIM table from step 1-b) 

sourceBinActivityFraction (from SourceBinDistribution table) 

Output Variable: 

meanBaseRate (in a new intermediate SBWeightedEmissionRate table) 

Calculation:

For all records in join of EmissionRateWithIM, SourceBin, 

SourceBinDistribution, and 

SourceTypeModelYear where: 

SourceBinDistribution.sourceBinID = SourceBin.sourceBinID and

SourceBinDistribution.sourceTypeModelYearID

 = SourceTypeModelYear.sourceTypeModelYearID and 

EmissionRateWithIM.polProcessID=SourceBinDistribution.polPro

cessID and 

EmissionRateWithIM.sourceBinID=SourceBinDistribution.source

BinID and 

EmissionRateWithIM.modelYearID=SourceTypeModelYear.mode

lYearID 

meanBaseRate(zoneID, yearID, polProcessID, sourceTypeID, modelYearID, 

fuelTypeID, opModeID) 

= sum (sourceBinActivityFraction * meanBaseRate) 

Note that sourceBinID is not included in the summation grouping; all of its

attributes except fuelTypeID are included instead, also note that there 

should be only one modelYearGroupID present in the source bin

distributions for a modelYearID and polProcessID without having to 

specify this. 

CREC-6: Weight emission rates by operating mode 

Input Variables: 

meanBaseRate (from SBWeightedEmissionRate table from step 5) 

opModeFraction (from OpModeDistribution table) 

Output Variable: 

meanBaseRate (in a intermediate FullyWeightedEmissionRate table) 

Calculation:

For all records in join of SBWeightedEmissionRate and OpModeDistribution 

where 

 SBWeightedEmissionRate.polProcessid=OpModeDistribution.polProcessI

D and 

 SBWeightedEmissionRate.opModeID=OpModeDistribution.opModeID and 

 SBWeightedEmissionRate.sourceTypeID=OpModeDistribution.sourceType

ID 

 OpModeDistribution.linkID=Link.linkID and 

 Link.zoneID= SBWeightedEmissionRate.zoneID 

meanBaseRate(linkID, yearID, polProcessID, sourceTypeID, modelYearID, 

fuelTypeID, hourDayID)

= sum (opModeFraction * meanBaseRate) 

141
CREC-7: Apply fuel, temperature, and AC adjustment factors to weighted emission

rates 

CREC 7-a: Combine Temperature and AC Adjustment Factors 

Input Variables: 

temperatureAdjustment (from METAdjustment table from step 3) 

ACAdjustment (from ACAdjustment table from step 4)

Output Variable: 

tempAndACAdjusment (in intermediate TempAndACAdjustment table) 

Calculation:

For all records in join of METAdjustment and ACAdjustment

Using zoneID, polProcessID, MonthID, and hourID 

tempAndACAdjustment (zoneID, polProcessID, sourceTypeID, modelYearID, 

fuelTypeID, monthID, hourID, dayID) = 

temperatureAdjustment*ACAdjustment 

CREC 7-b: Apply fuel adjustment to fully weighted emission rates 

Input Variables: 

meanBaseRate (from FullyWeightedEmissionRate table from step 6) 

fuelAdjustment (from FuelSupplyAdjustment table from step 2) 

Output Variable: 

fuelAdjustedRate (in intermediate FuelAdjustedRate table) 

Calculation:

For linkID in master loop context 

From join of FullyAdjustedEmissionRate and FuelSupplyAdjustment where 

FullyAdjustedEmissionRate.linkID = Link.linkID and

Link.countyID=FuelSupplyAdjustment.countyID and 

FullyAdjustedEmissionRate.yearID=FuelSupplyAdjustment.yearID and

FullyAdjustedEmissionRate.polProcessID 

=FuelSupplyAdjustment.polProcessID and 

FullyAdjustedEmissionRate.sourceTypeID= 

FuelSupplyAdjustment.sourceTypeID and 

FullyAdjustedEmissionRate.modelYearID=

FuelSupplyAdjustment.modelYearID and 

FullyAdjustedEmissionRate.fuelTypeID=FuelSupplyAdjustment.fuelTypeID 

fuelAdjustedRate (linkID, yearID, polProcessID, sourceTypeID, modelYearID, 

fuelTypeID, monthID, hourDayID) = meanBaseRate * fuelAdjustment

CREC 7-c: Apply temperature –and-AC adjustment to fuel-adjusted emission rate 

142
Input Variables: 

tempAndACAdjustment (from TempAndACAdjustment table from step 7-a) 

fuelAdjustedRate (from FuelAdjustedRate table from step 7-b) 

Output Variable: 

meanBaseRate (in intermediate WeightedAndAdjustedEmissionRate table 

Calculation:

From join of TempAndACAdjustment and FuelAdjustedRate tables where

FuelAdjustedRate.linkID = Link.linkID and 

Link.zoneID= TempAndACAdjustment.zoneID and 

TempAndACAdjustment.hourID=HourDay.hourID and 

TempAndACAdjustment.dayID=HourDay.dayID and 

HourDay.hourDayID= FuelAdjustedRate.hourDayID and

TempAndACAdjustment.polProcessID= FuelAdjustedRate.polProcessID and 

TempAndACAdjustment.sourceTypeID= FuelAdjustedRate.sourceTypeID and 

TempAndACAdjustment.modelYearID= FuelAdjustedRate.modelYearID and 

TempAndACAdjustment.monthID= FuelAdjustedRate.monthID and 

TempAndACAdjustment.fuelTypeID= FuelAdjustedRate.fuelTypeID 

meanBaseRate (linkID, yearID, polProcessID, sourceTypeID, modelYearID, 

fuelTypeID, hourID, dayID, monthID) = fuelAdjustedRate *

tempAndACAdjustment

CREC-8: Calculate and Apply Humidity Correction Factor to NOx Emissions 

Input Variables: 

meanBaseRate (from WeightedAndAdjustedEmissionRate table from step 7) 

humidityCorrectionCoeff (from FuelType table) 

specificHumidity (from ZoneMonthHour table) 

Output Variable: 

meanBaseRate (in WeightedAndAdjustedEmissionRate table) 

Calculation:

Using join of ZoneMonthHour, FuelType, and 

WeightedAndAdjustedEmissionRate where:

WeightedAndAdjustedEmissionRate.fuelTypeID = FuelType.fuelTypeID and 

WeightedAndAdjustedEmissionRate.linkID=Link.linkID and 

Link.zoneID=ZoneMonthHour.zoneID and 

WeightedAndAdjustedEmissionRate.monthID = ZoneMonthHour.monthID and 

WeightedAndAdjustedEmissionRate.hourID=ZoneMonthHour.hourID and

pollutantProcessID = 301 

boundedSpecificHumidity = GREATEST(21.0, 

LEAST(specificHumidity,124.0)) 

143
K = 1.0 – ( (boundedSpecificHumidity – 75.0) * humidityCorrectionCoeff) 

meanBaseRate = meanBaseRate * K 

CREC-9: Multiply fully weighted and adjusted emission rates by source hour 

operating (SHO) activity to generate inventory 

Input Variables: 

meanBaseRate (from WeightedAndAdjustedEmissionRate table from step 8) 

SHO (from SHO table) 

yearID, stateID, countyID, zoneID, linkID from MasterLoop context

pollutantID, processID from PollutantProcessAssoc table 

roadTypeID from Link table 

Output Variable: 

emissionQuant (in MOVESWorkerOutput table) 

Calculation:

For all records in join of SHO, WeightedAndAdjustedEmissionRate, 

HourDay, Link, and PollutantProcessAssoc tables where:

SHO.linkID = linkID value from MasterLoopContext and 

WeightedAndAdjustedEmissionRate.linkID = SHO.linkID and 

 SHO.yearID = WeightedAndAdjustedEmissionRate.yearID and 

yearID – SHO.ageID 

 = WeightedAndAdjustedEmissionRate.modelYearID and

SHO.monthID = WeightedAndAdjustedEmissionRate.monthID and 

 SHO.sourceTypeID = WeightedAndAdjustedEmissionRate.sourceTypeID

and 

SHO.hourDayID = HourDay.hourDayID and 

HourDay.hourID = WeightedAndAdjustedEmissionRate.hourID and

HourDay.dayID = WeightedAndAdjustedEmissionRate.dayID and 

 WeightedAndAdjustedEmissionRate.polProcessID 

=PollutantProcessAssoc.polProcessID 

roadTypeID = Link.roadTypeID 

SCC = null 

emissionQuant(stateID, countyID, zoneID, linkID, roadTypeID, yearID, 

monthID, dayID, hourID, pollutantID, processID, sourceTypeID,

modelYearID, fuelTypeID, SCC) 

= meanBaseRate * SHO 

CREC-10: Conditionally convert results by sourceTypeID to results by SCC 

This step is only performed when the run specification requires output by SCC 

Input Variables: 

SCCVTypeFraction (from SCCVTypeDistribution table) 

SCCRoadTypeFraction(from SCCRoadTypeDistribution table) 

SCC from SCC table 

emissionQuant from MOVESWorkerOutput table from step 9) 

sourceTypeID, modelYearID from SourceTypeModelYear

Output Variable: 

144
emissionQuant (in MOVESWorkerOutput table) 

Calculation:

From join of SCCVtypeDistribution, SCC, SourceTypeModelYear, and 

SCCRoadTypeDistribution where: 

zoneID = zoneID from master loop context

SourceTypeModelYear.sourceTypeModelYearID = 

 SCCVtypeDistribution.sourceTypeModelYearID and 

SCC.SCCVtypeID = SCCVtypeDistribution.SCCVtypeID and 

SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeID and 

MOVESWorkerOutput.sourceTypeID = sourceTypeModelYear.sourceTypeID and

SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeID and 

MOVESWorkerOutput.modelYearID = sourceTypeModelYear.modelYearID and 

MOVESWorkerOutput.fuelTypeID = SCCVtypeDistribution.fuelTypeID and 

MOVESWorkerOutput.roadTypeID = SCCRoadTypeDistribution.roadTypeID 

SCC= SCC.SCC 

emissionQuant = sum of emissionQuant * SCCVtypeFraction *

SCCRoadTypeFraction over sourceTypeID and roadTypeID 

sourceTypeID = null 

roadTypeID = null

linkID = null 

145
10.22. Criteria Pollutant Start EmissionCalculator (CSEC) 

10.22.1. General Description 

This EmissionCalculator signs up with the MOVES master looping mechanism at the 

Year level which, for the start process, means that a single execution need deals with one 

Zone and one Year. 

The major steps of the calculation are as follows: 

Preliminary Steps: 

CSEC-1 Calculate emission rates which account for I/M programs 

This step has two substeps: 

The first substep calculates an intermediate IMAdjustment table from the contents 

of the IMCoverage table for a particular zone and year. It puts the information 

into a usable form. The form of the IMCoverage table, in particular the use of 

model year ranges as non-key fields and the presence of information only where 

I/M programs exist, was constrained by overall table size considerations. To be 

used in subsequent steps the information needs to be into a more usable form, 

which this substep accomplishes. 

The second sub-step combines information from the EmissionRate table and the 

IMAdjustment table produced in the first substep to produce an intermediate 

EmissionRatesWithIM table. The function here is to weight the meanBaseRate 

and meanBaseRateIM fields together using the IM fractions calculated in the 

previous substep. (This makes the “blended” rates dependent upon yearID and 

countyID, but we are executing for a single Year and County) 

CSEC-2 Calculate fuel-supply-weighted fuel adjustment factors 

This step has two substeps: 

The first substep uses the FuelAdjustment and County tables to produce an 

intermediate CountyFuelAdjustment table specific to the county containing the 

zone being executed. It resolves the GPA and non-GPA fuel adjustment factors 

into a single factor based on the GPAFract value in the County table. It is still at 

the fuelFormulation level. (This step is repeated unnecessarily for each zone and 

year in the county, but is a minor one.) 

The second substep uses CountyFuelAdjustment and the FuelSupply table to 

produce an intermediate FuelSupplyAdjustment table of fuel adjustment factors at 

the fuelTypeID level. 

CSEC-3 Calculate temperature adjustment factors 

146
This step uses the StartTempAdjustment table along with temperature information 

from the ZoneMonthHour table to produce an intermediate METStartAdjustment 

table. This step is repeated unnecessarily for the zone for each year. 

The central core model calculations

CSEC-4 Apply Start Temperature Adjustment to Emission Rates. 

This step adds the start temperature adjustment factors determined CSEC-3 to the 

EmissionRatesWithIM table to produce an intermediate 

EmissionRatesWithIMAndTemp table. 

CSEC-5 Weight EmissionRates by Source Bin 

This step applies the source bin distributions to the 

EmissionRatesWithIMAndTemp table from the previous step to produce an 

intermediate METSourceBinEmissionRates table. FuelType distinctions from

the source bin classification are preserved but other source bin discriminators 

used in the start process (currently engine technology and regulatory class) are 

aggregated out. The modelYearID distinction is present in the 

EmissionRatesWithIMAndTemp table and is preserved, effectively subsuming the 

role of modelYearGroupID as a source bin discriminator. 

CSEC-6 Weight temperature-adjusted emission rates by operating mode 

This step applies the operating mode distributions to the results of step 5 to 

produce an intermediate ActivityWeightedEmissionRate table. This can be done 

since no further information is operating mode dependent. The 

ActivityWeightedEmissionRate table is at the level of the MOVESWorkerOutput 

by SourceType. 

CSEC-7 Apply fuel adjustment factors 

This step applies the fuel supply adjustment factors from step 2, stored in the 

FuelSupplyAdjustment table, to the results of step 6. 

CSEC-8 Multiply by start activity

This step multiplies the result of step 7 by the activity from the Starts table. 

CSEC-9 Convert results by source type into results by SCC 

This step is performed only when the run specification requests output by SCC 

code and has two substeps. 

The first substep produces an SCCDistribution table from the 

SCCSourceTypeDistribution and SCCRoadTypeDistribution tables. This is 

simplified by the fact that start emissions are associated only with the off network 

roadtype, so that only 12 of the 144 SCC codes are involved. 

147
The second substep applies the SCCDistribution table to the results of step 9 to 

convert the output from being by sourceTypeID to being by SCC. 

Implicit in these calculations is that the additional fields of stateID, countyID, and 

roadTypeID are added to the product table as needed by the MOVESOutput table format. 

The roadTypeID for start emissions is always 1. 

10.22.2. Detailed Calculation Steps 

CSEC-1: Calculate emission rates which account for I/M programs 

CSEC 1-a: Complete I/M adjustment fraction information 

Input Variables: 

begModelYearID, endModelYearID, IMAdjustFract (IMCoverage table)

countyID, zoneID, yearID (from Master Loop Context). 

ageID (AgeCategory table) 

regClassID (RegulatoryClass table) 

Output Variable: 

IMAdjustFract (in intermediate IMAdjustment table) 

Calculation:

For zoneID, yearID in Master Loop Context, 

for start process (which is also the Master Loop Context process)

 of all pollutants in runSpec which this calculator calculates 

for all ageID in AgeCategory table, 

for all fuelTypeID in IMCoverage, 

for all regClassID values in RegulatoryClass except regClassID=0 

modelYearID = yearID-ageID 

IMAdjustFract (zoneID, yearID, polProcessID, modelYearID, fuelTypeID, 

regClassID) = 

= IMAdjustFract if IMCoverage record exists

with begModelYearID <= modelYearID <= endModelYearID 

= 0.0 otherwise 

CSEC 1-b: Combine I/M and non I/M rates 

Input Variables: 

meanBaseRate and meanBaseRateIM (EmissionRate table) 

fuelTypeID, regClassID (from SourceBin table) 

modelYearGroupID (from PollutantProcessModelYear table) 

IMAdjustFract (from step 1-a)

Output Variable: 

meanBaseRate (in intermediate table EmissionRateWithIM)

Calculation:

For all records in join of IMAdjustment Table to EmissionRate table WHERE 

IMAdjustment.polProcessID=EmissionRate.polProcessID 

IMAdjustment.fuelTypeID = SourceBin.fuelTypeID AND 

148
IMAdjustment.regClassID = SourceBin.regClassID AND

IMAdjustment.modelYearID= PollutantProcessModelYear.modelYearID AND 

IMAdjustment.polProcessID = PollutantProcessModelYear.polProcessID AND 

PollutantProcessModelYear.modelYearGroupID = 

SourceBin.modelYearGroupID AND

EmissionRate.sourceBinID=SourceBin.sourceBinID 

meanBaseRate (zoneID, yearID, polProcessID, modelYearID, sourceBinID, 

opModeID) = meanBaseRate + (IMAdjustFract * (meanBaseRateIMmeanBaseRate)) 

Note that IMAdjustFract might be greater than 1.0. 

CSEC-2: Calculate fuel-supply-weighted Fuel Adjustment Factors 

CSEC 2-a: Combine GPA and non GPA fuel adjustment factors 

Input Variables: 

fuelAdjustment and fuelAdjustmentGPA (from FuelAdjustment table)

GPAFract (from County table) 

countyID (from MasterLoop Context)

Output Variable: 

fuelAdjustment (in intermediate CountyFuelAdjustment table) 

Calculation:

For countyID from Master Loop Context,

For all records in FuelAdjustment 

for start process (which is also the Master Loop Context process)

 of all pollutants in runSpec which this calculator calculates 

fuelAdjustment (countyID, polProcessID, fuelMYGroupID, sourceTypeID,

fuelFormulationID ) 

= fuelAdjustment + GPAFract*(fuelAdjustmentGPA-fuelAdjustment)

NOTE: An internal MOVES model component, the DefaultDataMaker, has set fuelAdjustment=1

for cases which are not populated in fuelAdjustment. 

CSEC 2-b: Aggregate county fuel adjustments to fuel type 

Input Variables: 

fuelAdjustment (from CountyFuelAdjustment table from step 2-a)

marketShare (from FuelSupply table) 

fuelSubTypeID (from FuelFormulation table) 

fuelTypeID (from FuelSubtype table)

monthID (from MonthOfAnyYear table) 

yearID (from MasterLoopContext) 

fuelYearID (from Year table)

modelYearID ( from PollutantProcessModelYear table) 

Output Variable: 

fuelAdjustment (in intermediate FuelSupplyAdjustment table) 

Calculation:

For all records in join of CountyFuelAdjustment and FuelSupply where 

149
CountyFuelAdjustment.countyID=FuelSupply.countyID and 

Year.yearID = yearID from MasterLoopContext and 

Year.fuelYearID = FuelSupply.yearID and 

FuelSupply.monthGroupID = MonthOfAnyYear.monthGroupID and 

CountyFuelAdjustment.monthGroupID=FuelSupply.monthGroupID and

CountyFuelAdjustment.fuelFormulationID=FuelFormulation.fuelFormulationID and 

FuelFormulation.fuelSubtypeID=FuelSubType.fuelSubtypeID and 

 PollutantProcessModelYear.polProcessID= 

CountyFuelAdjustment.polProcessID and 

PollutantProcessModelYear.fuelMYGroupID= 

CountyFuelAdjustment.fuelMYGroupID

fuelAdjustment (countyID, yearID, monthID, polProcessID, modelYearID,

 sourceTypeID, fuelTypeID )

= sum (fuelAdjustment * marketShare) over all fuel formulations in each fuel

type. 

CSEC-3: Calculate temperature adjustment factors 

Input Variables: 

tempAdjustTermA, tempAdjustTermB (from StartTempAdjustment table) 

temperature (from ZoneMonthHour table) 

zoneID (from MasterLoop context)

modelYearID ( from PollutantProcessModelYear table) 

Output Variable: 

temperatureAdjustment (in intermediate METStartAdjustment table) 

Calculation:

For zoneID in Master Loop Context, 

For start process (which is also the Master Loop Context process)

 of all pollutants in runSpec which this calculator calculates 

For all records in join of ZoneMonthHour , StartTemperatureAdjustment and 

PollutantProcessModelYear where:

PollutantProcessModelYear.polProcessID = 

 StartTempAdjustment.polProcessID and 

PollutantProcessModelYear.modelYearGroupID= 

StartTempAdjustment.modelYearGroupID 

temperatureAdjustment(zoneID, monthID, hourID, polProcessID, modelYearID, 

fuelTypeID, opModeID) 

= tempAdjustTermA * (temperature-75) + tempAdjustTermB (temperature-75)2 

+ tempAdjustTermC * (temperature-75)3 

CSEC-4: Apply temperature adjustment factors 

Input Variables: 

meanBaseRate (from EmissionRateWithIM table from step 1-b) 

temperatureAdjustment (from METStartAdjustment table from step 3)

Output Variable: 

meanBaseRate (in a new intermediate EmissionRateWithIMAndTemp table) 

Calculation:

For all records in join of METStartAdjustment and EmissionRateWithIM, 

150
(Using SourceBin table to relate METSTartAdjustment.fuelTypeID to

EmissionRateWithIM.sourceBinID)

EmissionRateWithIMAndTemp.meanBaseRate (zoneID, monthID, hourID,

yearID, polProcessID, modelYearID, sourceBinID, opModeID) = 

EmissonRateWithIM.meanBaseRate + temperatureAdjustment 

CSEC-5: Weight emission rates by source bin 

Input Variables: 

meanBaseRate (from EmissionRateWithIMAndTemp table from step 4)

sourceBinActivityFraction (from SourceBinDistribution table) 

Output Variable: 

meanBaseRate (in an intermediate METSourceBinEmissionRate table) 

Calculation:

For all records in join of EmissionRateWithIMAndTemp, SourceBin, 

SourceBinDistribution, and 

SourceTypeModelYear where: 

SourceBinDistribution.sourceBinID = SourceBin.sourceBinID and

SourceBinDistribution.sourceTypeModelYearID

 = SourceTypeModelYear.sourceTypeModelYearID 

EmissionRateWithIMAndTemp.polProcessID= 

SourceBinDistribution.polProcessID and

EmissionRateWithIMAndTemp.sourceBinID= 

SourceBinDistribution.sourceBinID and

SourceTypeModelYear.modelYearID =

EmissionRateWithIMAndTemp.modelYearID 

Note: This calculation can take advantage of the fact that there is only one

modelYearGroupID present for a modelYearID.

meanBaseRate(zoneID, monthID, hourID, yearID, polProcessID, sourceTypeID, 

modelYearID, fuelTypeID, opModeID) 

= sum over engTechID and regClassID (sourceBinActivityFraction *

meanBaseRate) 

CSEC-6: Weight temperature-adjusted emission rates by operating mode 

Input Variables: 

meanBaseRate (from METSourceBinEmissionRate table from step 5) 

opModeFraction (from OperatingModeDistribution table) 

linkID (from MasterLoopContext)

 (Note: calculations only performed for off-network links) 

Output Variable: 

meanBaseRate (in an intermediate ActivityWeightedEmissionRate table) 

Calculation:

For linkID from MasterLoop context. 

151
For all records in join of METSourceBinEmissionRate, HourDay, and

OperatingModeDistribution where: 

OpModeDistribution.hourDayID = HourDay.hourDayID and

HourDay.hourID=METSourceBinEmissionRate.hourID and

OpModeDistribution.polProcessID = 

METSourceBinEmissionRate.polProcessID and 

OpModeDistribution.sourceTypeID = 

METSourceBinEmissionRate.sourceTypeID and 

OpModeDistribution.opModeID = METSourceBinEmissionRate.opModeID

meanBaseRate(zoneID, yearID, monthID, dayID, hourID, polProcessID,

sourceTypeID, modelYearID, fuelTypeID)

= sum over opModeID (meanBaseRate * opModeFraction)

CSEC-7: Apply fuel adjustment factor 

Input Variables: 

meanBaseRate (from ActivityWeightedEmissionRate table from step 6)

fuelAdjustment (from FuelSupplyAdjustment table from step 2) 

Output Variable: 

meanBaseRate (in intermediate ActivityWeightedEmissionRate table) 

Calculation:

For all records in join of ActivityWeightedEmissionRate and

FuelSupplyAdjustment using: yearID, monthID, polProcessID,

sourceTypeID, modelYearID, and fuelTypeID 

meanBaseRate(zoneID, yearID, monthID, dayID, hourID, polProcessID,

sourceTypeID, modelYearID, fuelTypeID)

= meanBaseRate * fuelAdjustment 

CSEC-8: Multiply emission rates by start activity to generate inventory 

Input Variables: 

meanBaseRate (from ActivityWeightedEmissionRate table from step 7)

starts (from Starts table) 

yearID, stateID, countyID, zoneID, linkID from MasterLoop context

pollutantID, processID from PollutantProcessAssoc table 

Output Variable: 

emissionQuant (in MOVESWorkerOutput table) 

Calculation:

For all records in join of Starts, ActivityWeightedEmissionRate, HourDay, and

PollutantProcessAssoc tables where:

Starts.zoneID = zoneID value from MasterLoopContext

Starts.yearID = yearID value from MasterLoopContext

yearID – Starts.ageID 

 = ActivityWeightedEmissionRate.modelYearID and 

Starts.monthID = ActivityWeightedEmissionRate.monthID and 

 Starts.sourceTypeID = ActivityWeightedEmissionRate.sourceTypeID and 

Starts.hourDayID = HourDay.hourDayID and

152
HourDay.hourID = ActivityWeightedEmissionRate.hourID and

HourDay.dayID = ActivityWeightedemissionRate.dayID and 

 ActivityWeightedEmissionRate.polProcessID 

=PollutantProcessAssoc.polProcessID 

roadTypeID = 1 

SCC = null 

emissionQuant(stateID, countyID, zoneID, linkID, roadTypeID, yearID, 

monthID, dayID, hourID, pollutantID, processID, sourceTypeID,

modelYearID, fuelTypeID, SCC) 

= meanBaseRate * starts 

CSEC-9: Conditionally convert results by sourceTypeID to results by SCC 

This step is only performed when the run specification requires output by SCC 

CSEC 9-a: Calculate combined SCC Distribution (by both SCCVtype and SCCRoadtype) 

Input Variables: 

SCCVtypeFraction (from SCCVtypeDistribution table) 

SCC from SCC table 

Output Variable: 

SCCFraction (in intermediate SCCDistribution table) 

Calculation:

From join of SCCVtypeDistribution, SCC, and SourceTypeModelYear where:

SourceTypeModelYear.sourceTypeModelYearID = 

 SCCVtypeDistribution.sourceTypeModelYearID and 

SCC.SCCVtypeID = SCCVtypeDistribution.SCCVtypeID and 

SCC.SCCroadTypeID=1

SCCFraction(zoneID, sourceTypeID, modelYearID, fuelTypeID, SCC) =

SCCVtypeFraction 

CSEC 9-b: Apply SCCDistribution 

Input Variables: 

emissionQuant (from MOVESWorkerOutput table from step 8) 

SCCFraction (from SCCDistribution from step 9-a) 

Output Variable: 

emissionQuant (in MOVESWorkerOutput table) 

Calculation:

sourceTypeID=null 

from join of MOVESWorkerOutput and SCCDistribution using:

 sourceTypeID, modelYearID, fuelTypeID

emissionQuant(stateID, countyID, zoneID, linkID, roadTypeID, yearID, 

monthID, dayID, hourID, pollutantID, processID, sourceTypeID,

modelYearID, fuelTypeID, SCC) 

= sum over sourceTypeID (emissionQuant*SCCFraction) 

153
10.23. Basic Running PM EmissionCalculator 

10.23.1. General Description 

This calculator computes the emissions of OCarbon and ECarbon PM2.5 from the 

running exhaust process (polProcessIDs 11101 and 11201). It signs up with the 

MOVES master looping mechanism at the YEAR level. It retrieves its emission rates 

from EmissionRateByAge, and only considers the meanBaseRate, ignoring 

meanBaseRateIM. The only calculation it performs, beyond the core model 

considerations of retrieving total activity from SHO, applying source bin distributions 

and operating mode distributions, is to apply a multiplicative temperature adjustment 

factor retrieved from the TemperatureAdjustment table. 

10.23.2. Detailed Calculation Steps 

Step BRPMC-1: Weight Emission Rates by Operating Mode 

Structurally this combines the OpModeDistribution and EmissionRateByAge tables. 

Relative to EmissionRateByAge this step removes opModeID but adds hourDayID and 

sourceTypeID. If the calculator executed above the LINK level, linkID would also have 

to be added. 

Input Variables: 

polProcessID, linkID from Master Loop Context 

EmissionRateByAge table from MOVESExecution database 

OpModeDistribution table from MOVESExecution database 

Output Variables: 

Intermediate OpModeWeightedEmissionRate table 

 Key fields: hourDayID, sourceTypeID, sourceBinID, ageGroupID 

 Data field: opModeWeightedMeanBaseRate 

Calculation: 

For polProcessID, linkID from Master Loop Context 

For all hourDayID, sourceTypeID in Run Specification 

 opModeWeightedMeanBaseRate = SUM(opModeFraction * meanBaseRate) 

Step BRPMC-2: Weight Emission Rates by Source Bin 

154
This combines the results of the previous step with the SourceBinDistribution Table. In 

terms of table structure relative to the results of the previous step, this removes the 

engTechID and regClassID components of sourceBinID and fully expands ageGroupID 

and the modelYearGroupID component of sourceBinID into individual modelYearIDs. 

Because SourceBinDistributions are by individual model year, and the results of the 

previous step are by ageGroupID, yearID is added. 

Input Variables: 

OpModeWeightedEmissionRate table from previous step 

SourceBinDistribution table from MOVESExecution database 

 SourceTypeModelYear table from MOVESExecution database 

PollutantProcessModelYear table from MOVESExecution database 

SourceBin table from MOVESExecution database 

AgeCategory table from MOVESExecution database 

yearID value from the master loop context 

Output Variables: 

Intermediate FullyWeightedEmissionRate table 

Key fields: yearID, hourDayID, sourceTypeID, fuelTypeID, modelYearID 

Data field: fullyWeightedMeanBaseRate 

Calculation: 

For yearID in the master loop context 

modelYearID = yearID – ageID 

fullyWeightedMeanBaseRate = 

SUM(sourceBinActivityFraction * opModeWeightedMeanBaseRate) 

Step BRPMC-3: Multiply Emission Rates by Activity 

This combines the results of the previous step with the SHO table. In terms of table 

structure relative to the results of the previous step, this adds monthID. 

Input Variables: 

FullyWeightedEmissionRate table from previous step 

SHO table from MOVESExecution database 

monthID values from the run specification 

Output Variables: 

 Intermediate UnadjustedEmissionResults table 

155
Key fields: yearID, monthID, hourDayID, sourceTypeID, fuelTypeID, 

modelYearID 

 Data field: unadjustedEmissionQuant 

Calculation: 

modelYearID = calendar year - ageID 

For all monthID values in the run specification 

unadjustedEmissionQuant = fullyWeightedMeanBaseRate * SHO 

Step BRPMC-4: Apply Temperature Adjustment 

This applies the temperature adjustment to the results of the previous step. The table 

resulting from this step could have the same structure as that produced by the previous 

step, but it seems desirable to decompose hourDayID into hourID and dayID since this is 

needed to join to the ZoneMonthHour table and is the form eventually needed for 

MOVEWorkerOutput. 

Input Variables: 

zoneID and polProcessID from the MasterLoopContext 

UnadjustedEmissionResults table from previous step 

ZoneMonthHour table from MOVESExecution database 

TemperatureAdjustment table from MOVESExecution database 

HourDay table from MOVESExecution database 

Output Variables: 

Intermediate AdjustedEmissionResults table 

Key fields: yearID, monthID, dayID, hourID, sourceTypeID, fuelTypeID, 

modelYearID 

 Data field: emissionQuant 

Calculation: 

For the polProcessID and zoneID in the Master Loop Context 

emissionQuant = unadjustedEmissionQuant * (1.0 + tempAdjustTermA * 

(temperature-75) + tempAdustTermB (temperature-75)2

) 

Step BRPMC-5: Convert Results to Structure of MOVESWorkerOutput by 

sourceTypeID 

156
Structurally we need to add stateID, countyID, zoneID, linkID, roadTypeID, SCC (as null 

value) and decompose polProcessID into pollutantID and processID. 

Input Variables: 

stateID, linkID from MasterLoop Context 

Link table from MOVESExecution 

PollutantProcessAssoc table from MOVESExecution 

 AdjustedEmissionResults table from previous step 

Output Variables: 

 MOVESWorkerOutput Table 

Key fields: yearID, monthID, dayID, hourID, stateID, countyID, zoneID, 

linkID, pollutantID, processID, ,sourceTypeID, fuelTypeID, 

modelYearID, roadTypeID, SCC 

 Data field: emissionQuant 

Calculation: 

MOVESWorkerOutput.emissionQuant =AdjustedEmissionResults.emissionQuant 

 countyID = Link.countyID 

zoneID = Link.zoneID 

roadTypeID = Link.roadTypeID 

 pollutantID = PollutantProcessAssoc.pollutantID

processID = PollutantProcessAssoc.processID 

SCC = null 

Step BRPMC-6: Conditionally Convert Results to Structure of 

MOVESWorkerOutput by SCC 

This step is only performed when the run specification requires output by SCC. It is 

performed in several other emission calculators, e.g. step 10 of the CREC, and is repeated 

here: 

Input Variables: 

SCCVTypeFraction (from SCCVTypeDistribution table) 

SCCRoadTypeFraction(from SCCRoadTypeDistribution table) 

SCC from SCC table 

emissionQuant from MOVESWorkerOutput table from previous step 

sourceTypeID, modelYearID from SourceTypeModelYear 

Output Variable: 

157
emissionQuant (in restructured MOVESWorkerOutput table) 

Calculation:

From join of SCCVtypeDistribution, SCC, SourceTypeModelYear, and 

SCCRoadTypeDistribution where: 

zoneID = zoneID from master loop context 

SourceTypeModelYear.sourceTypeModelYearID = 

 SCCVtypeDistribution.sourceTypeModelYearID and 

SCC.SCCVtypeID = SCCVtypeDistribution.SCCVtypeID and 

SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeID and 

MOVESWorkerOutput.sourceTypeID = 

sourceTypeModelYear.sourceTypeID and 

MOVESWorkerOutput.modelYearID = sourceTypeModelYear.modelYearID 

and 

MOVESWorkerOutput.fuelTypeID = SCCVtypeDistribution.fuelTypeID and 

MOVESWorkerOutput.roadTypeID = 

SCCRoadTypeDistribution.roadTypeID 

SCC= SCC.SCC 

emissionQuant = sum of emissionQuant * SCCVtypeFraction * 

SCCRoadTypeFraction over sourceTypeID and roadTypeID 

sourceTypeID = null 

roadTypeID = null 

linkID = null 

158
10.24. Sulfate PM EmissionCalculator (SEC) 

10.24.1. General Description 

This calculator will gives the model the capability to compute sulfate PM 

emissions (both PM2.5 and PM10, though these quantities are equal). The basic design 

of the calculator is to compute sulfate emissions as the product of a sulfate emission 

factor and total energy consumption of the corresponding MOVES emission process. 

The MOVES SulfatePMEmissionsCalculator is ‘chained to’ the Total Energy

Consumption Calculator. 

The pollutant-processes for which emission calculations are performed by this 

calculator are: 

SulfatePM2.5 – running exhaust polProcessID = 11501 

SulfatePM2.5 – start exhaust polProcessID = 11502 

SulfatePM2.5 – extended idle exhaust polProcessID = 11590 

SulfatePM10 – running exhaust polProcessID = 10501 

SulfatePM10 – start exhaust polProcessID = 10502 

SulfatePM10 – extended idle exhaust polProcessID = 10590 

Inputs to the calculator are: 

 MOVESWorkerOutput.emissionQuant for total energy consumption of the 

corresponding emissions process (running exhaust, start exhaust, or extended idle 

exhaust). 

 FuelFormulation.sulfurLevel. (Market-weighted average per 

FuelSupply.marketShare) 

 FuelType.energyContent 

 SulfateEmissionRate.meanBaseRate.

The meanBaseRate sulfate emission factors for gasoline vehicles are unitless and

scaled to yield grams of SO4 particulate when multiplied by the product of the grams of 

gasoline fuel consumed * ppm sulfur of the fuel. 

159
Because the calculations are based on the emission results for total energy consumption 

this calculator is ‘chained’ to the TotalEnergyConsumptionCalculator which executes at 

the YEAR level. Like all emission calculators its output is 

MOVESWorkerOutput.emissionQuant. 

10.24.2 Detailed Calculation Steps 

The calculation will be performed in two basic steps: 

Step SEC-1 

The first step calculates the marketshare-weighted-average sulfur level of the fuel supply 

at the place (county) and times (year-months) for which the master loop is executing. 

Step SEC-2 

The second step completes the calculation, the basic equation for which is simply: 

emissionQuant(SulfatePM) = SulfateEmissionRate.meanBaseRate * averageSulfurLevel 

(from first step) * emissionQuant(EnergyConsumption) / 

FuelType.energyContent 

A sample of this calculation, showing the engineering units involved, is: 

(1.4807e-08 gSO4 / g fuel – ppm S ) * (30 ppm gasoline S) * 1000 KJ/hr / 10 KJ / gram fuel 

= 4.442e-05 g/SO4 / hr 

160
10.25. Basic Start PM EmissionCalculator 

10.25.1. General Description 

This calculator computes the emissions of OCarbon and ECarbon PM2.5 from the start 

exhaust process (polProcessIDs 11102 and 11202). It signs up with the MOVES master 

looping mechanism at the YEAR level. It retrieves its emission rates from 

EmissionRate, and only considers the meanBaseRate, ignoring meanBaseRateIM. The 

only calculation it performs, beyond the core model considerations of retrieving total 

activity from Starts, applying source bin distributions and operating mode distributions, is 

to apply a multiplicative temperature adjustment factor retrieved from the 

TemperatureAdjustment table (ironically not from the StartTemperatureAdjustment 

table). 

10.25.2. Detailed Calculation Steps 

Because this calculator is very much like Basic Running PM Emission Calculator, and is 

actually a bit simpler because its emission rates do not vary by age, the details of that 

calculation are not repeated here. 

161
10.26. Basic Brake and Tire Wear Emission Calculators 

10.26.1. General Description 

These two almost identical calculators compute the tirewear and brakewear process 

emissions of OCarbon and ECarbon PM2.5 (polProcessIDs 11609 and 11710). They 

sign up with the MOVES master looping mechanism at theYEAR level. They retrieve 

their emission rates from EmissionRate, and only consider the meanBaseRate, ignoring 

meanBaseRateIM. The only operations they perform are the core model calculations of 

retrieving total activity from SHO, applying source bin distributions and (possibly) 

operating mode distributions. The brake wear calculation does apply an operating mode 

distribution; the tire wear calculation does not. 

10.26.2. Detailed Calculation Steps 

Because this calculator is very much like Basic Running PM Emission Calculator, and is 

actually a bit simpler because its emission rates do not vary by age and it does not apply 

at temperature adjustment the details of that calculation are not repeated here. 

162
10.27. CriteriaAndPMExtendedIdleEmissionCalculator 

10.27.1. General Description 

This component calculates the the extended idle process emissions of 5 criteria 

and PM pollutants, specifically those of: 

Total Hydrocarbons (polProcessID = 190) 

Carbon Monoxide (polProcessID = 290) 

Oxides of Nitrogen (polProcessID = 390) 

OCarbon PM Size 2.5 (polProcessID = 11190) 

ECarbon PM Size 2.5 (polProcessID = 11290) 

It signs up with the MOVES master looping mechanism at theYEAR level. 

Extended idle emissions are associated with the single link in each zone 

representing off highway network locations. 

This calculator retrieves its emission rates from EmissionRate, and only considers 

the meanBaseRate field, ignoring meanBaseRateIM. It applies a multiplicative 

temperature adjustment factor retrieved from the TemperatureAdjustment table, an 

ACAdjustment factor as done in several other EmissionCalculators, and a humidity 

correction factor to NOx emissions as done by the CriteriaRunningEmissionCalculator. 

It does not apply an operating mode distribution. 

10.27.2. Detailed Calculation Steps 

Step CEIC-1: Calculate Temperature and NOx Humidity Adjustments 

Input Variables:

tempAdjustTermA and tempAdjustTermB 

from the TemperatureAdjustment Table 

temperature and specificHumidity from the ZoneMonthHour Table 

humidityCorrectionCoeff from the FuelType Table 

Output Variables: 

An intermediate METAdjustment table: 

Key fields: zoneID, monthID, hourID, polProcessID, fuelTypeID 

Data fields: temperatureAdjustment, K (the NOx correction factor) 

163
Calculations: 

temperatureAdjustment = 1.0 + (tempAdjustTermA * (temperature-75.0)) + 

(tempAdjustTermB * (temperature-75) * (temperature-75)) 

K= 1.0 – ((boundedSpecificHumidity – 75.0) * humidityCorrectionCoeff) 

 Where 

boundedSpecificHumidity = GREATEST(21.0,LEAST(specificHumidity,124.0)) 

Step CEIC-2: Calculate AC Adjustment Factor 

This step has 3 substeps: 

Step CEIC-2a: Calculate AC On Fraction 

Input Variables: 

heatIndex from ZoneMonthHour table 

ACActivityTermA, B, and C from the MonthGroupHour Table 

MonthOfAnyYear table used to associate month groups and months 

Output Variables: 

An intermediate ACOnFraction table:

Key Fields: zoneID, monthID, hourID 

Date Field: ACOnFraction 

Calculation:

ACOnFraction = ACActivityTermA + ACActivityTermB * heatIndex + 

ACActivityTermC * heatIndex * heatIndex 

If ACOnFraction < 0.0 Then ACOnFraction = 0.0 

If ACOnFraction > 1.0 Then ACOnFraction = 1.0 

Step CEIC-2b: Calculate AC Activity Fraction 

Input Variables: 

ACOnFraction from previous sub-step 

ACPenetrationFraction from SourceTypeModelYearTable 

functioningACFraction from SourceTypeAge Table 

164
Output Variables: 

An intermediate ACActivityFraction table:

Key Fields: zoneID, monthID, hourID, sourceTypeID, modelYearID 

Date Field: ACActivityFraction

Calculation: 

ageID = calendar year – modelYearID 

(needed to join to the SourceTypeAge table) 

ACActivityFraction = ACOnFraction * ACPenetrationFraction * 

functioningACFraction 

Step CEIC-2c: Calculate ACAdjustmentFraction 

Input Variables: 

ACActivityFraction from previous sub-step 

 fullACAdjustment from FullACAdjustment table

Output Variables: 

An intermediate ACAdjustment table:

Key Fields: zoneID, monthID, hourID, sourceTypeID, modelYearID, 

 polProcessID 

Date Field: ACAdjustment 

Calculation: 

Assume FullACAdjustment populated only for a single opModeID 

ACAdjustment = 1.0 + ((fullACAdjustment-1.0) * ACActivityFraction) 

Step CEIC-3: Calculate SourceBin-Weighted Emission Rates 

This step weights emission rates, which vary by source bin, by the source bin 

distribution, retaining, however, the fuel type distinction because it is needed by 

subsequent steps and in the eventual output. The model year group distinction within 

source bin is subsumed by the broader model year distinction required in the output. 

Input Variables: 

165
meanBaseRate from the EmissionRate table 

 sourceBinActivityFraction from the SourceBinDistribution table 

The SourceBin table is needed to decompose sourceBinID values into their 

constituent components. 

The SourceTypeModelYear table is needed to decompose 

sourceTypeModelYearID values into their constituent sourceTypeID and 

modelYearID values. 

Output Variables: 

An intermediate SBWeightedEmissionRate Table

Key fields: polProcessID, sourceTypeID, modelYearID, fuelTypeID 

Data field: meanBaseRate 

Calculation: 

In joining these tables it can be assumed that only one modelYearGroupID will be 

present in the source bin distributions for a polProcessID and modelYearID. 

SBWeightedEmissionRate.meanBaseRate = 

sum(sourceBinActivityFraction * EmissionRate.meanBaseRate) 

Step CEIC-4: Apply Adjustment Factors to Emission Rates 

Input Variables: 

meanBaseRate from the SBWeightedEmissionRate table from the previous step 

temperatureAdjustment and K from the METAdjustment table produced by step 1 

ACAdjustment from the ACAdjustment table produced by step 2-c. 

Output Variables: 

An intermediate WeightedAndAdjustedEmissionRate table 

Key fields: polProcessID, sourceTypeID, modelYearID, fuelTypeID, zoneID, 

monthID, hourID 

Data field: meanBaseRate 

Calculation: 

K_ToUse = K if pollutantID=3 otherwise K_ToUse = 1.0 

166
WeightedAndAdjustedEmissionRate.meanBaseRate = 

SBWeightedEmissionRate.meanBaseRate * temperatureAdjustment * 

ACAdjustment * K_ToUse 

Step CEIC-5: Multiply Emission Rates by Activity 

Input Variables: 

 meanBaseRate from WeightedAndAdjustedEmissionRate table from step 4. 

extendedIdleHours from ExtendedIdleHours table. 

HourDay table needed to decompose hourDayID values in extendedIdleHours 

into dayID and hourID values. 

Output Variables: 

emissionQuant in an intermediate AdjustedEmissionResults table 

Key Fields: polProcessID, sourceTypeID, modelYearID, fuelTypeID, zoneID, 

monthID, hourID, dayID, yearID 

 Data Field: emissionQuant 

Calculations: 

ageID = calendar year – modelYearID 

(needed to join to the extendedIdleHours table) 

emissionQuant = meanBaseRate * extendedIdleHours 

Step CEIC-6: Convert Results to Structure of MOVESWorkerOutput by 

sourceTypeID 

Structurally we need to add stateID, countyID, linkID, roadTypeID , SCC (as null value) 

and decompose polProcessID into pollutantID and processID. 

Input Variables: 

stateID, countyID from MasterLoop Context 

linkID from Link table 

PollutantProcessAssoc table 

 AdjustedEmissionResults table from previous step 

Output Variables: 

167
 MOVESWorkerOutput Table 

Key fields: yearID, monthID, dayID, hourID, stateID, countyID, zoneID, 

linkID, pollutantID, processID ,sourceTypeID, fuelTypeID, modelYearID, 

roadTypeID, SCC 

 Data field: emissionQuant 

Calculations: 

MOVESWorkerOutput.emissionQuant =AdjustedEmissionResults.emissionQuant 

stateID = stateID from MasterLoop context 

countyID = countyID from MasterLoop context 

roadTypeID = 1 

linkID = value from Link table for zoneID where roadTypeID = 1 

 pollutantID = PollutantProcessAssoc.pollutantID

processID = PollutantProcessAssoc.processID 

SCC = null 

Step CEIC-7: Conditionally Convert Results to Structure of MOVESWorkerOutput 

by SCC 

This step is only performed when the run specification requires output by SCC. It is 

performed in several other emission calculators; this description has been elaborated to 

explicitly consider SCCProcID. 

Input Variables: 

SCCVTypeFraction (from SCCVTypeDistribution table) 

SCCRoadTypeFraction(from SCCRoadTypeDistribution table) 

SCCProcID from EmissionProcess table 

SCC from SCC table 

emissionQuant from MOVESWorkerOutput table from previous step

sourceTypeID, modelYearID from SourceTypeModelYear

Output Variable: 

emissionQuant (in restructured MOVESWorkerOutput table) 

Calculation:

From join of SCCVtypeDistribution, SCC, EmissionProcess, 

SourceTypeModelYear, and SCCRoadTypeDistribution where: 

zoneID = zoneID from master loop context

SourceTypeModelYear.sourceTypeModelYearID = 

 SCCVtypeDistribution.sourceTypeModelYearID and 

SCC.SCCVtypeID = SCCVtypeDistribution.SCCVtypeID and 

SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeID and 

SCC.SCCProcID = EmissionProcess.SCCProcID and

EmissionProcess.processID = processID from masterloop context 

168
MOVESWorkerOutput.sourceTypeID = sourceTypeModelYear.sourceTypeID and

MOVESWorkerOutput.modelYearID = sourceTypeModelYear.modelYearID and 

MOVESWorkerOutput.fuelTypeID = SCCVtypeDistribution.fuelTypeID and 

MOVESWorkerOutput.roadTypeID = SCCRoadTypeDistribution.roadTypeID 

SCC= SCC.SCC 

emissionQuant = sum of emissionQuant * SCCVtypeFraction *

SCCRoadTypeFraction over sourceTypeID and roadTypeID 

sourceTypeID = null 

roadTypeID = null

linkID = null 

169
10.28. Permeation Calculator 

10.28.1. General Description 

This component signs up with the MOVES master looping mechanism at the MONTH 

level. 

Its inputs include: 

Source Bin Distributions 

Operating Mode Distributions 

The EmissionRateByAge table 

The AverageTankTemperature table 

The TemperatureAdjustment Table 

The FuelAdjustment Table (and associated tables used to determine fuel market 

shares) 

Its results are placed in the same MOVESOutput table format as other 

EmissionCalculators. 

10.28.2. Detailed Calculation Steps 

PC-1: Weight emission rates by source bin 

Input Variables: 

- meanBaseRate (from EmissionRateByAge table) 

- sourceBinActivityFraction (from SourceBinDistribution table) 

Output Variables: 

- meanBaseRate (intermediate table SBWeightedPermeationRate) 

Calculation:

meanBaseRate(zoneID, yearID, polProcessID, sourceTypeID, 

modelYearID, fuelTypeID) 

= sum (sourceBinActivityFraction * meanBaseRate) 

PC-2: Calculate weighted temperature adjustment 

Inputs: 

- averageTankTemperature (from averageTankTemperature) 

- opModeFraction (from operatingModeDistribution) 

- tempAdjustTermA (from temperatureAdjust) 

- tempAdjustTermB (from temperatureAdjust) 

Outputs: 

170
- weightedTemperatureAdjust (sourceTypeID, monthID, hourDayID, 

linkID, tankTemperatureGroupID) 

Preliminary Calculation: temperatureAdjustByOpmode (zoneID, monthID, 

hourDayID, hourDayID, tankTemperatureGroupID, opModeID) 

= tempAdjustTermA * etempAdjustTermB * averageTankTemperature (opModeID)

Calculation: weightedTemperatureAdjust 

 = SUM(temperatureAdjustByOpMode*opModeFraction) over all modes

PC-3: Calculate weighted fuel adjustment 

Input Variables: 

- fuelAdjustment (from fuelAdjustment table) 

- marketShare (from fuelSupply table) 

Output Variables: 

- weightedFuelAdjust(polProcessID, modelYearGroupID, 

sourceTypeID) 

Calculation: weightedFuelAdjust 

 = SUM(fuelAdjustment * marketShare) over all fuel formulations 

NOTE: An internal MOVES model component, the DefaultDataMaker, has set 

fuelAdjustment=1 for cases which are not populated in fuelAdjustment. 

PC-4: Calculate fuel adjusted meanBaseRate 

Input Variables: 

- meanBaseRate (SBWeightedEmissionRate from PC-1) 

- weightedFuelAdjust (PC-3) 

Output Variables: 

- FuelAdjustedMeanBaseRate (zoneID, yearID, polProcessID, 

sourceTypeID, modelYearID, fuelTypeID) 

Calculation: FuelAdjustedMeanBaseRate 

= meanBaseRate * weightedFuelAdjustment 

PC-5: Calculate fuel adjusted emissionQuant 

Input Variables: 

- fuelAdjustedMeanBaseRate (PC-4) 

- SourceHours (CMIT from TAG) 

171
Output Variables: 

- fuelAdjustedEmissionQuant (linkID, hourDayID, monthID, yearID, 

modelYearID, sourceTypeID) 

Calculation:

- fuelAdjustedEmissionQuant 

= fuelAdjustedMeanBaseRate * sourceHours 

PC-6: Calculate emissionQuant with temperature adjustment 

Input Variables: 

- fuelAdjustedEmissionQuant (PC-5) 

- weightedTemperatureAdjustment (PC-2) 

Output Variables: 

- emissionQuant (MOVES output table fields) 

Calculation:

- emissionQuant = fuelAdjustedEmissionQuant * 

weightedTemperatureAdjustment 

PC-7 Convert to SCC 

This step is only performed when the run specification requires output by SCC 

Input Variables: 

SCCVTypeFraction (from SCCVTypeDistribution table) 

SCCRoadTypeFraction(from SCCRoadTypeDistribution table) 

SCC from SCC table 

emissionQuant from MOVESWorkerOutput table from step 6) 

sourceTypeID, modelYearID from SourceTypeModelYear

Output Variable: 

emissionQuant (in MOVESWorkerOutput table) 

Calculation:

From join of SCCVtypeDistribution, SCC, SourceTypeModelYear, and 

SCCRoadTypeDistribution where: 

zoneID = zoneID from master loop context

SourceTypeModelYear.sourceTypeModelYearID = 

 SCCVtypeDistribution.sourceTypeModelYearID and 

SCC.SCCVtypeID = SCCVtypeDistribution.SCCVtypeID and 

SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeID and 

MOVESWorkerOutput.sourceTypeID = sourceTypeModelYear.sourceTypeID and

SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeID and 

MOVESWorkerOutput.modelYearID = sourceTypeModelYear.modelYearID and 

MOVESWorkerOutput.fuelTypeID = SCCVtypeDistribution.fuelTypeID and 

MOVESWorkerOutput.roadTypeID = SCCRoadTypeDistribution.roadTypeID 

172
SCC= SCC.SCC 

emissionQuant = sum of emissionQuant * SCCVtypeFraction *

SCCRoadTypeFraction over sourceTypeID and roadTypeID 

sourceTypeID = null 

roadTypeID = null

 linkID = null 

173
10.29. Liquid Leaking (LL) Calculator 

10.29.1. General Information 

This calculator executes at the MONTH master looping level. 

Input Tables 

• OpModeDistribution 

• SourceHours 

• EmissionRateByAge 

• SourceBinDistribution 

• IMCoverage 

• Miscellaneous MOVES Database category and association tables 

Output Table: MOVESWorkerOutput (has structure of MOVESOutput Table) 

10.29.2. Detailed Calculation Steps 

LL – 1 Compute I/M Adjustment Fraction Information 

 (same as CREC 1-a except for different value(s) of pollutant-process) 

Input Variables: 

IMCoverage table 

 zoneID, yearID, polProcessID from masterloop context 

 AgeCategory table 

 RegulatoryClass Table 

 FuelType table 

Input Variable: 

IMAdjustment Table 

Keys: zoneID, yearID, polProcessID, modelYearID, fuelTypeID, regClassID 

 Data: IMAdjustFract 

Calculation:

 For zoneID, yearID in masterloop context 

For Vapor Venting and Liquid Leaking processes of all pollutants in runspec which 

this calculator calculates

For all ageID in AgeCategory 

For all regClassID in RegulatoryClass except regClassID=0 

modelYearID = yearID – ageID 

174
 IMAdjustFract.IMAdjustFract = IMCoverage.IMAdjustFract if record exists 

With begModelYearID <= modelYearID <= endModelYearID 

 = 0.0 otherwise 

LL-2: Calculate I/M-Adjusted MeanBaseRates 

Input Variables: 

- EmissionRateByAge table 

- SourceBinDistribution table 

- SourceBinTable 

- IMAdjustment table (from step LL-1) 

- AgeCategory 

- PollutantProcessModelYear 

Output Variables: 

An intermediate WeightedMeanBaseRate table 

o Keys: yearID, polProcessID, sourceTypeID, fuelTypeID, 

zoneID, monthID, hourDayID, modelYearID, opModeID 

o Data: weightedMeanBaseRate 

Calculation:

modelYearID = yearID – ageID 

fuelTypeID = 1 (gasoline) 

weightedMeanBaseRate = (meanBaseRateIM * sourceBinActivityFraction 

* IMAdjustFract) + (meanBaseRate * sourceBinActivityFraction * (1-

IMAdjustFract)) 

summed over portions of sourceBinID not needed in the output, namely 

regClassID and engTechID. 

LL-3: Calculate MOVESWorkerOutput by Source Type 

Input Variables: 

- WeightedMeanBaseRate table from previous step 

- SourceHours table 

- OpModeDistribution table 

- HourDay table 

- County table 

- Zone table 

- PollutantProcessAssoc table 

- Link table 

Output Variables: 

175
- MOVESWorkerOutput table, which has structure of MOVESOutput 

Calculation:

 emissionQuant 

= weightedMeanBaseRate * sourceHours * opModeFraction 

 hourID = hourDay.hourID 

 dayID = hourDay.dayID 

 stateID = county.stateID

 countyID = zone.countyID 

 pollutantID = PollutantProcessAssoc.pollutantID

 processID = PollutantProcessAssoc.processID 

 roadTypeID = Link.roadTypeID 

 SCC = null 

LL- 4 Conditionally Convert SourceType Output to SCC 

This step is performed only when output by SCC is requested by the run specification 

and, if performed, is the same as that performed in several other EmissionCalculators, 

e.g. CREC step 10. 

176
10.30. Tank Vapor Venting (TVV) Calculator 

10.30.1. General Information 

This calculator executes at the MONTH master looping level. 

Input Tables 

• TankVaporGenCoeffs 

o Keys: ethanolLevelID (0 or 10), altitude (“H” or “L”) 

o Data: tvgTermA, tvgTermB, tvgTermC 

• CumTVVCoeffs (Analogous to EmissionRateByAge, knowing that there is only 

one opModeID and that the particular sourceBinID components needed are 

regClassID and modelYearGroupID)

o Keys: polProcessID, regClassID, modelYearGroupID, ageGroupID 

o Data: tvvTermA, tvvTermB,tvvTermC 

tvvTermACV,tvvTermBCV, tvvTermCCV 

tvvTermAIM,tvvTermBIM,tvvTermCIM 

tvvTermAIMCV,tvvTermBIMCV,tvvTermCIMCV 

• ResidualVaporRatio (a hard-coded Java array rather than an actual table) 

o Key: “hours past hour of max cold soak tank temperature” 

o Data: residualVaporRatio 

• AverageTankGasoline (Produced by Tank Fuel Generator) 

o Keys: zoneID, fuelYearID, monthGroupID 

o Data: ETOHVolume, RVP 

• ColdSoakTankTemperature (from TTG-1) 

o Keys: zoneID, monthID, hourID 

o Data: coldSoakTankTemperature 

• ColdSoakInitialHourFraction (from TTG-7) 

o Keys: sourceTypeID, zoneID, monthID, hourDayID, initialhourDayID 

o Data: coldSoakInitialHourFraction 

• OpModeDistribution 

• SourceHours 

• EmissionRateByAge 

• SourceBinDistribution 

• IMCoverage 

• Miscellaneous MOVES Database category and association tables 

Output Table: MOVESWorkerOutput (has structure of MOVESOutput Table) 

Calculation Overview:

The complete calculation at Macroscale requires up to ten steps. Steps 2 thru 7 apply 

only to the cold soaking operating mode and are not required for Mesoscale Lookup 

calculations.

177
TVV-1 is a preliminary step. It calculates the I/M adjustment factors which are used later 

in the calculation. 

TVV-2 is also a preliminary step. It calculates the hour of the day when the peak cold 

soak tank temperature value occurs.

TVV-3 calculates the amount of tank vapor generated, which depends upon gasoline 

ethanol content. 

TVV-4 calculates an ethanol-weighted value of the tank vapor generated from the values 

in step 3. 

TVV-5 calculates the tank vapor vented using the values in step 4. The values calculated 

here are cumulative for the day and are distinguished by the hour that the cold soaking 

began, as well as the hour of the day when they occur. 

TVV-6 calculates the total cumulative tank vapor vented for each hour of the day from

the values in step 5, so that they are no longer distinguished by the hour of the day when 

the cold soaking began. 

TVV-7 calculates hourly (not cumulative) tank vapor vented. 

TVV-8 Involves all three operating modes and applies the I/M adjustment factors 

calculated in preliminary step 1. 

TVV-9 multiplies by activity and applies the operating mode distribution.

TVV-10 converts results to SCC if required. 

10.30.2. Detailed Calculation Steps 

Note: Steps TVV-2 through TVV-7 need not be performed for mesoscale lookup 

runs. 

TVV – 1 Compute I/M Adjustment Fraction Information 

 (same as CREC 1-a except for different value(s) of pollutant-process) 

Input Variables: 

IMCoverage table 

 zoneID, yearID, polProcessID from masterloop context 

 AgeCategory table 

 RegulatoryClass Table 

 FuelType table 

Output Variable: 

178
IMAdjustment Table 

Keys: zoneID, yearID, polProcessID, modelYearID, fuelTypeID, regClassID 

 Data: IMAdjustFract 

Calculation:

 For zoneID, yearID in masterloop context 

For Vapor Venting and Liquid Leaking processes of all pollutants in runspec 

which this calculator calculates 

For all ageID in AgeCategory 

For all regClassID in RegulatoryClass except regClassID=0 

modelYearID = yearID – ageID 

 IMAdjustFract.IMAdjustFract = IMCoverage.IMAdjustFract if record exists 

With begModelYearID <= modelYearID <= endModelYearID 

= 0.0 otherwise 

TVV – 2 Determine Hour of Peak Cold Soak Tank Temperature 

Input Variable: 

 ColdSoakTankTemperature table 

Output Variables: 

intermediate PeakHourOfColdSoak table 

 Keys: zoneID, monthID 

 Data: peakHourID 

Calculation:

peakHourID is the first (smallest) hourID having the highest 

coldSoakTankTemperature for the zoneID and monthID 

TVV – 3 Calculate TankVaporGenerated (TVG) by Ethanol Level 

Input Variables: 

- ColdSoakInitialHourFraction table 

- PeakHourOfColdSoak table from previous step 

- ColdSoakTankTemperature table 

- TankVaporGenerationCoeffs table 

- AverageTankGasoline table 

- HourDay table 

- County table 

Output Variables: 

An intermediate TankVaporGenerated table 

179
Keys: hourDayID, initialhourDayID, ethanolLevelID, monthID, zoneID, 

sourceTypeID, fuelYearID 

Data: tankVaporGenerated 

Calculation:

Calculation is limited to: 

monthID, zoneID, sourceTypeIDs in the masterloopcontext and the run specification 

combinations of hourDayID and initialhourDayID present in

ColdSoakInitialHourFraction for which initialhourDayID <> hourDayID 

hourDayID values having an hourID value <= PeakHourOfColdSoak.peakHourID

tankVaporGenerated = 0.0 if t1>=t2 

 otherwise 

tankVaporGenerated = (a eb (RVP) (ect2 – ect1)) * k 

Where: 

t2 = ColdSoakTankTemperature of hourID associated with hourDayID 

t1 = ColdSoakTankTemperature of hourID associated with initialhourDayID 

k = 50% fill adjustment constant to be determined

a, b, and c are terms from TankVaporGenCoeffs table 

RVP is from AverageTankGasoline table 

The altitude of the County to which the zoneID belongs should be used 

when selecting the a,b, and c coefficients from the TankVaporGenCoeffs 

table. 

TVV-4 Calculate ethanol-weighted TVG 

Input Variables:

- TankVaporGenerated table from previous step 

- EtOH Volume value from AverageTankGasoline table 

Output Variables: 

- An intermediate EthanolWeightedTVG table 

o Key fields: hourDayID, initialhourDayID, monthID, zoneID, 

sourceTypeID, fuelYearID 

o Data: ethanolWeightedTVG 

Calculation:

ethanolWeightedTVG 

= tankVaporGeneratedE10 (ETOHVolume / 10) + 

tankVaporGeneratedE0 (1 – (ETOHVolume/ 10)) 

TVV-5: Calculate Cumulative Tank Vapor Vented (TVV) 

Input Variables: 

180
tankVaporVented = tvvTermA + tvvTermB*ethanolWeightedTVG + 

tvvTermC*ethanolWeightedTVG2 

tankVaporVentedIM = tvvTermAIM + tvvTermBIM*ethanolWeightedTVG + 

tvvTermCIM*ethanolWeightedTVG2 

The structure of the output table specified here implies that fuelYearID, 

ageGroupID, and modelYearGroupID be converted to the common basis of individual 

ageID to facilitate proper table joining and minimize the size of the resulting table (which 

nevertheless may be performance-constraining). The PollutantProcessModelYear, and 

AgeCategory tables can be used to accomplish this, along with the relationship ageID = 

yearID – modelYearID. 

TVV-6: Calculate Weighted CumulativeTVV Across Initial/Current pair 

Input Variables: 

- CumulativeTVV Table from previous step 

- ColdSoakInitialHourFraction table 

Output Variables: 

- An intermediate WeightedCumulativeTVV Table 

Key fields: regClassID, ageID, polProcessID, hourDayID, monthID, 

zoneID, sourceTypeID 

Data fields: weightedTVV, weightedTVVIM 

Calculation:

- EthanolWeightedTVG table from previous step 

- CumTVVCoeffs table 

- PollutantProcessModelYear 

- AgeCategory 

Output Variables: 

An intermediate CumulativeTVV table: 

Key fields: regClassID, ageID, polProcessID, hourDayID, 

initialhourDayID, monthID, zoneID, sourceTypeID 

Data fields: tankVaporVented, tankVaporVentedIM 

Calculation:

For all ageID: 

181
For each combination of regClassID, ageID, polProcessID, hourDayID, 

monthID, zoneID, and sourceTypeID

weightedTVV = [tankVaporVented * coldSoakInitialHourFraction]

summed over all initialHourIDs 

weightedTVVIM = [tankVaporVentedIM * coldSoakInitialHourFraction]

summed over all initialHourIDs 

TVV-7: Calculate HourlyTVV Emissions by RegulatoryClass and Vehicle Age 

Input Variables: 

- WeightedCumulativeTVV Table (from previous step) 

o LEFT JOINED to itself associating each hourID with otherwise 

same record for hourID-1, if present. 

- ResidualVaporRatio array; Values are: 

o 0.02 for 1 hour past max cold soak temperature 

o 0.01 for 2 hours past max cold soak temperature 

o 0.004 for 3 hours past max cold soak temperature 

o 0.0005 for 4 hours past max cold soak temperature 

o 0.0 for 5 or more hours past max cold soak temperature 

- PeakHourOfColdSoak table from step TVV-2 

- HourOfAnyDay 

Output Variable: 

an intermediate HourlyTVV table 

o key fields: regClassID, ageID, polProcessID, hourDayID, 

monthID, zoneID, sourceTypeID 

o data fields: hourlyTVV, hourlyTVVIM 

Calculation:

For records in WeightedCumulativeTVVTable (which have hourIDs prior or 

equal to the hour of the peak cold soak tank temperature because of the limited 

domain of the calculation in step 3) 

hourlyTVV = weightedTVV for the current hourID – weightedTVV for 

the previous hourID, (if no record is present for the previous hourID then 

the weighted TVV for the previous hourID is 0.0) 

hourlyTVVIM = weightedTVVIM for the current hourID – 

weightedTVVIM for the previous hourID, (if no record is present for the 

previous hourID then the weighted TVVIM for the previous hourID is 0.0) 

For all hourDayIDs in HourDay which have hourDayIDs greater than 

PeakHourOfColdSoak.peakHourID: 

182
hourlyTVV for each such hourID = weightedTVV for peakHourID * the 

residualVaporRatio for the number of hours the hourID is past the 

peakHourID (hourID-peakHourID). 

hourlyTVVIM for each such hourID = weightedTVVIM for peakHourID 

* the residualVaporRatio for the number of hours the hourID is past the 

peakHourID (hourID-peakHourID). 

TVV-8: Calculate I/M-Adjusted MeanBaseRates 

Previous steps have been done only for the cold soaking operating mode. This step 

begins calculating for the other two operating modes,”operating” and “hot soaking”, for 

which only the basic core model calculations are needed, applies the source bin 

distributions, and accounts for the effect of IM. 

Input Variables: 

: 

- HourlyTVV table (from previous step), used for cold soak 

- EmissionRateByAge table, used for hot soak and operating 

- SourceBinDistribution table 

- SourceBinTable 

- IMAdjustment table (from step TVV-1) 

- AgeCategory 

- PollutantProcessModelYear 

Output Variables: 

: 

An intermediate WeightedMeanBaseRate table 

o Keys: yearID, polProcessID, sourceTypeID, fuelTypeID, 

zoneID, monthID, hourDayID, modelYearID, opModeID 

o Data: weightedMeanBaseRate 

Calculation:

modelYearID = yearID – ageID 

fuelTypeID = 1 (gasoline) 

For cold soak mode (opModeID=151):

weightedMeanBaseRate = (hourlyTVVIM * sourceBinActivityFraction * 

IMAdjustFract) + (hourlyTVV * sourceBinActivityFraction * (1-

IMAdjustFract)) 

summed over portions of sourceBinID not needed in the output, namely 

regClassID and engTechID 

183
For operating and hot soaking modes (opModeIDs 300 and 150):

weightedMeanBaseRate = (meanBaseRateIM * sourceBinActivityFraction 

* IMAdjustFract) + (meanBaseRate * sourceBinActivityFraction * (1-

IMAdjustFract)) 

summed over portions of sourceBinID not needed in the output, namely 

regClassID and engTechID. 

TVV-9: Calculate MOVESWorkerOutput by Source Type 

Input Variables: 

- WeightedMeanBaseRate table from previous step 

- SourceHours table 

- OpModeDistribution table 

- HourDay table 

- County table 

- Zone table 

- PollutantProcessAssoc table 

- Link table 

Output Variables: 

- MOVESWorkerOutput table, which has structure of MOVESOutput 

Calculation:

 emissionQuant 

= weightedMeanBaseRate * sourceHours * opModeFraction 

 hourID = hourDay.hourID 

 dayID = hourDay.dayID 

 stateID = county.stateID

 countyID = zone.countyID 

 pollutantID = PollutantProcessAssoc.pollutantID

 processID = PollutantProcessAssoc.processID 

 roadTypeID = Link.roadTypeID 

 SCC = null 

TVV-10 Conditionally Convert SourceType Output to SCC 

This step is performed only when output by SCC is requested by the run specification 

and, if performed, is the same as that performed in several other EmissionCalculators, 

e.g. CREC step 10. 

184
10.31. Result Data Aggregation and Engineering Units Conversion 

This function aggregates the results produced by MOVES EmissionCalculators to 

the level of detail called for in the run specification and converts these results to the 

engineering units it specifies. Aggregation is performed to the extent possible by the 

MOVES Worker program and completed by the MOVES Master program. Conversion 

to engineering units is the final operation performed and is done by the MOVES Master 

program. 

10.31.1. How Aggregation Levels are Specified

The level of aggregation is specified on the MOVES GUI Output EmissionsDetail 

Screen. These specifications are made in terms of what distinctions are desired in the 

output. Output rows are always distinguished by time periods. The level of this 

distinction may be hour, single day, period of week, month or year. (Choices may be 

more limited, however, if time period “preaggregation” of the database was performed.) 

Output rows are always distinguished by location. The level of this distinction may be 

Nation, State, County, Roadtype or Link. (Choices may be more limited, however, if 

geographic “preaggregation” of the database was performed. Link is not available at

Macroscale and is required for Mesoscale Lookup calculations.) Output is always 

distinguished by pollutant. 

When reporting for entire months or years, MOVES2004 scales the results up by 

the number of weeks in each month, i.e. by the number of days in the month divided by 

seven. The reader may wish to refer to section 9.2 of this document where MOVES time 

periods are discussed. 

Output may be distinguished by SourceUseType (the recommended option), 

Source Code Category (SCC) or neither. (But not both since the two highway vehicle 

classification schemes are exclusive.) 

Output may optionally be distinguished by: 

Model Year 

Fuel Type 

185
Emission Process 

Roadtype 

In general, any combination of these distinctions may be specified. Output by 

SCC implies that roadtype and fueltype will be distinguished and the MOVES GUI 

enforces this. If “Roadtype” is selected as the Location level then “Roadtype” is 

automatically distinguished in the output (but the reverse is not necessarily true). 

10.31.2.Aggregation Algorithm - Logical Level Specification 

The raw output of MOVES is distinguished by year, month, day, hour, state, 

county, zone, link, road type, pollutant, process, source use type, fuel type, model year, 

and SCC. Taken together these fields may be considered an alternate key for the 

MOVESOutput table, except that, once aggregations are performed, they may assume the 

null value. 

At macroscale, zones are redundant with counties, so whenever a countyID is 

present, its corresponding zoneID is also present, and when counties are aggregated out, 

then so are zones. Also at macroscale, links represent a combination of a county and a 

roadtype, so when county and roadtype are both known, so is link. Otherwise linkID is 

null whenever either county or roadtype is null. 

The following aggregations may be carried out as implied by the RunSpec. 

Unless stated otherwise, any combination of these aggregations may be called for. This 

description is at a logical level; physical implementation differs. For example 

aggregation to the state level is not actually performed by aggregating roadtypes to 

counties and then aggregating counties to states. 

a. Output may be aggregated to be by source type only, by SCC only or neither. The 

GUI does not allow output to be requested by both SCC and source type. 

b. Hours are combined if the output time period is 24-hour day, portion of week, month 

or year. A warning message is generated if this aggregation is performed and all 

hours are not selected in the RunSpec. 

c. Days are converted to months if the output time period is month or year. The number 

of days in each month is obtained from the MonthOfAnyYear table, adding 1 day to 

February for leap years. 1/7 of these days are considered to be Mondays, 1/7 

186
Tuesdays, etc. without regard to calendar year . A warning is generated if this 

aggregation is performed and all days are not selected in the RunSpec. The user may 

choose to proceed but should be aware in this case that results produced for the 

“month” or “year” will only include emission results for the kinds of days contained 

in the run specification. 

d. Months are totaled to years if the output time period is year. A warning is generated 

if this aggregation is performed and all months are not selected. The user may choose 

to proceed but should be aware in this case that results produced for the “year” will 

not represent a 12 month period and will only include emissions for the months 

contained in the run specification. 

e. Road types are combined into county totals whenever “roadtype” has not been 

selected in the Output Emissions detail screen. Note that selection of the SCC level 

of detail forces road type to be selected and this aggregation not to be performed, as 

does selection of the roadtype level of geographic output detail. A warning message 

is generated if this aggregation is performed and all road types are not included in the 

runspec. 

f. State totals are combined into a single national (or total user modeling domain) result 

if the national level of geographic detail is selected. This aggregation is performed 

even if the road type level of detail has been selected on the “Output Emission Detail” 

panel. It is the user’s responsibility to insure that all desired states are included in 

domain totals. 

g. Fuel types are combined within source use types if this level of detail is not selected 

in the Output Emission Detail panel. It is the user’s responsibility to insure that all 

desired fuel types are included. 

h. Emission processes are combined if this level of detail is not selected in the Output 

Emission Detail panel. It is the user’s responsibility to insure that all desired 

processes are included. 

187
10.31.3. Engineering Unit Conversion 

Engineering units are indicated in the run specification for mass, energy, time and 

distance. In the MOVES GUI these are specified on the “Outputs” panel within the 

“General Output Screen”. Supported are: 

time units (seconds, hours, days, weeks, months and years) 

mass units (kilograms, grams, pounds, and U.S. tons) 

energy units (Joules, kiloJoules, and million BTU) 

distance units (miles and kilometers) 

The engineering units used are reported in the MOVESRun table. 

Distance units are only required if the run specification calls for travel distance to 

be reported. 

MOVES always reports mass pollutant emission results in terms of mass per time 

unit and always reports energy consumptions results in terms of energy per time unit. If

the time unit equals the output time period specified on the “Output Emissions Detail” 

screen, then the quantities reported amount to an inventory for that time period. 

188
10.32. Post-Processor for Mesoscale Lookup 

An “integrated post-processor” runs automatically when Mesoscale Lookup is selected, 

after aggregation to the reporting level and conversion to engineering units have been 

completed. This post-processor uses the regular MOVES output tables to produce an 

additional “MOVESLookupOutput” database table with the following fields: 

a. MOVESLookupOutputRowID 

b. MOVESRunID 

c. iterationID 

d. yearID 

e. monthID (May be aggregated out) 

f. dayID (May be aggregated out) 

g. hourID (May be aggregated out) 

h. stateID 

i. countyID 

j. zoneID 

k. sourceTypeID (May be aggregated out) 

l. fuelTypeID (May be aggregated out) 

m. modelYearID (May be aggregated out) 

n. roadTypeID

o. pollutantID 

p. processID (May be aggregated out) 

q. averageSpeedBinID (as determined through joins with the LinkAverageSpeed 

Table) 

r. temperature (as determined through joins with the ZoneMonthHour table) 

s. humidity (as determined through joins with the ZoneMonthHour table) 

t. emissionRate (emissionQuant divided by MOVESActivityOutput.distance. 

“Zero” miles for any link leads to divide-by-zero errors. In such cases there 

are no emissions reported. 

189
10.33. Post-Processing Script Execution 

The “Post Processing” menu in the MOVES GUI includes a selection to “Run 

MySQL Script on Output Database”. When this item is selected MOVES searches the 

“OutputProcessingScripts”subdirectory in its “...database” directory, and presents a list of 

file names found there which have a file name extension of “.sql”. Users may wish to 

add scripts to those distributed with the model. 

When one of these files is selected, MOVES displays to the user any leading 

block of comment lines it may contain in a popup window. If the user wants to proceed, 

MOVES executes the file as a MySQL script on the MOVES output database specified 

by the currently active run specification (or gives an appropriate error message if no 

output database is specified). Scripts in the OutputProcessingScripts folder should 

operate only on the currently active MySQL database, should not include the MySQL 

USE command, should use as input only the tables contained in the MOVES Output 

database schema, (along possibly with MOVESDefault) and should store any files and 

tables they produce in this same database. The MOVES program, however, does not 

enforce these conventions. 

Scripts distributed with the model are: 

Script Function 

DecodeMovesOutput.sql Decodes (i.e. adds textual descriptions of ) most of the 

key fields in MOVESOutput and MOVESActivityOutput 

tables. The SummaryReporter, described in the next 

section, does this in a more general fashion and so this is 

now best viewed as an example of how these scripts can 

be written. 

MPGCalculator.sql calculates fuel economy from MOVES normal model 

output. As documented in its comment block it assumes 

that certain selections have been made in the run 

190
specification.

TabbedOutput.sql Produces tab-delimitted output file versions of the 

MOVESRun, MOVESActivityOutput, and 

MOVESOutput tables. These are suitable for importing 

into EXCEL or other software. The same thing can no be 

accomplished by using the SummaryReporter, described 

in the next section. 

191
10.34. Summary Reporter 

Background: 

The output directly available from the MOVES core model is in the form of a MySQL 

database as documented in Chapter 12. The Summary Reporter provides a “postprocessing” function which makes it easy to produce various reports summarizing this 

information. Several of the organizations which commented formally on MOVES2004 

indicated that a more convenient reporting capability was needed. 

Functional Specification: 

Inspired by the NONROAD Model’s reporting utility, the Summary Reporter produces 

reports consisting of: 

1. Header information such as: 

 Report Title 

Date and time the report produced. 

MOVES Output Database Name

MOVES Output Run Number 

MOVES Output Run Date and Time

 RunSpec used 

Date and time of the runspec file used. 

“Description” field from the Runspec used 

Engineering units used for Mass, Energy, Time, and Distance 

Emission Process (either a particular emission process or “all”) 

2. A tabular report body where the data columns correspond to pollutants and 

activity basis results (currently “distance”) and the rows correspond to an ordered set of 

MOVES output classifications selected from the following options: 

 Year 

 Month 

 Day

 Hour 

 State 

 County 

 Zone 

Source Type (mutually exclusive with SCC) 

SCC (mutually exclusive with Source Type) 

 Fuel Type 

 Model Year 

Road Type (not allowed if SCC selected) 

 MOVESRunID 

192
Assuming the report is printed in landscape, there is sufficient space to report four 

or five pollutants and activities, e.g. HC, CO, NOx and distance, classified by three 

categories. Classification values are reported in their integer form. Specification of more 

columns than will fit on a single page is allowed. The supporting GUI includes an option 

to estimate how wide the report will be. Wide reports are fine as a table or .csv file, but 

wrap when displayed on the screen or printed. The fixed-column style report tables 

produced by this utility could be further processed with a reporting utility to deal more 

gracefully with wide reports, but MOVES does not currently provide this feature. 

3. The current version of Summary Reporter reports numeric category codes in 

the table constituting the report body, and includes an appended lookup table which can 

be used to decode them. 

The Summary Reporter includes a simple Graphical User Interface which works roughly 

as follows: 

1. The user loads the run specification which produced the output. This serves to point 

to the output database and helps the GUI insure that the specified report is consistent with 

the run. 

2. The user selects from a popup list the run, or set of runs to be reported. Only the most 

recent runs are available.

3. The Summary Reporter, based on the run specification and the output run data, 

constructs a dialog window (JDialog) to get user selections for: 

a. The report title. This defaults to “Summary Report”. 

b. A base name for the report files. This defaults to “SummaryReport”. (Report 

header, body, and decoding tables are produced in separate files, plus several 

forms of output (table, .prn, and tab-separated .txt) can be produced) . 

c. The emission process to be reported or “all”. 

d. A list of pollutants and activity bases (currently “distance”) from which the 

user selects the report data columns desired. 

e. Selections from the list of output classifications listed above. Only options 

consistent with the run specification are offered. 

f. The forms of output desired. 

4. Several forms of output may be selected: 

a. MySQL table output is always produced. 

b. Option for screen display (Screen reports can be printed after being displayed 

on the screen; they are then closed.)

c. Option for tab-separated text form. 

193
Report output is produced in the directory containing the output database. 

Additional Information: 

The Summary Reporter is covered from a GUI perspective in the MOVES-HVI User 

Guide. 

194
10.35 GREET Model Interface 

The GREET Model Interface is not operational in the demonstration version of 

MOVES-HVI. We are working with the authors of GREET to restore this function in 

future versions of MOVES-HVI. This section describes how the interace functions in 

MOVES2004. 

MOVES is designed to interface with GREET, as detailed in the following 

section. Further detail on the GREET interface itself is contained in a separate document 

entitled “User Manual and Technical Issues of GREET for MOVES Integration”, 

prepared by Argonne National Laboratory. 

10.35.1 MOVES2004 GREET Interface Functionality: 

1. If requested in the RunSpec, MOVES2004 calculates well-to-pump inventories for 

total energy consumption, petroleum-based energy consumption, fossil fuel-based 

energy consumption, N2O, and CH4, using the emission factors in the 

GREETWellToPump table. 

2. MOVES2004 offers a “preprocessing” menu option to “Update Well-To-Pump” 

factors. When this menu option is selected MOVES2004 produces, in XML format, a 

table of information needed by GREET. This contains a list of calendar years, and a 

list of MOVES fuel sub-types implied by the RunSpec. 

3. MOVES2004 then executes the GREET GUI described below. 

4. When control is returned, MOVES2004 receives a tab-separated variable, well-topump emission factor result table from the GREET GUI and incorporates these 

factors into the GREETWellToPump table in a database suitable for use as in input 

database by subsequent MOVES2004 model runs. 

5. MOVES2004 interacts with the GREET GUI, which in turn invokes the GREET 

spreadsheet model. MOVES2004 does not interact directly with the GREET 

spreadsheet model, only with the GREET GUI. 

195
10.35.2. GREET and GREET GUI Functionality 

The design of the interface between MOVES2004 and GREET is based upon the 

following functional characteristics of GREET. 

1. GREET estimates Well-to-Pump and Vehicle Manufacture/Disposal emissions of 

Total Energy Consumption, Petroleum-based Energy Consumption, Fossil Fuel-based 

Energy Consumption, N2O, and CH4 appropriate to calendar years 1990 thru 2050. 

(Internally to GREET, estimates are actually produced by interpolating between 

estimates applicable to five year periods and estimates beyond 2020 are based on 

many of the same parameter values as those for 2020. ) 

2. When the two models are used together, the United States (or the user modeling 

domain) is modeled as a single geographic region. 

3. Where GREET has multiple Pathway Options for a fuel, it is generally possible for 

the user to supply input parameters for each pathway (with associated percentages 

which sum to unity), and these Pathway Options and percentages may vary by 

calendar year. 

4. Only GREET parameters accessible from a version of the GREET GUI may be 

altered. To alter more deeply embedded GREET parameters the user would have to 

manually modify the underlying GREET spreadsheet before running MOVES. 

5. GREET estimates well-to-pump emissions relative to consumption of the following 

fuels (in MOVES2004 these are referred to as fuel subtypes): 

Conventional Gasoline 

Reformulated Gasoline 

Gasohol (E10) 

Conventional Highway Diesel Fuel 

(GREET has the logic built in to use its high sulfur version of this fuel prior to 2006, 

its low sulfur version after 2006 and a blend for 2006). 

Biodiesel 

FT Diesel 

CNG 

LPG 

196
Ethanol 

Methanol 

Gaseous H2 

Liquid H2 

Electricity 

6. The GREET GUI, while not itself written in Java, can be run from a Java program, i.e. 

MOVES2004. It accepts command line parameters which specify: 

- an XML input file name

- an output file name (for well-to-pump factors and vehicle manufacture/disposal 

factors) 

- an error file name (used to return any GREET error messages to MOVES). 

7. Execution of the GREET GUI normally results in execution of the version of the 

GREET spreadsheet, but may return to MOVES without executing it if the user 

desires. Upon return to MOVES2004, status information is available as to whether 

the GREET spreadsheet was run or not and whether execution was successful or an 

error occurred. Error messages are returned to MOVES in a separate file. 

8. The GREET GUI accepts an XML-formatted list of MOVES2004 Calendar YearIDs, 

determines what five-year GREET periods are needed to estimate emissions for all 

years listed, and executes the GREET spreadsheet for each such period, and 

interpolates between these results as needed to produce results for the calendar years 

listed. GREET also accepts an XML-formatted list of fuel types (MOVES 

fuelSubtypes). GREET results are limited to these fuels. 

9. The GREET GUI consolidates the results of these GREET spreadsheet runs into a 

single tab-delimited table of well-to-pump emission factors and (eventually) a single 

tab-delimited table of vehicle manufacture/disposal emission factors for use by 

MOVES2004. The table of well-to-pump emission factors is described in the next 

section. 

10.35.3. GREET Well-to-Pump Emission Factor Result Table: 

This table is a tab-separated variable ASCII text file and contains the following 

fields:

197
a. pollutantID (an Integer from the set of values used in MOVES2004) 

b. fuelSubtypeID (an Integer from the set of values used in MOVES2004) 

c. yearID (an Integer identifying the calendar year to which the factor applies) 

d. emission rate (a floating point number, expressed in the appropriate units) 

Fields a, b, and c, together form the primary key of this table. Field d is its only 

non-key field. The fields pollutantID, fuelSubtypeID and yearID are as defined in the 

MOVESDefault database schema. 

198
10.36 Future Emission Rate Creator (FERC) 

The Future Emission Rate Creator (FERC) allows MOVES users to alter the 

energy and emission rates for advanced technology vehicles for model years 2001 and 

later, and for all energy and emission rates (conventional and advanced technology) for 

2011 and later. The FERC works with user-supplied ratios which express the relative 

benefit of advanced technologies versus conventional technology, by operating mode, to 

generate advanced technology rates. The FERC is an “external control strategy”, 

meaning it requires work outside of MOVES with MySQL databases and is executed 

from the “Pre-Processing” menu of the MOVES GUI, rather than being executed as part 

of the model run itself. 

Input data: The FERC requires two input tables, one to create “short term” future rates 

and another to create “long term” future rates. These are stored in ASCII text, comma 

separated variable (CSV) format. To generate an alternative set of future emission rates 

the user must alter these tables directly (outside of MOVES) before running the FERC. 

The user names these tables as desired and selects them from the MOVES GUI. One set 

of example input tables is supplied with the demonstration version of MOVES-HVI . 

The two tables contain identical fields, except that the opModeID field is present only in 

the “short term” table. The first record in each file contains column names to facilitate 

human readability and is ignored by the calculations. The FERC input table fields are 

shown in Table 10-9. 

Table 10-9: FERC Input Table Fields 

Field Description 

polProcessID Pollutant / Process ID 

501 = CH4 running 

502 = CH4 start

601 = N2O running 

602 = N2O start

9101 = total energy running

9102 = total energy start 

9190 = total energy start 

opModeID (present in short

term table only) 

Operating Mode ID 

0-36 = running VSP/speed modes (total energy only) 

200 = start mode 

199
300 = running mode (CH4 and N2O) 

targetFuelTypeID Type of fuel:

1 = Gasoline 

2 = Diesel 

3 = CNG 

4 = LPG 

5 = E85 

6 = M85 

7 = Gaseous Hydrogen 

8 = Liquid Hydrogen 

9 = Electricity 

targetEngTechID Engine Technology ID 

1 = Conventional Internal Combustion (CIC) 

2 = Advanced Internal Combustion (AIC) 

11 = Moderate Hybrid CIC

12 = Full Hybrid CIC 

20 = Hybrid AIC (used only for Hydrogen IC hybrid) 

21 = Moderate Hybrid AIC

22 = Full Hybrid AIC 

30 = Electric 

40 = Fuel Cell 

50 = Hybrid Fuel Cell 

targetModelYearGroupID Model Year Group ID

20012010 = 2001 thru 2010

20112020 = 2011 thru 2020

20212050 = 2021 thru 2050

fuelTypeID Base fuel type ID (same as targetFuelTypeID) 

engTechID Base engine technology ID (same as targetEngTech ID) 

modelYearGroupID Base model year group ID (same as targetModelYearGroupID) 

fuelEngAdjust Fuel / Engine Adjustment, i.e. the relative benefit of the target fuel / 

engine technology versus the base fuel/engine technology. A value of

1 = no benefit, a value of 0.5 = 50% improvement

dataSourceID 5001 thru 5004 = FERC short term 6000 = FERC long term 

These fields fall into three functional groups: 

1. fields describing the emission rates produced by the adjustment 

a. polProcessID 

b. opModeID 

c. targetFuelTypeID 

d. targetEngTechID 

e. targetModelYearGroupID 

f. dataSourceID 

2. fields describing the base technology emission rates to which the adjustment 

is applied 

200
a. polProcessID 

b. opModeID 

c. fuelTypeID 

d. engTechID 

e. modelYearGroupID 

3. the adjustment itself

a. fuelEngAdjust 

Of these fields, the user would generally only need to alter values of fuelEngAdjust, 

which are the ratios which define the benefit of the target technology relative to the base 

technology. Note that the values of polProcessID and opModeID contained in the base 

records are carried into the future emission rates produced, as are the values of 

regClassID, engSizeID and weightClassID implicit in the base record sourceBinIDs. 

The short term table contains the information necessary to produce alternative 

fuel and advanced vehicle technology rates for model years 2001 through 2010 (which 

are treated as one model year group). The long term table contains the information 

necessary to produce conventional and advanced vehicle technology rates for model year 

groups 2011 and later, split into two model year groups: 2011 - 2020 and 2021 - 2050. 

The main difference between the tables is that the short term table uses as base rates the 

gasoline and diesel rates for conventional technology in the 2001 through 2010 model 

year group, while the long term table uses the 2001 – 2010 rates as a base the 2001-2010 

rates for each technology (i.e. those generated by the short term table). The long term 

table enables the user to model technology evolution over time, within each technology. 

Output produced: 

201
The FERC produces a MySQL database suitable for use as a MOVES user input 

database. This database contains two tables: EmissionRate and SourceBin. The name of 

this database is specified by the user. 

Calculations performed: 

Short term future emission rates are created by applying fuelEngAdjust as a 

multiplicative adjustment factor to the meanBaseRate of all non-motorcycle 

EmissionRate table records in the MOVESDefault database with dataSourceIDs less than 

5000. For each such record with matching values of polProcessID, opModeID, 

fuelTypeID, engTechID, and modelYearGroupID a short term future emission rate record 

is generated having the targetFuelTypeID, targetEngTechID, targetModelYearGroupID 

and new dataSourceID (while retaining the prior values of polProcessID, opModeID, 

regClassID, engSizeID, and weightClassID). 

Long term future emission rates are created by applying fuelEngAdjust as a 

multiplicative adjustment factor to the meanBaseRate of all EmissionRate table records 

in the MOVESDefault database with dataSourceIDs less than 5000 (including those for 

Motorcycles), along with the short term future emission rates produced by the first step. 

For each such record with matching values of polProcessID, fuelTypeID, engTechID, and 

modelYearGroupID a long term future emission rate record is created having the 

targetFuelTypeID, targetEngTechID, targetModelYearGroupID, and new dataSourceID 

(while retaining the prior values of polprocessID, opmodeID, regClassID, engSizeID, and 

weightClassID). 

For this calculation to operate correctly the MOVESDefault.SourceBin table must 

contain a record for each sourceBinID present in the EmissionRate table having a 

dataSourceID less than 5000. The MOVESDefault database distributed with MOVESHVI satisfies this condition. 

202
10.37 I/M Coverage Table Editor 

The IMCoverage Table editor provides a Graphical User Interface (GUI) to easily 

display, edit, and print reports of the IMCoverage table contents. It uses the loaded run

specification to determine which records are of interest. As regards its input, it constructs 

and works to the extent possible only with the IMCoverage Table contents that would be 

used if that run specification were executed. As regards its output, rather than actually 

changing the IMCoverage table in MOVESDefault, it produces an IMCoverage table in a 

User Input Database. Because it operates as a user graphical user interface, further 

documentation can be found in the MOVES-HVI User Guide. 

203
10.38 Estimating the Uncertainty of MOVES Results 

Uncertainty in the model results is introduced by the model theory, the 

mathematical formulation of the model, and the data used to calibrate the model. The 

first two sources of uncertainty are not amenable to quantification, so the uncertainty 

estimates in MOVES focus on the data used to calibrate the model. However, even with 

this narrower focus, the challenges are significant. MOVES uses data for dozens of 

variables covering most aspects of mobile source emission generation: the vehicle fleet, 

vehicle activity patterns, emission rates, fuel properties, geographic location, fuel 

properties, meteorology, and the presence or absence of vehicle emission control 

programs. The uncertainty of emission rates is relatively easy to quantify, using standard 

data analysis techniques, but much of the fleet, activity, fuel, and meteorology data 

sources have limited information regarding their degree of uncertainty. The primary 

challenge in including uncertainty estimation in MOVES is therefore to quantify 

uncertainties for all of the input data used in the model. 

MOVES-HVI includes a basic mechanism which can be used to estimate a 

portion of the uncertainty of its calculated emissions results, which results from the 

uncertainty in some particular model inputs, using a Monte Carlo method. A level was 

added to the model’s master looping framework to execute multiple “iterations” of the 

same run specification on versions of the MOVESExecution database where these input 

values have been “pseudo-randomly” sampled (as independent samples) from their 

assumed probability distributions. As currently implemented these probability 

distributions are assumed to have the form of the normal or Gaussian distribution. Only 

certain inputs are considered by the program to be random variants, namely those which 

function as emission rates and emission rate adjustment factors. Specifically these are: 

The meanBaseRate field in the EmissionRate, EmissionRateByAge, and 

SulfateEmissionRate tables. 

The tank vapor venting (TVV) terms in the CumTVVCoeffs Table. 

204
The temperature adjustment terms in the TemperatureAdjustment and 

StartTempAdjustment tables. 

The “full AC adjustment factor” in the FullACAdjustment table. 

The fuel adjustment factor in the FuelAdjustment table. 

Because all records in the MOVESExecution database containing these values are 

sampled before every iteration and all components of the model obtain their input data 

from this database, every parameter has a single value for a given iteration that is 

identical everywhere it is used. 

Calculation and Storage of the Input Data Random Samples: 

 When the Monte Carlo uncertainty estimation feature is invoked the user 

specifies: 1) the number of iterations to be run (which must be at least two), 2) whether 

the results of each individual iteration are to be reported or only the last one, 3) whether 

the input data samples used for each iteration are to be preserved for later reference in the 

output. Uncertainty estimation may not be invoked in conjunction with either geographic 

or time period data preaggregation. 

When uncertainty estimation is being performed, prior to every iteration each data 

value in the MOVESExecution database which is considered to be uncertain is replaced 

with an independent “pseudo-random” sample from the normal or Gaussian distribution 

whose mean value is the original database point value and whose standard deviation is 

calculated from this mean value and an associated CV field value. (The coefficient of 

variation, or CV, is the standard deviation divided by mean.) The MOVESDefault 

database includes a Coefficient of Variation (CV) field for the fields listed above which 

the model uses at the start of each iteration to generate a sample value for the field. (The 

database also includes additional CV fields which are not currently used.) 

If the CV field contains a zero or NULL value then the standard deviation is 

considered to be 0.0. 

205
Specifically, if Z is a pseudo-random sample from the normal distribution with 

mean 0.0 and unit standard deviation, then: 

sampledMeanValue[i] = 

originalMeanValue * (1.0 + CV * Z[i]) 

In the unlikely, but not impossible, event that the sampledMeanValue[i]<0, 

MOVES sets the sampledMeanValue[i]=0. (In future this may not be done for every 

value subject to uncertainty.) 

MOVES uses the java.util.Random class to generate the Z values. 

None of the “random variates” currently implemented involves components of a 

distribution which sum to unity, but when this mechanism is expanded to include such 

elements, each term of the distribution will first be generated individually. Then the 

resulting set of variates will be normalized so that the total sums to one. This procedure 

will result in the terms of the distribution being negatively correlated, as they should be: 

if one term is especially large, others must be correspondingly small, and vice versa. 

After versions of these tables to be used for a particular iteration have been 

produced, and if requested by the run specification, their records are copied into 

corresponding tables in the MOVES output database. These tables added to the output 

database have the same structure as the original MOVESExecution database tables (e.g. 

EmissionRate, EmissionRateByAge, etc.) with the addition of fields identifying model 

run and iteration (MOVESRunID and iterationID). 

Calculation and Output of Uncertainty Statistics: 

If uncertainty results are being calculated, and if the run specification calls for the 

results of each iteration to be reported, then two statistics are calculated and reported in 

each MOVESOutput and MOVESActivityOutput table record. 

206
The mean values of emissionQuant and (if produced) distance, based on the 

iterations performed so far are reported in the emissionQuantMean and 

distanceMean fields. 

The standard deviations of emissionQuant and (if produced) distance, based on 

the iterations performed so far are reported in the emissionQuantSigma and 

distanceSigma fields. 

In order to calculate these statistics, the count (which equals the iterationNo), 

sum, and sum of the squares of emissionQuant and distance are accumulated in a running 

sum and saved between runs. The full results of each iteration do not need to be saved to 

calculate these statistics (although the user has the option to save the results for 

diagnostic and further analytical purposes). These statistics are calculated and saved at 

the level of detail, and in the engineering units, of the output table. Listed below are the 

formulas for emissionQuantMean and emissionQuantSigma. Similar formulas would 

apply to any other variable. In these formulas, the xis are the results of each iteration, and 

n is the number of iterations. 

n

x

emissionQuantMean

n

i

∑ i

= = 1

( )

1

* 2

1

2

−

−

=

∑=

n

nx emissionQuantMean

Var

n

i

i

Sigma = Var (the positive square root) 

207
If uncertainty results are being calculated, and if the run specification does not 

call for the results of each iteration to be reported, then only the records for the last

iteration are reported. 

Confidence intervals and other statistics can be generated, outside the model, 

from these results. Dynamic sensitivity can also be calculated from this model output by 

regressing model inputs against model outputs. Inputs with the highest (in absolute 

value) regression coefficients will be those for which the greatest improvement will result 

from decreasing their uncertainty. 

208
11. MOVES-HVI Input and Default Databases 

The principal input data for a MOVES model run is normally obtained from the 

MySQL database named MOVESDefault. A version of this database is included in each 

distribution of MOVES. The user may change this database if desired. This is not 

normally done directly, however, unless records need to be deleted, or a fundamental 

change to the scope of the model is involved, because MOVES has a more convenient 

mechanism for the user to supply additional or alternative input data. The MOVES GUI 

program and MOVES run specifications allow the user to specify one or more MySQL 

databases whose table records are to be added to or to replace data table records in 

MOVESDefault during model execution. The simplicity and generality of this scheme is 

that these MOVES input databases have exactly the same table structure as 

MOVESDefault (or any portion of it), and may be used to replace all input data items. A 

limitation of this scheme, however, is that the user is responsible for the accuracy, 

completeness and consistency of the database that results from this process. This is not 

always a simple endeavor. EPA envisions that “data importer” programs will be written 

to help prepare MOVES input databases and support the principal specialized input use 

cases as they arise. It is also envisioned that organizations outside EPA will produce data 

importers for MOVES. MOVES-HVI does not include any data importers, strictly 

speaking, but its future emission rate creator (FERC) is like a data importer in that it 

creates EmissionRate table records from externally supplied information. The I/M Table 

Coverage Editor in MOVES-HVI is also somewhat like a data importer in that it can be 

used to create IMCoverage table records, in this case the records are produced from user 

input to a GUI. 

Since the MOVESDefault database and MOVES user input databases have the 

same table structure, this structure will be referred to in the remainder of this section as 

simply the “MOVES Database.” The MOVES Database is a relational database which 

means, among other things, that it is made up entirely of tables, and that every record 

within a given table has the same set of data items or “fields.” The MOVES database has 

a naming convention that table names begin with a capital letter and field names begin 

with a small letter (unless their name starts with an acronym). 

209
The MOVES database structure is highly “normalized” which means that data is 

contained in many separate tables, several of which usually need to be joined together to 

satisfy an information requirement. 

11.1. Use of Data Types 

The overall approach to the use of MySQL column types in the MOVES database 

is to use integer type columns (2-byte integers where possible, 4-byte integers otherwise) 

for all key identifying fields (stateID, countyID, hourID, sourceTypeID, etc), and to use 

normal-precision floating point columns for numeric information. Since MySQL has no 

boolean (logical true/false) column type, the MOVES database uses columns of character 

type with length 1 for data items that have a yes/no or true/false nature. Such columns 

are populated with “Y” to represent “yes” or “true,” and “N” to represent “no” or “false.” 

11.2. Functional Types of Tables: 

While the MOVES Database consists entirely of tables, these tables serve several 

different purposes. Some tables function merely to establish value lists for some of the 

fundamental entities in the database. Examples of such “category value list” tables 

include State, Year, and DayOfAnyWeek. 

A few tables represent “Associations” between database entities. These usually 

have “Assoc” as the last part of their name. An example of an association type table is 

PollutantProcessAssoc, which contains information as to which pollutants are emitted by 

which emission processes. Since this is a many-to-many relationship (i.e. several 

pollutants are generally produced by each emission process and a pollutant can be 

produced by several emission processes), an “Association type” table is used to store the 

valid combinations. 

The most common kind of tables in the MOVES database store the substantive 

subject matter information, and in this document are termed “information” tables. The 

EmissionRate table, for example, stores emission rates for some of the emission 

processes in MOVES. 

Some “information” tables store data “distributions,” i.e. sets of fractions which 

add to unity. The MOVES database has a naming convention that such tables have the 

210
word “Fraction” or “Distribution” as the last part of their name, and the field containing 

such fractions has the word “Fraction” as the latter part of its name. An example of this 

is the “HourVMTFraction” table whose “hourVMTFraction” field stores information as 

to what fraction of certain VMT occurs during each of the hours of the day. Another 

example is the “RoadTypeDistribution” table whose “roadTypeVMTFraction” field 

stores information as to what fraction of certain VMT occurs on each RoadType. 

A kind of “information” table which merits special consideration consists of those 

which are written by MOVES Generators and which MOVES EmissionCalculators, 

(which can be considered to implement the MOVES Core Model), use as their principal 

inputs. These are called “core model input tables” or CMITs. The reason CMITs are

important to the MOVES user is that they are alternative points for data entry to the 

model. Generally, the user has a choice as to whether to supply input data to a Generator 

and have the Generator populate its CMIT tables during model execution, or to place 

input data directly into the CMIT, (in which case the Generators are programmed not to 

modify it). A combination of the two approaches may also be used. Most CMITs are 

information type tables, but there is one notable exception to this, namely the SourceBin 

table, which can be considered a category or an association type table. 

These various kinds of tables are not always completely distinct. The 

SourceUseType table for example functions as a “category” type table in that it defines 

the set of sourceTypeIDs available for use in the database, but it also functions as an 

“information” table, since it contains several subject matter information fields, e.g. 

sourceMass.

11.3. Database Tables and Their Use 

This section briefly describes the purpose of each MOVES database table, and 

classifies each table in terms of the categories discussed in the previous section. For 

“Information Tables” it also lists any application-level components of the model which 

write the table’s records, and which use the table’s data elements. This section can 

therefore be used to trace the flow of data in the central portion of the model at the table 

level. The discussion of tables in this document is relatively brief, and is only intended to 

give a general idea of how each table is used and its most significant characteristics. 

211
The following abbreviations are used in the table to identify the kinds of tables: 

CVL (Category Value List) 

ASSOC (Association Table) 

CMIT (Core Model Input Table) 

DIST (Distribution Table) 

INF (Information Table which is not also a CMIT or a Distribution Table) 

The following abbreviations are used to identify the components of MOVES which read 

and write the tables: (All tables are written into the MOVESExecution database by the 

InputDataManager, which along with data preaggregation, is not shown here. Usage by 

the GUI or other framework components is likewise not shown.) 

LTLP (Lookup Table Link Producer) 

TAG (Total Activity Generator, includes version for Mesoscale Lookup) 

OMDG (Operating Mode Distribution Generator, for running and braking, 

includes version for Mesoscale Lookup) 

SBDG (Source Bin Distribution Generator) 

METG (Meterology Generator) 

StartOMDG (Start process operating mode distribution generator) 

TTG (Tank Temperature Generator) 

EvapOMDG (Operating mode distribution generator for the evaporative emission 

processes) 

TFG (Tank Fuel Generator) 

AVFT (Alternative Vehicle Fuels and Technologies Strategy) 

EC (EmissionCalculators for the Exhaust, TireWear and Brake Wear emission 

processes which are not “chained” to other calculators, includes Distance 

Calculator.) 

ChainEC (Emission calculator which are “chained” to other calculators) 

EvapEC (EmissionCalculators for the Evaporative emission processes) 

Table 11.1 MOVES Input Database Tables – Use by Software Components 

Table Name Type Function /Description Writers Readers 

(as DIST, 

CMIT or

INF) 

212
AgeCategory CVL Defines the valid age categories 

of SourceUseTypes. ageID=0 

represents new vehicles;

ageID=30 represents vehicles

30 years old or older.

modelyearID=calendarYearIDageID 

AgeGroup CVL Defines the valid age groups, a 

single set of which is used for

all pollutant-processes. 

AverageTankGasoline CMIT The gasoline in the fuel tanks of 

gasoline-fueled vehicles. 

Allows modeling of mixtures of

fuel formulations from the fuel

supply. 

TFG EvapEC 

AverageTankTemperature CMIT Temperature of the fuel in the

tanks of vehicles. 

TTG EvapEC 

AvgSpeedBin CVL 

INF 

Defines the average speed bins. LTLP 

TAG 

OMDG 

AvgSpeedDistribution DIST Distribution of time spent in 

average speed bins, by source

type, roadtype, hour and day.

TAG 

OMDG 

ColdSoakInitialHourFraction CMIT 

DIST

The fraction of cold soaking in 

each hour-day that began in 

each hour, by source type, zone 

and month. 

TTG EvapEC 

ColdSoakTankTemperature CMIT Temperature of the fuel in tanks 

of cold-soaking vehicles, by

zone, month, and hour 

TTG TTG 

EvapEC 

County CVL 

INF 

Establishes the set of counties. 

Counties belong to states, but

their IDs, based on FIPS state 

and county codes, are globally

unique. 

METG 

EC 

EvapEC 

CountyYear ASSOC Associates years with counties 

CumTVVCoeffs INF Terms used to calculate tank 

vapor vented from tank vapor

generated. Somewhat

analogous to emission rates by 

age for TVV process. Stored 

by regClass, modelYearGroup, 

and ageGroup. 

EvapEC 

DataSource INF Metadata for emission rate 

records. 

DayOfAnyWeek CVL Establishes set of dayIDs which 

identify a kind of day of the 

week. 

DayVMTFraction DIST Distributes VMT for a source

type in a month on a roadtype

to the kinds of days of the 

week. 

TAG 

DriveSchedule CVL 

INF 

Defines the set of driving 

schedules or patterns. Each

OMDG 

213
schedule has an average speed 

information item.

DriveScheduleAssoc ASSOC 

INF 

Associates a driving schedule 

with a combination of source 

type and road type. Also

indicates whether schedule is a 

ramp schedule.

OMDG 

DriveScheduleSecond INF Records contain the speed for 

one second of a driving 

schedule. Schedules start at

second = 0. Time gaps are 

allowed. Such gaps divide 

schedule into “snippets”. 

OMDG 

EmissionProcess CVL Establish the set of emission 

processes.

EmissionRate INF Contains emission rates for 

most pollutant-processes which

do not depend upon vehicle age 

and which are not calculated 

from other pollutant-processes. 

Rates depend upon

polprocessID, opModeID, and 

sourceBinID 

EC 

EmissionRateByAge INF Contains emission rates for 

most pollutant-processes which

depend upon vehicle age and 

which are not calculated from

other pollutant-processes.

Rates depend upon

polprocessID, opModeID, 

sourceBinID, and ageID 

EC 

EvapEC 

EngineSize CVL Establishes the set of engSizeID 

values. 

EngineTech CVL Establishes the set of 

engTechID values. 

ExtendedIdleHours CMIT Stores total activity for 

extended idling process. 

Geographic unit is the zone. 

TAG EC 

FuelAdjustment INF Stores multiplicative emission

result adjustment factors to

account for fuel effects by 

polProcessID, sourceTypeID, 

fuel model year groups, and

fuel formulation. 

EC 

EvapEC 

FuelEngFraction DIST Distributes sourceType -

modelYear combinations to

fuelType - engine technology

combinations. 

AVFT AVFT 

SBDG 

FuelEngTechAssoc ASSOC Established the combinations of

fuelType and engTech that are 

valid for each sourceType.

AVFT (GUI

portion) 

FuelFormulation CVL 

INF 

Establishes the set of fuel 

formulations. Stores their fuel

characteristics. 

TFG 

EC 

ChainEC 

FuelModelYearGroup CVL Establishes the model year 

214
groupings relevant to vehicle 

fuel effects upon emissions 

FuelSubType CVL 

INF 

Establishes the set of fuel 

subtypes. Stores information 

about them. 

EC 

ChainEC 

FuelSupply DIST Contains the marketshare of 

fuel formulations for each 

county for each month group

and fuel year. When present, 

marketshares sum to unity for 

each fuel type. When data not

present model assumes 100%

marketshare of the fuel type’s

default formulation. 

TFG 

EC 

ChainEC 

EvapEC 

FuelSupplyYear CVL List of valid fuel supply years.

FuelType CVL 

INF 

List of valid fuel types. EC

ChainEC 

EvapEC 

FullACAdjustment INF Stores “fullACAdjustment” 

factors by source type, 

pollutant-process, and operating 

mode. Missing values mean no

adjustment. 

EC 

GREETManfAndDisposal INF Placeholder table for emission

processes not yet implemented. 

(not used) 

GREETWellToPump INF Contains emission rates for the 

Well-to-Pump process by year, 

pollutant, and fuel subtype.

(May be 

written by

GREET 

Interface) 

ChainEC 

Grid CVL Placeholder table to reprent grid

cells. 

(not used) 

GridZoneAssoc ASSOC Placeholder table to associate

grid cells with zones. 

(not used) 

HourDay CVL 

ASSOC

Exists only because of database

design considerations. 

Associates all hours of the day 

with all kinds of days of the 

week. 

HourOfAnyDay CVL Lists valid hourIDs. hourID=1

represents the hour beginning at

midnight.

HourVMTFraction DIST Allocates the VMT for a 

sourceTypeID-roadTypeIDdayID combination to the hours 

of the day

TAG 

HPMSVtype CVL List of valid vehicle types as

classified by the Highway 

Performance Management

System

HPMSVtypeYear INF Stores VMT data for base years 

and VMT growth factors for all 

years 

TAG 

IMCoverage INF Information about the existence 

and effectiveness of vehicle I/M 

programs. Stored by county, 

(may be 

modified by

IMCoverage 

EC 

EvapEC 

215
year, pollutant-process, fuel 

type, regulatory class, and

range of modelyears. Missing

data means no I/M. 

table editor) 

Link CVL Establishes the linkID values 

and relates Links to Counties, 

Zones, and Roadtypes. Its

informational data items are not

currently used. 

LTLP 

LinkAverageSpeed INF Stores average speed 

information for a Link. Used 

for Mesoscale Lookup 

LTLP TAG 

(Mesoscale 

lookup)

OMDG 

(Mesoscale 

lookup)

LinkHourVMTFraction INF Not yet used, a placeholder 

table, intended for smaller scale 

modeling 

(not used) 

ModelYear CVL Simply lists the valid

modelYearIDs

ModelYearGroup CVL Lists the modelYearGroupIds. 

Establishes a short form for 

embedding these in

sourceBinIDs 

MonthGroupHour INF Stores terms used to calculate

AC activity 

EC 

MonthGroupOfAnyYear CVL Establishes month groups, 

which currently are individual

months. Would allow fuelrelated info to be stored more 

coarsely. 

MonthOfAnyYear CVL Establishes the set of monthID 

values. Relates months to 

month groups. 

MonthVMTFraction INF Allocates annual VMT to 

months. Allocation is by

sourceTypeID. 

TAG 

OperatingMode CVL 

INF 

Establishes the opModeIDs. OMDG 

StartOMDG 

OpModeDistribution CMIT 

DIST

Stores operating mode 

distributions for several 

operating mode distribution 

generators 

OMDG 

StartOMDG 

EvapOMDG 

EC 

EvapEC 

OpModePolProcAssoc ASSOC Associates operating modes 

with pollutant-processes. 

Pollutant CVL 

INF 

Lists the pollutants calculated 

by the model, along with

information item(s) pertaining

to them. 

ChainedEC

PollutantDisplayGroup CVL 

INF 

Used by the MOVES GUI in

constructing the pollutantprocesses screen. 

PollutantProcessAssoc ASSOC Establishes the combinations of

pollutant and process which the 

model calculates 

216
PollutantProcessModelYear ASSOC Associates pollutant-processes 

with modelYearGroupIDs and 

fuelMYGroupIDs by listing

what model year group and fuel

model year group each 

pollutant-process-model year 

belongs to. 

RegClassFraction DIST Distributes elements of 

FuelEngFraction distributions 

by Regulatory Class 

AVFT SBDG 

RegulatoryClass CVL Establishes the set of 

RegClassIDs. 

RoadType CVL 

INF 

Establishes the set of 

roadTypeIDs. Indicates 

fraction of SHO on each driven 

on ramps. 

OMDG 

RoadTypeDistribution DIST Distributes VMT, by

sourceType, to roadTypes 

TAG 

SampleVehicleDay CVL 

INF 

Establishes the set of vehicles 

sampled for each kind of day.

Indicates the source type of 

each sample vehicle. 

TAG 

TTG 

SampleVehicleTrip INF Contains data about each trip

made by the sample vehicles. 

TAG 

TTG 

StartOMDG 

SCC CVL List of valid highway SCCs.

Decomposes this composite 

code into its component parts.

SCCProcess CVL List of process codes embedded 

in SCCs 

SCCRoadtype CVL List of road classifications

embedded in SCCs

SCCRoadTypeDistribution DIST Distributes activity on each 

roadtype in a zone to the 

SCCRoadtypes 

EC 

EvapEC 

SCCVtype CVL List of vehicle classifications 

embedded in SCCs

SCCVtypeDistribution DIST Distribution activity within a 

sourceTypeID, modelYearID, 

and fuelTypeID to 

SCCVtypeIDs 

EC 

EvapEC 

SHO CMIT Stores source hours operating

total activity and distance 

traveled. Geographically these 

are stored by Link. 

TAG 

SizeWeightFraction DIST Distributions elements of

FuelEngFraction distributions 

by engine size and vehicle 

weight. 

AVFT SBDG 

SoakActivityFraction CMIT 

DIST

Distributes hours of parking 

into hot soaking and cold

soaking 

TTG EvapOMDG 

SourceBin CMIT 

CVL 

Lists the sourceBins that used

in SourceBinDistributions. 

Forms an association among the 

SBDG EC 

EvapEC 

217
six source bin discriminating 

fields, indicating which

combinations are used. The

fact that source bins can be 

created dynamically is one of 

the most complicated aspects of 

the model. 

SourceBinDistribution CMIT 

DIST

Stores source bin distributions, 

which allocate total activity to

source bins. 

SBDG EC 

EvapEC 

SourceHours CMIT Store source hours (all hours in

which the source type exists, 

equal to SHO plus SHP) total 

activity. Geographicly these 

are stored by Link. 

TAG EvapOMDG 

EvapEC 

SourceTypeAge INF Stores information items which

depend only upon

sourceTypeID and ageID 

TAG 

EC 

SourceTypeAgeDistribution DIST Allocates source type 

population in each year to 

vehicle ageIDs

TAG 

SourceTypeHour INF Stores activity information 

pertinent to a sourceTypeID 

during each hourDayID, 

currently idleSHOFactor. 

TAG 

SourceTypeModelYear CVL 

INF 

Establishes combined IDs for 

combinations of sourceTypeID 

and modelYearID. Stores

information that depends only 

on these two factors, currently

ACPenetrationFraction.

EC 

SourceTypeModelYearGroup INF 

ASSOC

Associates 

TankTemperatureGroups with

combinations of sourceTypeID 

and modelYearGroupID 

TTG 

EvapEC 

SourceTypePolProcess ASSOC 

INF 

Establishes which combinations

of sourceTypeID and

polProcessID require source bin 

distributions. For such 

combinatations indicates which 

source bin discriminators are to

be considered in the source bin

distributions. 

SBDG 

SourceTypeYear INF Store vehicle population for 

base year, sales growth and 

migration rate information for 

other years 

TAG 

SourceUseType CVL 

INF 

Establishes the set of 

sourceTypeID values. Relates 

sourceTypeIDs to HPMS 

vehicle types. Stores items

depending only on

sourceTypeID 

OMDG 

Starts CMIT Stores total number of starts 

activity. Geographically this is 

TAG EC 

218
stored by Zone. 

StartsPerVehicle CMIT Stores number of starts per 

vehicle for each sourceType 

and hour on each kind of day

TAG TAG 

StartTempAdjustment INF Stores factors used to calculate 

temperature adjustments for 

certain pollutant-processes 

EC 

State CVL Defines the set of stateID 

values used in the database 

SulfateEmissionRate INF Stores “rates” used to calculate 

sulfate particulate emissions 

based on energy consumption

ChainedEC

TankTemperatureGroup CVL Defines the set of tank

temperature groups 

TankTemperatureRise INF Stores coefficients for the

equation used to calculate tank

temperature rise. 

TTG 

TankVaporGenCoeffs INF Store coefficients for the

equation used to calculate fuel

tank vapor generation 

EvapEC 

TemperatureAdjustment INF Stores factors used to calculate 

temperature adjustments for 

certain pollutant-processes 

EC 

EvapEC 

WeightClass CVL Establishes the set of weightID 

values. 

Year CVL 

INF 

Establishes the set of calendar 

years for which emissions may 

be estimated. Indicates which 

are base years. Maps years to a 

smaller set of “fuel years”. 

TAG 

EC 

ChainedEC

EvapEC 

Zone CVL 

DIST

Establishes the set of zoneIDs. 

Relates zones to counties. 

Stores information depending

only on zoneID, currently

several activity allocation 

factors. 

TAG 

ZoneMonthHour INF Stores information depending

only upon zoneID, monthID,

and hourID, currently 

meteorogy-related items. 

METG METG 

TTG 

TFG 

EC 

ZoneRoadType DIST Stores information depending

only upon zoneID and

roadTypeID, currently SHO 

allocation factors 

TAG 

11.4. Where to Find More Detailed MOVES Database Documentation 

More detailed documentation of the MOVES database is contained in a readme

directory within the actual database directory. Assuming that MySQL is installed at the 

standard location on your hard drive and that MOVES has been installed with the 

219
MOVES installation package, this would be 

C:\mysql\data\MOVESDByyyymmdd\readme where “yyyymmdd is the version date. 

Within this directory a Microsoft WORD document named “MOVESDB.doc” contains 

definitions for the tables and fields in the database for which the tablename is not fully 

explanatory. Also located in this directory are a set of Entity-Relationship diagrams 

illustrating the database. These take the form of “.pdf” files. The graphical conventions 

which apply to these diagrams, one of which also appears in chapter 12 of this document, 

include: 

Each rectangle represents a table. 

The primary key fields of the table are shown above the line horizontal line 

inside these rectangles. 

Fields designated “FK” are foreign key fields; i.e., they help identify related 

records in other tables. 

Lines connecting the rectangles represent relationships between records in the 

tables. 

A short perpendicular line at the end of relationship indicates that it is possible 

that one record from that table participates in the relationship.

A small “o” at the end of a relationship line indicates that it is possible that no 

records from that table participate in the relationship. 

A small “v” (sometimes refered to as “crow’s feet”) at the end of a relationship 

line indicates that it is possible that many records from that table participate 

in the relationship. 

220
12. MOVES-HVI Output Databases 

The MOVES GUI/Master program reports the results of each simulation run in 

the MySQL database named in its run specification. The MOVES GUI may also be used 

to create an “empty” MOVES Output Database. 

There are several software options for working with these databases once they 

have been created: 

In many situations the most convenient option is to use the “Summary 

Reporter” component described in Chapter 10 Section 34 of this document and in 

greater detail in the MOVES-HVI User Guide. This component, accessible via 

the “Post-Processing Menu in the MOVES GUI, can be used to aggregate the 

output various ways, producing screen displays (which can be printed) and tabseparated variable ASCII files which can be imported into other software. 

For operations that cannot be done with the Summary Reporter, the most 

natural method is to use MySQL itself, either via its command line client, which 

is installed as part of the MySQL installation, or via the MySQL Query Browser 

which is a graphical client program for MySQL. The command line client is 

invoked from a DOS window by entering the “mysql” command. The MySQL 

Query Browser is included in the MOVES-HVI Program Suite Distribution and 

requires a separate installation. A set of MySQL commands, produced by either 

client program, can be stored and executed again as a MySQL “script”. Several 

MySQL scripts are distributed with MOVES-HVI and are accessible via the 

“Post-Processor Script Execution” feature documented in Chapter 10.33. Users 

may add their own scripts to this menu in the MOVES GUI. 

MySQL output databases can also be used via Microsoft FoxPro or 

MicroSoft ACCESS via an ODBC connection. Even Microsoft EXCEL can be 

used in this fashion if the database is small enough. Instructions as to how to 

establish these ODBC connections can be found in Appendix B of the MOVESHVI User Guide. 

221
The results of multiple runs may be stored in the same database and are identified 

by MOVESRunID. This database consists of six tables as shown in Figure 12-1. 

Figure 12-1. Tables in Output Database 

222
12.1. MOVESRun Table 

The MOVESRun Table contains information that pertains to the model run as a 

whole. 

The MOVESRunID field contains a number identifying the model run. A single 

record is written into this table for each run. The first run whose results are stored in 

this database is assigned run number 1, and the number is incremented for any 

subsequent runs. 

The outputTimePeriod field indicates the time period (Hour, Single Day, Portion of 

the Week, Month, or Year) for this run. This is a MOVES GUI selection. 

The four Units fields indicate the engineering units used to express time, distance, 

mass, and energy results for this run. The GUI determines the time units 

automatically based on other selections. The last three are GUI selections. 

The runSpecFileName field contains the file name (not including path) of the 

RunSpecification upon which this run was based. Of course the contents of the 

runspec may have been changed since the run was performed. 

The runSpecDescription field contains the description portion of the run 

specification.

The runspecFileDateTime field indicates the time and date stamp the run 

specification file had when the run was executed. If this date-time differs between 

two runs using the same run specification file name, this may be an indication that 

some change was made to the run specification between the two runs. 

The runDateTime field contains the date and time the run began. 

The scale field indicates the modeling scale applicable to the run. In MOVE-HVI 

this field always contains the value “MACRO” for “Macroscale” or “MESLK” 

indicating “Mesoscale Lookup”. 

The minutesDuration field indicates the time required to complete the run, expressed 

in minutes. 

The defaultDatabaseUsed field indicates the name of the default database used for 

the run. 

The masterVersionDate field contains the version date of the master program used 

for the run. This is the same date as appears in a popup window when the program is 

started or the “Help-About MOVES” menu item is selected. 

The masterComputerID field contains the contents of a field in the MOVES 

Configuration file which is intended to indicate the computer used for the run. When 

MOVES is first installed this field is not meaningful. To change it a text editor can 

be used to edit this item in the MOVESConfiguration.txt file. 

223
12.2. MOVESError Table 

This table contains a record for each error message generated during runs for 

which this is the output database. Internally MOVES has several levels of error 

messages. Currently “warning-level” and “error level” messages are written to this file, 

and “informational level” messages are not. 

The MOVESErrorID field identifies the error message record. It serves as a key 

field for this table, but its value is not meaningful to the user. 

As in the other MOVES Output Database tables, the MOVESRunID field identifies 

the model run during which the error occurred. 

The errorMessage field contains the text of the error or warning level message. 

The other fields in this table were intended to identify the portion of the model run 

that experienced the error, but are not used in MOVES-HVI. 

12.3. The MOVESActivityOutput and MOVESOutput Tables 

These two tables contain the substantive results of each model run. Both tables 

are described in this section since they have many fields in common. The 

MOVESActivityOutput table is used to report activity-related information which is not 

specific to an emission process or pollutant. Distance traveled is the only such result 

produced by MOVE-HVI. (Future versions of the model may add fields to the 

MOVESActivityOutput table to report items such as number of starts, number of 

extended idle hours, etc.) The MOVESOutputTable is used to report the pollutant 

emission results, including energy consumption. The fields of these tables function as 

follows: 

The MOVESActivityOutputRowID and MOVESOutputRowId fields serve to 

uniquely identify rows in each table, but their values are not meaningful to users. 

The MOVESRunID field identifies the model run that produced each output record. 

The iterationID field supports estimation of the uncertainty of model results via 

Monte Carlo statistical approach described in Chapter 10. If uncertainty estimation 

is not being performed it has a value of 1. If uncertainty estimation is being 

performed it identifies the model iteration. 

The yearID field identifies the calendar year to which the output record pertains. 

The Year table in the MOVESDefault database defines its legal values. The 

distributed version of MOVESDefault is intended to support calendar year 1990 and 

years 1999 thru 2050. 

The monthID field identifies the month of the year (if any) to which the output 

record pertains. Its legal values are defined by the MonthOfAnyYear table in the 

224
MOVESDefault database and are 1 thru 12 in the distributed version. A null or zero 

value indicates that the record pertains to all months of the year that were included in 

the run specification. 

The dayID field identifies the day or portion of the week to which the output record 

pertains. Its legal values are defined by the DayOfAnyWeek table in the 

MOVESDefault database. A null or zero value indicates that the record pertains to 

all portions of the week that were included in the run specification. 

The hourID field identifies the hour of the day to which the output record pertains. 

Its legal values are defined by the HourOfAnyDay table in the MOVESDefault 

database and are 1 thru 24 in the distributed version (where hour number 1 begins at 

midnight). A null or zero value indicates that the record pertains to all hours of the 

day that were included in the run specification. 

The stateID field identifies the state to which the output record pertains. Its legal 

values are defined by the State table in the MOVESDefault database and are based 

on the FIPS state codes in the distributed version. A null or zero value indicates that 

the record pertains to all states in the modeling domain (normally the nation) that 

were included in the run specification. 

The countyID field identifies the county to which the output record pertains. Its 

legal values are defined by the County table in the MOVESDefault database and are 

based on the FIPS state and FIPS county codes in the distributed version. Note that 

these county identifications are unique across the entire database since they include 

the state identification. A null or zero value indicates that the record pertains to all 

counties in the state, (or, if stateID is also zero or null, the entire modeling domain) 

that were included in the run specification. When the state level data preaggregation 

computational shortcuts is taken, as described in Chapter 10.4, values of countyID 

based only on the FIPS states codes are used to represent entire states. 

The zoneID field is based on the countyID in the default database distributed with 

MOVES-HVI and provides no additional information in this case. Databases can be 

constructed, however, wherein each county may have multiple zones. 

The linkID field identifies the link (if any) to which the output record pertains. Its 

legal values are defined by the Link table in the MOVESDefault database and are 

based on the FIPS state and FIPS county codes and road type classifications in the 

distributed version. A null or zero value indicates that the record pertains to all links 

in the county or zone, that were included in the run specification. (In the default 

database distributed with MOVES-HVI this corresponds to all road types in the 

county that were included in the run specification.) This field has a special meaning 

in Mesoscale Lookup runs as describe in section 10.5. 

The sourceTypeID field numerically identifies the source use type (if any) to which 

the output record pertains. Its legal values are defined by the SourceUseType table 

in the MOVESDefault database. In the distributed default version these are: 

 11 Motorcycle 

21 Passenger Car 

31 Passenger Truck 

32 Light Commercial Truck 

225
 41 Intercity Bus 

42 Transit Bus 

43 School Bus 

51 Refuse Truck 

52 Single Unit Short-haul Truck 

53 Single Unit Long-haul Truck 

54 Motor Home 

61 Combination Short-haul Truck 

62 Combination Long-haul Truck 

A null value indicates that the output record does not pertain to a particular 

SourceUseType. (Either the user has selected to report by Source Classification 

Code (SCC) instead, or not to distinguish the results by any vehicle classification.) 

The SCC field identifies the Source Classification Code (if any) to which the output 

record pertains. Its legal values are defined by the SCC table in the MOVESDefault 

database. A null value indicates that the output record does not pertain to a particular 

SCC. (Either the user has selected to report by Source Use type instead, which is 

recommended, or not to distinguish the results by any vehicle classification.) 

The fuelTypeID field numerically identifies the top-level fuel type (if any) to which 

the output record pertains. A null value indicates that the record pertains to all fuel 

types. Whether results are to be distinguished by fuel type is a GUI selection and is 

included in the run specification. The legal values of fuelTypeID are defined by the 

FuelType table in the MOVESDefault database. In the distributed default version 

these are: 

 1 Gasoline 

 2 Diesel Fuel 

3 Compressed Natural Gas (CNG) 

4 Liquid Propane Gas (LPG) 

5 Ethanol (E85 or E95) 

6 Methanol (M85 or M95) 

 7 Gaseous Hydrogen 

 8 Liquid Hydrogen 

 9 Electricity 

The modelYearID field identifies the model year (if any) to which the output record 

pertains. A null value indicates that the record pertains to all model years. Whether 

results are to be distinguished by model year is a GUI selection and is included in the 

run specification. 

The roadTypeID field identifies the road type (if any) to which the output record 

pertains. The legal values of this field are defined by the RoadType table in the 

MOVESDefault database. In the distributed version of MOVES-HVI there are 4 

roadtypes intended to classify actual highways, plus a fifth RoadType representing 

locations in the zone which are not on the highway network. 

226
 1 Off-Network 

 2 Rural Roadways with Restricted Vehicle Access

 3 Rural Roadways with Unrestricted Vehicle Access 

 4 Urban Roadways with Restricted Vehicle Access 

 5 Urban Roadways with Unrestricted Vehicle Access 

MOVES associates start, extended idle, and well-to-pump emissions with RoadType 

1 and running emissions with the four actual roadway classifications. A null value of 

roadTypeID indicates that the results pertain to all roadway types. Whether to 

distinguish results by roadTypeID is a GUI selection that is included in the run 

specification. Producing results by SCC implies that roadtypes are not distinguished 

which is a change in MOVES-HVI. EPA considers roadtypes 2 thru 5 listed above 

to represent a set of HPMS roadway classifications, but MOVES itself does not 

make this assumption. 

The pollutantID field numerically identifies the pollutant to which the output record 

pertains. It is present only in the MOVESOutput table. Results are always 

distinguished by pollutant. The Pollutant table in the MOVESDefault database 

defines the legal values of pollutantID. In the distributed default MOVES-HVI 

database for the demonstration version they are as follows: 

 1 Total Gaseous Hydrocarbons 

 2 Carbon Monoxide (CO) 

 3 Oxides of Nitrogen (NOx) 

 5 Methane (CH4) 

 6 Nitrous Oxide (N20) 

 90 Atmospheric Carbon Dioxide (CO2) 

 91 Total Energy Consumption 

 92 Petroleum Energy Consumption 

 93 Fossil Energy Consumption 

 98 CO2 Equivalent 

105 Primary PM10 – Sulfate Particulate Matter 

111 Primary PM2.5 – Organic Carbon Particulate Matter 

112 Primary PM2.5 – Elemental Carbon Particulate Matter 

115 Primary PM2.5 - Sulfate Particulate Matter 

116 Primary PM2.5 – Brake Wear Particulate Matter 

117 Primary PM2.5 – Tire Wear Particulate Matter 

The processID field numerically identifies the emission process (if any) to which the 

output record pertains. It is present only in the MOVESOutputTable. The 

EmissionProcess table in the MOVESDefault database defines the legal values for 

processID. In the distributed version these are: 

 1 Running Exhaust 

 2 Start Exhaust 

227
90 Extended Idle Exhaust 

99 Well-to-Pump 

A null value in this field indicates that the result record pertains to all emission 

processes. Whether to distinguish results by emission process is a GUI selection that

is contained in the run specification. 

The emissionQuant field is present only in the MOVESOutput table and contains the 

quantity of emissions of the given pollutant as qualified by all the other identifying 

fields. Engineering units for mass type pollutants may be in terms of kilograms, 

grams, pounds, or U.S. tons as selected in the GUI, contained in the run specification 

and output in the MOVESRun table. Engineering units for energy consumption 

results may be in terms of Joules or millions of BTU’s as selected in the GUI, 

contained in the run specification, and output in the MOVERun table. 

The emissionQuantMean field is present only in the MOVESOutput table. It is only 

used if the uncertainty estimation feature is invoked in the run specification. In 

“normal” runs it contains a zero value. When uncertainty estimation is being 

performed it contains the mean value of emissionQuant in iterations up to and 

including the one represented by this record. 

The emissionQuantSigma field is present only in the MOVESOutput table. It is only 

used if the uncertainty estimation feature is invoked in the run specification. In 

“normal” runs it contains a zero value. When uncertainty estimation is being 

performed it contains the variance of the emissionQuant in iterations up to and 

including the one represented by this record. 

The distance field is present only in the MOVESActivityOutput table and contains 

the distance traveled as qualified by all the other identifying fields. Its engineering 

units may be miles or kilometers as selected in the GUI, contained in the run 

specification,and output in the MOVESRun table.

The distanceMean field is present only in the MOVESActivityOutput table. It is not 

used in the demonstration version of MOVES-HVI. 

The distanceSigma field is present only in the MOVESActivityOutput table. It is not 

used in the demonstration version of MOVES-HVI. 

228
Appendix A. Table of Acronyms 

AB aktiebolog (Swedish) 

AC air conditioning 

API application program interface 

AVFT alternative vehicle fuels and technologies 

ASCII American Standard Code for Information Interchange 

BTU British thermal unit 

CH4 methane 

CD compact disc 

CMIT core model input table 

CNG compressed natural gas 

CSEC criteria start emission calculator 

CSV comma-separated variable 

DOT Department of Transportation 

ECC energy consumption calculator 

EPA Environmental Protection Agency 

F Fahrenheit 

FERC future emission rate calculator 

FK foreign key 

FIPS federal information processing standard 

GB gigabyte 

GPL general public license 

GHz gigahertz 

GUI graphical user interface 

GNU GNU’s not UNIX (recursive) 

GREET Greenhouse gases, Regulated Emissions, and Energy uses in 

Transportation 

H2 hydrogen 

HC hydrocarbons 

HDT heavy duty truck 

HPMS Highway Performance Management System

IC internal combustion 

ID identification 

IM inspection/maintenance 

kW kiloWatt 

LDT light duty truck 

LDV light duty vehicle 

LPG liquified propane gas 

LTLP lookup table link producer 

MAR mileage accumulation rate 

MB megabyte 

MOVES MOtor Vehicle Emissions Simulator 

MOVES-HVI The Highway Vehicle Implementation of MOVES 

N2O nitrous oxide 

NMIM National Mobile Inventory Model 

229
OBD on board diagnostics 

ODBC open database connectivity 

OMDG operating mode distribution generator 

OTAQ Office of Transportation and Air Quality 

PTW pump-to-wheel 

RAM random access memory 

RTC runs to completion 

SBDG source bin distribution generator 

SCC source classification code

SDK software development kit 

SDRM Software Design and Reference Manual 

SHO source hours operating 

SHP source hours parked 

SQL structured query language 

SUV sport utility vehicle 

TAG total activity generator 

US United States 

VMT vehicle miles traveled 

VOC volatile organic hydrocarbon 

VSP vehicle specific power 

WTP well-to-pump 

XML extended markup language 

230