Draft Motor Vehicle Emission Simulator
(MOVES) 2009
Software Design and Reference Manual
United States
Environmental Protection
Agency
-------
Draft Motor Vehicle Emission Simulator
(MOVES) 2009
Software Design and Reference Manual
Assessment and Standards Division
Office of Transportation and Air Quality
U.S. Environmental Protection Agency
SER&
United States
Environmental Protection
Agency
EPA-420-B-09-007
March 2009
-------
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.
-------
Table of Contents
A Note about the Capitalization and Naming Conventions Used in this Document 2
1. Introduction 6
2. MOVES Software Components 10
3. Computer Hardware and System Software Requirements 12
3.1. Details on JAVAPlatform Requirements 12
3.2. Details on My SQL Platform Requirements 13
3.3. Details on Shared File Directory Platform Requirements 14
4. MOVES Computer Platform Configuration 15
5. MOVES Software Licensing 18
6. Installation Overview 19
7. Processing Overview 22
8. Data and Control Flow 23
9. Functional Design Concepts 28
9.1. Geographic Locations 28
9.2. Time Periods 30
9.3. Characterizing Emission Sources (Vehicle Classification) 31
9.4. Emission Pollutants 35
9.5. Emission Processes 35
9.6. Vehicle Fuel Classifications 36
9.7. Emission Source Activity 38
9.8. Modeling Vehicle Inspection/Maintenance Programs 42
10. MOVES Functional Specifications 45
10.1. Graphical User Interface (GUI) / Run Specification Editor 46
10.2. Application Program Interface and Master Looping Mechanism 46
10.3. Input Data Manager 47
10.4. Database Pre-Aggregation 48
10.5. Mesoscale Lookup Table Link Producer (LTLP) 60
10.6. Total Activity Generator (TAG) for Macroscale 61
10.7. Total Activity Generator (TAG) for Mesoscale Lookup 72
-------
10.7A. Total Activity Generator (ProjectTAG) for Project Level Modeling 80
10.8. Running OperatingModeDistributionGenerator (OMDG) for Macroscale 90
10.9. Running OperatingModeDistributionGenerator (OMDG) for Mesoscale Lookup
99
10.10. Source Bin Distribution Generator (SBDG) 106
10.11. Meteorology Generator Ill
10.12. Start OperatingModeDistributionGenerator (StartOMDG) 113
10.13. Tank Temperature Generator (TTG) 115
10.14. Tank Fuel Generator (TFG) 124
10.15. Evaporative OperatingModeDistributionGenerator (EvapOMDG) 129
10.16. Alternative Vehicle Fuels and Technologies (AVFT) Strategy 131
10.17. Energy Consumption Calculator (ECC) 136
10.18. Distance Calculator 143
10.19. Methane (CH4) and Nitrous Oxide (N2O) Calculator 146
10.20. Atmospheric CO2 and CO2-Equivalent Calculator 148
10.21. Criteria Pollutant Running EmissionCalculator (CREC) 150
10.22. Criteria Pollutant Start EmissionCalculator (CSEC) 162
10.23. Basic Running PM EmissionCalculator 172
10.24. Sulfate PM EmissionCalculator (SEC) 179
10.25. Basic Start PM EmissionCalculator 182
10.26. Basic Brake and Tire Wear Emission Calculators 187
10.27. CriteriaAndPMExtendedldleEmissionCalculator 188
10.28 Air Toxics Calculator 194
10.29. Permeation Calculator 197
10.30. Liquid Leaking (LL) Calculator 201
10.3l.HCSpeciation Calculator (HCSC) Calculator 204
10.32. Tank Vapor Venting (TVV) Calculator 206
10.33. Result Data Aggregation and Engineering Units Conversion 215
10.34. Post-Processor for Mesoscale Lookup 219
10.35. Post-Processing Script Execution 220
10.36. Summary Reporter 222
-------
10.37. GREET Model Interface 226
10.38 Future Emission Rate Creator (FERC) 230
10.39 I/M Coverage Table Editor 234
10.40 Estimating the Uncertainty of MOVES Results 235
10.41. Retrofit Strategy 239
11. DRAFT MOVES2009 Input and Default Databases 241
11.1. Use of Data Types 242
11.2. Functional Types of Tables: 243
11.3. Database Tables and Their Use 244
11.4. Where to Find More Detailed MOVES Database Documentation 252
12. DRAFT MOVES2009 Output Databases 254
12.1. MOVESRun Table 256
12.2. MOVESError Table 256
12.3. The MOVESActivityOutput, MOVESOutput, MOVESMesoscalActivityOutput
and MOVESMesoscaleOutput Tables 257
Appendix A. Table of Acronyms 262
Appendix B. MOVES Error/Warning Messages 264
-------
1. Introduction
The Draft 2009 Motor Vehicle Emission Simulator (DRAFT MOVES2009) is
released to the general public mainly for users' review and comments. A follow-up final
version of MOVES, scheduled to be released in late 2009, will include modifications
based on users' feedback and EPA's planned enhancement. DRAFT MOVES2009, which
is the third of the current series of the MOVES "implementations", includes several new
features, e.g., user data importers and air toxic. Although this draft model contains more
realistic estimates of pollutant emissions than previous versions, it still holds some
placeholder data, for example the emission rates for motorcycles were set to 0 (zero),
which serve as placeholders to make users aware that the model includes motorcycles,
while numeric estimates are not currently available. In addition, the GREET model
interface that was incorporated in earlier versions has been disabled in this version
because it is no longer operational. EPA hopes to restore this GREET functionality in a
future version of MOVES.
A brief description of the two previous versions of MOVES before Draft
MOVES2009 is as follows.
• MOVES2004 (released in 2004): the first version of MOVES that can be used to
estimate and project national inventories at the county level for energy
consumption, N2O, and CH4from highway vehicles.
• MOVES-HVI (released in 2007): a demonstration version of MOVES that is the
Highway Vehicle Implementation of EPA's Motor Vehicle Emission Simulator.
The MOVES-HVI retains much of the functionality of MOVES2004 with a few
significant updates as it 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. It is suitable only for demonstration purposes; none of its numerical
value results should be considered to be realistic.
-------
Future implementations of MOVES are planned to operate at smaller scales,
estimate non-highway mobile source emissions, and estimate pollutants from additional
mobile sources such as aircraft, locomotives, and commercial marine activity.
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
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 Draft MOVES2009 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 Draft MO VES2009 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
DRAFT MOVES2009. 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 DRAFT MOVES2009 software is
divided into about 25 components.
Chapter 9 discusses the functional design concepts of MOVES.
Chapter 10 documents the functionality of most of the individual components of
MOVES, their inputs, the calculations they perform, and the outputs they produce. This
single chapter composes nearly half of the entire document.
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 DRAFTMOVES2009 User Guide and the Draft
MOVES2009 Software Design and Reference Manual. Those most closely related to the
software are:
The MOVES Program Suite Distribution which 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 DRAFT
MOVES2009 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.
Although the GREET interface has been disabled in MOVES, the
documentation for GREET is provided in this version because EPA hopes
to restore this functionality in a future version of MOVES.
-------
2. MOVES Software Components
MOVES is written in Java™ 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. This "MOVESDefault"
may be replaced by a database specifically named as "MOVESDByyyymmdd" in the
10
-------
MOVES installation package, where yyyymmdd stands for a string of year, month and
day.
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
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.
11
-------
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 512MB 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 dual-core processor(s), at least 1-2 GHz and preferably faster, are
highly recommended. The MOVESDefault database distributed with MOVES requires
approximately 1.3 GB 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 MOVE 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, WINDOWS XP, and 32-bit Vista systems. MOVES does not operate successfully
on 64-bit Vista or 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
12
-------
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 DRAFT MOVES2009
Program Suite Distribution includes an installation package for this MySQL version,
suitable for installation on WINDOWS NT, WINDOWS 2000, WINDOWS XP and 32-
bit Vista systems. The version of DRAFT MOVES2009 will not operate with MySQL
version 4.0.21 or earlier, neither will the future MOVES versions. Users are not
recommended to attempt to operate MOVES program with MySQL versions of 5.1 or
later since EPA has not tested MOVES on them. 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. DRAFT MOVES2009 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 DRAFT
MOVES2009 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/Sun Microsystems.
13
-------
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 3 GB of disk space should be available.
14
-------
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.
Single Computer Configuration
Computer # 1
Master/GUI
Program
Worker Program
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
15
-------
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.
16
-------
Typical Multiple Computer Configuration
Computer # 1
MasterVGUI
Program
Computer # 2
Shared File
Directory
Computers # 3, ,n
MySQL Server
MGVlESWorker
Program
17
-------
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/.
18
-------
6. Installation Overview
The DRAFT MOVES2009 Program Distribution Suite contains all software
components necessary to install and use DRAFT MOVES2009 on microcomputer
systems based on the WINDOWS NT, WINDOWS 2000, WINDOWS XP and 32-bit
Vista software operating systems. Installing MOVES on a 64-bit Vista machine is not
recommended at this time since MySQL on 64-bit Windows Vista machines is not yet
supported by MySQL AB. Users should be able to install and run MOVES and its
components/tools on a 32-bit Vista machine. Please be advised that currently EPA won't
be unable to provide further support for Vista until Vista has become part of EPA IT OS
standards. The MOVES Program Suite Distribution is available for download from the
EPA web site. Because of its size (several hundred MBs) 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
19
-------
double-click on the installer installation program (J2sdk-l_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 DRAFT MOVES2009 operates with MySQL version 5.0.27
and EPA's 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 DRAFT MOVES2009 components can be installed by running
the MOVESInstallationPackage.jar file included in the DRAFT MOVES2009 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 DRAFT MOVES2009.
20
-------
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.
21
-------
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
' Master
MOVESWindow
RunSpec
rotalActivityGenerator,
WellToPumpProcessor,
OperatingModeDistributionGenerator,
AVFTControlStrategy,
FuelEngineStartCalculator
MasterLoopables —
MasterLoopables
TotalActivity Generator,
WellToPumpProcessor,
OperatingModeDistributionGenerator,
AVFTControl Strategy,
FuelEngineStartCalculator
MasterLoop
Ti Slnstantiator .performlnstanti ati on
EmissionCalculatorlnboundUnBundlerO
MYSQL •"
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.
22
-------
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.
23
-------
Figure 8-1 MOVES Logical Level Data Flow Diagram
MOVES
Command Line
Interface
Application Program
Interface (API) I
Master Loop
Via Master Loop-
. RTC- •
-RTC- ,
Pre-Processor
Menu Items
>\
\
\
J
h \
t
\
i,
RtunSpdc R
-IN,
Database
Preaggregatlon
Total Activity
Generator (TAG)
Operating Mode
Distribution
Generators
(OMDGs)
Source Bin
Distribution
Generator
(SBDG)
~
_
Meterotogy
Generator
Lookup Table Link
Producer
Tank Fuel and
Temperature
Generators
Text Files
for Data
Import
Alternative Vehicle
Fuels and
Technology
(AVFT) Strategy
MOVES
Execution
Database
nput Data
Manager
User Input
Databases
Result Data
lion /
Units Conversion
Emission
Calojlatofs
MOVES
Default
Database
Post Processor for
Mesoscale Lookup
Table
Post-Processing
Script or
Summary Reporter
MOVES
Output
" Database
On-Screen and
Printed Reports
Taxi Fltes for
Data Export
The graphical conventions used in this diagram are:
24
-------
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.
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
database with any User Input Databases specified by the RunSpec, producing the
MOVESExecution database
25
-------
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. DRAFT MOVES2009 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. DRAFT MOVES2009 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.
After all Generators, Internal Control Strategies and Emission Calculators needed
to produce the results required by the run specification have executed, several more
26
-------
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. DRAFT
MOVES2009 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 tab-separated variable ASCII files of selected results. These are suitable for
importing into other software, such as spreadsheets, for further display and analysis.
27
-------
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 DRAFT MOVES2009 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.
28
-------
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 previous versions of MOVES 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 previous versions of MOVES. 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,
29
-------
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 DRAFT MOVES2009
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
30
-------
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.
31
-------
Table 9-1. MOVES Source Use Type Definitions
HPMS Class
Passenger Cars
Other 2-axle / 4-tire
Vehicles
Single Unit Trucks
Buses
Combination Trucks
Motorcycles
MOVES use type
2 1 . Passenger Car
3 1 . Passenger Truck
32. Light Commercial Truck
5 1 . Refuse Truck
52. Single-Unit Short-Haul
Truck
53. Single-Unit Long-Haul
Truck
54. Motor Home
41. Intercity Bus
42. Transit Bus
43. School Bus
61. Combination Short-Haul
Truck
62. Combination Long -Haul
Truck
1 1 . Motorcycle
Description
Minivans, pickups, SUVs and other
2-axle / 4-tire trucks used primarily
for personal transportation
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
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
Single -unit trucks with majority of
operation within 200 miles of home
base
Single -unit trucks with majority of
operation outside of 200 miles of
home base
Buses which are not transit buses or
school buses, e.g. those used
primarily by commercial carriers for
city -to-city transport.
Buses used for public transit.
School and church buses.
Combination trucks with majority
of operation within 200 miles of
home base
Combination trucks with majority
of operation outside of 200 miles of
home base
32
-------
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
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.l 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 Ib. compact car and 5000 Ib. 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
DRAFT MOVES2009 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 PARTS and NMDVI. This scheme is not native to MOVEs, however, and the
MOVEs modeling team discourages continued use of this classification scheme.
33
-------
Table 9-2a. MOVES Source Bin Definitions (other than ModelYearGroup)
Fuel Type
(All Pollutants)
Gas
Diesel
CNG
LPG
Ethanol (E85)
Methanol (E85)
GasH2
Liquid H2
Electric
Engine Technology
(All Pollutants)
Conventional 1C (CIC)
Advanced 1C (AIC)
Hybrid - CIC Moderate
Hybrid - CIC Full
Hybrid - AIC Moderate
Hybrid - AIC Full
Fuel Cell
Hybrid - Fuel Cell
Electric
Loaded
Weight
(Energy)
Null
< 500 (for motorcycles)
500-700 (for motorcycles)
> 700 (for motorcycles)
<= 2000 Ibs
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
Engine
Size
(Energy)
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
Regulatory Class
(All pollutants except
energy and evap
permeation)
Null
Motorcycle
LDV
LOT
HD gasoline GVWR <= 14K Ibs
HD gasoline GVWR > 14K libs.
LHDD
MHDD
HHDD
Urban Bus
Table 9-2b. MOVES Source Bin Definitions (ModelYearGroup)
Model Year Group
Energy
1980 and earlier
1981-85
1986-90
1991-2000
2001-2010
2011-2020
2021 and later
CH4, N2O
1972 and earlier
1973
1974
1975
1999
2000
2001-2010
2011-2020
2021 and later
HC - Evap
1970 and earlier
1971-1977
1978-1995
1996-2003
2004
2005
2019
2020
2021 and later
HC, CO,
NOx, PM
start, running
1980 and earlier
1981-1982
1983-1984
1985
1986-1987
1988-1989
1990
1991-1993
1994
1995
2019
2020
2021 and later
HC, CO,
NOx, PM
extended idle
1980 and earlier
1981-85
1986-90
1991-2000
2001-2006
2007-2010
2011-2020
2021 and later
Sulfate PM
(ratios to
energy)
1980 and earlier
1981 and later
34
-------
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 DRAFT MOVES2009 are total energy
consumption, fossil fuel energy consumption, and petroleum fuel energy consumption.
The more familiar mass emissions estimated by DRAFT MOVES2009 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 DRAFT MOVES2009 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.
-------
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 DRAFT MOVES2009, 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. DRAFT MOVES2009 has not been
expanded in this area relative to MOVES-HVI or MOVES2004 and so only
reports the well-to-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. It should
also be noted that GREET in DRAFT MOVES2009 has been disabled and
the emission rates of well-to-pump were set to 0 (zero).
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
36
-------
fuel. The MOVES term for this top-level classification of vehicle fuels is "fuel type".
DRAFT MOVES2009 considers the following fuel types:
Gasoline
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 DRAFT MOVES2009 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 DRAFT MOVES2009 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.
37
-------
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
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 DRAFT
MOVES2009 the Total Activity Generator (TAG) estimates Total Activity for all
emission processes except well-to-pump. A simplified version of the TAG is used for
runs involving mesoscale table lookup.
38
-------
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
emission rates. The operating mode concept is central to MOVES multi-scale analysis
capability, and has been expanded in DRAFT MOVES2009. 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
39
-------
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 kW/tonne
Oto3
3 to 6
6 to 9
9 to 12
12 and greater
6 to 12
<6
0-25mph
Bin 11
Bin 12
Bin 13
Bin 14
Bin 15
Bin 16
-
-
25-50
Bin 21
Bin 22
Bin 23
Bin 24
Bin 25
Bin 26
-
-
>50
-
-
-
-
-
Bin 36
Bin 35
Bin 33
Table 9-5. Operating Mode Bin Definitions for Running THC, CO, NOx
Braking (Bin 0)
Idle (Bin 1)
VSP \ Instantaneous Speed
< 0 kW/tonne
Oto3
3 to 6
6 to 9
9 to 12
12 and greater
12 to 18
18 to 24
24 to 30
30 and greater
6 to 12
<6
0-25mph
Bin 11
Bin 12
Bin 13
Bin 14
Bin 15
Bin 16
25-50
Bin 21
Bin 22
Bin 23
Bin 24
Bin 25
Bin 27
Bin 28
Bin 29
Bin 30
>50
Bin 37
Bin 38
Bin 39
Bin 40
Bin 35
Bin 33
40
-------
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
opModelD
101
102
103
104
105
106
107
108
minSoakBound
in minutes
null
6
30
60
90
120
360
720
maxSoakBound
in minutes
6
30
60
90
120
360
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
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.
41
-------
9.8. Modeling Vehicle Inspection/Maintenance Programs
The MOVES model contains two basic classes for estimating Inspection and
Maintenance program (I/M) benefits. One is the exhaust I/M calculation class and the
other is evaporative I/M calculation class. Both classes have a similar basic algorithm
where the I/M emission reduction fraction is the product of an I/M Coverage fraction and
an Emission Reduction fraction.
9.8.1. I/M Coverage
Information about which pollutant-processes are "covered" by I/M programs in
various counties and calendar years is contained in the MOVES database table
IMCoverage. This coverage information is allowed to vary by pollutant - process,
county, year, regulatory class, and fuel type. The principal piece of information
contained in the IMCoverage table is the compliance factor. It attempts to represent (in
practice) a particular I/M program's ability to achieve theoretical design benefits for their
program. It may vary from 0 to 1.0 where zero would represent a totally failed program
and 1.0 a perfectly successful program. Factors which tend to reduce the compliance
factor are the systematic waiver of failed vehicles from program requirements, the
existence of large numbers of motorists who completely evade the program requirements,
technical losses from improperly functioning equipment or inadequately trained
technicians.
Other data in the IMCoverage table includes the concept of I/M program sub-
types (called IMProgramID). A particular county will likely have several IMProgramlDs
that reflect different test types, test standards or inspection frequencies being applied to
different regulatory classes, model year groups or pollutant- process combinations. For
example, County A in calendar year 2007 may have an IMProgramID=l that annually
inspects pre-1981 model year cars using an Idle test, and an IMProgramID=2 that
biennially inspects 1996 and later model year light-trucks using an OBD-II test.
The IMCoverage table also shows other important I/M parameters for each
IMProgramID. These include the model year information as a model year range (i.e.,
42
-------
beginning and ending model year), the frequency of inspection (i.e., annual, biennial and
continuous (i.e., monthly)), and test type (Idle, IM240, ASM, OBD-II) and test standard.
9.8.2. I/M Effectiveness
Information about the theoretical effectiveness of an I/M program design is
contained in the MOVES database table IMF actor. The effectiveness information varies
by pollutant - process, inspection frequency, test type, test standards, regulatory class,
fuel type, model year group and age group. All MOVES I/M effectiveness values
(IMFactor variable) were empirically generated from MOBILE6.2 runs. The Arizona
I/M program as generally operated from 1995 through 2002 was used as the reference
case. It receives an IMF actor of unity. Arizona's I/M program was picked as the
reference because the underlying emission factors in MOVES are based on Arizona I/M
testing. The principal piece of information contained in the IMCoverage table is the
IMF actor. It represents the comparative effectiveness of one particular I/M test to
identify and reduce emissions.
The IMFactor and IMCompliance rate are multiplied together to compute the
IMAdjustFract. It is used in MOVES in the following general equation, and is labeled as
variable 'R'. This equation is used to weight the I/M and Non I/M emission rates
together in MOVE to compute a composite result.
Ep = Eim * R + Enoim*(l — R)
Ep is the Target I/M program emission rate from MOBILE6.2
Eim is the Reference I/M program (Arizona) emission rate from MOBILE6.2
Enoim is the Reference NON I/M program emission rate from MOBILE6.2
R is the I/M adjustment factor
Rearranging and solving for R equals:
43
-------
R — (Ep — Enoim) / (Eim - Enoim)
or
R = Ep /( Eim — Enoim) - Enoim / (Eim — Enoim)
I/M-i Merge IMCompliance and IMFactor
This section computes the product of IMCompliance and IMFactor
Input Variables:
PollutantProcessModelYear. polProcessID,
PollutantProcessModelYear. modelYearlD,
IMFactor. fuelTypelD,
IMFactor. regClassID,
IMFactor. IMFactor
IMCoverage. complianceFactor
Output Variable:
IMAdjustFract
weightF actor
Joining and Conditional Variables
polProcessID
countylD
yearlD
modelYearlD
inspectFreq
testTypelD
testStandardsID
regClassID
fuelTypelD
begModelYearlD
endModelYearlD
Calculation:
IMAdjustFract = (IMFactor*complianceFactor*.01)
complianceFactor as weightF actor
44
-------
I/M-2 Combine I/M and Non I/M Emission Rates
This section weights the I/M and Non I/M Emission Rates using the
IMAdjustFract
Input Variables:
IMAdjustmentWithSourceBin. zonelD,
IMAdjustmentWithSourceBin, yearlD,
EmissionRateByAge. polProcessID,
IM Adj ustmentWith S ourceB in. model YearlD,
EmissionRateByAge. sourceBinID,
EmissionRateByAge. opModelD
IMAdjustmentWithSourceBin. IMAdjustFract
EmissionRateByAge. meanBaseRate
Output Variable:
meanBaseRate
Joining and Conditional Variables
polProcessID
sourceBinID,
ageGroupID
Calculation:
meanBaseRate = (meanBaseRatelM * IMAdjustFract +
meanBaseRate * (i.o-IMAdjustFract)
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.
45
-------
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 DRAFT
MOVES2009 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
performed, an integrated post-processor is also invoked to create an additional table of
emission rates in the output database.
46
-------
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.
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.
47
-------
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
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
48
-------
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.
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.
49
-------
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 statelD, countylD, 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
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 "activity-
weighted" aggregations involve compromise and simplification. Specifically, the activity
50
-------
weighting is based entirely upon "startAllocFactor" values in the Zone table. The
variable startAllocF actor 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
DRAFT MOVES2009 this allocation is based on vehicle miles traveled (VMT), hence
the use of startAllocF actor for the pre-aggregation weightings is in essence a VMT
weighting. More details on startAllocF actor 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
statelD
County
Single Record, countylD = 0.
stateID=0, countyName=Nation,
altitude=L
barometric pressure and GPAFract
are activity-weighted.
Single record per statelD,
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 statelD,
zoneID=stateID* 10000,
countyID= statelD* 1000
startAllocFactor = sum of old factors for
state.
Same for idleAllocFactor and
SHPAllocFactor
Single record for each roadTypelD
in RunSpec.
HnkID=roadTypeID,
county ID = 0.
zonelD = 0.
linkLength = NULL
linkVolume = NULL
grade = weighted national average
Link
Single record for each statelD - roadTypelD
in RunSpec.
linkID= statelD * 100000 + roadTypelD,
countylD = statelD* 1000,
zoneID = statelD* 10000
linkLength = NULL
linkVolume = NULL
grade = weighted state average
CountyYear
Single record for each yearlD,
countylD = 0
Single record per statelD - yearlD
combination. countylD = statelD* 1000.
51
-------
ZoneMonthHour
Single record for each monthlD-
hourlD combination in old table.
(These have been filtered.)
Calculate activity-weighted national
average temperature and relative
humidity.
heatlndex and specific humidity are
recalculated by Met generator.
Single record for each combination of new
zonelD, month and hour. (These have been
filtered.)
Calculate activity-weighted state average
temperature and relative humidity.
heatlndex and specific humidity are
recalculated by Met generator.
OpMode
Distribution
(contents would be from user input.)
Aggregate to national level roadType
linklDs, weighting by activity.
(contents would be from user input.)
Aggregate to state level roadType linklDs,
weighting by activity.
ZoneRoadtype
Single record for each roadTypelD.
SHOAllocFactor = sum of old
SHOAllocFactors
Single record for each new zonelD,
roadTypelD combination. SHOAllocFactor
= sum of old SHOAllocFactors
Fuel Supply
(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, activity-
weighted 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.
extendedldleHours field is a simple
summation.
(contents would be from user input.)
Combine all zones within state.
extendedldleHours field is a simple
summation.
52
-------
SCCRoadType
Distribution
Combine all zones,
SCCRoadTypeFractions are activity-
weighted.
Combine all zones in state,
SCCRoadTypeFractions are activity-
weighted.
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 activity-
weighted.
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.
ColdSoaklnitial
HourFraction
(contents would be from user input.)
Combine all zones,
coldSoaklnitialHourFraction values
are activity-weighted.
(contents would be from user input.)
Combine all zones in state,
coldSoaklnitialHourFraction values are
activity-weighted.
AverageTank
Gasoline
(contents would be from user input.)
Combine all zones, ETOFfVolume
and RVP values are activity-
weighted.
(contents would be from user input.)
Combine all zones in state, ETOFfVolume
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 pre-
aggregations. 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 activity-
weighted summations to be performed entirely correctly, something approaching the full
execution of the control strategies and generators would have to be performed which
53
-------
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 Day VMTFraction table; and the activity weighting used for the YEAR
aggregation is based upon the values in the Month VMTFraction 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.)
HourWeightingl: is based directly on the HourVMTFraction table itself, which is
used to aggregate tables sharing its sourceTypelD, roadTypelD, and daylD primary
keys.
HourWeightingl: uses RoadTypeDistribution to aggregate HourVMTFraction over
Roadtype. This is used to aggregate tables having sourceTypelD and daylD, but not
roadTypelD.
HourWeightingS: is a simple weighting by hourlD used to aggregate tables sharing no
keys with HourVMTFraction except hourlD. It is produced from HourWeightingl by
using the data for the passenger car source type, and giving equal weight to all
portions of the week.
HourWeighting4: is produced from HourWeightingl by using the data for the
passenger car source type. This is used to aggregate tables sharing no keys with
HourVMTFraction except daylD and hourlD.
For aggregating days (periods of the week) into Months, three activity-weighting
variations are needed. The third is an approximation.
54
-------
DayWeightingl: is based on the DAYVMTFraction table, with MonthID removed by
using weights from MonthVMTFraction. Its key fields are sourceTypelD,
roadTypelD, and day ID.
DayWeighting2: is based on DayWeightingl, with roadTypelD removed by using
information from RoadTypeDistribution. Its key fields are sourceTypelD and daylD.
Day Weightings: is based on DayWeightingl, and uses the distribution for
sourceTypelD = 21 for all sourceTypes.
For aggregating months into years, only one activity-weighting is needed, and it is an
approximation:
Month Weighting: based on Month VMTFraction 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.
55
-------
Table 10-2. Description of Time Period Aggregations to Be Performed
MOVES Database
Table
HourOfAnyDay
DayOfAnyWeek
HourDay
MonthOfAny
Year
MonthGroup
OfAnyYear
HourVMT
Fraction
DayVMT
Fraction
MonthVMT
Fraction
AvgSpeed
Distribution
Aggregation of Hours to
DAY (Portion of the
week)
Single Record, hourID=0,
hourName = "Entire day".
Record for each daylD,
hourDaylD = daylD;
hourID=0
Record for each
SourceType- RoadType-
Day combination.
HourVMTFraction = 1.0
Activity-weighted average
avgSpeedFraction using
HourWeightingl
Aggregation of Days
(Portions of the week) to
MONTH
(assumes DAY
aggregation.)
Single record.
dayID=0.
dayName = "Whole
Week"; noOfRealDays=7
Single record. dayID=0.
hourID=0.
Record for each
SourceType- RoadType
combination.
HourVMTFraction = 1.0
Record for each
SourceType-Month-
RoadType combination.
DayVMTFraction = 1.0
Activity-weighted
average
avgSpeedFraction using
Day Weighting 1
Aggregation of Months
to YEAR
(assumes MONTH
aggregation.)
Single record.
MonthID = 0
noOfDays = 365
monthGroupID=0
Single record.
MonthGroupID=0
monthGroupName =
"Entire Year".
Record for each
SourceType-RoadType
combination.
DayVMTFraction = 1.0
monthVMTFraction = 1.0
56
-------
OpMode
Distribution
(contents would be
from user input.)
Activity-weighted average
opModeFraction using
HourWeightingl
Activity-weighted
average opModeFraction
using Day Weighting 1
Source Type
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
extendedldleHours
Simple summation of
extendedldleHours
Simple summation of
extendedldleHours
ZoneMonthHour
Activity-weighted average
temperature and
relHumidity using
HourWeightingS.
MetGenerator will
recalculate heatlndex and
specific humidity.
Activity-weighted
average temperature and
relHumidity using
MonthWeighting.
MetGenerator will
recalculate heatlndex and
specific humidity.
MonthGroup
Hour
Activity-weighted
ACActivity terms using
HourWeightingS.
Activity-weighted
ACActivity terms using
MonthGroup Weighting.
Sample VehicleTrip
Set hourlD = 0 for all trips
Set daylD = 0 for all
trips. Assumes vehlDs
are unique across day IDs.
Sample VehicleDay
Set daylD = 0 for all
vehicle days. Assumes
vehlDs are unique across
daylDs.
StartsPerVehicle
(contents would be
from user input.)
hourDaylD = daylD
Simple summation of
StartsPerVehicle
hourDaylD = 0.
Simple summation of
StartsPerVehicle
57
-------
Fuel Supply
Activity-weighted
marketshare using
MonthGroup Weighting.
(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 DayWeightingS.
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
58
-------
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, AC Activity, fuel Subtype marketshares, average fuel tank temperatures and
soakactivityfractions.
- When calculating annual data from monthly data, all years are considered to be non-
leap years.
An initial analysis of the sensitivity of MOVES results to levels of pre-aggregation was
presented in the report "MOVES2004 Validation Results". While DRAFT MOVES2009
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 pre-
aggregation was selected was about 2 percent higher than the same run where nation /
year pre-aggregation was selected.
59
-------
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 zonelD in the RunSpec,
and each roadTypelD in the RunSpec.
a. The linkID is generated to be a unique value. (Current macroscale linkID * 100 +
averageSpeedBinID.)
b. The zonelD and roadTypelD fields are populated appropriately.
c. The countylD field is populated based on the zonelD.
d. The linkLength, link Volume 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 linklDs. The average speed value used is the avgBinSpeed value from
the AverageSpeedBin table for the AvgSpeedBin represented by the Link.
60
-------
10.6. Total Activity Generator (TAG) for Macroscale
This generator calculates total activity pursuant to the run specification for each
source use type in DRAFT MOVES2009 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,
ExtendedldleHours, 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 Total ActivityGenerator 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
TAG-0
Determine the base year
Description
Determine the appropriate base year to use in
61
-------
TAG-1
TAG-2
2a
2b
2c
TAG-3
3a
3b
3c
TAG-4
TAG-5
TAG-6
TAG-7
7a
7b
7c
7d
7e
TAG-8
8a
8b
8c
8d
8e
TAG-9
Calculate Base Year Vehicle
Population
Grow Vehicle Population to Analysis
Year
AgeO
Age 1 through 29
Age 30 and higher
Calculate Analysis Year Travel
Fraction
Calculate total population within
HPMS vehicle class
Calculate fraction within HPMS
vehicle class
Compute travel fraction
Calculate Analysis Year VMT
Allocate Analysis Year VMT By
Roadway Type, Use Type, Age
Allocate Annual VMT to Hour by
Roadway Type, Use Type, Age
Convert to Total Activity Basis By
Process
Calculate average speed
Convert to SHO
Calculate Starts
Convert SHO to Exetended Idle Hours
Calculate Source Hours Parked (SHP)
Allocate Total Activity to Location
Allocate SHO to Links
Allocate Starts to Zones
Allocate Extended Idle Hours to Zones
Allocate SHP to Zones
Calculate Source Hours by Zone and
Roadway
Calculate Distance Traveled
growth calculations
Establish base-year vehicle population in
modeling domain by use type, age
If analysis year is in future, establish analysis
year population through growth and scrappage
Calculation travel fraction across domain as
function of age mix and annual miles traveled,
by use type and age
If analysis year is in future, establish analysis
year aggregate VMT across domain from base
year VMT and growth
Allocate aggregate VMT to roadway type, use
type and age
Allocate annual VMT to hourly VMT
Convert to total activity basis at domain level:
SHO, Starts, Extended Idle Hours, Source
Hours Parked (a portion of Source Hours)
Allocate total activity to locations using
geographic allocation factors
Calculate SHO. distance from SHO and
average speeds
62
-------
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, 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, ExtendedldleHours 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:
yearlD = calendar year
IF isBaseYear(yearID) = "Y", then baseYeai=yearID.
ELSE
63
-------
baseYear = maximum value of yearlD 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 (yearlD, sourceTypelD, agelD) =
sourceTypePopulation (yearlD, sourceTypelD) *
ageFraction (yearlD, sourceTypelD, agelD)
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,
forageID=0 andyearID=yearID-l
salesGrowthFactor (SourceTypeYear)
migrationRate (foryearlD andyearID-1) (SourceTypeYear)
Output Variable:
sourceTypeAgePopulation (for ageID=0 in current yearlD)
Calculation:
sourceTypeAgePopulation (yearlD, sourceTypelD, ageID=0) =
[sourceTypeAgePopulation (yearID-1, sourceTypelD, ageID=0) /
migrationRate (yearID-1, sourceTypelD)] *
salesGrowthFactor (yearlD, sourceTypelD) *
migrationRate (yearlD, sourceTypelD)
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.
64
-------
Input Variables:
sourceTypeAgePopulation (for ageID=x and yearID=yearID-l)
survivalRate (for AgeID=x) (SourceTypeAge)
migratioriRate (SourceTypeYear)
Output Variable:
sourceTypeAgePopulation (for ageID=l through 29 in current yearlD)
Calculation:
sourceTypeAgePopulation (yearlD, sourceTypelD, ageID=x) =
sourceTypeAgePopulation (yearID-1, sourceTypelD, ageID=x-l) *
survivalRate (sourceTypelD, ageID=x-l) *
migrationRate (yearlD, sourceTypelD)
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-l)
survivalRate (for ageID=29 & 30) (SourceTypeAge)
migrationRate (SourceTypeYear)
Output Variable:
sourceTypeAgePopulation (for ageID=30 in current yearlD)
Calculation:
sourceTypeAgePopulation (yearlD, sourceTypelD, ageID=30) =
sourceTypeAgePopulation (yearID-1, sourceTypelD, ageID=29) *
survivalRate (sourceTypelD, ageID=29) *
migrationRate (yearlD, sourceTypelD) +
sourceTypeAgePopulation (yearID-1, sourceTypelD, ageID=30) *
survivalRate (sourceTypelD, ageID=30) *
migrationRate (yearlD, sourceTypelD)
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 sourceTypelD within HPMS VtypelD)
(SourceTypeYear)
HPMSVtypelD (HPMSVtype)
Output Variable:
HPMSVtypePopulation
Calculation:
HPMSVTypePopulation (yearlD, HPMSVtypelD) =
Sum of [SourceTypeAgePopulation (yearlD, sourceTypelD, agelD)]
over all agelD,
for all sourceTypelD within each HPMSVtypelD.
TAG-3b: Calculate fraction within HPMS vehicle class
Input Variables:
65
-------
sourceTypeAgePopulation (from step 2)
HPMSVtypePopulation (from previous step)
Output Variable:
fractionwithinHPMSVtype
Calculation:
fractionwithinHPMSVtype (yearlD, sourceTypelD, agelD) =
sourceTypeAgePopulation (yearlD, sourceTypelD, agelD) /
HPMSVTypePopulation (yearlD, HPMSVtypelD, sourceTypelD)
TAG-3c: Compute travel fraction
Input Variables:
fractionwithinHPMSVtype (from previous step)
relativeMAR (SourceTypeAge)
Output Variable:
travelFraction
Calculation:
travelFraction (yearlD, sourceTypelD, agelD) =
(fractionwithinHPMSVtype (yearlD, sourceTypelD, ageID=x) *
relativeMAR (sourceTypelD, ageID=x)) /
Sum of [fractionwithinHPMSVtype (yearlD, sourceTypelD, ageID=x) *
relativeMAR (sourceTypelD, ageID=x)] over all agelD and for all
sourceTypelD 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 yearlD until the analysis year is reached.
TAG-4 a: Base year.
In the base year, the analysis Year VMT is the same as the HPMSBaseYearVMT.
Input Variables:
HPMSBaseYearVMT (yearID=BaseYear) (HPMSVtypeYear)
Output Variable:
analysisYearVMT
Calculation:
analysisYearVMT (yearlD, HPMSVTypelD) =
HPMSBaseYearVMT (yearlD, HPMSVTypelD)
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:
66
-------
analysisYearVMT
Calculation:
analysisYearVMT (yearlD, HPMSVTypelD) =
analysisYearVMT (yearID-1, HPMSVTypelD) *
VMTGrowthFactor (yearlD, HPMSVTypelD)
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:
annual VMTbyAgeRoadway
Calculation:
annualVMTbyAgeRoadway (yearlD, roadTypelD, sourceTypelD, agelD) =
analysisYearVMT (yearlD, HPMSVTypelD) *
roadTypeVMTFraction (roadTypelD, sourceTypelD) *
travelFraction (yearlD, sourceTypelD, agelD)
10.6.7. TAG-6: Allocate Annual VMT to Hour
Input Variables:
annualVMTbyAgeRoadway (from previous step)
monthVMTFraction (MonthVMTFraction)
day VMTFraction (Day VMTFraction)
hourVMTFraction (HourVMTFraction)
noOfDays (MonthOfAnyYear)
Output Variable:
VMTbyAgeRoadwayHour
Calculation:
VMTbyAgeRoadwayHour (yearlD, roadTypelD, sourceTypelD, agelD,
monthID, daylD, hourlD) =
annualVMTbyAgeRoadway (yearlD, roadTypelD, sourceTypelD, agelD) *
monthVMTFraction (sourceTypelD, isLeapYear, monthID) *
day VMTFraction (roadTypelD, sourceTypelD, monthID, daylD) *
hourVMTFraction (roadTypelD, sourceTypelD, daylD, hourlD)
/ (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:
average Speed
Calculation:
averageSpeed (roadTypelD, sourceTypelD, daylD, hourlD) =
67
-------
Sum of [avgBinSpeed(avgSpeedBin) *
averageSpeedFraction(roadTypeID, sourceTypelD, daylD, hourlD,
avgSpeedBin)] over all avgSpeedBin
Tag-7b: Convert VMTtoSHO
Input Variables:
VMTbyAgeRoadwayHour (from step 6)
average Speed (from previous step)
Output Variable:
SHObyAgeRoadwayHour
Calculation:
SHObyAgeRoadwayHour (yearlD, roadTypelD, sourceTypelD, agelD,
monthID, daylD, hourlD) =
VMTbyAgeRoadwayHour(yearID, roadTypelD, sourceTypelD, agelD,
monthID, daylD, hourlD) /
averageSpeed (roadTypelD, sourceTypelD, daylD, hourlD)
Tag-7c: Calculate Starts
Preliminary Calculation
For each combination of sourceTypelD, hourlD, and day ID
startsPerVehicle = (number of records in INNER JOIN of Sample VehicleDay
and SampleVehicleTrip with non null keyOnTimes)
(number of records in Sample VehicleDay)
This calculation excludes "Marker Trips".
Input Variables:
startsPerVehicle (sourceTypelD, hourlD, daylD)
sourceTypeAgePopulation (yearlD, sourceTypelD, agelD) (from step 2)
Output Variable:
StartsByAgeHour
Calculation:
StartsByAgeHour (yearlD, sourceTypelD, agelD, day ID, hourlD) =
sourceTypeAgePopulation (yearlD, sourceTypelD, agelD) *
startsPerVehicle (sourceTypelD, hourlD, daylD)
68
-------
Tag-7d: Convert SHO to Extended Idle Hours
Input Variables:
SHObyAgeRoadwayHour (from step 7b)
idleSHOFactor (SourceTypeHour)
Output Variable:
idleHoursbyAgeHour
Calculation:
idleHoursbyAgeHour (yearlD, sourceTypelD, agelD, monthID, day ID, HourlD)
(Sum over 24 hours and over all Roadtypes (SHObyAgeRoadwayHour(yearID,
roadTypelD, sourceTypelD, agelD, monthID, daylD, hourlD))) *
idleSHOFactor(sourceType, daylD, hourlD)
Tag-7e: Calculate Source Hours Parked (SHP)
Input Variables:
SHObyAgeRoadwayHour (yearlD, roadTypelD, sourceTypelD, agelD,
monthID, daylD, hourlD) (from step 7b)
sourceTypeAgePopulation (yearlD, sourceTypelD, agelD) (from step 2)
noOfRealDays (DayOfAnyWeek)
Output Variable:
SHPbyAgeHour (yearlD, sourceTypelD, agelD, monthID, day ID, hourlD)
Calculation:
SHPbyAgeHour = sourceTypeAgePopulation * noOfRealDays-
Sum 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)
SHO AllocationFactor (ZoneRoadway Type)
Output Variable:
SHO (SHO)
This result populates the SHO field in SHO table.
Calculation:
SHO(yearID, zonelD, roadTypelD, sourceTypelD, agelD, monthID, day ID,
hourlD) =
SHOByAgeRoadwayHour(yearID, roadTypelD, sourceTypelD, agelD,
monthID, daylD, hourlD) *
SHOAllocationFactor( zonelD, roadTypelD)
Tag-8b: Allocate Starts to Zones
Input Variables:
startsByAgeHour (from step 7c)
69
-------
startAllocFactor (Zone)
Output Variable:
Starts (Starts)
Result of TAG-8b populates "starts" field of Starts Table
Calculation:
starts(yearID, zonelD, sourceTypelD, agelD, monthlD, daylD, hourlD):
startsByAgeHour(yearID, sourceTypelD, agelD, daylD, hourlD) *
startAllocFactor(zonelD))
Tag-8c: Allocate Extended Idle Hours to Zones
Input Variables:
IdleHoursByAgeHour (from step 7d)
idleAllocFactor (Zone)
Output Variable:
extendedldleHours(ExtendedldleHours)
Result of TAG-8c populates "extendedldleHours" field of ExtendedldleHours
Table
Calculation:
extended!dleHours(yearID, zonelD, sourceTypelD, agelD, monthlD, daylD,
hourlD) =
idleHoursByAgeHour(yearID, sourceTypelD, agelD, monthlD, daylD, hourlD)
* idleAllocFactor(zonelD)
Tag-8d: Allocate SHP to Zones
Input Variables:
SHPByAgeHour (from step 7e)
SHPAllocFactor (Zone)
Output Variable:
SHP (in an intermediate table)
Calculation:
SHP(yearID, zonelD, sourceTypelD, agelD, monthlD, daylD, hourlD) =
SHPByAgeHour(yearID, sourceTypelD, agelD, monthlD, daylD, hourlD) *
SHPAllocFactor(yearID, zonelD)
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, zonelD, roadTypelD <> OffNetwork, sourceTypelD,
agelD, monthlD, day ID, hourlD) = SHO(yearID, zonelD, roadTypelD,
sourceTypelD, agelD, monthlD, daylD, hourlD)
70
-------
sourceHours(yearID, zonelD, roadTypelD = OffNetwork, sourceTypelD, agelD,
montMD, daylD, hourlD) = SHP(yearID, zonelD, sourceTypelD, agelD,
monthID, daylD, hourlD)
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
average Speed from step 7a
Output Variable:
distance (in SHO table)
Calculation:
distance (yearlD, monthID, linkID (zonelD with roadTypelD), hourlD, daylD,
agelD, aourceTypelD) =
SHO((yearID, monthID, linkID (zonelD with roadTypelD), hourlD, daylD,
agelD, sourceTypelD ) * averageSpeed(roadTypeID, sourceTypelD, daylD,
hourlD)
71
-------
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 DRAFT MOVES2009 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.
72
-------
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
VMTGrowthF actor
roadTypeVMTFraction
averageSpeedFraction
idleSHOFactor
SHO All ocati onF actor
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.
73
-------
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:
yearlD = calendar year
IF isBaseYear(yearID) = "Y", then baseYeai=yearID.
ELSE
baseYear = maximum value of yearlD 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 (yearlD, sourceTypelD, agelD) =
sourceTypePopulation (yearlD, sourceTypelD) *
ageFraction (yearlD, sourceTypelD, agelD)
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,
forageID=0 andyearID=yearID-l
salesGrowthFactor (SourceTypeYear)
migrationRate (foryearlD andyearID-1) (SourceTypeYear)
74
-------
Output Variable:
sourceTypeAgePopulation (for ageID=0 in current yearlD)
Calculation:
sourceTypeAgePopulation (yearlD, sourceTypelD, ageID=0) =
[sourceTypeAgePopulation (yearID-1, sourceTypelD, ageID=0) /
migrationRate (yearID-1, sourceTypelD)] *
salesGrowthFactor (yearlD, sourceTypelD) *
migrationRate (yearlD, sourceTypelD)
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-l)
survivalRate (for AgeID=x) (SourceTypeAge)
migrationRate (SourceTypeYear)
Output Variable:
sourceTypeAgePopulation (for ageID=l through 29 in current yearlD)
Calculation:
sourceTypeAgePopulation (yearlD, sourceTypelD, ageID=x) =
sourceTypeAgePopulation (yearID-1, sourceTypelD, ageID=x-l) *
survivalRate (sourceTypelD, ageID=x-l) *
migrationRate (yearlD, sourceTypelD)
TAG-2c:Age30
This calculation is for Age 30, which includes years 30 and higher.
Input Variables:
sourceTypeAgePopulation (for ageID=29 & 30 and yearID=yearID-l)
survivalRate (for ageID=29 & 30) (SourceTypeAge)
migrationRate (SourceTypeYear)
Output Variable:
sourceTypeAgePopulation (for ageID=30 in current yearlD)
Calculation:
sourceTypeAgePopulation (yearlD, sourceTypelD, ageID=30) =
sourceTypeAgePopulation (yearID-1, sourceTypelD, ageID=29) *
survivalRate (sourceTypelD, ageID=29) *
migrationRate (yearlD, sourceTypelD) +
sourceTypeAgePopulation (yearID-1, sourceTypelD, ageID=30) *
survivalRate (sourceTypelD, ageID=30) *
migrationRate (yearlD, sourceTypelD)
10.7.4. TAG-3: Calculate Analysis Year Travel Fraction
75
-------
TAG-3a: Calculate total population within Highway Performance Management System
(HPMS) vehicle class.
Input Variables:
sourceTypePopulation (for each sourceTypelD within HPMS VtypelD)
(SourceTypeYear)
HPMSVtypelD (HPMSVtype)
Output Variable:
HPMSVtypePopulation
Calculation:
HPMSVTypePopulation (yearlD, HPMSVtypelD) =
Sum of [SourceTypeAgePopulation (yearlD, sourceTypelD, agelD)]
over all agelD,
for all sourceTypelD within each HPMSVtypelD.
TAG-3b: Calculate fraction within HPMS vehicle class
Input Variables:
SourceTypeAgePopulation (from step 2)
HPMSVtypePopulation (from previous step)
Output Variable:
fractionwithinHPMSVtype
Calculation:
fractionwithinHPMSVtype (yearlD, sourceTypelD, agelD) =
SourceTypeAgePopulation (yearlD, sourceTypelD, agelD) /
HPMSVTypePopulation (yearlD, HPMSVtypelD, sourceTypelD)
TAG-3c: Compute travel fraction
Input Variables:
fractionwithinHPMSVtype (from previous step)
relativeMAR (SourceTypeAge)
Output Variable:
travelFraction
Calculation:
travelFraction (yearlD, sourceTypelD, agelD) =
(fractionwithinHPMSVtype (yearlD, sourceTypelD, ageID=x) *
relativeMAR (sourceTypelD, ageID=x)) /
Sum of [fractionwithinHPMSVtype (yearlD, sourceTypelD, ageID=x) *
relativeMAR (sourceTypelD, ageID=x)] over all agelD and for all
sourceTypelD 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.
76
-------
Input Variables: TravelFraction(yearID, sourceTypelD, agelD)
Output Variable: AnnualVMTbyAgeRoadway
Calculation:
AnnualVMTby AgeRoadway(YearID, roadTypelD, sourceTypelD, AgelD) =
TravelFraction(YearID, sourceTypelD, AgelD)
10.7.7. TAG-6: Temporally Allocate Annual VMT to Hour
Input Variables:
annualVMTbyAgeRoadway (from previous step)
monthVMTFraction (MonthVMTFraction)
day VMTFraction (Day VMTFraction)
hourVMTFraction (HourVMTFraction)
noOfDays (MonthOfAnyYear)
Output Variable:
VMTbyAgeRoadwayHour
Calculation:
VMTbyAgeRoadwayHour (yearlD, roadTypelD, sourceTypelD, agelD,
monthID, daylD, hourlD) =
annualVMTbyAgeRoadway (yearlD, roadTypelD, sourceTypelD, agelD) *
monthVMTFraction (sourceTypelD, isLeapYear, montMD) *
day VMTFraction (roadTypelD, sourceTypelD, monthID, daylD) *
hourVMTFraction (roadTypelD, sourceTypelD, daylD, hourlD)
/ (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 (yearlD, roadTypelD, sourceTypelD, agelD,
monthID, daylD, hourlD) =
VMTbyAgeRoadwayHour(yearID, roadTypelD, sourceTypelD, agelD,
monthID, daylD, hourlD)
77
-------
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, countylD, zonelD, roadTypelD) (Created by the LTLP)
Output Variable:
SHO (SHO)
This result populates the SHO field in SHO CMIT table.
Calculation:
SHO(yearID, linkID, sourceTypelD, agelD, monthID, daylD, hourlD) =
SHOByAgeRoadwayHour(yearID, roadTypelD, sourceTypelD, agelD,
monthID, daylD, hourlD)
Tag-8b: Calculate Source Hours by Zone and Roadway
Input Variables:
SHO (from step 8a)
LinkAverageSpeed(linklD)
Output Variable:
sourceHours(SourceHours) result of this step populates sourceHours field in
SourceHours table
Calculation:
sourceHours(yearID, linkID, sourceTypelD, agelD, monthID, day ID, hourlD):
SHO(yearID, linkID, sourceTypelD, agelD, monthID, daylD, hourlD)
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
average Speed from step 7a
Output Variable:
78
-------
distance (in SHO table)
Calculation:
distance (yearlD, monthID, linkID (zonelD with roadTypelD), hourlD, daylD,
agelD, aourceTypelD) =
SHO((yearID, monthID, linkID (zonelD with roadTypelD), hourlD, daylD,
agelD, sourceTypelD ) * averageSpeed(linklD)
79
-------
10.7A. Total Activity Generator (ProjectTAG) for Project Level
Modeling
This version of the ProjectTAG is used for the Project Level Domain Scale and is
analogous, but also substantially different from the "Macroscale" and "Mesoscale" TAG
described in the preceding sections. A MOVES project-level analysis is the modeling of
one or more individual roadway links which are spatially connected to each other. It also
extends the definition of project to off-network common areas within the project
boundaries where vehicle starts, extended idling and evaporative emissions are allocated.
This generator calculates and allocates total activity basis, starts, source-hours parked
(SHP) and source hours pursuant to the run specification for each user specified link /
roadway type and source type. The ProjectTAG produces core model input tables in
MOVESExecution containing these results: SHO, SHP and SourceHours. The TAG does
not calculate distance traveled information because it is a user input for each link.
Some overall considerations when performing these calculations are:
1. The ProjectTAG signs up for the Master Loop at the Year level which means the
calculations are performed individually for the specified year, location, hour for each
emission process requiring SHO, SHP or source hour activity information.
2. The MOVES design requires the user to provide all of the values basic inputs for the
calculator
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.
Detailed descriptions of the calculations in each TAG step follow. Each of the
principal variables used in the TAG calculations are entered by the user into a special
Project database or are calculated by a previous TAG step. The table in which each
variable can be found is indicated in parentheses in the "Input Variables" portion of each
80
-------
Project!AG step description. The Project!AG implementation can be found in the Java
method "Project!AG.allocateTotalActivityBasis".
10.7A.1 Determine Project Context
The MOVES Runspec and the Project Data Manager input must have the same
context in terms of MOVES countylD, zonelD, yearlD, and hourlD. Only one value of
each may be specified in a Project Level Runspec. Both Day IDs, any and all
sourcetypelDs, pollutantID and processID may be chosen in the Runspec, but these must
be consistent between the Runspec and the Project Data Manager.
The ProjectTAG allocates activity according the Runspec and Project Data
Manager inputs. The allocations are according to:
Age SourceTypeAgeDistribution as a functionjyear} - either a
user input or calculated by ProjectTAG.
SHO source hours operating
SHP source hours parked
Starts vehicle starts / soak times
Extldle extended idle operation
SH source hours
The possible process allocations for ProjectTAG include:
evapPermeationProcess
evapFuelVaporVentingProcess
evapFuelLeaksProcess
evapNonFuelVaporProcess
runningExhaustProcess
extendedldleProcess
exhaustStartProcess
brakeWearProcess
ProjectTAG-2a Total Population Calculation
81
-------
Calculate the total population for ages 1 through 30 for the given year and
sourcetypes
Input Variables:
sourceTypeAgePopulati on.population,
where yearid = year
sourcetypelD = sourcetype
Output Variable:
sourceTypeAgePopulationSummary. totalPopulation
Calculation:
Sum [sourceTypeAgePopulation.population[ageID]] AgeID=x,
where x is 1 through 29
ProjectTAG-2b Age Fraction Calculation
Calculate the age fraction for the given year, age and sourcetype
Input Variables:
sourceTypeAgePopulation.population,
sourceTypeAgePopulati onSummary. totalPopulation
where yearid = year
sourcetypelD = sourcetype
Output Variable:
sourceTypeAgeDistribution. ageFraction
Calculation:
p.population / s.totalPopulation) as ageFraction"
Where
sourceTypeAgePopulationSummary as s"
sourceTypeAgePopulation as p "
82
-------
ProjectTAG-3 Calculation Source Hours Operating (SHO)
This section calculates the sourcehours operating if a roadway link is selected by the
user. Context variables are from the Runspec.
Input Variables:
runSpecSourceType. Context.sourceTypelD
runSpecDay. Context (daylD)
runSpecMonth. Context (monthID)
hourDay. Context (hourDaylD)
dayOfAnyWeek. noOfRealDays
link. HnkAvgSpeed
link. linkVolume
link. linkLength
HnkSourceTypeHour. sourceTypeHourFraction
sourceTypeAgeDistribution. ageFraction
Output Variable:
SHO, distance
Calculation:
SHO = (linkVolume * sourceTypeHourFraction * noOfRealDays
* ageFraction) * linkLength / HnkAvgSpeed
distance = linkVolume * sourceTypeHourFraction *
noOfRealDays * ageFraction * linkLength
Proj ectTAG-4 Calculation Source Hours Parked (SHP)
This section calculates the sourcehours parked if an off-network link is selected by
the user. Context variables are from the Runspec.
Input Variables:
runSpecSourceType. Context.sourceTypelD
runSpecDay. Context (daylD)
runSpecMonth. Context (monthID)
83
-------
hourDay. Context (hourDaylD)
offNetworkLink. vehiclePopulation
offNetworkLink. parkedVehicleFraction
dayOfAnyWeek. noOfRealDays
sourceTypeAgeDistribution. ageFraction
Output Variable:
SHP
Calculation:
SHP = (vehiclePopulation * parkedVehicleFraction * ageFraction)
ProjectTAG-5 Calculation Starts (STARTS)
This section calculates the number of starts if an off-network link is selected by the
user. Context variables are from the Runspec.
Input Variables:
runSpecSourceType. Context.sourceTypelD
runSpecDay. Context (daylD)
runSpecMonth. Context (monthID)
hourDay. Context (hourDaylD)
offNetworkLink. vehiclePopulation
offNetworkLink. startFraction
sourceTypeAgeDistribution. ageFraction
Output Variable:
STARTS
Calculation:
STARTS = (vehiclePopulation * startFraction * ageFraction)
84
-------
ProjectTAG-6 Calculation Extended Idle (Extldle)
This section calculates the fraction of extended idle operation if an off-network link is
selected by the user. Context variables are from the Runspec.
Input Variables:
runSpecSourceType. Context.sourceTypelD
runSpecDay. Context (daylD)
runSpecMonth. Context (monthID)
hourDay. Context (hourDaylD)
offNetworkLink. vehiclePopulation
offNetworkLink. extendedldleFraction
sourceTypeAgeDistribution. ageFraction
Output Variable:
extendedldleFraction
Calculation:
extendedldleFraction = (vehiclePopulation * extendedldleFraction
* ageFraction)
Proj ectTAG-7a Calculation Source Hours (SH)
This section calculates the source hours if an off-network link is selected by the user.
Context variables are from the Runspec. This variable is used in the calculation of
evaporative processes.
Input Variables:
runSpecSourceType. Context.sourceTypelD
runSpecDay. Context (daylD)
runSpecMonth. Context (monthID)
hourDay. Context (hourDaylD)
offNetworkLink. vehiclePopulation
offNetworkLink. parkedVehicleFraction
dayOfAnyWeek. noOfRealDays
sourceTypeAgeDistribution. ageFraction
85
-------
Output Variable:
SH
Calculation:
SH = (vehiclePopulation * parkedVehicleFraction * ageFraction)
Proj ectTAG-7b Calculation Source Hours (SH)
This section calculates the source hours if a roadway link is selected by the user.
Context variables are from the Runspec. This variable is used in the calculation of
evaporative processes.
Input Variables:
runSpecSourceType. Context.sourceTypelD
runSpecDay. Context (daylD)
runSpecMonth. Context (monthID)
hourDay. Context (hourDaylD)
dayOfAnyWeek. noOfRealDays
link. HnkAvgSpeed
link. linkVolume
link. linkLength
HnkSourceTypeHour. sourceTypeHourFraction
sourceTypeAgeDistribution. ageFraction
Output Variable:
SH
Calculation:
SH = (linkVolume * sourceTypeHourFraction * noOfRealDays *
ageFraction) * linkLength / HnkAvgSpeed
86
-------
10.7B. Link Operating Mode Distribution Generator (ProjectTAG) for
Project Level Modeling
The Link Operating Mode Distribution Generator is used in the calculation of
project domain emission inventories, and is closely associated with the ProjectTAG
generator. This class called "LinkOperatingModeDistributionGenerator.java" builds an
operating mode distribution for a particular project domain link from a speed-time
driving cycle when it is supplied by the user. The generator is not utilized in cases where
the user chooses to enter the operating mode distribution for the particular link directly as
a distribution.
10.7B.1 Calculate VSP Second by Second
This section calculates the vehicle specific power (VSP) in units of kW/tonne
using first principals of vehicle dynamics. The code recursively joins 'itself (i.e.,
driveScheduleSecondLink) to create acceleration and previous second acceleration
values for the special case of the 'braking' opmode (opmodelD = 0).
Input Variables:
sourceUseType. sourcetypelD
driveScheduleSecondLink. linkID
driveScheduleSecondLink. secondID
driveScheduleSecondLink. speed
driveScheduleSecondLink. grade
sourceUseType. sourceMass
sourceUseType. rollingTermA
sourceUseType. rotatingTermB
sourceUseType. dragTermC
constantTerml 0.44704 - conversion miles/hour to
meters/second
constantTerml 9.81 - gravitational constant meters/sec2
87
-------
Output Variable:
Calculation:
VSP
VSP = [ ((speed*0.44704)*(rollingTermA+
(speed*0.44704)*(rotatingTermB+
dragTermC*(speed*0.44704)))/sourceMass ] +
(speed*0.44704)*(a.speed-b.speed)*0.44704 +
(9.81*sin(atan(grade/100.0))*(speed*0.44704)))
10.7B.2
Count the Total Seconds in the Link
This section counts the total seconds in the link. It is grouped by source type and
link.
Input Variables:
Output Variable:
Calculation:
tempDriveScheduleSecondLink. sourceTypelD
tempDriveScheduleSecondLink. linkID
tempDriveScheduleSecondLinkTotal. secondTotal
Count(*) group by sourceTypelD and linkID
10.7B.3 Count the Seconds per Individual opModelD
This section counts the total seconds in the link and opmodelD combination. It is
grouped by source type, opmodelD and link.
Input Variables:
tempDriveScheduleSecondLink. sourceTypelD
tempDriveScheduleSecondLink. linkID
tempDriveScheduleSecondLink. opModelD
-------
Output Variable:
tempDriveScheduleSecondLinkCount. secondCount
Calculation:
Count(*) group by sourceTypelD, linkID and opModelD
10.7B.4 Calculate the opMode Fraction for each opMode
This section calculates the operating mode fraction by source type, operating
mode and link.
Input Variables:
tempDriveScheduleSecondLinkCount. sourceTypelD
tempDriveScheduleSecondLinkCount. linkID
tempDriveScheduleSecondLinkCount. opModelD
Output Variable:
tempDrive ScheduleSecondLinkFraction. opModeFraction
Calculation:
opModeFraction = (secondCount*i.o/secondTotal)
10.7B.5 Calculate the opMode Distribution Linking hourdaylD and polprocessID
This section calculates the operating mode distribution and creates the opmode
distribution table. It is grouped by sourceTypelD, hourDaylD, linkID, and
polProcessID.
Input Variables:
tempDriveScheduleSecondLinkFraction. sourceTypelD
tempDriveScheduleSecondLinkFraction. linkID
tempDri ve Schedul e S econdLinkFracti on. opModelD
tempDriveScheduleSecondLinkFraction. opModeFraction
opModePolProcAssoc. polProcessID
RunSpecHourDay. hourDaylD
Output Variable:
89
-------
opModeDi stributi on. opModeFracti on
Calculation:
opModeFraction
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 $\Q 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.
90
-------
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
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
OMDG-1
OMDG-2
OMDG-3
OMDG-4
OMDG-5
OMDG-6
OMDG-7
Description
Determine bracketing drive schedules
Determine proportions for bracketing drive schedules
Determine distribution of drive schedules, including a sub-step to reflect
separation of ramp and non-ramp freeway driving
Calculate second-by-second vehicle specific power (VSP)
Determine operating mode bin for each second
Calculate operating mode fractions for each drive schedule
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.
91
-------
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. 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. However, it is not done
for ramp drive schedules. A separate algorithm that does not include bracketing is used
for ramps.
Input Variables:
AvgBinSpeed (avgSpeedBinID) from the AvgSpeedBin table.
AverageSpeed(driveSchedulelD) from the DriveSchedule table.
Output Variables:
BracketScheduleLo (sourceTypelD, roadTypelD, avgSpeedBinID)
LoScheduleSpeed (sourceTypelD, roadTypelD, avgSpeedBinID)
BracketScheduleHi (sourceTypelD, roadTypelD, avgSpeedBinID)
HiScheduleSpeed (sourceTypelD, roadTypelD, avgSpeedBinID)
Calculation:
For each sourceTypelD, roadTypelD, and avgSpeedBinID:
The output variables are determined using table DriveSchedule, where for each
combination of sourceTypelD, roadTypelD, 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. lo Schedule Speed and hiSchedule Speed are the values of
averageSpeed for the bracket schedules. The DriveScheduleAssoc table
contains the information as to which driveSchedulelD's are associated with
which sourceTypelD's and which roadTypelD'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
92
-------
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 (sourceTypelD, roadTypelD, hourDaylD, avgSpeedBinID)
from the AvgSpeedDistribution table.
with
BracketScheduleLo (sourceTypelD, roadTypelD, avgSpeedBinID)
loScheduleSpeed (sourceTypelD, roadTypelD, avgSpeedBinID)
bracketScheduleHi (sourceTypelD, roadTypelD, avgSpeedBinID)
hiScheduleSpeed (sourceTypelD, roadTypelD, avgSpeedBinID)
Output Variable:
loScheduleFraction (sourceTypelD, roadTypelD, hourDaylD, avgSpeedBinID)
hiScheduleFraction (sourceTypelD, roadTypelD, hourDaylD, avgSpeedBinID)
Calculation:
For each sourceTypelD, roadTypelD, hourDaylD 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
Drive Schedule As soc table determines whether a schedule is to be associated with ramp
driving or with driving on roadways exclusive of ramps. Currently, the MOVESDefault
contains ramp activity with a constant ramp fraction of 8 percent for the two roadtypes
with"isRamp = 'Y'.
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
Drive Schedule As soc table
93
-------
OMDG-3a: Determine distribution of ramp schedules
This step accounts for ramps, based on the input fields RampFraction and
opModeFraction contained in table RoadType and RoadOpmodeDistribution tables,
respectively. For any driving schedule which is associated with the source type and
roadway type which has an IsRamp value of "Y", the following methodology is used to
calculate the ramp contribution.
The calculation starts, by obtaining from the RoadOpmodeDistribution table, the
operating mode distribution for each sourcetype, average speed bin and roadtype (only
those which contain ramp driving are selected). Next, the algorithm determines the road
type's average speed for each sourcetype and hour. The avgSpeedFraction is taken from
the avgSpeedDistribution table and the avgBinSpeed is from the avgSpeedBin table.
Input Variables:
avgSpeedFraction(sourceTypeID, roadTypelD, hourDaylD,
avgSpeedBinID
avgBinSpeed(avgSpeedBinlD)
roadTypeSourceTypeAvgSpeedBinID(sourceTypeID, roadTypelD, hourDaylD)
Output Variable:
avgSpeed(sourceTypeID, roadTypelD, hourDaylD)
Calculation:
avgSpeed = sum(avgSpeedFraction * avgBinSpeed)
Once the average speed is determined using the table
roadTypeSourceTypeAvgSpeedBinID, its bin must be assigned by taking minimum
avgSpeedBinID from avgSpeedBin table such that avgBinSpeed >= avgSpeed.
Ramps are not considered separate roadtypes in MOVES, but their contribution is
weighted into the two restricted entry roadtypes (i.e., rural and urban freeways, non-
freeway types contain no ramp fractions) using the weighed ramp opmode fraction and
the rampfraction (i.e, 8% for all ramps). A separate ramp cycle is now available for each
avgSpeedBin in MOVES. A total of 16 ramp cycles are present and differentiated by
average speeds which range from 2.5 to 75 mph. Each ramp cycle contains a different
94
-------
opmode fraction distribution due the different speeds, acceleration and VSP values of
each cycle. The opModeFraction is obtained from the RoadOpmodeDistribution table
using avgSpeedBinID entries that match roadTypeSourceTypeAvgSpeedBinID for each
hour and day. The opmode fraction from the table weightedRampOpmodeFraction is
used in subsequent calculations for roadtypes which contain on and off ramps.
Input Variables:
rampFraction(roadTypeID)
opModeFraction(sourceTypeID, roadTypelD, opModelD, avgSpeedBinID)
Output Variable:
weightedRampOpModeFraction(sourceTypeID, roadTypelD, hourDaylD,
opModelD)
Calculation:
weightedRampOpModeFraction = rampFraction* opModeFraction
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 (sourceTypelD, roadTypelD, hourDaylD, avgSpeedBinID)
HiScheduleFraction (sourceTypelD, roadTypelD, hourDaylD, AvgSpeedBinID)
RampFraction(roadTypelD)
driveSchedulelD (sourceTypelD, roadTypelD, isRamp=N)
Output Variable:
DriveScheduleFraction (sourceTypelD, roadTypelD, hourDaylD,)
Calculation:
For each sourceTypelD, roadTypelD, hourDaylD and driveSchedulelD:
drive ScheduleFraction =
[(Sum Of loScheduleFraction over all cases where bracketScheduleLo =
driveSchedulelD) + (Sum Of hiScheduleFraction over all cases where
BracketScheduleHi =
driveSchedulelD)] * (1-rampFraction)
95
-------
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 (driveSchedulelD, second) from the DriveScheduleSecond table.
rollingTermA (sourceTypelD) from the SourceUseType table.
rotatingTermB (sourceTypelD) from the SourceUseType table.
dragTermC (sourceTypelD) from the SourceUseType table.
sourceMass (sourceTypelD) from the SourceUseType table.
Output Variable:
VSP (sourceTypelD, driveSchedulelD, second)
Accel (sourceTypelD, driveSchedulelD, second)
Calculation:
For each sourceTypelD, driveSchedulelD 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(opModelD) from the OperatingMode table.
SpeedLower(opModelD) from the OperatingMode table.
SpeedUpper(opModelD) from the OperatingMode table.
BrakeRatelSec(opModelD) from the OperatingMode table.
BrakeRate3Sec(opModeID) from the OperatingMode table.
Speed (sourceTypelD, driveSchedulelD, second) from DriveScheduleSecond
with
VSP (sourceTypelD, driveSchedulelD, second) from OMDG-4
accel (sourceTypelD, driveSchedulelD, second) from OMDG-4
Output Variable:
opModelDbySecond (sourceTypelD, driveSchedulelD, second)
Calculation:
For each sourceTypelD, driveSchedulelD and second:
96
-------
An opModelD 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.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:
opModelDbySecond (sourceTypelD, driveSchedulelD, second)
Output Variable:
OpModeFractionbySchedule (sourceTypelD, driveSchedulelD, opModelD)
Calculation:
For each sourceTypelD, driveSchedulelD and opModelD:
OpModeFractionbySchedule =
(Number of Seconds in opModelD 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 (sourceTypelD, driveSchedulelD, opModelD)
DriveScheduleFraction (sourceTypelD, roadTypelD, hourDaylD,
driveSchedulelD)
Output Variable:
OpModeFraction (sourceTypelD, roadTypelD, hourDaylD, polProcessID,
opModelD)
Calculation:
For each sourceTypelD, roadTypelD, hourDaylD and opModelD:
OpModeFraction =
Sum of OpModeFractionby Schedule *Drive ScheduleFraction over all
DriveSchedules
The Results of OMDG-7 populate the OpModeDistribution table of the Execution Location
Database.
The OpModeFraction in the OpModeDistribution table is:
97
-------
opModeFraction (sourceTypelD, linkID, hourDaylD, polProcessID,
opModelD)
The value of linkID needed for this table is determined from roadTypelD and
zonelD.
98
-------
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
99
-------
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.
100
-------
AverageSpeed(driveSchedulelD) from the DriveSchedule table.
Output Variables:
BracketScheduleLo (sourceTypelD, roadTypelD, AvgSpeedBinID)
LoScheduleSpeed (sourceTypelD, roadTypelD, AvgSpeedBinID)
BracketScheduleHi (sourceTypelD, roadTypelD, AvgSpeedBinID)
HiScheduleSpeed (sourceTypelD, roadTypelD, AvgSpeedBinID)
Calculation:
For each sourceTypelD, roadTypelD, and AvgSpeedBinID:
The output variables are determined using table DriveSchedule, where for each
combination of sourceTypelD, roadTypelD, 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 driveSchedulelD's are associated with
which sourceTypelD's and which roadTypelD'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 (sourceTypelD, roadTypelD, avgSpeedBinID)
LoScheduleSpeed (sourceTypelD, roadTypelD, avgSpeedBinID)
BracketScheduleHi (sourceTypelD, roadTypelD, avgSpeedBinID)
HiScheduleSpeed (sourceTypelD, roadTypelD, avgSpeedBinID)
Output Variable:
LoScheduleFraction (sourceTypelD, roadTypelD, avgSpeedBinID)
HiScheduleFraction (sourceTypelD, roadTypelD, avgSpeedBinID)
Calculation:
For each sourceTypelD, hourDaylD and avgSpeedBinID:
IF (BracketScheduleLo=BracketScheduleHi)
loScheduleFraction= 1.0
ELSE
loScheduleFraction =
(hiScheduleSpeed - avgBinSpeed) /
(hiScheduleSpeed - lo Schedule Speed)
hiScheduleFraction = (1 - loScheduleFraction)
101
-------
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
Drive Schedule As soc 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 DRAFT MOVES2009 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(roadTypelD)
driveSchedulelD (sourceTypelD, roadTypelD, isRamp=Y)
Output Variable:
Drive ScheduleFraction (sourceTypelD, hourDaylD, drive SchedulelD)
Calculation:
drive ScheduleFraction = rampFraction(roadTypelD)
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
102
-------
the links. Since the LTLP assigns only the averageSpeeds in the AvgSpeedBin table, this
is simpler than for Macroscale.
Input Variables:
LoScheduleFraction (sourceTypelD, roadTypelD, hourDaylD, avgSpeedBinID)
HiScheduleFraction (sourceTypelD, roadTypelD, hourDaylD, avgSpeedBinID)
RampFraction(roadTypelD)
driveSchedulelD (sourceTypelD, roadTypelD, isRamp=N)
Output Variable:
DriveScheduleFraction (sourceTypelD, avgSpeedBinID, driveSchedulelD)
Calculation:
For each sourceTypelD, avgSpeedBinID, and driveSchedulelD:
drive ScheduleFraction =
[loScheduleFraction (if bracketScheduleLo = driveSchedulelD) +
hiScheduleFraction (if bracketScheduleHi = driveSchedulelD)] * (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 (driveSchedulelD, second) from the DriveScheduleSecond table.
rollingTermA (sourceTypelD) from the SourceUseType table.
rotatingTermB (sourceTypelD) from the SourceUseType table.
dragTermC (sourceTypelD) from the SourceUseType table.
sourceMass (sourceTypelD) from the SourceUseType table.
Output Variable:
VSP (sourceTypelD, driveSchedulelD, second)
accel (sourceTypelD, driveSchedulelD, second)
Calculation:
For each sourceTypelD, driveSchedulelD 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)
103
-------
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(opModelD) from the OperatingMode table.
speedLower(opModelD) from the OperatingMode table.
speedUpper(opModelD) from the OperatingMode table.
brakeRatelSec(opModelD) from the OperatingMode table.
brakeRate3Sec(opModeID) from the OperatingMode table.
speed (sourceTypelD, driveSchedulelD, second) from DriveScheduleSecond
with
VSP (sourceTypelD, driveSchedulelD, Second) from OMDG-4
accel (sourceTypelD, driveSchedulelD, Second) from OMDG-4
Output Variable:
opModelDbySecond (sourceTypelD, driveSchedulelD, second)
Calculation:
For each sourceTypelD, driveSchedulelD and second:
An opModelD 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:
opModelDby Second (sourceTypelD, driveSchedulelD, second)
Output Variable:
OpModeFractionbySchedule (sourceTypelD, driveSchedulelD, opModelD)
Calculation:
For each sourceTypelD, driveSchedulelD and opModelD:
OpModeFractionbySchedule =
(Number of seconds in opModelD during drive Schedule) /
(Total number of seconds in driveSchedule)
104
-------
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 (sourceTypelD, driveSchedulelD, opModelD)
DriveScheduleFraction (sourceTypelD, roadTypelD, avgtSpeedBinID,
driveSchedulelD)
Link(linkID, countylD, zonelD, roadTypelD)
LinkAverageSpeed(linkID, hourDaylD, sourceTypelD)
Output Variable:
OpModeFraction (sourceTypelD, linkID, hourDaylD, polProcessID,
opModelD)
Calculation:
For each sourceTypelD, linkID, hourDaylD and opModelD:
OpModeFraction =
Sum of OpModeFractionby Schedule *Drive ScheduleFraction over all
DriveSchedules where the roadTypelD of the Link equals the roadTypelD
of the driveScheduleFraction and the averageSpeed of the Link equals the
average Speed of the avgSpeedBinlD.
The Results of OMDG-7 populate the OpModeDistribution table of the Execution Location
Database.
The OpModeFraction in the OpModeDistribution table is:
OpModeFraction (sourceTypelD, linkID, hourDaylD, polProcessID,
opModelD)
105
-------
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
SourceTypePolProcess
FuelEngFraction
SizeWeightFraction
Key Fields
sourceTypelD
polProcessID
sourceTypeModelYearlD
fuelTypelD
engTechID
sourceTypeModelYearlD
fuelTypelD
engTechID
weightClassID
engSizelD
Additional Fields
isSizeWeightReqd
isRegClassReqd
isMYGroupReqd
fuelEngFraction
SizeWeightFraction
Notes
Indicates which
pollutant-processes the
source bin distributions
may be applied to and
indicates which
discriminators are
relevant for each
sourceType and
polProcess
Joint distribution of
vehicles with a given
fuel type and engine
technology. Sums to
one for each sourceType
& modelYear
Joint distribution of
engine size and weight.
Sums to one for each
sourceType, modelYear
and fuel/engtech
combination.
106
-------
RegClassFraction
PollutantProcessModel
Year
ModelYearGroup
SourceTypeModelYear
SourceBin
SourceBinDistribution
sourceTypeModelYearlD
fuelTypelD
engTechID
regClassID
polProcessID
modelYearlD
modelYearGroupID
sourceTypeModelYearlD
SourceBinID
SourceTypeModelYearlD
polProcessID
sourceBinID
regClassFraction
modelYearGroupID
shortModYrGroupID
modelYearGroupName
modelYearGroupID
modelYearlD
sourceTypelD
engSizelD
fuelTypelD
engTechID
regClassID
modelYearGroupID
weightClassID
sourceBinActivityFract
ion
Fraction of vehicles in a
regulatory class. Sums
to one for each
source Type, modelYear
and fuel/engtech
combination.
Defines model year
groups.
Defines short model
year group Ids.
Decodes ID field into
modelYearlD and
sourceTypelD
List of sourceBins
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
107
-------
identifier IffttrryysssswwwwOO, 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 agelD), and for each
relevant/existing combination of sourcebin discriminators (as determined by the input
tables), the sourceBinActivityFraction is calculated as follows:
sourceBinActivity Fraction = fuelEngFraction *regClassFraction
* size WeightFraction
e. The SourceBinDistribution table lists the sourceBinActivityFractions for each
sourceBin, sourceType, modelYear and polProcess. The set of such records for a
108
-------
given sourceType, modelyear, and polProcess constitute a source bin distribution
which sums to unity.
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:
109
-------
Table 10-6. SourceBin Generator Calculation Steps
Step/Query
1 populate sb_fractions
2 1 sb fractions update
regulatory class.
2 2 sb fractions update MY
GroupID
2_3 sb_fractions update size
and weight
2_5 calculate sb_fractions
2 7 populate sb fractions no
dups
4 populate SourceBin
4 5 generate bin IDs
5 append source bin
distributions
Description
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.
For each record, for pollutant-processes that do not require regulatory
class information, set regClassID to 0 and regClass Fraction to 1 .
For each record, for pollutant-processes that do not require model year
group information, set MYGroupID to 0.
For each record, for pollutant-processes that do not require size and
weight information, set engSizelD and weightClassID to 0 and
sizeWeightFraction to 1 .
For each record, calculate sb_fractions as the product of
fuelEngFraction, emisTechFraction, and sizeWeightFraction.
Remove duplicate records from sb fractions; save as a second
temporary table, "sb fractions no dups".
Select unique sourceBinlDs with fractions >0 to fill SourceBin table.
Generate sourceBinlDs from bin discriminators.
Use SourceBin table and "sb fractions no dups" to fill
SourceBinDistribution table.
110
-------
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 heatlndex 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 DRAFT MOVES2009 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.
Ill
-------
Inputs:
TF is the temperature in degrees F. (from temperature field in ZoneMonthHour)
Pb is the barometric pressure, (from barometricPressure field in County)
Hrei is the relative humidity (from relHumidity field in ZoneMonthHour)
-!5/)[r _321
I/F JZJ
T0=641.21-TK
" ratio or speciflchumidity ~434/.O ry
ITT
nrel/ ID
/100 } db
^=29.92*218.167*10
(-TO/TK)
S.2437+0.00588ro + 0.0000000117T0:
l+0.00219ro
db
=6527.557*10
(-TO/TK)
i.2437+0.00588T0 + 0.0000000117T0'
l+0.00219rn
112
-------
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 opModelD to the trip by comparing its soak length with the
minSoakBound and maxSoakBound values in the OperatingMode table.
3. Then for each sourceTypelD and hourDaylD, the opModeFraction of each
opModelD equals:
the count of records having the opModelD
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.
113
-------
4. During each Zone level iteration of the StartOMDG masterloopable, the
operating mode distribution (which is by sourceTypelD, hourDaylD and
opModelD) 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 DRAFT MOVES2009 does not
require an operating mode distribution, whereas estimating the start process
emission of the "criteria" pollutants added in DRAFT MOVES2009 does involve
using an operating mode distribution.)
Records already existing in the CMIT are not overwritten.
114
-------
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
ColdSoaklnitialHourFraction tables which are CMITs.
No records are added to the AverageTankTemperature table for a combination of
tankTemperatureGroupID, zonelD, and monthID if any record pertaining to this
combination is already present. No records are added to the SoakActivityFraction table
for a combination of sourceTypelD, zonelD, and monthID if any records are already
present for it. No records are added to the ColdSoaklnitialHourFraction table for a
combination of sourceTypelD, zonelD, 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 (zonelD, monthID, hourlD). This is saved in
the ColdSoakTankTemperature CMIT.
Preliminary Calculation: ISminuteTemperature - Create intermediate table of
temperatures in 15 minute time steps, with key fields hourlD, timeStep (1 through
4 with 1 representing the top of the hourlD). Within each hourly temperature, set
115
-------
time step 1 to the corresponding value from zoneMonthHour. Then perform
linear interpolation with hourID+1 timeStep 1 to fill in hourlD TimeStep 2-4 .
For the "highest" hour ID interpolate (default = 24) with the "lowest" hour ID
(default = 1).
Preliminary Calculation: ISminuteTankTemperature - Performed on the 15
minutes temperature table produced in the preliminary calculation.
ISminuteTankTemperate and tempDelta need to be calculated at each time step
before performing calculations on the next time step.
- for hourlD =1, timeStep=l
1 SminuteTankTemperature
= ISminuteTemperature (hourID=l, timeStep=l)
tempDelta
= ISminuteTemperature- ISminuteTankTemperature
- for all other hourlD, timeSteps:
1 SminuteTankTemperature
= 1.4*SUM(tempDelta hourID=l, timeStep=l through
most recent hourlD, timeStep)+ ISminuteTankTemperature
(hourlD 1, timeStep 1)
tempDelta
= ISminuteTemperature - ISminuteTankTemperature
Calculation: coldSoakTankTemperature (hourlD) = ISminuteTankTemperature
(hourlD, timeStep=l)
TTG-2 Create sampleVehicleTripByHour
Trips in the sampleVehicleTrip table may span the top of the next hourDaylD. This step
is needed to parse the trips into segments for which the start and finish are within the
same hourlD. "Marker Trips", which have a keyOffTime, but null value of keyOnTime
are ignored in this calculation.
Inputs:
SampleVehicleTrip
Outputs:
116
-------
- Intermediate table SampleVehicleTripByHour (vehiclelD, tripID,
hourDaylD, 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 hourlD 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=l 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 hourlD = 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
-------
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=l
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 hourlD = 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:
118
-------
for first (non-marker) trip in sampleVehicleTripByHour:
keyOnTemp = hourlyColdSoakTemperature for that hour (linking of
hourDaylD in sampleVehicleTripByHour and hourlD 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=l (i.e. new trip)
- keyOnTemp = final soakTankTemperature from hotSoakTemperature
where TripID of hotSoakTemperatures = prior TripID 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
hourly SoakEventByHour to store the hot soak tank temperature for each hot soak
event minute-by-minute. Construct hotSoakTemperature as follows:
key fields vehiclelD, tripID, hourDaylD from
hourly SoakEventByHour
- 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=l, 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 opModelD =150 if soakTankTemperature >
coldSoakTemperature + 3, otherwise end
119
-------
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 opModelD =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 (zonelD, monthID, hourDaylD,
tankTemperatureGroupID, opModelD, averageTankTemperature)
Calculation:
averageTankTemperature, for a given hourDaylD:
o for opModeID=151 (cold soak) = hourlyColdSoakTankTemp
for that hour
o for each zonelD, monthID, hourDaylD, 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 hourDaylD
TTG-6 Calculate soakActivityFraction CMIT
Inputs:
intermediate table HotSoakTemperature
SampleVehicleDay table
120
-------
Outputs:
- SoakActivityFraction CMIT
Calculation:
Fraction of cold soaking = cMinutes / (cMinutes + hMinutes)
Fraction of hot soaking = hMinutes/ (cMinutes + hMinutes)
Where:
cMinutes, on a day ID = total minutes of cold soaking for all vehicles in
SampleVehicleDay = (60 * number of sample vehicles existing on the
daylD) - oMinutes - hMinutes
oMinutes, on a day ID = total minutes of vehicle operation in the
hourDaylD = sum (keyOffTime-keyOnTime) for all trips in the
hourDaylD from VehicleTripByHour
hMinutes, on a day ID = total minutes of vehicle hot soaking in the
hourDaylD = 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 ColdSoaklnitialHourFraction CMIT table
Calculations:
First, make an intermediate table, ColdSoaklnitialHourMinutes:
Key fields:
zonelD
monthID
tankTemperatureGroupID
vehID
daylD
hourlD
initialHourlD
Data field:
ColdSoaklnitialHourMinutes
121
-------
The produce ColdSoaklnitialHourMinutes as follows:
For each tankTemperatureGroupID
For each vehID and day ID in SampleVehicle
Initial Hour = 1
For Each Hour
Write two records into ColdSoaklnitialHourMinutes, 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
hourlD, or must have begun in this hour. This single prior hourlD
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.
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
122
-------
Next Vehicle - Day
Next TankTemperatureGroup
TTG-7 can now produce the ColdSoaklnitialHourFraction table by summing the
ColdSoaklnitialHourMinutes table across tankTemperatureGroups and sampleVehicles
within SourceType, and normalizing to distributions which sum to unity.
The format of the ColdSoaklnitialHourFraction table remains:
Key Fields:
sourceTypelD
zonelD
monthID
hourDaylD
initialhourDaylD
Data Field:
col d S oaklniti alHourFracti on
ignoring the detail that hourlDs and daylDs are combined into hourDaylDs
ColdSoaklnitialHourFraction =
(sum of all minutes for vehlDs belonging to sourceTypelD in the zonelD,
monthID, and daylD having the hourlD and initialHourlD) /
(sum of all minutes for vehlDs belonging to sourceTypelD in the zonelD,
monthID and daylD having the hourlD)
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.)
123
-------
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-la: Calculate Average Pump Gasoline and Ethanol Blend Type
Inputs:
marketShare from FuelSupply (county, fuel Year, monthGroup,
fuelFormulation)
ETOHvolume from FuelFormulation (fuelFormulation)
RVP from FuelFormulation (fuelFormulation)
fuel SubTypelD from FuelFormulation
fuelTypelD 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 fuelTypelD =1))
(Sum (RVP*marketshare)) / (Sum (marketshare))
tankAverageETOHVolume = For all Fuel Formulations in county, fuel year &
monthgroup where fuelType = "gasoline" (ie fuelTypelD =1))
(Sum (ETOH Volume*marketshare)) / (Sum (marketshare))
124
-------
TFG-lb: Calculate Ethanol Market Share and Ethanol BlendType
Inputs:
marketShare from Fuel Supply (county, fuel Year, monthGroup,
fuelF ormul ati on)
fuel SubTypelD from FuelFormulation
fuelTypelD from FuelSubType
Outputs:
gasoholMarketShare (countyID, fuelYearlD, 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 fuelTypelD = 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 fuelTypelD = 1)) and
ETOHVolume >= 4
IF gasoholMarketShare = 0,
highETOHRVP = AverageRVP
ELSE
highETOHRVP =(Sum (RVP*marketshare)) /
gasoholMarketShare
ethanolB 1 endTy p e:
IF absolute value (highETOHRVP -lowETOHRVP) <= 0.2,
ethanolBlendType -'Match"
ELSE ethanolBlendType = "Splash"
125
-------
TFG-lc: Calculate Commingled Tank FuelRVP
Inputs:
gasoholMarketShare (countyID, fuelYearlD, monthGroupID) from TFG-lb
averageRVP (countyID, fuelYearlD, monthGroupID) from TFG-la
Commingling Lookup (stored in program)
Commingling
LookupMarketShare RVP Factor
0.0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1.0
.000
.016
.028
.035
.039
.040
.038
.034
.027
.018
.000
Outputs:
commingledRVP (countylD, fuelYearlD, monthGroupID)
Calculation:
comminglingFactor (countylD, fuelyearlD, monthgroupID) = lookup from
table using smallest value of "LookupMarketShare" that is greater than or
equal to the gasoholMarketShare.
commingledRVP = averageRVP * comminglingF actor
TFG-2: Weathered RVP
TFG-2a: Calculate "EvapTemp" by zonelD, MonthGroupID
Inputs:
temperature (zonelD, hourlD monthgroupID)
zonelD from masterloopcontext
Outputs:
zoneEvapTemp (zonelD, monthgroupID)
Calculation :
126
-------
zoneMin(zoneID, monthgroupID) = MIN (temperature(zoneID,
monthgroupID, hourlD))
zoneMax (zonelD, monthgroupID) = MAX(temperature(zoneID,
monthgroupID, hourlD)
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 (zonelD, monthgroupID) from previous step
commingledRVP (countyID, fuelYearlD, monthgroupID) from TFG-lc
zone(countyID, zonelD)
Outputs:
ratioGasolineRVPLoss(zoneID, fuelYearlD, 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, fuel Year, monthGroup) from TFG-la
gasoholMarketShare (countyID, fuelYearlD, monthGroupID) from TFG-lb
Outputs:
avgWeatheringConstant (countyID, fuelYearlD, monthGroupID)
Calculations:
IF ethanolBlendType = "Match", avgWeatheringConstant = 0.049 - 0.0034 *
gasoholMarketShare
ELSE avgWeatheringConstant = 0.049 - 0.0116 * gasoholMarketShare
127
-------
TFG-2d: Calculate weathered RVPfor county-average fuel adjusted for zone
temperatures
Inputs:
ratioGasolineRVPLoss (zonelD, fuelYearlD, monthgroupID) from TFG-2b
avgWeatheringConstant (countyID, fuelYearlD, monthGroupID)
from previous step
commingledRVP (countyID, fuelYearlD, monthGroupID) from TFG-lc
zone(countyID, zonelD)
Outputs:
tankAverageGasolineRVP(zoneID, fuelYearlD, monthgroupID)
Calculation :
tankAverageGasolineRVP (zonelD) = commingledRVP(countylD) * (1 -
ratioGasolineRVPLoss (zonelD) * avgWeatheringConstant (countylD))
This is stored as the RVP field of AverageTankGasoline
128
-------
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:
129
-------
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 agelD, 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.
130
-------
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 Internal Control Strategy 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
131
-------
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
132
-------
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 FuelTypelD* 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.
133
-------
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 EngSizelD and WeightClassID.
134
-------
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) /
(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(ij), where "i" indicates the associated FuelEng combination
and "j" indicates the RegClass. These are used with the results of the above
calculations to create NewRegClassFractions(i,j,).
For eachj
For each i
Compute NewRegClassFraction(i,j) as:
IF NewFuelEngFraction(i)= 0,
NewRegClassFraction(ij) =0
(Doesn t need to be in database)
ELSE
NewRegClassFraction(ij) =
PortionOld(i) * RegClassFraction (i,j)
[l-PortionOld(i)) *
(Sum(overaUi) (ProportionOfNew(i)
*RegClassFraction(i,j))]
135
-------
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 DRAFT MOVES2009. 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
ECCP-la
ECCP-1 b
ECCP-2
ECCP-2a
ECCP-2b
ECCP-2c
ECCP-3
ECCP-4
ECCP-5
ECCP-6
ECCP-6a
ECCP-6b
ECCP-6c
ECCP-6d
Preliminary calculations
Calculate petroleum and fossil energy fractions
Convert age to model year for analysis year
Calculate adjustments
Calculate air conditioning adjustment
Calculate temperature adjustment
Calculate fuel adjustment
Calculate running energy consumption
Calculate start energy consumption
Calculate extended idle energy consumption
Calculate well-to-pump energy consumption
Calculate pump-to-wheel energy consumption
Interpolate well-to-pump factor by
FuelSubType in analysis year
Calculate well-to-pump factor by FuelType in
analysis year
Calculate well-to-pump energy consumption
136
-------
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 DRAFT MOVES2009 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 la: 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
fuelSubtypelD ends withO, 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. o/FuelSubTypeswithinFuelType
^MarketShare * FuelSubtypePetroleumFraction
n=l
FossilFraction =
137
-------
no.q/FuelSubTypeswithinFuelType
^ MarketShare * FuelSubtypeFossilFraction
n=l
Step Ib: Convert Age to Model Year For Analysis Year
Input Variables:
YearlD
AgelD
Output Variable:
ModelYearlD
Calculation:
ModelYearlD = YearlD - AgelD
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:
Heatlndex (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+ACActivityTerrnB*HeatIndex
+ACActivityTermC*HeatIndex2)
If ACOnFraction<0, set to 0
If ACOnFraction>l, 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
138
-------
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 -l)*ACActivity Adjustment)
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)
139
-------
Calculation:
FuelAdjustmentbyType =
no .o/FuelSubTypeswithinFuelType
' MarketShare * Fuel Adjustment
z_
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
^ SourceBinActivityFraction* MeanBaseRate
SourceBin=\
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.OpModeBim
^^OpModeFraction * MeanBaseRatebyType * ACAdjustment
OpModeBin=\
Step 3c: Calculate Total Energy
Input Variables:
140
-------
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 IMOBD Adjustment 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-la, existing code)
FossilFraction (ECCP-la, existing code)
Calculation:
Total Energy
EmissionQuant = SCCVtypeFraction *
No. SourceTypes
y"' SHO * SourceTypeEnergy * FuelAdjustment * TempAdjustment * IMOBDAdjustment
SourceBin=\
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
"ExtendedldleHours" 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:
141
-------
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 YearlD)
(Note : WTPFactor represents the field EmissionRate located in the
GreetWellToPump table of the MOVES database.)
Outputs:
WTPFactor (Pollutant, FuelSubType, YearlD)
Calculation:
Linear interpolation using "bracketing" years in WTP database:
WTPFactor = WTPFactor (Lo YearlD) +
(WTPFactor (HiYearlD) - WTPFactor (Lo YearlD)) *
((YearlD - LoYearlD) / (HiYearlD - Lo YearlD))
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, YearlD)
Calculation:
WTPFactorbyFuelType =
no . ofFuelSubTypeswithinFuelType
^MarketShare * 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
142
-------
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. Note that MOVES stores distance within the
MOVESMesoscaleActivityOutput table for runs using the Mesoscale Lookup scale
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:
SCCVtypelD(SCC) from SCC table
SCCVtypeFraction(sourceTypeModelYearID, fuelTypelD, SCCVtypelD)
From SCCVtypeDistribution table
sourceBinActivityFraction (sourceTypeModelYearlD, polProcessID,
sourceBinID) from SourceBinDistribution table
distance(sourceTypeID, linkID, agelD, yearlD, monthlD, hourDaylD)
from SHO table
Output Variable:
143
-------
MOVESActivityOutput.distance(runID, yearlD, monthlD, daylD, hourlD,
statelD, county ID, zonelD, linkID, sourceTypelD, fuelTypelD,
modelYearlD, roadTypelD, SCC)
Conceptual Calculation:
MOVESActivityOutput.distance =
SCCVtypeFraction* distance *
[sum over all sourceBins in fuelTypelD (sourceBinActivityFraction)]
Several detailed considerations must be kept in mind as these calculations are
performed.
One consideration is just that model years are converted to agelD values by the
relationship: model YearlD = yearlD - agelD.
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
sourceTypelD, modelYearlD, and fuelTypelD. 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
fuelTypelD. This is accomplished by determining the portion of the
SourceBinDistribution which involves the given fuelTypelD.
The table 10-8 illustrates the structural differences between the input to this
calculation and the output it must produce:
144
-------
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
yearlD Yes Yes
monthID Yes Yes
daylD Yes Yes
hourlD Yes Yes
statelD Yes, but redundant with county
county ID Yes, but redundant with zone
zonelD Yes Yes
roadTypelD Yes Yes
pollutantID Yes, but constant for this calculation
processID Yes, but constant for this calculation
sourceTypelD Yes Yes
fuelTypelD No Yes
modelYearlD as agelD Yes
SCC No Yes
145
-------
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-to-
pump) 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 CJLt 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:
146
-------
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:
Output Variables:
EmissionRate from GREETWellToPump (Year, Pollutant,
FuelSubType)
MarketShare (County, Year, MonthGroup, FuelSubType,)
Calculation:
WTPFactorbyFuelType(Year, Pollutant, FuelType)
WTPFactorbyFuelType =
no. o/FuelSubTypes withinFuelType
^MarketShare * WTPFactor
n=l
Step 3b: Calculate Well-To-Pump Emissions
Input:
Output:
Calculation:
PTWEmissionQuant for total energy (Step 6a of Total Energy Calculator)
WTPFactorbyFuelType for CH4/N2O (Step 3a above)
EmissionQuant (SourceType, Pollutant, Process, FuelType....see MOVES
output database design)
EmissionQuant = PTWEmissionQuant * WTPFactorbyFuelType
147
-------
10.20. Atmospheric CO2 and CO2-Equivalent Calculator
10.20.1. General Description
This task involves performs the calculation of two pollutants: Atmospheric CC>2 and CC>2
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, Fuel Sub Type) From Fuel Supply table
Outputs:
• CarbonContent by FuelType
• OxidationFraction by FuelType
Calculations:
CarbonContent by FuelType
no. o/FuelSubTypeswithinFuelType
^MarketShare * CarbonContent(FuelSubtype)
n=l
148
-------
OxidationFraction by FuelType =
no. ofFuelSubTypeswithinFuelType
^MarketShare * OxidationFraction(Fuel Subtype)
n=l
Calculate Atmospheric CO2from Total Energy
Inputs:
• Total Energy (KJ)
• CarbonContent by FuelType (previous calculation)
• Oxidation Fraction by FuelType (previous calculation)
Output:
• Atmospheric CC>2 (grams)
Calculation:
Atmospheric CC>2 = 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 * GWPC02 + CH4 * GWPCH4 + N2O * GWPN2o
149
-------
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 sub steps:
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 meanBaseRatelM fields together using the EVI fractions
calculated in the previous substep.
CREC-2 Calculate fuel-supply-weighted fuel adjustment factors
This step has two sub steps:
The first substep uses the Fuel Adjustment 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 Fuel Supply Adjustment table of fuel adjustment factors at
the fuelTypelD 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.
150
-------
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 Full AC Adjustment factors
from the contents of the Full AC Adjustment 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 modelYearlD distinction
contained in the EmissionRateWithIM table is preserved in
SBWeightedEmissionRate, effectively subsuming the role of model YearGroupID
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 AC Adjustment 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.
151
-------
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 sourceTypelD.
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:
begModelYearlD, endModelYearlD, IMAdjustFract (IMCoverage table)
countylD, zonelD, yearlD (from Master Loop Context).
agelD (AgeCategory table)
regClassID (RegulatoryClass table)
Output Variable:
IMAdjustFract (in intermediate IMAdjustment table)
Calculation:
For zonelD, yearlD 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 agelD in AgeCategory table,
for all regClassID values in RegulatoryClass except regClassID=0
modelYearlD = yearlD-agelD
IMAdjustFract (zonelD, yearlD, polProcessID, modelYearlD, agelD,
fuelTypelD, regClassID)
= IMAdjustFract if IMCoverage record exists
with begModelYearlD <= modelYearlD <= endModelYearlD
= 0.0 otherwise
CREC 1-b: Combine I/M andnon I/M rates
Input Variables:
meanBaseRate and meanBaseRatelM (EmissionRateByAge table)
fuelTypelD, regClassID (from SourceBin table)
modelYearGroupID (from PollutantProcessModelYear table)
IMAdjustFract (from step 1-a)
152
-------
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
IMAdjustmentfuelTypelD = SourceBin.fuelTypelD AND
IMAdjustmentregClassID = SourceBin.regClassID AND
IMAdjustment. modelYearID= PollutantProcessModelYear.modelYearlD 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 (zonelD, yearlD, polProcessID, modelYearlD, sourceBinID,
opModelD) = meanBaseRate + (IMAdjustFract * (meanBaseRatelM-
meanBaseRate))
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 andnon GPA fuel adjustment factors
Input Variables:
fuelAdjustment and fuelAdjustmentGPA (from FuelAdjustment table)
GPAFract (from County table)
county ID (from MasterLoop Context)
Output Variable:
fuelAdjustment (in intermediate CountyFuelAdjustment table)
Calculation:
For county ID 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, sourceTypelD,
fuelFormulationID)
= fuelAdjustment + GPAFract*(fuelAdjustmentGPA-fuelAdjustment)
NOTE: An internal MOVES model component, the DefaultDataMaker, has set fuelAdjustment=l
for cases which are not populated in fuelAdjustment.
153
-------
CREC 2-b: Aggregate county fuel adjustments to fuel type
Input Variables:
fuelAdjustment (from CountyFuelAdjustment table from step 2-a)
marketShare (from FuelSupply table)
fuelSubTypelD (from FuelFormulation table)
fuelTypelD (from FuelSubtype table)
monthlD (from MonthOfAny Year table)
yearlD (from MasterLoopContext)
fuelYearlD (from Year table)
modelYearlD (from PollutantProcessModelYear table)
Output Variable:
fuelAdjustment (in intermediate FuelSupply Adjustment table)
Calculation:
For all records in join of CountyFuelAdjustment and FuelSupply where
CountyFuelAdjustment.countyID=FuelSupplycountyID and
Year.yearlD = yearlD from MasterLoopContext and
Year.fuelYearlD = FuelSupply.fuelYearlD and
FuelSupply.monthGroupID = MonthOf Any Year, mo nthGroupID 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 (countylD, yearlD, monthlD, polProcessID, modelYearlD,
sourceTypelD, fuelTypelD)
= 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)
zonelD (from MasterLoop context)
Output Variable:
temperatureAdjustment (in intermediate METAdjustment table)
Calculation:
For zonelD 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, monthlD, hourlD, polProcessID, fuelTypelD)
= 1.0 + tempAdjustTermA * (temperature-75) + tempAdjustTermB
(temperature-75)2
154
-------
CREC-4: Calculate Air Conditioning (AC) Adjustment Factors
CREC4-a: Calculate AC On Fraction
Input Variables:
heatlndex (zonelD, monthID, hourlD)
From ZoneMonthHour table
ACActivityTermA (monthGroupID, hourlD)
From MonthGroupHour table
ACActivityTermB (monthGroupID, hourlD)
From MonthGroupHour table
ACActivityTermC (monthGroupID, hourlD)
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. hourlD = ZoneMonthHour.hourlD
ACOnFraction (zonelD, monthID, hourlD) =
(ACActivityTermA+ACActivityTerrnB*heatIndex
+ACActivityTermC*heatIndex2)
If ACOnFraction<0, set to 0
If ACOnFraction>l, set to 1
CREC 4-b: Calculate AC Activity Fraction
Input Variables:
ACOnFraction (zonelD, monthID, hourlD) from previous calculation
ACPenetrationFraction (sourceTypelD, modelYearlD) from
SourceTypeModelYear table
functioningACFraction (sourceTypelD, agelD) from SourceTypeAge table
Output Variable:
ACActivityFraction (in intermediate ACActivityFraction table)
Calculation:
From join of ACOnFraction, SourceTypeModelYear and SourceTypeAge tables
where
yearlD = yearlD value from master loop context
SourceTypeModelYear.sourceTypelD = SourceTypeAge.sourceTypelD and
SourceTypeModelYear.modelYearlD = yearlD - SourceTypeAge.agelD
ACActivityFraction (zonelD, monthID, hourlD, sourceTypelD, modelYearlD)
= ACOnFraction * ACPenetrationFraction * functioningACFraction
155
-------
CREC 4-c: Weight FullACAdjustment Factors by Operating Mode
Input Variables:
FullACAdjustment (polProcessID, sourceTypelD, opModelD) from
FullACAdjustment table
opModeFraction (sourceTypelD, hourDaylD, linkID, polProcessID, opModelD)
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, sourceTypelD, and opModelD
where linkID = value from master loop context and hourDaylD is in the run
specification
weightedFullACAdjustment (sourceTypelD, polProcessID, linkID, hourDaylD )
= sum (fullACAdjustment * opModeFraction)
CREC 4-d: Calculate AC Adjustment Factor
Input Variables:
ACActivityFraction (zonelD, monthID, hourlD, sourceTypelD, modelYearlD)
From step 4-b
weightedFullACAdjustment (sourceTypelD, polProcessID, linkID, hourDaylD)
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=AC ActivityFraction. sourceTyp
elD
ACAdjustment (zonelD, monthID, hourlD, daylD, sourceTypelD,
modelYearlD, polProcessID)
= 1 + ((weightedFullACAdjustment -l)*ACActivityFraction)
CREC-5: Weight emission rates by source bin
Input Variables:
156
-------
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:
SourceBinDistributionsourceBinTD = SourceBin.sourceBinID and
SourceBinDistribution. sourceTypeModelYearlD
= SourceTypeModelYear. sourceTypeModelYearlD and
EmissionRateWithIM.polProcessID=SourceBinDistribution.polPro
cessID and
EmissionRateWithIM.sourceBinID=SourceBinDistribution. source
BinID and
EmissionRateWithIM.modelYearID=SourceTypeModelYear.mode
lYearlD
meanBaseRate(zoneID, yearlD, polProcessID, sourceTypelD, modelYearlD,
fuelTypelD, opModelD)
= sum (sourceBinActivityFraction * meanBaseRate)
Note that sourceBinID is not included in the summation grouping; all of its
attributes except fuelTypelD are included instead, also note that there
should be only one modelYearGroupID present in the source bin
distributions for a modelYearlD 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
Dand
SBWeightedEmissionRate.opModeID=OpModeDistribution.opModeID and
SBWeightedEmissionRate.sourceTypeID=OpModeDistribution.sourceType
ID
OpModeDistribution.linkID=Link.linkID and
Link.zoneID= SBWeightedEmissionRate.zonelD
meanBaseRate(linkID, yearlD, polProcessID, sourceTypelD, modelYearlD,
fuelTypelD, hourDaylD)
= sum (opModeFraction * meanBaseRate)
157
-------
CREC-7: Apply fuel, temperature, and AC adjustment factors to weighted emission
rates
CREC 7-a: Combine Temperature and AC Adjustment Factors
Input Variables:
temperature Adjustment (from MET Adjustment 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 MET Adjustment and ACAdjustment
Using zonelD, polProcessID, MonthID, and hourlD
tempAndACAdjustment (zonelD, polProcessID, sourceTypelD, modelYearlD,
fuelTypelD, monthID, hourlD, daylD) =
temperatureAdjustment* ACAdjustment
CREC 7-b: Apply fuel adjustment to fully weighted emission rates
Input Variables:
meanBaseRate (from Fully WeightedEmissionRate 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 Fully AdjustedEmissionRate and FuelSupply Adjustment where
FullyAdjustedEmissionRate.linklD = Link.linkID and
Link.countyID=FuelSupplyAdjustment.countyID and
FullyAdjustedEmissionRate.yearID=FuelSupplyAdjustment.yearID and
Fully AdjustedEmissionRate.polProcessID
=FuelSupplyAdjustment.polProcessID and
Fully AdjustedEmissionRate.sourceTypeID=
FuelSupplyAdjustment.sourceTypelD and
Fully AdjustedEmissionRate.modeiYearID=
FuelSupplyAdjustment.modelYearlD and
Fully AdjustedEmissionRate.fuelTypeID=FuelSupplyAdjustment.fuelTypeID
fuelAdjustedRate (linkID, yearlD, polProcessID, sourceTypelD, modelYearlD,
fuelTypelD, monthID, hourDaylD) = meanBaseRate * fuelAdjustment
CREC 7-c: Apply temperature -and-AC adjustment to fuel-adjusted emission rate
158
-------
Input Variables:
tempAndACAdjustment (from TempAndACAdjustment table from step 7-a)
fuelAdjustedRate (from FuelAdjustedRate table from step 7-b)
Output Variable:
meariBaseRate (in intermediate WeightedAndAdjustedEmissionRate table
Calculation:
From join of TempAndACAdjustment and FuelAdjustedRate tables where
FuelAdjustedRate.linkID = Link.linkID and
Link.zoneID= TempAndACAdjustment.zonelD and
TempAndACAdjustment.hourID=HourDay.hourID and
TempAndACAdjustment.dayID=HourDay.dayID and
HourDay.hourDayID= FuelAdjustedRate.hourDaylD and
TempAndACAdjustment.polProcessID=FuelAdjustedRate.polProcessID and
TempAndACAdjustment.sourceTypeID=FuelAdjustedRate.sourceTypeID and
TempAndACAdjustment.modelYearID= FuelAdjustedRate.modelYearlD and
TempAndACAdjustment.montMD= FuelAdjustedRate.monthTD and
TempAndACAdjustment.fuelTypeID=FuelAdjustedRate.fuelTypeID
meanBaseRate (linkID, yearlD, polProcessID, sourceTypelD, modelYearlD,
fuelTypelD, hourlD, daylD, montMD) = 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.fuelTypelD = FuelType.fuelTypelD 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))
159
-------
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)
yearlD, statelD, county ID, zonelD, linkID from MasterLoop context
pollutantID, processID from PollutantProcessAssoc table
roadTypelD 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.yearlD = WeightedAndAdjustedEmissionRate.yearlD and
yearlD - SHO.agelD
= WeightedAndAdjustedEmissionRate.modelYearlD and
SHO.monthID = WeightedAndAdjustedEmissionRate.monthID and
SHO.sourceTypelD = WeightedAndAdjustedEmissionRate.sourceTypelD
and
SHO.hourDaylD = HourDay.hourDaylD and
HourDay.hourlD = WeightedAndAdjustedEmissionRate.hourlD and
HourDay.daylD = WeightedAndAdjustedEmissionRate.daylD and
WeightedAndAdjustedEmissionRate.polProcessID
=PollutantProcessAssoc.polProcessID
roadTypelD = Link.roadTypelD
SCC = null
emissionQuant(stateID, countylD, zonelD, linkID, roadTypelD, yearlD,
monthID, daylD, hourlD, pollutantID, processID, sourceTypelD,
modelYearlD, fuelTypelD, SCC)
= meanBaseRate * SHO
CREC-10: Conditionally convert results by sourceTypelD 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)
sourceTypelD, modelYearlD from SourceTypeModelYear
Output Variable:
160
-------
emissionQuant (in MOVESWorkerOutput table)
Calculation:
From join of SCCVtypeDistribution, SCC, SourceTypeModelYear, and
SCCRoadTypeDistribution where:
zonelD = zonelD from master loop context
SourceTypeModelYear. sourceTypeModelYearlD =
SCCVtypeDistribution. sourceTypeModelYearlD and
SCC.SCCVtypelD = SCCVtypeDistribution.SCCVtypelD and
SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeIDand
MOVESWorkerOutput.sourceTypeID = sourceTypeModelYear.sourceTypelD and
SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeIDand
MOVESWorkerOutput.modelYearlD = sourceTypeModelYear.modelYearlD and
MOVESWorkerOutput.fuelTypelD = SCCVtypeDistribution.fuelTypelD and
MOVESWorkerOutput.roadTypelD = SCCRoadTypeDistribution.roadTypelD
SCC= SCC.SCC
emissionQuant = sum of emissionQuant * SCCVtypeFraction *
SCCRoadTypeFraction over sourceTypelD and roadTypelD
sourceTypelD = null
roadTypelD = null
linkID = null
161
-------
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 sub steps:
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 EmissionRateByAge 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 meanBaseRatelM fields together using the EVI fractions
calculated in the previous substep. (This makes the "blended" rates dependent
upon yearlD and countylD, but we are executing for a single Year and County)
CSEC-2 Calculate fuel-supply-weighted fuel adjustment factors
This step has two sub steps:
162
-------
The first substep uses the Fuel Adjustment 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 Fuel Supply Adjustment table of fuel adjustment factors at
the fuelTypelD level.
CSEC-3 Calculate temperature adjustment factors
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
EmissionRatesWithlMAndTemp table.
CSEC-5 Weight EmissionRates by Source Bin
This step applies the source bin distributions to the
EmissionRatesWithlMAndTemp table from the previous step to produce an
163
-------
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 modelYearlD distinction is present in the
EmissionRatesWithlMAndTemp 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
Fuel Supply Adjustment 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 sub steps.
The first substep produces an SCCDistribution table from the
SCCSourceTypeDistribution and SCCRoadTypeDistribution tables. This is
164
-------
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.
The second substep applies the SCCDistribution table to the results of step 9 to
convert the output from being by sourceTypelD to being by SCC.
Implicit in these calculations is that the additional fields of statelD, countylD, and
roadTypelD are added to the product table as needed by the MOVESOutput table format.
The roadTypelD 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:
begModelYearlD, endModelYearlD, IMAdjustFract (IMCoverage table)
countylD, zonelD, yearlD (from Master Loop Context).
agelD (AgeCategory table)
regClassID (RegulatoryClass table)
Output Variable:
IMAdjustFract (in intermediate IMAdjustment table)
Calculation:
For zonelD, yearlD 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 agelD in AgeCategory table,
for all fuelTypelD in IMCoverage,
for all regClassID values in RegulatoryClass except regClassID=0
modelYearlD = yearlD-agelD
IMAdjustFract (zonelD, yearlD, polProcessID, modelYearlD, fuelTypelD,
regClassID) =
= IMAdjustFract if IMCoverage record exists
with begModelYearlD <= modelYearlD <= endModelYearlD
= 0.0 otherwise
CSEC 1-b: Combine I/M and non I/M rates
CSEC 1-b-l
Input Variables:
agelD (AgeCategory table)
polProcessID (from SourceBin table)
165
-------
modelYearGroupID (from tables of PollutantProcessModelYear and
IMAdjustment)
fuelTypelD & regClassID (from IMAdjustment in step 1-a and SourceBin table)
modelYearlD (from IMAdjustment in step 1-a and PollutantProcessModelYear
table)
Output Variable:
zonelD, yearlD, ageGroupID, polProcessID, modelYearlD,
sourceBinID, IMAdjustFract (in intermediate table
IMAdjustmentWithSourceBin)
Calculation:
INSERT INTO IMAdjustmentWithSourceBin
SELECT zonelD, yearlD, ageGroupID, ima.polProcessID, ima.modelYearlD,
sourceBinID, IMAdjustFract
FROM IMAdjustment ima
INNER JOIN AgeCategory ac ON (ac.agelD = yearlD-ima.modelYearlD)
INNER JOIN PollutantProcessModelYear ppmy ON (
ppmy.polProcessID=ima.polProcessID AND
ppmy.modelYearID=ima.modelYearID)
INNER JOIN SourceBin sb ON (
sb.fuelTypelD = ima.fuelTypelD AND
sb.regClassID = ima.regClassID AND
sb. modelYearGroupID = ppmy.modelYearGroupID);
CSEC l-b-2
Input Variables:
meanBaseRate and meanBaseRatelM (EmissionRate By Age table)
sourceBinID, polProcessID and ageGroupID (from tables of
EmissionRateByAge and step 1-b-l IMAdjustmentWithSourceBin)
modelYearGroupID (from PollutantProcessModelYear table)
IMAdjustFract (from step 1-b-l IMAdjustmentWithSourceBin table)
Output Variable:
meanBaseRate (in intermediate table EmissionRateWithIM)
Calculation:
For all records in join of IMAdjustmentWithSourceBin Table to
EmissionRateByAge table WHERE
IMAdjustmentWithSourceBin.polProcessID=EmissionRateByAge.polProcessID
IMAdjustmentWithSourceBin.ageGroupID = EmissionRateByAge. AgeGroupID
AND
IMAdjustmentWithSourceBin.polProcessID = EmissionRateByAge.polProcessID
AND
IMAdjustmentWithSourceBin.sourceBinID= EmissionRateByAge. sourceBinID
meanBaseRate (zonelD, yearlD, polProcessID, modelYearlD,
166
-------
sourceBinID, opModelD) = GREATEST(meanBaseRateIM*IMAdjustFract +
meanBaseRate*(1.0-IMAdjustFract),0.0)
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)
county ID (from MasterLoop Context)
Output Variable:
fuelAdjustment (in intermediate CountyFuelAdjustment table)
Calculation:
For county ID 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, sourceTypelD,
fuelFormulationiD)
= fuelAdjustment + GPAFract*(fuelAdjustmentGPA-fuelAdjustment)
NOTE: An internal MOVES model component, the DefaultDataMaker, has set fuelAdjustment=l
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)
fuelSubTypelD (from FuelFormulation table)
fuelTypelD (from FuelSubtype table)
monthID (from MonthOfAny Year table)
yearlD (from MasterLoopContext)
fuelYearlD (from Year table)
modelYearlD (from PollutantProcessModelYear table)
Output Variable:
fuelAdjustment (in intermediate FuelSupply Adjustment table)
Calculation:
For all records in join of CountyFuelAdjustment and FuelSupply where
CountyFuelAdjustment.countyID=FuelSupply.countyID and
Year.yearlD = yearlD from MasterLoopContext and
Year.fuelYearlD = FuelSupply .yearlD and
FuelSupply.monthGroupID = MonthOfAnyYear.monthGroupID and
CountyFuelAdjustment.monthGroupID=FuelSupply.monthGroupID and
CountyFuelAdjustment.fuelFormulationID=FuelFormulation.fuelFormulationID and
FuelFormulation.fuelSubtypeID=FuelSubType.fuelSubtypeID and
PollutantProcessModelYear.polProcessID=
167
-------
CountyFuelAdjustment.polProcessID and
PollutantProcessModelYear.fuelMYGroupID=
CountyFuelAdjustment.fuelMYGroupID
fuelAdjustment (countylD, yearlD, montMD, polProcessID, modelYearlD,
sourceTypelD, fuelTypelD)
= 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)
zonelD (from MasterLoop context)
modelYearlD (from PollutantProcessModelYear table)
Output Variable:
temperatureAdjustment (in intermediate METStartAdjustment table)
Calculation:
For zonelD 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, StartTemperature Adjustment and
PollutantProcessModelYear where:
PollutantProcessModelYear.polProcessID =
StartTempAdjustment.polProcessID and
PollutantProcessModelYear.modelYearGroupID=
StartTempAdjustment.modelYearGroupID
temperatureAdjustment(zoneID, monthID, hourlD, polProcessID, modelYearlD,
fuelTypelD, opModelD)
= 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 EmissionRateWithlMAndTemp table)
Calculation:
For all records in join of METStartAdjustment and EmissionRateWithIM,
(Using SourceBin table to relate METSTartAdjustmentfuelTypelD to
EmissionRateWithlM.sourceBinID)
EmissionRateWithlMAndTemp.meanBaseRate (zonelD, monthID, hourlD,
yearlD, polProcessID, modelYearlD, sourceBinID, opModelD) =
EmissonRateWithlM.meanBaseRate + temperatureAdjustment
168
-------
CSEC-5: Weight emission rates by source bin
Input Variables:
meanBaseRate (from EmissionRateWithlMAndTemp table from step 4)
sourceBinActivityFraction (from SourceBinDistribution table)
Output Variable:
meanBaseRate (in an intermediate METSourceBinEmissionRate table)
Calculation:
For all records in join of EmissionRateWithlMAndTemp, SourceBin,
SourceBinDistribution, and
SourceTypeModelYear where:
SourceBinDistribution.sourceBinID = SourceBin.sourceBinID and
SourceBinDistribution. sourceTypeModelYearlD
= SourceTypeModelYear. sourceTypeModelYearlD
EmissionRateWithIMAndTemp.polProcessID=
SourceBinDistribution.polProcessID and
EmissionRateWithIMAndTemp.sourceBinID=
SourceBinDistribution. sourceBinID and
SourceTypeModelYear. modelYearlD =
EmissionRateWithlMAndTemp.modelYearlD
Note: This calculation can take advantage of the fact that there is only one
modelYearGroupID present for a modelYearlD.
meanBaseRate(zoneID, monthID, hourlD, yearlD, polProcessID, sourceTypelD,
modelYearlD, fuelTypelD, opModelD)
= 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 Activity WeightedEmissionRate table)
Calculation:
For linkID from MasterLoop context.
For all records in join of METSourceBinEmissionRate, HourDay, and
OperatingModeDistribution where:
OpModeDistribution.hourDayID = HourDay.hourDaylD and
HourDay.hourID=METSourceBinEmissionRate.hourID and
OpModeDistribution. polProcessID =
METSourceBinEmissionRate.polProcessID and
OpModeDistribution. sourceTypelD =
METSourceBinEmissionRate. sourceTypelD and
169
-------
OpModeDistribution.opModelD = METSourceBinEmissionRate.opModelD
meanBaseRate(zoneID, yearlD, monthID, daylD, hourlD, polProcessID,
sourceTypelD, modelYearlD, fuelTypelD)
= sum over opModelD (meanBaseRate * opModeFraction)
CSEC-7: Apply fuel adjustment factor
Input Variables:
meanBaseRate (from Activity WeightedEmissionRate table from step 6)
fuelAdjustment (from FuelSupplyAdjustment table from step 2)
Output Variable:
meanBaseRate (in intermediate Activity WeightedEmissionRate table)
Calculation:
For all records in join of Activity WeightedEmissionRate and
FuelSupply Adjustment using: yearlD, monthID, polProcessID,
sourceTypelD, modelYearlD, and fuelTypelD
meanBaseRate(zoneID, yearlD, monthID, daylD, hourlD, polProcessID,
sourceTypelD, modelYearlD, fuelTypelD)
= meanBaseRate * fuelAdjustment
CSEC-8: Multiply emission rates by start activity to generate inventory
Input Variables:
meanBaseRate (from Activity WeightedEmissionRate table from step 7)
starts (from Starts table)
yearlD, statelD, county ID, zonelD, linkID from MasterLoop context
pollutantID, processID from PollutantProcessAssoc table
Output Variable:
emissionQuant (in MOVESWorkerOutput table)
Calculation:
For all records in join of Starts, Activity WeightedEmissionRate, HourDay, and
PollutantProcessAssoc tables where:
Starts.zonelD = zonelD value from MasterLoopContext
Starts.yearlD = yearlD value from MasterLoopContext
yearlD - Starts.agelD
= ActivityWeightedEmissionRate.modelYearlD and
Starts.monthID = ActivityWeightedEmissionRate.monthID and
Starts.sourceTypelD = Activity WeightedEmissionRate. sourceTypelD and
Starts.hourDaylD = HourDay.hourDaylD and
HourDay.hourlD = ActivityWeightedEmissionRate.hourlD and
HourDay.daylD = ActivityWeightedemissionRate.daylD and
Activity WeightedEmissionRate.polProcessID
=PollutantProcessAssoc.polProcessID
roadTypelD = 1
SCC = null
170
-------
emissionQuant(stateID, countylD, zonelD, linkID, roadTypelD, yearlD,
monthID, daylD, hourlD, pollutantID, processID, sourceTypelD,
modelYearlD, fuelTypelD, SCC)
= meanBaseRate * starts
CSEC-9: Conditionally convert results by sourceTypelD 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. sourceTypeModelYearlD =
SCCVtypeDistribution. sourceTypeModelYearlD and
SCC.SCCVtypelD = SCCVtypeDistribution.SCCVtypelD and
SCC.SCCroadTypeID=l
SCCFraction(zoneID, sourceTypelD, modelYearlD, fuelTypelD, 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 MOVES WorkerOutput and SCCDistribution using:
sourceTypelD, modelYearlD, fuelTypelD
emissionQuant(stateID, countylD, zonelD, linkID, roadTypelD, yearlD,
monthID, daylD, hourlD, pollutantID, processID, sourceTypelD,
modelYearlD, fuelTypelD, SCC)
= sum over sourceTypelD (emissionQuant* SCCFraction)
171
-------
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
meanBaseRatelM. 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 Temperature Adjustment 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 opModelD but adds hourDaylD and
sourceTypelD. 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: hourDaylD, sourceTypelD, sourceBinID, ageGroupID
Data field: opModeWeightedMeanBaseRate
Calculation:
For polProcessID, linkID from Master Loop Context
For all hourDaylD, sourceTypelD in Run Specification
opModeWeightedMeanBaseRate = SUM(opModeFraction * meanBaseRate)
Step BRPMC-2: Weight Emission Rates by Source Bin
172
-------
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 modelYearlDs.
Because SourceBinDistributions are by individual model year, and the results of the
previous step are by ageGroupID, yearlD 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
yearlD value from the master loop context
Output Variables:
Intermediate FullyWeightedEmissionRate table
Key fields: yearlD, hourDaylD, sourceTypelD, fuelTypelD, model YearlD
Data field: fullyWeightedMeanBaseRate
Calculation:
For yearlD in the master loop context
modelYearlD = yearlD - agelD
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 monthlD.
Input Variables:
FullyWeightedEmissionRate table from previous step
SHO table from MOVESExecution database
monthlD values from the run specification
Output Variables:
Intermediate UnadjustedEmissionResults table
173
-------
Key fields: yearlD, monthID, hourDaylD, sourceTypelD, fuelTypelD,
modelYearlD
Data field: unadjustedEmissionQuant
Calculation:
modelYearlD = calendar year - agelD
For all monthID values in the run specification
unadjustedEmissionQuant = fullyWeightedMeanBaseRate * SHO
Step BRPMC-4: Apply Fuel Adjustment by weighing emission rates by fuel
adjustment
Step BRPMC-4-a: Combine GPA and non GPA fuel adjustment factors
Input Variables:
countylD from the MasterLoopContext
Fuel Adjustment table from MOVESExecution database
Output Variables:
Intermediate CountyFuelAdjustment table
Key fields: countylD, polProcessID, fuelMYGroupID, sourceTypelD,
fuelF ormul ati onID
Data field: fuel Adjustment
Calculation:
For the countylD in the Master Loop Context
New fuel Adjustment = fuel Adjustment+GPAF ract* (fuel AdjustmentGP A-
fuel Adjustment)
Step BRPMC-4-b: Aggregate county fuel adjustments to fuel type
Input Variables:
countylD and yearlD from the MasterLoopContext
fuelF ormul ati onID & marketShare from Fuel Supply table from from
MOVESExecution database
fuelTypelD from Fuel Sub Type table from MOVESExecution database
174
-------
monthID from MonthOfAnyYear table from MOVESExecution database
CountyFuelAdjustment table in previous step
modelYearlD from PollutantProcessModelYear table from from
MOVESExecution database
Output Variables:
Intermediate Fuel Supply WithFuelType table
Key fields: countylD, yearlD, monthID, fuelFormulationID, fuelTypelD
Data field: marketShare
Execution Code :
INSERT INTO FuelSupplyWithFuelType
SELECT countylD, yearlD, may .monthID, fs. fuelFormulationID, fst.fuelTypelD,
fs.marketShare
FROMFuelSupplyfs
INNER JOIN FuelFormulation ff ON ff.fuelFormulationID = fs. fuelFormulationID
INNER JOIN FuelSubType fst ON fst.fuelSubTypelD = fffuelSubTypelD
INNER JOIN MonthOfAny Year may ON fs.monthGroupID = may.monthGroupID
INNER JOIN Year y ON y. fuel YearlD = fs.fuelYearlD
WHERE y.yearlD = ##context.year##;
Intermediate Fuel Supply Adjustment table
Key fields: countylD, yearlD, monthID, polProcessID, model YearlD,
sourceTypelD, fuelTypelD
Data field: fuel Adjustment
Calculation:
For the countylD (in the Master Loop Context), yearlD (in the Master Loop
Context), monthID, polProcessID, modelYearlD, sourceTypelD, fuelTypelD
New fuel Adjustment = SUM(fuelAdjustment*marketShare)
Step BRPMC-4-c: Apply fuel adjustment to weighted emission rates
Input Variables:
UnadjustedEmissionResuits table from previous step
Fuel Supply Adjustment table from from previous step
Output Variables:
Intermediate FuelAdjustedEmissionRate table
175
-------
Key fields: yearlD, monthID, hourDaylD, sourceTypelD, fuelTypelD,
modelYearlD, polProcessID
Data field: unadjustedEmissionQuant
Calculation:
For the yearlD (in the Master Loop Context), monthID, hourDaylD,
sourceTypelD, fuelTypelD, modelYearlD, polProcessID
New unadjustedEmissionQuant = unadjustedEmissionQuant * fuel Adjustment
Step BRPMC-5: 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 hourDaylD into hourlD and daylD since this is
needed to join to the ZoneMonthHour table and is the form eventually needed for
MOVEWorkerOutput.
Input Variables:
zonelD and polProcessID from the MasterLoopContext
UnadjustedEmissionResuits table from previous step
ZoneMonthHour table from MOVESExecution database
Temperature Adjustment table from MOVESExecution database
HourDay table from MOVESExecution database
Output Variables:
Intermediate AdjustedEmissionResults table
Key fields: yearlD, monthID, daylD, hourlD, sourceTypelD, fuelTypelD,
modelYearlD
Data field: emissionQuant
Calculation:
For the polProcessID and zonelD in the Master Loop Context
emissionQuant = unadjustedEmissionQuant * exp(tempAdjustTermA * (72-
temperature))
176
-------
Step BRPMC-6: Convert Results to Structure of MOVESWorkerOutput by
sourceTypelD
Structurally we need to add statelD, countylD, zonelD, linkID, roadTypelD, SCC (as null
value) and decompose polProcessID into pollutantID and processID.
Input Variables:
statelD, linkID from MasterLoop Context
Link table from MOVESExecution
PollutantProcessAssoc table from MOVESExecution
AdjustedEmissionResults table from previous step
Output Variables:
MOVESWorkerOutput Table
Key fields: yearlD, monthID, daylD, hourlD, statelD, countylD, zonelD,
linkID, pollutantID, processID,,sourceTypelD, fuelTypelD,
modelYearlD, roadTypelD, SCC
Data field: emissionQuant
Calculation:
MO VESWorkerOutput.emissionQuant=AdjustedEmissionResults.emissionQuant
countylD = Link, county ID
zonelD = Link.zonelD
roadTypelD = Link.roadTypelD
pollutantID = PollutantProcessAssoc.pollutantID
processID = PollutantProcessAssoc.processID
SCC = null
Step BRPMC-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, 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
sourceTypelD, modelYearlD from SourceTypeModelYear
177
-------
Output Variable:
emissionQuant (in restructured MOVESWorkerOutput table)
Calculation:
From join of SCCVtypeDistribution, SCC, SourceTypeModelYear, and
SCCRoadTypeDistribution where:
zonelD = zonelD from master loop context
SourceTypeModelYear. sourceTypeModel YearlD =
SCCVtypeDistribution. sourceTypeModel YearlD and
SCC.SCCVtypelD = SCCVtypeDistribution. SCCVtypelD and
SCC. SCCroadTypeID=SCCRoadTypeDistribution.roadTypeID and
MOVESWorkerOutput.sourceTypelD =
SourceTypeModelYear. sourceTypelD and
MOVESWorkerOutput.modelYearlD = sourceTypeModel Year, model YearlD
and
MOVESWorkerOutput.fuelTypelD = SCCVtypeDistribution.fuelTypelD and
MOVESWorkerOutput.roadTypelD =
SCCRoadTypeDistribution.roadTypelD
SCC= SCC. SCC
emissionQuant = sum of emissionQuant * SCCVtypeFraction *
SCCRoadTypeFraction over sourceTypelD and roadTypelD
sourceTypelD = null
roadTypelD = null
linkID = null
178
-------
10.24. Sulfate PM EmissionCalculator (SEC)
10.24.1. General Description
This calculator will gives the model the capability to compute sulfate PM 2.5
emissions. 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
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.
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.
179
-------
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) /
Fuel Type.energyContent
A sample of this calculation, showing the engineering units involved, is:
(1.4807e-08gSO4/gfuel-ppmS)* (30 ppm gasoline S) * lOOOKJ/hr / 10 KJ/ gram fuel
= 4.442e-05 g/SO4 / hr
10.24.3 PM 10 Emission Calculator
10.24.3.1 General Description
This calculator will gives the model the capability to compute PM 10 sulfate,
elemental carbon, and organic carbon emissions. The basic design of the calculator is to
compute PM 10 emissions as the product of a PM 2.5/sourcetype/fueltype-specific
emission factor and the amount of PM 2.5 of the corresponding MOVES emission
process. The MOVES PMlOEmissionCalculator is 'chained to' any PM 2.5 calculator.
The pollutant-processes for which emission calculations are performed by this
calculator are:
SulfatePMlO - running exhaust polProcessID = 10501
SulfatePMlO-start exhaust polProcessID = 10502
SulfatePMlO - extended idle exhaust polProcessID = 10590
180
-------
Organic Carbon PM10 - running exhaust polProcessID = 10101
Organic Carbon PM10 - start exhaust polProcessID = 10102
Organic Carbon PM10 - extended idle exhaust polProcessID = 10190
Organic Carbon PM10 - crankcase running exhaust polProcessID = 10115
Organic Carbon PM10 - crankcase start exhaust polProcessID = 10116
Organic Carbon PM10 - crankcase extended idle exhaust polProcessID = 10117
Elemental Carbon PM10 - running exhaust polProcessID = 10201
Elemental Carbon PM10 - start exhaust polProcessID = 10202
Elemental Carbon PM10 - extended idle exhaust polProcessID = 10290
Elemental Carbon PM10 - crankcase running exhaust polProcessID = 10215
Elemental Carbon PM10 - crankcase start exhaust polProcessID = 10216
Elemental Carbon PM10 - crankcase extended idle exhaust polProcessID =
10217
Inputs to the calculator are:
• MOVESWorkerOutput.emissionQuant for PM 2.5 of the corresponding emissions
process (running exhaust, start exhaust, extended idle exhaust, or other).
• PMlOEmissionRatio - a unitless factor for the amount of PM 10 created per unit
of PM 2.5. This factor varies by the output pollutant, the source type, and the fuel
type.
Like all emission calculators its output is MOVESWorkerOutput.emissionQuant.
10.24.3.2 Detailed Calculation Step
The calculation will be performed in one basic step:
emissionQuant(PM 10) = emissionQuant(PM 2.5) * PM10EmissionRatio(PM 10
pollutant and process, source type, fuel type)
Note that the emissionQuant values vary by all dimensions of the MOVESWorkerOutput
table, including process, source type, and fuel type.
181
-------
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
EmissionRateByAge table, and only considers the meanBaseRate, ignoring
meanBaseRatelM. 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 StartTempAdjustment table. This allows the temperature
adjustment to vary by operating mode and model year group, which is needed in order to
apply the effects of the Mobile Source Air Toxics (MS AT) rule effects on engine start
emissions.
10.25.2. Detailed Calculation Steps
This calculator is very similar to the Basic Running PM Emission Calculator. However,
the operating mode is carried forward until the temperature adjustments (which depend
on operating mode) can be applied.
Step BSPMC-1: Weight Emission Rates by Operating Mode
Structurally this combines the OpModeDistribution and EmissionRateByAge tables.
Relative to EmissionRateByAge adds hourDaylD and sourceTypelD. If the calculator
executed above the LINK level, linkID would also have to be added. The meanBaseRate
is adjusted by the opModeFraction, but the operating modes are not yet summed, since
the temperature adjustment (in BSPMC-4) has not yet been applied.
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: hourDaylD, sourceTypelD, sourceBinID, ageGroupID,
opModelD
Data field: opModeWeightedMeanBaseRate
Calculation:
For polProcessID, linkID from Master Loop Context
For all hourDaylD, sourceTypelD in Run Specification
182
-------
opModeWeightedMeanBaseRate = (opModeFraction * meanBaseRate)
Step BSPMC-2: Weight Emission Rates by Source Bin
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 modelYearlDs.
Because SourceBinDistributions are by individual model year, and the results of the
previous step are by ageGroupID, yearlD 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
yearlD value from the master loop context
Output Variables:
Intermediate FullyWeightedEmissionRate table
Key fields: yearlD, hourDaylD, sourceTypelD, fuelTypelD,
modelYearlD, opModelD
Data field: fullyWeightedMeanBaseRate
Calculation:
For yearlD in the master loop context
modelYearlD = yearlD - agelD
fullyWeightedMeanBaseRate =
SUM(sourceBinActivityFraction * opModeWeightedMeanBaseRate)
Step BSPMC-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 monthlD.
Input Variables:
183
-------
FullyWeightedEmissionRate table from previous step
SHO table from MOVESExecution database
monthID values from the run specification
Output Variables:
Intermediate UnadjustedEmissionResults table
Key fields: yearlD, monthID, hourDaylD, sourceTypelD, fuelTypelD,
modelYearlD, opModelD
Data field: unadjustedEmissionQuant
Calculation:
modelYearlD = calendar year - agelD
For all monthID values in the run specification
unadjustedEmissionQuant = fullyWeightedMeanBaseRate * SHO
Step BSPMC-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 hourDaylD into hourlD and daylD since this is
needed to join to the ZoneMonthHour table and is the form eventually needed for
MOVEWorkerOutput. The unadjustedEmissionQuant values are summed across
operating modes, since this key is no longer needed after the temperature adjustments
have been applied.
Input Variables:
zonelD and polProcessID from the MasterLoopContext
UnadjustedEmissionResults table from previous step
ZoneMonthHour table from MOVESExecution database
StartTempAdjustment table from MOVESExecution database
HourDay table from MOVESExecution database
Output Variables:
Intermediate AdjustedEmissionResults table
Key fields: yearlD, monthID, daylD, hourlD, sourceTypelD, fuelTypelD,
modelYearlD
Data field: emissionQuant
184
-------
Calculation:
For the polProcessID and zonelD in the Master Loop Context
emissionQuant = sum(unadjustedEmissionQuant *
tempAdustTermB*exp(tempAdjustTermA * (72-least(temperature,72))) +
tempAdustTermC
Step BSPMC-5: Convert Results to Structure of MOVESWorkerOutput by
sourceTypelD
Structurally we need to add statelD, countylD, zonelD, linkID, roadTypelD, SCC (as null
value) and decompose polProcessID into pollutantID and processID.
Input Variables:
statelD, linkID from MasterLoop Context
Link table from MOVESExecution
PollutantProcessAssoc table from MOVESExecution
AdjustedEmissionResults table from previous step
Output Variables:
MOVESWorkerOutput Table
Key fields: yearlD, monthID, daylD, hourlD, statelD, countylD, zonelD,
linkID, pollutantID, processID,,sourceTypelD, fuelTypelD,
modelYearlD, roadTypelD, SCC
Data field: emissionQuant
Calculation:
MO VESWorkerOutput.emissionQuant=AdjustedEmissionResults.emissionQuant
countylD = Link, county ID
zonelD = Link.zonelD
roadTypelD = Link.roadTypelD
pollutantID = PollutantProcessAssoc.pollutantID
processID = PollutantProcessAssoc.processID
SCC = null
Step BSPMC-6: Conditionally Convert Results to Structure of
MOVESWorkerOutput by SCC
185
-------
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
sourceTypelD, modelYearlD from SourceTypeModelYear
Output Variable:
emissionQuant (in restructured MOVESWorkerOutput table)
Calculation:
From join of SCCVtypeDistribution, SCC, SourceTypeModelYear, and
SCCRoadTypeDistribution where:
zonelD = zonelD from master loop context
SourceTypeModelYear. sourceTypeModel YearlD =
SCCVtypeDistribution. sourceTypeModel YearlD and
SCC.SCCVtypelD = SCCVtypeDistribution. SCCVtypelD and
SCC. SCCroadTypeID=SCCRoadTypeDistribution.roadTypeID and
MOVESWorkerOutput. sourceTypelD =
SourceTypeModelYear. sourceTypelD and
MOVESWorkerOutput.modelYearlD = sourceTypeModel Year, model YearlD
and
MOVESWorkerOutput.fuelTypelD = SCCVtypeDistribution.fuelTypelD and
MOVESWorkerOutput.roadTypelD =
SCCRoadTypeDistribution.roadTypelD
SCC= SCC. SCC
emissionQuant = sum of emissionQuant * SCCVtypeFraction *
SCCRoadTypeFraction over sourceTypelD and roadTypelD
sourceTypelD = null
roadTypelD = null
linkID = null
186
-------
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 the YEAR level. They retrieve
their emission rates from EmissionRate, and only consider the meanBaseRate, ignoring
meanBaseRatelM. 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.
187
-------
10.27. CriteriaAndPMExtendedldleEmissionCalculator
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 meanBaseRateEVI. 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 Fuel Type Table
Output Variables:
An intermediate METAdjustment table:
Key fields: zonelD, monthID, hourlD, polProcessID, fuelTypelD
Data fields: temperature Adjustment, K (the NOx correction factor)
188
-------
Calculations:
temperature Adjustment = 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:
heatlndex 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: zonelD, monthID, hourlD
Date Field: ACOnFraction
Calculation:
ACOnFraction = ACActivityTermA + ACActivityTermB * heatlndex
ACActivityTermC * heatlndex * heatlndex
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
189
-------
Output Variables:
An intermediate ACActivityFraction table:
Key Fields: zonelD, monthID, hourlD, sourceTypelD, modelYearlD
Date Field: ACActivityFraction
Calculation:
agelD = calendar year - modelYearlD
(needed to join to the SourceTypeAge table)
ACActivityFraction = ACOnFraction * ACPenetrationFraction *
functi oning ACFracti on
Step CEIC-2c: Calculate ACAdjustmentFraction
Input Variables:
ACActivityFraction from previous sub-step
full AC Adjustment from Full AC Adjustment table
Output Variables:
An intermediate ACAdjustment table:
Key Fields: zonelD, monthID, hourlD, sourceTypelD, modelYearlD,
polProcessID
Date Field: ACAdjustment
Calculation:
Assume Full AC Adjustment populated only for a single opModelD
ACAdjustment = 1.0 + ((full AC Adjustment-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:
190
-------
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
sourceTypeModelYearlD values into their constituent sourceTypelD and
modelYearlD values.
Output Variables:
An intermediate SBWeightedEmissionRate Table
Key fields: polProcessID, sourceTypelD, modelYearlD, fuelTypelD
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 modelYearlD.
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
temperature Adjustment and K from the MET Adjustment table produced by step 1
ACAdjustment from the ACAdjustment table produced by step 2-c.
Output Variables:
An intermediate WeightedAndAdjustedEmissionRate table
Key fields: polProcessID, sourceTypelD, modelYearlD, fuelTypelD, zonelD,
monthID, hourlD
Data field: meanBaseRate
Calculation:
K_ToUse = K if pollutantID=3 otherwise K_ToUse = 1.0
191
-------
WeightedAndAdjustedEmissionRate.meanBaseRate =
SBWeightedEmissionRate.meanBaseRate * temperature Adjustment *
ACAdjustment * K_ToUse
Step CEIC-5: Multiply Emission Rates by Activity
Input Variables:
meanBaseRate from WeightedAndAdjustedEmissionRate table from step 4.
extendedldleHours from ExtendedldleHours table.
HourDay table needed to decompose hourDaylD values in extendedldleHours
into daylD and hourlD values.
Output Variables:
emissionQuant in an intermediate AdjustedEmissionResults table
Key Fields: polProcessID, sourceTypelD, modelYearlD, fuelTypelD, zonelD,
monthID, hourlD, daylD, yearlD
Data Field: emissionQuant
Calculations:
agelD = calendar year - modelYearlD
(needed to join to the extendedldleHours table)
emissionQuant = meanBaseRate * extendedldleHours
Step CEIC-6: Convert Results to Structure of MOVESWorkerOutput by
sourceTypelD
Structurally we need to add statelD, countylD, linkID, roadTypelD , SCC (as null value)
and decompose polProcessID into pollutantID and processID.
Input Variables:
statelD, countylD from MasterLoop Context
linkID from Link table
PollutantProcessAssoc table
AdjustedEmissionResults table from previous step
Output Variables:
192
-------
MOVESWorkerOutput Table
Key fields: yearlD, monthID, daylD, hourlD, statelD, countylD, zonelD,
linkID, pollutantID, processID ,sourceTypeID, fuelTypelD, model YearlD,
roadTypelD, SCC
Data field: emissionQuant
Calculations:
MO VESWorkerOutput.emissionQuant=AdjustedEmissionResults.emissionQuant
statelD = statelD from MasterLoop context
county ID = county ID from MasterLoop context
roadTypelD = 1
linkID = value from Link table for zonelD where roadTypelD = 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
sourceTypelD, modelYearlD from SourceTypeModelYear
Output Variable:
emissionQuant (in restructured MOVESWorkerOutput table)
Calculation:
From join of SCCVtypeDistribution, SCC, EmissionProcess,
SourceTypeModelYear, and SCCRoadTypeDistribution where:
zonelD = zonelD from master loop context
SourceTypeModelYear. sourceTypeModelYearlD =
SCCVtypeDistribution. sourceTypeModelYearlD and
SCC.SCCVtypelD = SCCVtypeDistribution.SCCVtypelD and
SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeIDand
SCC. SCCProcID = EmissionProcess. SCCProcID and
EmissionProcess.processID = processID from masterloop context
193
-------
MOVESWorkerOutputsourceTypelD = sourceTypeModelYear.sourceTypelD and
MOVESWorkerOutput.modelYearlD = sourceTypeModelYear.modelYearlD and
MOVESWorkerOutput.fuelTypelD = SCCVtypeDistribution.fuelTypelD and
MOVESWorkerOutput.roadTypelD = SCCRoadTypeDistribution.roadTypelD
SCC= SCC.SCC
emissionQuant = sum of emissionQuant * SCCVtypeFraction *
SCCRoadTypeFraction over sourceTypelD and roadTypelD
sourceTypelD = null
roadTypelD = null
linkID = null
10.28 Air Toxics Calculator
The MOVES model calculates emission rates and inventories for several air toxic
pollutants and processes. The algorithm for the air toxics calculator can be found in the
MOVES file AirToxicsCalculator.sql. The term air toxics and the particular compounds
listed in MOVES are generally defined in the EPA Mobile Source Air Toxics (MSAT)
rulemaking as 'air toxics'. The MOVES list is not an exhaustive one of all vehicle
related air toxic pollutants. Exclusion from the list does not imply that a particular
compound (i.e., carbon monoxide) is non-toxic. The list of MOVES air toxics pollutants
includes:
Benzene
Ethanol
MTBE
Naphthalene
1,3-Butadiene
Formaldehyde
Acetaldehyde
Acrolein
194
-------
All of the air toxic pollutants have exhaust processes. However, only benzene,
ethanol, MTBE and Naphthalene have evaporative processes. Ethanol and MTBE are not
products of combustion so they may have zero emission rates if the fuel(s) used in the
MOVES simulation are non-ethanol or non-MTBE fuels.
10.28.1. Air Toxics Calculator Overview
The MOVES model does not contain direct emission rates for any of the air toxic
pollutants. All of them are computed in MOVES from 'chained' calculators using simple
ratios. All pollutants, with the exception of Naphthalene, are ratios (and chained) to
volatile hydrocarbon (VOC) emissions. Naphthalene is a ratio of Total PM10 emissions
(PM10 is in turn chained to PM2.5 emissions which is in turn chained to total energy
emissions).
The basic conceptual air toxics equations in MOVES are:
Air Toxic Emissions = Air Toxic Ratio * VOC Emissions Eq 10.28.1
Air Toxic Emissions = Air Toxic Ratio * PM10 Emissions Eq 10.28.2
All correction factors such as I/M, fuel effects, temperature, etc. are performed on
the underlying VOC or Total PM10 emissions. Thus, the air toxic's calculator does not
apply any additional correct factor modules after Eq 10.28.1 or 10.28.2 is performed.
10.28.2. Air Toxics calculation
Because of size considerations, the air toxic ratios (see Eq 10.28.1) are stored in
three separate MOVE database tables. These tables are ATRatioGasl, ATRatioGas2 and
ATRatioNonGas. Tables ATRatioGasl and ATRatioGas2 contain air toxic ratios for
gasoline powered vehicles only. More specifically, MOVES table ATRatioGasl contains
195
-------
air toxic ratios for pollutants Benzene, MTBE, 1,3-Butadiene, Formaldehyde and
Acetaldehyde for the Running, Start and Extended Idle processes, and air toxics ratios for
Benzene and MTBE for all of the evaporative processes. Table ATRatioGas2 contains
air toxic ratios for pollutants Ethanol and Naphthalene for all exhaust and evaporative
processes, and Acrolein air toxic ratios for all exhaust processes. Table ATRatioNonGas
contains air toxic ratios for diesel and ethanol (E-85) powered vehicles for all pollutant /
process combinations.
Input Variables:
From table MOVESWorkerOutput the following variables:
yearlD, monthID, daylD, hourlD, statelD, countylD, zonelD, linkID,
sourceTypelD, .fuelTypelD, modelYearlD, roadTypelD, SCC and emissionQuant
Because air toxics are chained pollutants, emissionQuant contains the VOC or Total
PM10 emission quantity as it enters the air toxics calculator. The variable
emissionQuant contains the air toxic pollutant quantity as it departs the air toxics
calculator.
Other inputs are:
fuel supply. marketShare
ATRatioGasl. ATRatio
ATRatioGas2. ATRatio
ATRatioNonGas. ATRatio
The value and table source for the variable ATRatio depends on which air toxic
pollutant / process / fueltype is being calculated.
Output Variable:
MOVESWorkerOutput. emissionQuant
196
-------
Calculation:
emissionQuant(air toxic compound) = AirToxicGasl.ATRatio
fuelSupply.marketShare * MOVESWorkerOutput. emissionQuant(VOC)
emissionQuant(air toxic compound) = AirToxicGasl.ATRatio *
fuelSupply.marketShare * MOVESWorkerOutput. emissionQuant(VOC)
emissionQuant(air toxic compound) = AirToxicNonGas. ATRatio *
fuelSupply.marketShare * MOVESWorkerOutput. emissionQuant(VOC)
for Naphthalene
emissionQuant(air toxic compound) = AirToxicGasl.ATRatio *
fuelSupply.marketShare * MOVESWorkerOutput. emissionQuant(PMlO)
emissionQuant(air toxic compound) = AirToxicNonGas. ATRatio *
fuelSupply.marketShare * MOVESWorkerOutput. emissionQuant(PMlO)
10.29. Permeation Calculator
10.29.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 Temperature Adjustment 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
Emi s si onC al cul ator s.
197
-------
10.29.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, yearlD, polProcessID, sourceTypelD,
modelYearlD, fuelTypelD)
= sum (sourceBinActivityFraction * meanBaseRate)
PC-2: Calculate weighted temperature adjustment
Inputs:
- averageTankTemperature (from averageTankTemperature)
- opModeFraction (from operatingModeDistribution)
tempAdjustTermA (from temperature Adjust)
tempAdjustTermB (from temperature Adjust)
Outputs:
weightedTemperatureAdjust (sourceTypelD, monthID, hourDaylD,
linkID, tankTemperatureGroupID)
Preliminary Calculation: temperatureAdjustByOpmode (zonelD, monthID,
hourDaylD, hourDaylD, tankTemperatureGroupID, opModelD)
* etemPAdJustTermB * averageTankTemperature (opModelD)
Calculation: weightedTemperature Adjust
= SUM(temperatureAdjustByOpMode*opModeFraction) over all modes
PC-3: Calculate weighted fuel adjustment
Input Variables:
- fuel Adjustment (from fuel Adjustment table)
marketShare (from fuel Supply table)
Output Variables:
weightedFuelAdjust(polProcessID, modelYearGroupID,
sourceTypelD, fueltypeid)
198
-------
Calculation: weightedFuelAdjust
= SUM(fuelAdjustment * marketShare) over all fuel formulations for the
county, fuelyear, month and fueltypeid.
NOTE: An internal MOVES model component, the DefaultDataMaker, has set
fuel Adjustment=l for cases which are not populated in fuel Adjustment.
PC-4: Calculate fuel adjusted meanBaseRate
Input Variables:
- meanBaseRate (SBWeightedEmissionRate from PC-1)
- weightedFuel Adjust (PC-3)
Output Variables:
- FuelAdjustedMeanBaseRate (zonelD, yearlD, polProcessID,
sourceTypelD, modelYearlD, fuelTypelD)
Calculation: FuelAdjustedMeanBaseRate
= meanBaseRate * weightedFuel Adjustment
PC- 5: Calculate fuel adjusted emissionQuant
Input Variables:
- fuelAdjustedMeanBaseRate (PC-4)
- SourceHours (CMIT from TAG)
Output Variables:
- fuelAdjustedEmissionQuant (linkID, hourDaylD, monthID, yearlD,
modelYearlD, sourceTypelD, fueltypelD)
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:
199
-------
- emissionQuant = fuelAdjustedEmissionQuant *
weightedTemperature Adj ustment
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)
sourceTypelD, modelYearlD from SourceTypeModelYear
Output Variable:
emissionQuant (in MOVESWorkerOutput table)
Calculation:
From join of SCCVtypeDistribution, SCC, SourceTypeModelYear, and
SCCRoadTypeDistribution where:
zonelD = zonelD from master loop context
SourceTypeModelYear. sourceTypeModelYearlD =
SCCVtypeDistribution. sourceTypeModelYearlD and
SCC.SCCVtypelD = SCCVtypeDistribution.SCCVtypelD and
SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeIDand
MOVESWorkerOutputsourceTypelD = sourceTypeModelYear.sourceTypelD and
SCC.SCCroadTypeID=SCCRoadTypeDistribution.roadTypeIDand
MOVESWorkerOutput.modelYearlD = sourceTypeModelYear.modelYearlD and
MOVESWorkerOutput.fuelTypelD = SCCVtypeDistribution.fuelTypelD and
MOVESWorkerOutput.roadTypelD = SCCRoadTypeDistribution.roadTypelD
SCC= SCC.SCC
emissionQuant = sum of emissionQuant * SCCVtypeFraction *
SCCRoadTypeFraction over sourceTypelD and roadTypelD
sourceTypelD = null
roadTypelD = null
linkID = null
200
-------
10.30. Liquid Leaking (LL) Calculator
10.30.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
zonelD, yearlD, polProcessID from masterloop context
AgeCategory table
RegulatoryClass Table
FuelType table
Input Variable:
IMAdjustment Table
Keys: zonelD, yearlD, polProcessID, model YearlD, fuelTypelD, regClassID
Data: IMAdjustFract
Calculation:
For zonelD, yearlD in masterloop context
For Vapor Venting and Liquid Leaking processes of all pollutants in runspec which
this calculator calculates
For all agelD in AgeCategory
For all regClassID in RegulatoryClass except regClassID=0
For FueltypelD = 1 & 5 (right?)
201
-------
modelYearlD = yearlD - agelD
IMAdjustFract.IMAdjustFract = IMCoverage.IMAdjustFract if record exists
With begModelYearlD <= modelYearlD <= endModelYearlD
= 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: yearlD, polProcessID, sourceTypelD, fuelTypelD,
zonelD, monthID, hourDaylD, modelYearlD, opModelD
o Data: WeightedMeanBaseRate
Calculation:
modelYearlD = yearlD - agelD
fuelTypelD = 1 (gasoline) or 5 (E85)
WeightedMeanBaseRate = (meanBaseRatelM * sourceBinActivityFraction
* IMAdjustFract) + (meanBaseRate * sourceBinActivityFraction * (1-
IMAdjustFract))
summed over portions of sourceBinID not needed in the output, namely
regClassID and engTechlD.
LL-3: Calculate MOVESWorkerOutput by Source Type and FuelType
Input Variables:
- WeightedMeanBaseRate table from previous step
- SourceHours table
- OpModeDistribution table
- HourDay table
- County table
- Zone table
- PollutantProcessAssoc table
- Link table
Output Variables:
202
-------
- MOVESWorkerOutput table, which has structure of MOVESOutput
Calculation:
emissionQuant
= weightedMeanBaseRate * sourceHours * opModeFraction
hourlD = hourDay.hourlD
day ID = hourDay.daylD
statelD = county. statelD
county ID = zone, county ID
pollutantID = PollutantProcessAssoc.pollutantID
processID = PollutantProcessAssoc.processID
roadTypelD = Link.roadTypelD
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.
203
-------
10.31. HC Speciation Calculator (HCSC) Calculator
10.31.1. General Information
This calculator gives the model the ability to calculate NMHC (Non-Methane
Hydrocarbons, pollutant 79), NMOG (Non-Methane Organic Gases, pollutant 80), TOG
(Total Organic Gases, pollutant 86), and VOC (Volatile Organic Compounds, pollutant
87). The basic design of the calculator is to compute the results as linear functions of
chained pollutants and fuel-formulation-specific constants. The input pollutants vary
according to the output and the type of fuel. Also, being dependent upon fuel
formulations not just fuel types, market shares are factored into the results.
10.30.2. Detailed Calculation Steps
The HC Speciation table provides formula parameters, with most formulas being of the
form:
outputQuant = sum of (inputQuant * fuel formulation market share * (speciationConstant
+ oxySpeciation*volToWtPercentOxy* sum of oxygenates in the fuel formulation))
across all fuel formulations in a county
There is an added condition on the above: if a fuel has no oxygenates, it has no HC
speciation output. This is not a mere algebraic outcome of the above equation which
would still yield a non-zero number given the speciationConstant term even with zero
oxygenates. All HC speciation equations that require oxygenates are subject to this
conditional logic.
All HC speciation calculations have common table connectivity, differing only in their
formula for calculating new emission quantities and criteria for input pollutants and fuels.
To perform HC speciation, connect the following tables and columns:
• MOVESWorkerOutput.fuelTypelD with FuelSupply.fuelTypelD
• MO VESWorkerOutput. county ID with Fuel Supply, county ID
• MOVESWorkerOutput.yearlD with Fuel Supply .yearlD
204
-------
• MOVESWorkerOutput.monthID with Fuel Supply. monthID
• MOVESWorkerOutput.modelYearlD with
PollutantProcessModelYear.modelYearlD
• MOVESWorkerOutput.processID with PollutantProcessAssoc.processID
• Fuel Supply. fuelFormulationlD with FuelFormulation.fuelFormulationlD and with
HCSpeciation.fuelFormulationlD
• HCSpeciation.fuelMYGroupID with
PollutantProcessModelYear.fuelMYGroupID
• HCSpeciation.polProcessID with PollutantProcessModelYear.polProcessID and
PollutantProcessAssoc.polProcessID
The output of the calculations has the same dimensional values as each input
MOVESWorkerOutput table row except that the output pollutantID should be taken from
PollutantProcessAssoc.pollutantlD. All outputs are summed across the contributing fuel
formulations and weighted according to market share.
For non-E85, non-E70 fuels:
NMHC = (THC - Methane) * marketShare
Thus, for an input record of THC, an equal amount of NMHC should be generated. For
Methane input, the output is NMHC = -Methane. Worker-side and master-side
aggregation logic will sum the values completing the formula.
ForE85 or E70 fuels:
NMHC=THC * (speciationConstant + oxySpeciation * volToWtPercentOxy *
ETOHVolume) * marketShare
For non-E85, non-E70 fuels:
NMOG = NMHC * (speciationConstant + oxySpeciation * volToWtPercentOxy *
(MTBEVolume + ETBEVolume + TAMEVolume + ETOHVolume)) *
marketShare
For E85 or E70 fuels:
NMOG=THC * (speciationConstant + oxySpeciation * volToWtPercentOxy *
ETOHVolume) * marketShare
For non-E85, non-E70 fuels:
VOC = NMHC * (speciationConstant + oxySpeciation * volToWtPercentOxy *
(MTBEVolume + ETBEVolume + TAMEVolume + ETOHVolume)) *
marketShare
205
-------
For E85 or E70 fuels:
VOC=THC * (speciationConstant + oxySpeciation * volToWtPercentOxy *
ETOHVolume) * marketShare
For non-E85, non-E70 fuels:
TOG = (NMOG + Methane) * marketShare
Thus, for an input record of NMOG, an equal amount of TOG should be generated. For
Methane input, an equal amount of TOG should be generated. Worker-side and master-
side aggregation logic will sum the values completing the formula.
ForE85 or E70 fuels:
TOG=THC * (speciationConstant + oxySpeciation * volToWtPercentOxy *
ETOHVolume) * marketShare
10.32. Tank Vapor Venting (TVV) Calculator
10.32.1. General Information
This calculator executes at the MONTH master looping level.
Input Tables
• TankVaporGenCoeffs
o Keys: ethanolLevellD (0 or 10), altitude ("H" or "L")
o Data: tvgTermA, tvgTermB, tvgTermC
• CumTVVCoeffs (Analogous to EmissionRateByAge, knowing that there is only
one opModelD 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: zonelD, fuelYearlD, monthGroupID, fuelTypelD
o Data: ETOHVolume, RVP
• ColdSoakTankTemperature (from TTG-1)
o Keys: zonelD, monthID, hourlD
o Data: ColdSoakTankTemperature
• ColdSoaklnitialHourFraction (from TTG-7)
o Keys: sourceTypelD, zonelD, monthID, hourDaylD, initialhourDaylD
o Data: ColdSoaklnitialHourFraction
206
-------
• 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.
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 and
E85 ethanol contents.
TVV-4 calculates an ethanol-weighted values of the tank vapors 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.
207
-------
10.32.2. Detailed Calculation Steps
Note: Steps TVV-2 through TVV-7 need not be performed for mesoscale lookup
runs.
TW — 1 Compute I/M Adjustment Fraction Information
(same as CREC 1-a except for different value(s) of pollutant-process)
Input Variables:
IMCoverage table
zonelD, yearlD, polProcessID from masterloop context
AgeCategory table
RegulatoryClass Table
FuelType table
Output Variable:
IMAdjustment Table
Keys: zonelD, yearlD, polProcessID, model YearlD, fuelTypelD, regClassID
Data: IMAdjustFract
Calculation:
For zonelD, yearlD in masterloop context
For Vapor Venting and Liquid Leaking processes of all pollutants in runspec
which this calculator calculates
For all agelD in AgeCategory
For all regClassID in RegulatoryClass except regClassID=0
modelYearlD = yearlD - agelD
IMAdjustFract.IMAdjustFract = IMCoverage.IMAdjustFract if record exists
With begModelYearlD <= modelYearlD <= endModelYearlD
= 0.0 otherwise
TW- 2 Determine Hour of Peak Cold Soak Tank Temperature
Input Variable:
ColdSoakTankTemperature table
Output Variables:
intermediate PeakHourOfColdSoak table
Keys: zonelD, monthID
Data: peakHourlD
Calculation:
208
-------
peakHourlD is the first (smallest) hourlD having the highest
coldSoakTankTemperature for the zonelD and monthID
TW-3 Calculate TankVaporGenerated (TVG) by Ethanol Level
Input Variables:
- ColdSoaklnitialHourFraction table
- PeakHourOfColdSoak table from previous step
- ColdSoakTankTemperature table
- TankVaporGenerationCoeffs table
- AverageTankGasoline table
- HourDay table
- County table
Output Variables:
An intermediate TankVaporGenerated table
Keys: hourDaylD, initialhourDaylD, ethanolLevellD, monthID, zonelD,
sourceTypelD, fuelYearlD, fueltypelD
Data: tankVaporGenerated
Calculation:
Calculation is limited to:
monthID, zonelD, sourceTypelDs and fueltypeids in the masterloopcontext and the ran
specification
combinations of hourDaylD and initialhourDaylD present in
ColdSoaklnitialHourFraction for which initialhourDaylD <> hourDaylD
hourDaylD values having an hourlD value <= PeakHourOfColdSoak.peakHourlD
tankVaporGenerated = 0.0 if tl>=t2
otherwise
tankVaporGenerated = (a eb(RVP) (ect2 - ect1)) * k
Where:
t2 = ColdSoakTankTemperature of hourlD associated with hourDaylD
tl = ColdSoakTankTemperature of hourlD associated with initialhourDaylD
k = 50% fill adjustment constant to be determined
a, b, and c are terms from TankVaporGenCoeffs table
RVP is from AverageTankGasoline table by fuelTypelD
The altitude of the County to which the zonelD belongs should be used
when selecting the a,b, and c coefficients from the TankVaporGenCoeffs
table.
TW-4 Calculate ethanol-weighted TVG
Input Variables:
209
-------
- TankVaporGenerated table from previous step
EtOH Volume value from AverageTankGasoline table
Output Variables:
An intermediate EthanolWeightedTVG table
o Key fields: hourDaylD, initialhourDaylD, monthID, zonelD,
sourceTypelD, fuelYearlD, fueltypelD
o Data: ethanolWeightedTVG
Calculation:
ethanolWeightedTVG
= tankVaporGeneratedEio (ETOHVolume /10) +
tankVaporGeneratedEO (1 - (ETOHVolume/10))
TW-5: Calculate Cumulative Tank Vapor Vented (TW)
Input Variables:
- EthanolWeightedTVG table from previous step
- CumTVVCoeffs table
- PollutantProcessModelYear
- AgeCategory
Output Variables:
An intermediate CumulativeTVV table:
Key fields: regClassID, agelD, polProcessID, hourDaylD,
initialhourDaylD, monthID, zonelD, sourceTypelD, fuelTypelD
Data fields: tankVaporVented, tankVaporVentedIM
Calculation:
For all agelD:
tankVaporVented = tvvTermA + tvvTermB* ethanolWeightedTVG +
tvvTermC* ethanolWeightedTVG2
tankVaporVentedIM = tvvTermAIM + tvvTermBIM* ethanolWeightedTVG +
tvvTermCIM*ethanolWeightedTVG2
The structure of the output table specified here implies that fuelYearlD,
ageGroupID, and model YearGroupID be converted to the common basis of individual
agelD to facilitate proper table joining and minimize the size of the resulting table (which
nevertheless may be performance-constraining). The PollutantProcessModelYear, and
210
-------
AgeCategory tables can be used to accomplish this, along with the relationship agelD =
yearlD - model YearlD.
TW-6: Calculate Weighted CumulativeTVV Across Initial/Current pair
Input Variables:
- CumulativeTVV Table from previous step
ColdSoaklnitialHourFraction table
Output Variables:
An intermediate WeightedCumulativeTVV Table
Key fields: regClassID, agelD, polProcessID, hourDaylD, monthID,
zonelD, sourceTypelD, fuelTypelD
Data fields: weightedTVV, weightedTVVIM
Calculation:
For each combination of regClassID, agelD, polProcessID, hourDaylD,
monthID, zonelD, and sourceTypelD, fuelTypelD
weightedTVV = [tankVaporVented * ColdSoaklnitialHourFraction]
summed over all initialHourlDs
weightedTVVIM = [tankVaporVentedEVI * ColdSoaklnitialHourFraction]
summed over all initialHourlDs
TW-7: Calculate HourlyTW Emissions by Regulatory Class and Vehicle Age
Input Variables:
- WeightedCumulativeTVV Table (from previous step)
o LEFT JOINED to itself associating each hourlD 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 HourlyTW table
211
-------
o key fields: regClassID, agelD, polProcessID, hourDaylD,
monthID, zonelD, sourceTypelD, fuelTypelD
o data fields: hourlyTVV, hourlyTVVIM
Calculation:
For records in WeightedCumulativeTVVTable (which have hourlDs prior or
equal to the hour of the peak cold soak tank temperature because of the limited
domain of the calculation in step 3)
hourly TVV = weightedTVV for the current hourlD - weightedTVV for
the previous hourlD, (if no record is present for the previous hourlD then
the weighted TVV for the previous hourlD is 0.0)
hourly TVVIM = weightedTVVIM for the current hourlD -
weightedTVVIM for the previous hourlD, (if no record is present for the
previous hourlD then the weighted TVVIM for the previous hourlD is 0.0)
For all hourDaylDs in HourDay which have hourDaylDs greater than
PeakHourOfColdSoak.peakHourlD:
hourly TVV for each such hourlD = weightedTVV for peakHourlD * the
residualVaporRatio for the number of hours the hourlD is past the
peakHourlD (hourlD-peakHourlD).
hourly TVVIM for each such hourlD = weightedTVVIM for peakHourlD
* the residualVaporRatio for the number of hours the hourlD is past the
peakHourlD (hourlD-peakHourlD).
TW-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:
- Hourly TVV 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:
212
-------
An intermediate WeightedMeanBaseRate table
o Keys: yearlD, polProcessID, sourceTypelD, fuelTypelD,
zonelD, monthID, hourDaylD, modelYearlD, opModelD
o Data: WeightedMeanBaseRate
Calculation:
modelYearlD = yearlD - agelD
fuelTypelD = 1 (gasoline) or 5 (E85)
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
For operating and hot soaking modes (opModelDs 300 and 150):
WeightedMeanBaseRate = (meanBaseRatelM * sourceBinActivityFraction
* IMAdjustFract) + (meanBaseRate * sourceBinActivityFraction * (1-
IMAdjustFract))
summed over portions of sourceBinID not needed in the output, namely
regClassID and engTechID.
TW-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
213
-------
= weightedMeanBaseRate * sourceHours * opModeFraction
hourlD = hourDay.hourlD
day ID = hourDay.daylD
statelD = county. statelD
county ID = zone, county ID
pollutantID = PollutantProcessAssoc.pollutantID
processID = PollutantProcessAssoc.processID
roadTypelD = Link.roadTypelD
SCC = null
TW-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.
214
-------
10.33. 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.33.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, DRAFT MOVES2009 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
215
-------
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.33.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 county ID is
present, its corresponding zonelD 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
216
-------
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.
217
-------
10.33.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.
218
-------
10.34. 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. yearlD
e. monthID (May be aggregated out)
f. daylD (May be aggregated out)
g. hourlD (May be aggregated out)
h. statelD
i. county ID
j. zonelD
k. sourceTypelD (May be aggregated out)
1. fuelTypelD (May be aggregated out)
m. modelYearlD (May be aggregated out)
n. roadTypelD
o. pollutantID
p. processID (May be aggregated out)
q. averageSpeedBinID (as determined through joins with the LinkAverageSpeed
Table)
r. temperature (as determined through j oins with the ZoneMonthHour table)
s. humidity (as determined through joins with the ZoneMonthHour table)
t. emissionRate (MOVESMesoscaleOutput.emissionQuant divided by
MOVESMesoscalActivityOutput.activity (for all activityTypeID=l records).
"Zero" miles for any link leads to divide-by-zero errors. In such cases there
are no emissions reported.
219
-------
10.35. 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
DecodeMovesOutput. sql
TabbedOutput.sql
Function
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.
Produces tab-delimitted output file versions of the
MOVESRun, MOVESActivityOutput, and
220
-------
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.
221
-------
10.36. 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 "post-
processing" function which makes it easy to produce various reports summarizing this
information. Several of the organizations which commented formally on DRAFT
MOVES2009 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
222
-------
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
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.
223
-------
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.
Report output is produced in the directory containing the output database.
Additional Information:
224
-------
The Summary Reporter is covered from a GUI perspective in the DRAFTMOVES2009
User Guide.
225
-------
10.37. GREET Model Interface
The GREET Model Interface is not operational in the version of DRAFT
MOVES2009. We are working with the authors of GREET to restore this function in
future versions of MOVES. This section describes how the interace functions in DRAFT
MOVES2009.
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.37.1 DRAFT MOVES2009 GREET Interface Functionality:
1. If requested in the RunSpec, DRAFT MOVES2009 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. DRAFT MOVES2009 offers a "preprocessing" menu option to "Update Well-To-
Pump" factors. When this menu option is selected DRAFT MOVES2009 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. DRAFT MOVES2009 then executes the GREET GUI described below.
4. When control is returned, DRAFT MOVES2009 receives a tab-separated variable,
well-to-pump 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 DRAFT MOVES2009 model runs.
5. DRAFT MOVES2009 interacts with the GREET GUI, which in turn invokes the
GREET spreadsheet model. DRAFT MOVES2009 does not interact directly with the
GREET spreadsheet model, only with the GREET GUI.
10.37.2. GREET and GREET GUI Functionality
The design of the interface between DRAFT MOVES2009 and GREET is based upon the
following functional characteristics of GREET.
226
-------
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 DRAFT MOVES2009 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
Ethanol
Methanol
Gaseous H2
Liquid H2
227
-------
Electricity
6. The GREET GUI, while not itself written in Java, can be run from a Java program, i.e.
DRAFT MOVES2009. 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 DRAFT MOVES2009, 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 DRAFT MOVES2009 Calendar
YearlDs, 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
fuel Subtypes). 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
DRAFT MOVES2009. The table of well-to-pump emission factors is described in
the next section.
10.37.3. GREET Well-to-Pump Emission Factor Result Table:
This table is a tab-separated variable ASCII text file and contains the following
fields:
a. pollutanflD (an Integer from the set of values used in DRAFT MOVES2009)
b. fuelSubtypelD (an Integer from the set of values used in DRAFT
MOVES2009)
228
-------
c. yearlD (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, fuelSubtypelD and yearlD are as defined in the
MOVESDefault database schema.
229
-------
10.38 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 DRAFT
MOVES2009 .
The two tables contain identical fields, except that the opModelD 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
polProcessID
opModelD (present in short
Description
Pollutant / Process ID
50 1 = CH4 running
502 = CH4 start
60 1=N2O running
602 = N2O start
9101 = total energy running
9102 = total energy start
9190 = total energy start
Operating Mode ID
230
-------
term table only)
targetFuelTypelD
targetEngTechID
targetModelYearGroupID
fuelTypelD
engTecMD
modelYearGroupID
fuelEngAdjust
dataSourcelD
0-36 = running VSP/speed modes (total energy only)
200 = start mode
300 = running mode (CH4 and N2O)
Type of fuel:
1 = Gasoline
2 = Diesel
3 = CNG
4 = LPG
5 = E85
6 = M85
7 = Gaseous Hydrogen
8 = Liquid Hydrogen
9 = Electricity
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 1C hybrid)
21 = Moderate Hybrid AIC
22 = Full Hybrid AIC
30 = Electric
40 = Fuel Cell
50 = Hybrid Fuel Cell
Model Year Group ID
200 120 10 = 2001 thru 20 10
20 112020 = 20 11 thru 2020
202 12050 = 2021 thru 2050
Base fuel type ID (same as targetFuelTypelD)
Base engine technology ID (same as targetEngTech ID)
Base model year group ID (same as targetModelYearGroupID)
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
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. opModelD
c. targetFuelTypelD
d. targetEngTechID
e. targetModelYearGroupID
f. dataSourcelD
231
-------
2. fields describing the base technology emission rates to which the adjustment
is applied
a. polProcessID
b. opModelD
c. fuelTypelD
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 opModelD contained in the base
records are carried into the future emission rates produced, as are the values of
regClassID, engSizelD and weightClassID implicit in the base record sourceBinlDs.
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.
232
-------
Output produced:
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 dataSourcelDs less than
5000. For each such record with matching values of polProcessID, opModelD,
fuelTypelD, engTechID, and modelYearGroupID a short term future emission rate record
is generated having the targetFuelTypelD, targetEngTechID, targetModelYearGroupID
and new dataSourcelD (while retaining the prior values of polProcessID, opModelD,
regClassID, engSizelD, 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 dataSourcelDs 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, fuelTypelD, engTechID, and
modelYearGroupID a long term future emission rate record is created having the
targetFuelTypelD, targetEngTechID, targetModelYearGroupID, and new dataSourcelD
(while retaining the prior values of polprocessID, opmodelD, regClassID, engSizelD, 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
dataSourcelD less than 5000. The MOVESDefault database distributed with DRAFT
MOVES2009 satisfies this condition.
233
-------
10.39 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 DRAFTMOVES2009 User Guide.
234
-------
10.40 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.
DRAFT MOVES2009 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.
235
-------
The temperature adjustment terms in the Temperature Adjustment and
StartTempAdjustment tables.
The "full AC adjustment factor" in the Full AC Adjustment table.
The fuel adjustment factor in the Fuel Adjustment 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.
236
-------
Specifically, if Z is a pseudo-random sample from the normal distribution with
mean 0.0 and unit standard deviation, then:
sampledMean Value [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.
237
-------
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 xfs are the results of each iteration, and
n is the number of iterations.
emissionQuantMean =
i=\
n
-n* (emissionQuantMean)2
77-1
Sigma — V VCW (the positive square root)
238
-------
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.
10.41. Retrofit Strategy
The MOVES Retrofit Strategy implements a control strategy for on-road vehicle
retrofit modeling. It allows the user to select a portion of the overall fleet, and reduce its
emission rates by a selected percentage. This section of the SDRM contains a definition
sub-section that describes the major retrofit variables, and discusses the retrofit
conditional rules. A subsequent section describes the retrofit algorithm.
10.41.1 Definition of Variables
Initial Calendar Year of Retrofit Implementation - The Initial Calendar Year of the
Retrofit Implementation is the first calendar year that a retrofit program is administered.
A valid Initial Calendar Year input must be equal to or less than the Final Calendar Year
of Retrofit Implementation. Initial Retrofit Calendar Year entries that are greater than the
MOVES evaluation calendar year are to be ignored. All months within a calendar year
are affected equally by the retrofit.
Final Calendar Year of Retrofit Implementation - The Final Calendar Year of the
Retrofit Implementation is the last calendar year that a retrofit program is administered.
Final Calendar Year input must be equal to or greater than Initial Calendar Year of
Retrofit Implementation.
239
-------
Initial Model Year that will be Retrofit - The Initial Model Year that will be retrofit is
the first model year of coverage for a particular vehicle class / pollutant combination.
Valid entries for initial model year must meet the following requirement:
Initial Model Year >= Initial Calendar Year - 30
Also, the Initial Model Year cannot be greater than the Final Model Year that will
be Retrofit.
Final Model Year that will be Retrofit - The Final Model Year that will be retrofit is the
last model year of coverage for a particular vehicle class / pollutant combination. No
retrofit shall be performed on Final Model Year inputs which are greater than the
Evaluation Calendar Year. Also, the Final Model Year input cannot be less than the
Initial Model Year that will be Retrofit.
Percentage of the Fleet Retrofit per Year - The Percentage of the Fleet Retrofit per Year
represents the percentage of VMT of a particular fleet of a particular vehicle class,
retrofit calendar year group, model year group and pollutant combination that is to be
rebuilt in a given calendar year. Only values greater than zero and less than or equal to
100.0% are valid. MOVES also checks to insure that the product of the number of
calendar years of retrofit coverage (Final Calendar Year of Retrofit Implementation -
Initial Calendar Year of Retrofit Implementation) times the Percentage of the Fleet
Retrofit per Year does not exceed 100%. For example, a retrofit simulation is flagged as
invalid if it had a retrofit program start in calendar year 2005, a program end in calendar
year 2008, and a yearly Fleet Retrofit Percentage of 50 percent (3 times 50% > 100%).
Percentage Effectiveness of the Retrofit - The Percentage Effectiveness of the Retrofit is
the percent emission reduction achieved by a retrofit. It is computed from a non retrofit
240
-------
emission baseline. The file input structure allows the user to enter a retrofit effectiveness
value for a particular vehicle class, retrofit calendar year group, model year group and
pollutant combination. All values up to 100% are valid. A negative value is permitted
because it implies an emission increase as a result of retrofit which sometimes occurs. A
value greater than 100% is not permitted because it implies negative emissions will be
generated.
10.41.2 Retrofit Algorithm
The general form of the retrofit algorithm is shown below. Retrofit Emis is the emission
rate after a retrofit. Base Emis is the emission rate without retrofit.
Retrofit Emis = [ (%Retrofitl*(l-RetrofitEffectivenessl)) +
(%Retrofit2*(l-Retrofit Effectiveness2)) ... + ... (%Retrofit (i) *(l-Retrofit
Effectiveness(i))) + (1- %Retrofitl -%Retrofit2 ....... %Retrofit (i)) ] * Base Emis
Where
%Retrofitl + %Retrofit2 ... + %Retrofit(i) <= 100%
i < 29 in %Retrofit(i)
11. DRAFT MOVES2009 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
241
-------
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. DRAFT MOVES2009 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 DRAFT MOVES2009 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).
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 (statelD, countylD, hourlD, sourceTypelD, 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."
242
-------
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
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
243
-------
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 sourceTypelDs 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.
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)
244
-------
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
AgeCategory
AgeGroup
AverageTankGasoline
AverageTankTemperature
AvgSpeedBin
AvgSpeedDistribution
Type
CVL
CVL
CMIT
CMIT
CVL
INF
DIST
Function /Description
Defines the valid age categories
of SourceUseTypes. ageID=0
represents new vehicles;
ageID=30 represents vehicles
30 years old or older.
modelyearID=calendarYearID-
agelD
Defines the valid age groups, a
single set of which is used for
all pollutant-processes.
The gasoline in the fuel tanks of
gasoline-fueled vehicles.
Allows modeling of mixtures of
fuel formulations from the fuel
supply.
Temperature of the fuel in the
tanks of vehicles.
Defines the average speed bins.
Distribution of time spent in
Writers
TFG
TTG
Readers
(as DIST,
CMIT or
INF)
EvapEC
EvapEC
LTLP
TAG
OMDG
TAG
245
-------
ColdSoaklnitialHourFraction
ColdSoakTankTemperature
County
CountyYear
CumTWCoeffs
DataSource
DayOfAnyWeek
DayVMTFraction
Drive Schedule
Drive Schedule Assoc
DriveScheduleSecond
EmissionProcess
EmissionRate
CMIT
DIST
CMIT
CVL
INF
ASSOC
INF
INF
CVL
DIST
CVL
INF
ASSOC
INF
INF
CVL
INF
average speed bins, by source
type, roadtype, hour and day.
The fraction of cold soaking in
each hour-day that began in
each hour, by source type, zone
and month.
Temperature of the fuel in tanks
of cold-soaking vehicles, by
zone, month, and hour
Establishes the set of counties.
Counties belong to states, but
their IDs, based on FIPS state
and county codes, are globally
unique.
Associates years with counties
Terms used to calculate tank
vapor vented from tank vapor
generated. Somewhat
analogous to emission rates by
age for TW process. Stored
by regClass, modelYearGroup,
and ageGroup.
Metadata for emission rate
records.
Establishes set of day IDs which
identify a kind of day of the
week.
Distributes VMT for a source
type in a month on a roadtype
to the kinds of days of the
week.
Defines the set of driving
schedules or patterns. Each
schedule has an average speed
information item.
Associates a driving schedule
with a combination of source
type and road type. Also
indicates whether schedule is a
ramp schedule.
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".
Establish the set of emission
processes.
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, opModelD, and
TTG
TTG
OMDG
EvapEC
TTG
EvapEC
METG
EC
EvapEC
EvapEC
TAG
OMDG
OMDG
OMDG
EC
246
-------
EmissionRateByAge
EngineSize
EngineTech
ExtendedldleHours
FuelAdjustment
FuelEngFraction
FuelEngTechAssoc
FuelFormulation
FuelModelYearGroup
FuelSubType
FuelSupply
FuelSupplyYear
FuelType
FullACAdjustment
INF
CVL
CVL
CMIT
INF
DIST
ASSOC
CVL
INF
CVL
CVL
INF
DIST
CVL
CVL
INF
INF
sourceBinID
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, opModelD,
sourceBinID, and agelD
Establishes the set of engSizelD
values.
Establishes the set of
engTechID values.
Stores total activity for
extended idling process.
Geographic unit is the zone.
Stores multiplicative emission
result adjustment factors to
account for fuel effects by
polProcessID, sourceTypelD,
fuel model year groups, and
fuel formulation.
Distributes sourceType -
modelYear combinations to
fuelType - engine technology
combinations.
Established the combinations of
fuelType and engTech that are
valid for each sourceType.
Establishes the set of fuel
formulations. Stores their fuel
characteristics.
Establishes the model year
groupings relevant to vehicle
fuel effects upon emissions
Establishes the set of fuel
subtypes. Stores information
about them.
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.
List of valid fuel supply years.
List of valid fuel types.
Stores "fullACAdjustment"
factors by source type,
pollutant-process, and operating
mode. Missing values mean no
TAG
AVFT
EC
EvapEC
EC
EC
EvapEC
AVFT
SBDG
AVFT (GUI
portion)
TFG
EC
ChainEC
EC
ChainEC
TFG
EC
ChainEC
EvapEC
EC
ChainEC
EvapEC
EC
247
-------
GREETManfAndDisposal
GREETWellToPump
Grid
GridZoneAssoc
HourDay
HourOfAnyDay
HourVMTFraction
HPMSVtype
HPMSVtypeYear
IMCoverage
Link
LinkAverageSpeed
LinkHourVMTFraction
ModelYear
ModelYearGroup
INF
INF
CVL
ASSOC
CVL
ASSOC
CVL
DIST
CVL
INF
INF
CVL
INF
INF
CVL
CVL
adjustment.
Placeholder table for emission
processes not yet implemented.
Contains emission rates for the
Well-to-Pump process by year,
pollutant, and fuel subtype.
Placeholder table to reprent grid
cells.
Placeholder table to associate
grid cells with zones.
Exists only because of database
design considerations.
Associates all hours of the day
with all kinds of days of the
week.
Lists valid hourlDs. hourID=l
represents the hour beginning at
midnight.
Allocates the VMT for a
sourceTypelD-roadTypelD-
daylD combination to the hours
of the day
List of valid vehicle types as
classified by the Highway
Performance Management
System
Stores VMT data for base years
and VMT growth factors for all
years
Information about the existence
and effectiveness of vehicle I/M
programs. Stored by county,
year, pollutant-process, fuel
type, regulatory class, and
range of modelyears. Missing
data means no I/M.
Establishes the linkID values
and relates Links to Counties,
Zones, and Roadtypes. Its
informational data items are not
currently used.
Stores average speed
information for a Link. Used
for Mesoscale Lookup
Not yet used, a placeholder
table, intended for smaller scale
modeling
Simply lists the valid
modelYearlDs
Lists the modelYearGroupIds.
Establishes a short form for
(May be
written by
GREET
Interface)
(may be
modified by
IMCoverage
table editor)
LTLP
LTLP
(not used)
ChainEC
(not used)
(not used)
TAG
TAG
EC
EvapEC
TAG
(Mesoscale
lookup)
OMDG
(Mesoscale
lookup)
(not used)
248
-------
MonthGroupHour
MonthGroupOf Any Year
MonthOf Any Year
MonthVMTFraction
OperatingMode
OpModeDistribution
OpModePolProcAssoc
Pollutant
PollutantDisplayGroup
PollutantProcessAssoc
PollutantProcessModelYear
RegClassFraction
RegulatoryClass
RoadType
RoadTypeDistribution
Sample VehicleDay
INF
CVL
CVL
INF
CVL
INF
CMIT
DIST
ASSOC
CVL
INF
CVL
INF
ASSOC
ASSOC
DIST
CVL
CVL
INF
DIST
CVL
INF
embedding these in
sourceBinlDs
Stores terms used to calculate
AC activity
Establishes month groups,
which currently are individual
months. Would allow fuel-
related info to be stored more
coarsely.
Establishes the set of monthID
values. Relates months to
month groups.
Allocates annual VMT to
months. Allocation is by
sourceTypelD.
Establishes the opModelDs.
Stores operating mode
distributions for several
operating mode distribution
generators
Associates operating modes
with pollutant-processes.
Lists the pollutants calculated
by the model, along with
information item(s) pertaining
to them.
Used by the MOVES GUI in
constructing the pollutant-
processes screen.
Establishes the combinations of
pollutant and process which the
model calculates
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.
Distributes elements of
FuelEngFraction distributions
by Regulatory Class
Establishes the set of
RegClassIDs.
Establishes the set of
roadTypelDs. Indicates
fraction of SHO on each driven
on ramps.
Distributes VMT, by
sourceType, to roadTypes
Establishes the set of vehicles
sampled for each kind of day.
Indicates the source type of
each sample vehicle.
OMDG
StartOMDG
EvapOMDG
AVFT
EC
TAG
OMDG
StartOMDG
EC
EvapEC
ChainedEC
SBDG
OMDG
TAG
TAG
TTG
249
-------
Sample VehicleTrip
sec
SCCProcess
SCCRoadtype
SCCRoadTypeDistribution
SCCVtype
SCCVtypeDistribution
SHO
SHP
SizeWeightFraction
SoakActivityFraction
SourceBin
SourceBinDistribution
SourceHours
SourceTypeAge
SourceTypeAgeDistribution
INF
CVL
CVL
CVL
DIST
CVL
DIST
CMIT
CMIT
DIST
CMIT
DIST
CMIT
CVL
CMIT
DIST
CMIT
INF
DIST
Contains data about each trip
made by the sample vehicles.
List of valid highway SCCs.
Decomposes this composite
code into its component parts.
List of process codes embedded
in SCCs
List of road classifications
embedded in SCCs
Distributes activity on each
roadtype in a zone to the
SCCRoadtypes
List of vehicle classifications
embedded in SCCs
Distribution activity within a
sourceTypelD, modelYearlD,
and fuelTypelD to
SCCVtypelDs
Stores source hours operating
total activity and distance
traveled. Geographically these
are stored by Link.
Stores source hours parked.
Distributions elements of
FuelEngFraction distributions
by engine size and vehicle
weight.
Distributes hours of parking
into hot soaking and cold
soaking
Lists the sourceBins that used
in SourceBinDistributions.
Forms an association among the
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.
Stores source bin distributions,
which allocate total activity to
source bins.
Store source hours (all hours in
which the source type exists,
equal to SHO plus SHP) total
activity. Geographicly these
are stored by Link.
Stores information items which
depend only upon
sourceTypelD and agelD
Allocates source type
population in each year to
vehicle agelDs
TAG
AVFT
TTG
SBDG
SBDG
TAG
TAG
TTG
StartOMDG
EC
EvapEC
EC
EvapEC
TAG
????
SBDG
EvapOMDG
EC
EvapEC
EC
EvapEC
EvapOMDG
EvapEC
TAG
EC
TAG
250
-------
SourceTypeHour
SourceTypeModelYear
SourceTypeModelYearGroup
SourceTypePolProcess
SourceTypeYear
SourceUseType
Starts
StartsPerVehicle
StartTempAdjustment
State
SulfateEmissionRate
TankTemperatureGroup
TankTemperatureRise
TankVaporGenCoeffs
TemperatureAdjustment
INF
CVL
INF
INF
ASSOC
ASSOC
INF
INF
CVL
INF
CMIT
CMIT
INF
CVL
INF
CVL
INF
INF
INF
Stores activity information
pertinent to a sourceTypelD
during each hourDaylD,
currently idleSHOFactor.
Establishes combined IDs for
combinations of sourceTypelD
and modelYearlD. Stores
information that depends only
on these two factors, currently
ACPenetrationFraction.
Associates
TankTemperatureGroups with
combinations of sourceTypelD
and modelYearGroupID
Establishes which combinations
of sourceTypelD and
polProcessID require source bin
distributions. For such
combinatations indicates which
source bin discriminators are to
be considered in the source bin
distributions.
Store vehicle population for
base year, sales growth and
migration rate information for
other years
Establishes the set of
sourceTypelD values. Relates
sourceTypelD s to HPMS
vehicle types. Stores items
depending only on
sourceTypelD
Stores total number of starts
activity. Geographically this is
stored by Zone.
Stores number of starts per
vehicle for each sourceType
and hour on each kind of day
Stores factors used to calculate
temperature adjustments for
certain pollutant-processes
Defines the set of statelD
values used in the database
Stores "rates" used to calculate
sulfate paniculate emissions
based on energy consumption
Defines the set of tank
temperature groups
Stores coefficients for the
equation used to calculate tank
temperature rise.
Store coefficients for the
equation used to calculate fuel
tank vapor generation
Stores factors used to calculate
TAG
TAG
TAG
EC
TTG
EvapEC
SBDG
TAG
OMDG
EC
TAG
EC
ChainedEC
TTG
EvapEC
EC
251
-------
WeightClass
Year
Zone
ZoneMonthHour
ZoneRoadType
CVL
CVL
INF
CVL
DIST
INF
DIST
temperature adjustments for
certain pollutant-processes
Establishes the set of weightID
values.
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".
Establishes the set of zonelDs.
Relates zones to counties.
Stores information depending
only on zonelD, currently
several activity allocation
factors.
Stores information depending
only upon zonelD, monthID,
and hourlD, currently
meteorogy-related items.
Stores information depending
only upon zonelD and
roadTypelD, currently SHO
allocation factors
METG
EvapEC
TAG
EC
ChainedEC
EvapEC
TAG
METG
TTG
TFG
EC
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
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.
252
-------
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.
253
-------
12. DRAFT MOVES2009 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 DRAFTMOVES2009 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 tab-separated 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 DRAFT MOVES2009 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 DRAFT MOVES2009 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 DRAFT
MOVES2009 User Guide.
254
-------
The results of multiple runs may be stored in the same database and are identified
by MOVESRunlD. This database consists of six tables as shown in Figure 12-1.
Figure 12-1. Tables in Output Database
MOVESEmy
&" D
b.,nd'eCc'jnl
r
MCy'/EER^n
1
MOVES=FD-D
vearlMFKi
'"io-:- D ;F«"i
-cu'ic:-'.;
slate DiFKi
ro-ntjrtC :--.;
crccess D i'F*-' i
erroryessage
r
<
S-are---'d51
yiea-B
iron:1-, C
S-.3S D
£r&j
rhmth
TTT
MJVESTabesJses
MCVESRuniD(=V<:i
daiaFil&Size
dxaFileModificat onDate
table JseSequence
MCV-SLcckupCXteut
lk'GVESRunlp(=Ki
iteratiiyJ3(FKi
y-earlC :-<;
rronlhlC ;FK;
daylD |FK«
ccurcy 3jF'i
zcnelt IF'-C)
scurceTypelC :~K'i
f-erypelc :F<;
ircdelYea' D i FK'i
'
po utant D I'FK'i
prosesaO sFK;
augSs€ed3in!C
temperattre
reH jii :ih
enisscnRace
~l
hole: Th,-s table is
only Drodueed -"or
Mesocale Lookup
Runs
yfcS-Cut
tera:.:n DiFh i
yea-D.F'j
-!rP^V
»*^:>F=;
Z0r€ Jf" 1
LeType'DiF-i
rx>:elYear'2':FK
'cad vpeIC -H ;
3:1 ii-ry~;.pelC 'r' ;
a-l 'l .•/
^
KOMSS:D
•&— -
•iBi
1
1
4
1
* *
MCVESOino..!
f
^j*
+f=3$
jnkAr»:SCC
'
[
nND
=rc
y=a'rlCA=K;
iot/ D iFKi
zcneifc :r-::
JnhDiFK;
pro;es5.3iFK:
s.:"jrte~>pelC ;--.;
•'-erypelj;-Kv
nrcde res- D . F- I
3CC :"". ;
IriScng:^;
;,^areoFe'c53
^eh
-6h
:e-3tcnlC
50-
'^
•>>-,
Ta
TO
e VT* .<
Tvre-D
IP
•vear C
ypeD
255
-------
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.
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 masterComputerIP 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.
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
256
-------
messages. Currently "warning-level" and "error level" messages are written to this file,
and "informational level" messages are not.
The MOVESErrorlD 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 DRAFT MOVES2009.
12.3. The MOVESActivityOutput, MOVESOutput,
MOVESMesoscalActivityOutput and MOVESMesoscaleOutput Tables
These four tables contain the substantive results of each model run. All four
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. The MOVESOutputTable is used to report
the pollutant emission results, including energy consumption. The
MOVESMesoscaleActivityOutput and MOVESMesoscaleOutput tables match the
structure of the MOVESActivityOutput and MOVESOutput tables respectively but are
only populated for runs using the Mesoscale Lookup scale. Such runs require special
indexing that would be a burden on normal MOVES runs and are separated for
performance purposes. The fields of these four tables function as follows:
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 yearlD 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
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.
257
-------
The daylD 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 hourlD 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 statelD 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 county ID 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 statelD 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 county ID
based only on the FIPS states codes are used to represent entire states.
The zonelD field is based on the county ID in the default database distributed with
DRAFT MOVES2009 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 DRAFT MOVES2009 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 sourceTypelD 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
41 Intercity Bus
42 Transit Bus
258
-------
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 fuelTypelD 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 fuelTypelD 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 modelYearlD 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 roadTypelD 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 DRAFT MOVES2009 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.
1 Off-Network
259
-------
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
roadTypelD indicates that the results pertain to all roadway types. Whether to
distinguish results by roadTypelD 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 DRAFT MOVES2009. 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 DRAFT
MOVES2009 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
90 Extended Idle Exhaust
99 Well-to-Pump
260
-------
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 and MOVES
MESOscaleOutput tables 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 emissionOuantMean field is present only in the MOVESOutput and
MOVESMesoscaleOutput tables. 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 and
MOVESMesoscaleOutput tables. 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 activity field is present only in the MOVESActivityOutput and
MOVESMesoscaleActivityOutput tables 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 activityTypelD field is present only in the MOVESActivityOutput and
MOVESMesoscaleActivityOutput tables. It references the Activity Type table which
defines activityTypeID=l as distance.
The activityMean field is present only in the MOVESActivityOutput and
MOVESMesoscaleActivityOutput tables. It is not used in the demonstration version
ofDraftMOVES2009.
The activitySigma field is present only in the MOVESActivityOutput and
MOVESMesoscaleActivityOutput tables. It is not used in the demonstration version
ofDraftMOVES2009.
261
-------
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
1C internal combustion
ID identification
IM inspection/maintenance
kW kiloWatt
LOT 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
DRAFT MOVES2009 The Highway Vehicle Implementation of MOVES
N2O nitrous oxide
NMEVI National Mobile Inventory Model
262
-------
OBD
ODBC
OMDG
OTAQ
PTW
RAM
RTC
SBDG
SCC
SDK
SDRM
SHO
SHP
SQL
SUV
TAG
US
VMT
VOC
VSP
WTP
XML
on board diagnostics
open database connectivity
operating mode distribution generator
Office of Transportation and Air Quality
pump-to-wheel
random access memory
runs to completion
source bin distribution generator
source classification code
software development kit
Software Design and Reference Manual
source hours operating
source hours parked
structured query language
sport utility vehicle
total activity generator
United States
vehicle miles traveled
volatile organic hydrocarbon
vehicle specific power
well-to-pump
extended markup language
263
-------
Appendix B. MOVES Error/Warning Messages
Messages
Adding execution locations for county, [*], failed.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Adding execution locations for link, [*], failed.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Adding execution locations for state, [*], failed.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Adding execution locations for the nation failed.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Adding execution locations for zone, [*], failed.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
All data is not yet ready to be exported. [*]
The selected internal control strategy is not ready to export its data. Check
the strategy's GUI to resolve any errors before exporting.
An EmissionCalculator encountered an SQL exception while
exporting data using:
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
An SQL exception occurred while adding execution locations.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
An SQL exception occurred while building execution indexes.
264
-------
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
An SQL exception occurred while building mesoscale lookup links.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
An SQL exception occurred while building the runspec filter sets.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
An SQL exception occurred while building the runspec filter tables.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Copy table, [*],Jrom source database failed.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not build TTGeMinutes table.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not calculate average speeds
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not calculate Engine Power Distribution.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not calculate operating mode distributions
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not check driveScheduleSecondLink
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
265
-------
MOVES.
Could not create hot soak and operating temperature tables.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not create unique vehicle IDs.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not delete Project Total Activity data.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not delete Total Activity data from previous run.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine average tank temperature.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine brackets for Average Speed Bins.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine cold soak fractions.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine cold soak tank temperature.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine Evaporative Emissions Operating Mode
Distribution.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
266
-------
Could not determine final Operating Mode Distribution.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine Jr action of drive schedules in each speed bin.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine Jr actions of Operating Modes per Drive
Schedule
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine hot soak temperatures.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine operating mode for sample vehicle trips.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine operating modejraction.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine Operating Mode ID distribution.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine soak activity fraction.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine soak times for sample vehicle trips.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
267
-------
Could not determine the distribution of drive schedules for non ramp
drive cycle.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not determine the distribution of drive schedules for ramp
drive cycle.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not do link operating mode setup
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not do TFG sql.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not flag marker trips
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Could not load InternalControlStrategy text
The RunSpec file is corrupt, likely due to a typo.
Could not load InternalControlStrategy XML.
The RunSpec file is corrupt, likely due to a typo.
Could not load runspec XML.
The RunSpec file is corrupt, likely due to a typo.
Could not remove Source Bin Distribution data from previous run.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
DROP TABLE failed
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Error removing generated data from the execution database.
268
-------
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Exception occurred on 'randomizeTableData' [*] using
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Failed to get monthlDfrom MonthOJAnyYear urith:
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Failed to update MOVESRun.minutesDuration
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Get list of years failed
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
IMGUI countyName= =null, countyID=
The I/M display could not find required human-readable details for an
I/M program in the database.
IMGUIJuelName==null,fuelTypeID=
The I/M display could not find required human-readable details for an
I/M program in the database.
IMGUI inspectFreqName==null, inspectFreq=
The I/M display could not find required human-readable details for an
I/M program in the database.
IMGUI null text for display line
The I/M display could not find required human-readable details for an
I/M program in the database.
IMGUI pollutantName==null, polProcessID=
The I/M display could not find required human-readable details for an
I/M program in the database.
IMGUI processName==null, polProcessID=
The I/M display could not find required human-readable details for an
I/M program in the database.
269
-------
IMGUI regClassName==null, regClassID=
The I/M display could not find required human-readable details for an
I/M program in the database.
IMGUI testStandardsName==null, testStandardsID=
The I/M display could not find required human-readable details for an
I/M program in the database.
IMGUI testTypeName==null, testTypeID=
The I/M display could not find required human-readable details for an
I/M program in the database.
InternalControlStrategy failed to load
The RunSpec file is corrupt, likely due to a typo.
Invalid class name entry
The RunSpec file is corrupt, likely due to a typo.
Invalid DatabaseSelection
The RunSpec file is corrupt, likely due to a typo.
Invalid Generic County.
The RunSpec file is corrupt, likely due to a typo.
Invalid GeographicOutputDetail
The RunSpec file is corrupt, likely due to a typo.
Invalid GeographicSelection.
The RunSpec file is corrupt, likely due to a typo.
Invalid HydrocarbonUnitSystem
The RunSpec file is corrupt, likely due to a typo.
Invalid InputDatabase
The RunSpec file is corrupt, likely due to a typo.
Invalid InternalControlStrategy
The RunSpec file is corrupt, likely due to a typo.
Invalid InternalControlStrategy XML file.
The RunSpec file is corrupt, likely due to a typo.
Invalid ModelDomain
The RunSpec file is corrupt, likely due to a typo.
Invalid ModelScale
270
-------
The RunSpec file is corrupt, likely due to a typo.
Invalid OJfRoadVehicleSCC
The RunSpec file is corrupt, likely due to a typo.
Invalid OJfRoadVehicleSelection
The RunSpec file is corrupt, likely due to a typo.
Invalid OnRoadVehicleSelection
The RunSpec file is corrupt, likely due to a typo.
Invalid OutputDatabase
The RunSpec file is corrupt, likely due to a typo.
Invalid OutputEmissionsBreakdoivnSelection
The RunSpec file is corrupt, likely due to a typo.
Invalid OutputFactors
The RunSpec file is corrupt, likely due to a typo.
Invalid OutputTimeStep
The RunSpec file is corrupt, likely due to a typo.
Invalid PMSize
The RunSpec file is corrupt, likely due to a typo.
Invalid PollutantProcessAssotiation
The RunSpec file is corrupt, likely due to a typo.
Invalid RoadType
The RunSpec file is corrupt, likely due to a typo.
Invalid RunSpec XML file.
The RunSpec file is corrupt, likely due to a typo.
Invalid ScalelnputDatabase
The RunSpec file is corrupt, likely due to a typo.
Invalid timing on request/or instantiated object [name]
This internal error can occur if user-modified Java code calls
MOVESInstantiator.didlnstantiateQ out of the proper sequence.
Invalid UncertaintyParameter
The RunSpec file is corrupt, likely due to a typo.
Loading a list of runs for the MOVES Error Log failed.
An error occurred while working with a database. The database could
271
-------
have become unavailable or could have been modified externally from
MOVES.
loading counties failed
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
loading lookup table failed
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
loading pollutantProcessMap failed
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
loading reverse lookup table failed
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Missing parameter i=
The RunSpec file is corrupt, likely due to a typo.
Only one object per RunSpec is allowed for this type
For some internal control strategies, the AVFT for instance, it only makes
sense to have at most one of them per RunSpec.
Replace into table, [*],from source database failed.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Road type ID, [*], with name, '[*]', was not found in the default
database.
The RunSpec file is corrupt, likely due to a typo.
Run specification must contain pollutant-process, county, year, and
vehicle-Juel type selections for an IMCoverage report to be produced.
MOVES could not generate the list of I/M coverage records that apply to
the current RunSpec because the RunSpec lacks selections on one or more
required screens.
Since only one object per RunSpec is allowedfor this type, importing
a new one will overwrite this object. Do you really want to do this?
272
-------
For some internal control strategies, the AVFT for instance, it only makes
sense to have at most one of them per RunSpec.
SQL error in FER Adjustment File Loading
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
SQL error in heat index.calculation
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Table model unable to select
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Table name is NULL for the query :
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
The selectedfile does not contain this type of object, it has not been
loaded.
MOVES could not find the requested internal control strategy object
within the file you selected.
TTG could not access SoakActivityFractions
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to apply new FuelEngFraction
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to calculate FuelEng Fraction
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to calculate model year range needed
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
273
-------
Unable to calculate RegClassFraction
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to calculate SCCVTypeDistribution
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to calculate SizeWeightFraction
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to check for county domain data
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to check missing emission rates:
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to count operating modes for polProcessID = [*].
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to create InternalControlStrategy
While setting up a requested internal control strategy, an error occurred.
This is likely a case of a RunSpec that requests an internal control strategy
that is not compiled into this machine's MOVES.
Unable to create MOVESLookupOutput table
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to create temporary summary tables
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to delete EE Operating Mode Distribution data
274
-------
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to delete from database
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to delete Operating Mode Distribution data from a previous
run
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to delete Start Operating Mode Distribution data from a
previous run
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to delete tank fuel data from a previous run
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to delete tank temperature data from a previous run
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to do AVFT diagnostics
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to fill lookup array
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to fill lookup arrays
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to finalize MOVESEventLog
275
-------
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to find user inputs for ColdSoaklnitialHourFraction
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to get database info for Pollutant Process Association where
polProcessID =
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to get database key for Pollutant Process Association where
Process ID = [*] and Pollutant ID = [*].
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to get SHO count in ECC
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to get single opModelD for polProcessID = [*].
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to learn Create Table statements
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to loadATRatio entries
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to load columns in StateCountyMapGUI using
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to load HC entries
276
-------
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to load tables in StateCountyMapGUI using
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to lookup retrofit abbreviation
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to open hot soak cursor
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to open SVTH cursor
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to perform Source Bin Distribution for pollutant/process,[ *]/
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to process exported file contents
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to process work file contents
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to query PollutantProcessAssoc
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to save CMITs
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
277
-------
MOVES.
Unable to save XML for InternalControlStrategy
The RunSpec file is corrupt, likely due to a typo.
Unable to save XML.
The RunSpec could not be saved. This often happens if the file is already
open in a text editor.
Unable to store table tracking details
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to update database
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to update MOVESWorkersUsed
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to urrite error message to output database.
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to urrite start time to MOVESEventLog
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Unable to urrite stop time to MOVESEventLog
An error occurred while working with a database. The database could
have become unavailable or could have been modified externally from
MOVES.
Warning: [SAXXML parser exception]
The RunSpec file is corrupt, likely due to a typo.
278
------- |