Jump to main content.

Motor Vehicle Emission Simulator (MOVES)
Frequently Asked Questions (FAQ)

Mobile6.2 Transition

Q: Are there tools to help ease the transition from MOBILE6.2

A: The U.S. Environmental Protection Agency (EPA) has posted tools to help with the transition form MOBILE6.2 to MOVES. These tools are spreadsheet files that take MOBILE6.2 (or NMIM) formatted inputs such as registration distributions and average speed distributions, and convert them to MOVES format. The conversion processes include mapping schemes for matching MOBILE6.2 vehicles classes to MOVES source types and for matching MOBILE6.2 road types to MOVES road types. The detailed instructions are included in the converter files and the converters automatically perform all the necessary calculations when MOBILE6.2 formatted data are entered.

The converters address almost all of the inputs specified in the MOVES County Data Manager. There are multiple versions of some of the converters to account for differences between MOBILE and NMIM inputs and for differences in the way users may be aggregating vehicle types.

The converters are posted on a web page, Tools for MOVES:

http://www.epa.gov/otaq/models/moves/tools.htm

EPA will post additional tools on this page as they are developed.

top of page

Hardware/Software

Q: Can I install MOVES on a PC Server with Windows Server Standard, copyright 2007 Microsoft Corporation, with 64-bit operating system?

A: MOVES is not a server based product. MOVES2010 is intended for use on a Windows 32/64 bit personal computer only

Q: May we received more information about computer specifications for systems that run MOVES? Our IT department has requested additional information on specifications for new computer systems that will make the most efficient use of MOVES software. For example, will MOVES take advantage of multiple processors, multiple cores, or both? Should we buy 32-bit or 64-bit processors? Are there operating systems we should avoid? We are concerned about processing speed. We would appreciate any advice you can provide on the most appropriate hardware/software configuration for the final version of MOVES. Thanks.

A: We recommend:

- Dual-core processor,
- At least 1 GB memory, and
- At least 40 GB storage.

Some other notes:

1) When MOVES runs with multiple computers, it does automated file sharing between master and workers that seems to conflict with many workplaces' firewall protections. Some offices have gotten around this by setting up a separate network that is outside their firewall.

2) The ideal MOVES network will depend on your most common run characteristics, but we think it will often be a single Master computer and 2-5 workers.

Q: What is the minimum and recommended hardware configurations for installing and running MOVES?

A: While MOVES may be able to run on an older machine, you may find that runs take too long and you cannot store results from large runs.

To optimize your processing, you should have a dual-core processor so that your machine does not totally lock up when MOVES is running. You need a fast processor to reduce run time. MOVES runs can take hours, even on our fastest machines. You need lots of RAM. MOVES uses lots of memory when running and using virtual memory slows down the processing. You also need lots of room to store results on your hard drive. Unless you restrict your runs to just summaries, results from MOVES runs can be quite large. Even if you ultimately move the results to other storage media or locations, you need working space on your computer.

The EPA is in the process of obtaining new machines for our own work here. Below is a summary of the specifications we are using for our own machines.

2 Quad Core Xeon processor 2.66 Ghz
4 GB memory
Keyboard with Smart Card Reader and mouse
19" LCD Monitor
80 GB Hard drive
500 GB Hard drive
16x DVD +/- RW
nVidia Quadro FX1700 br 512MB dual DVI graphics card

Slower machines with less memory and disk space will likely still work, but you may have serious limitations of what you can do in a limited time. If you have a choice, select your fastest machines for working with MOVES. If you run a distributed version of MOVES, use your fastest machines for the master and your slower machines for workers.

Q: How will MOVES behave with 64 bit machine? Do I need to do anything to switch MOVES from 32 bit to 64 bit machine. Do any programs or executable file need to change with this update?

A: The MOVES team is aware that older versions of Java (and any software) are likely more prone to attack. We are working continuously to upgrade our code to be compatible with the latest versions of Java and MySQL to take advantage of any patches and other upgrades. The version of MOVES we released at the end of last year will require the installation of newer versions of both Java and MySQL. However, the versions of the software required to run MOVES is not a security issue and should not provide a reason to avoid installing MOVES on any machine.

Older versions of Java can coexist on the same machine with the latest version of Java. Web browsers operating on your machine will use the latest version of Java and will therefore not expose the older Java to attacks. Any other software already installed on your machine will, by default, use the latest installed Java, as well. The MOVES application has special configuration settings to direct the MOVES code to use the proper version of Java. Since the code base that can touch the older Java is restricted to just MOVES, the older Java is not exposed to attack.

The MOVES application only requires localhost access to the MySQL application via TCP/IP, so the firewall on your machine can be set to block access to MySQL from the outside world. Since this limits the code base that can communicate with MySQL to only MOVES (and any other program IT has installed on your computer), MySQL is not exposed to attack.

The MySQL application does not require a web server to be installed and our MOVES installation instructions do not include any directions to do so. MySQL itself is not a web server. Any IT policy about local web servers does not apply to the installation of the MOVES/MySQL application.

Until your IT group has satisfied themselves that installation of the MOVES application, along with Java and MySQL, is not a threat to your computer or their network, you can still ask that MOVES be installed right away on a stand-alone computer to allow you to work with the application as soon as possible.

As of January 2010 the MOVES application became the official (and only) highway mobile source emission model for use in any and all submissions by states and local areas to EPA. This includes State Implementation Plans submissions. A version of MOVES to be use for Conformity analysis will be released in the Spring of 2010. Release of the Draft MOVES2009 application was intended to give states and local areas more time to prepare for using MOVES. Moving forward, it will be important for you to determine how you will get access to the MOVES application to do the necessary work for your state.

Q: Can you provide us a detailed write up with examples to try the running of MOVES model in the recommended Master-Worker setup with a shared work folder. EPA suggests the MOVES model to be run in a multiple computer configuration so that several computers work together to execute the model simulation runs saving considerable time. For lack of any detailed information for this kind of set up, our IT department thinks that it may not work with our existing network environment. We are in the process of procuring 2 PCs with dual-core processors and adequate RAM to try this set up seriously.

A: MOVES has two major components, a "Master" and a "Worker". These two applications communicate solely through text files written to a shared folder on your hard drive, typically

C:\Program Files\MOVESYYYYMMDD\SharedWork

MOVES is designed so that work is bundled in "packets" that can be processed by any worker application, one at a time.

So, to have distributed processing, you only need a folder on a network drive that can be "seen" by more than one computer and that all computers have full access (read, write, create, etc.) to all files in that folder.

In the MOVESYYYYMMDD folder there are two configuration text files: MOVESConfiguration.txt and WorkerConfiguration.txt. Each of these files has a path that tells the Master and the Worker applications where to put files:

sharedDistributedFolderPath = C:\Program Files\MOVESYYYYMMDD\SharedWork

Both the Master and the Worker should have the same path, otherwise the Master will create work bundles and put them in a location that the Worker will not see and no work will be done. To implement distributed processing, you only need to set the shared distributed folder path for both the Master and the Worker to be a folder found on the network that can be seen (with full access) by other computers on the network. The name of the folder does not matter. We usually just call it "SharedWork".

Now you simply install MOVES on computers you wish to include in the processing. Make sure that all of the installations have the same shared distributed folder path for both the Master and the Worker to the folder found on the network.

Decide which computer to use as the Master. Since the Master does the most work, it should be the computer with the most memory and hard drive space and the fastest CPU. Start a worker on each of the other computers you wish to include in the processing using the Worker desktop icon. If you look in the shared distributed folder, you should see a Worker ID file for each computer which is running a worker.

Now start the MOVES application on the Master machine. Once the Master is started, a Master ID file will appear in the shared distributed folder. You can now run the MOVES application on the Master machine as normal, but when the bundles are produced, they will appear in the shared distributed folder on the network. The Worker applications on the other machines will see the bundles, read them and process them. The results of their processing will be placed back in the shared distributed folder on the network to be picked up by the Master application and stored in the output database on the Master machine.

You can watch the creation of "to do" files, "in process" files and "done" files while MOVES is running. When MOVES is complete, the only remaining files in the shared distributed folder on the network will be the Worker and Master ID files.

Features of distributed processing:

Machines running Workers will use most of the available CPU for processing and will be difficult to use for other purposes while processing MOVES bundles from the Master computer.

Q: Why does my RunSpec hang up halfway through job and appear to be dead in the water?

A: Occasionally, MOVES will fail to start the MOVES worker. For a restart, double click on the MOVESWorker.bat file in the MOVESYYYYMMDDfolder to start the MOVES worker file. If a MOVES worker is already running, you will not be able to start a second worker.

top of page

Input - General

Q: What is the purpose of the "year" field in the I/M input database table? I thought the intention was that one set of I/M records could be used for multiple calendar years, but the user guide indicates that the year field is supposed to record the year in which the I/M program applies (presumably, the year being modeled).

A: The yearid is used to indicate the calendar years in which an IM program applies. Compared to Draft MOVES2009, we have simplified the input requirements. Now, the user must input yearID, begmodelyearID, and endmodelyearID. Unless new programs are added, the begmodelyearID can remain the same from one calendar year to the next.

Q: I'm trying to put together a test MOVES run for a county; and, I'm stuck on the fuel distribution. Can you help? With MOBILE6, we used northern tier reformulated gas. When I export the defaults in MOVES (for 2040), I get E10 and diesel, each with a market share of 1 and a market share CV of 0.5. I'm not sure what the latter is, and I don't understand why Reformulated Gasoline (RFG) doesn't show up. Could you give me some advice on how to figure this out? Thanks.

A: The fuelsubtypeID in MOVES is a holdover from earlier vesions of MOVES. When deciding on which fuelformulationID to choose for your area, ignore the fuelsubtype, and instead find a fuel with attributes that most closely matches the fuel used in the county being analyzed.. For current and future RFG, these fuels should have EtOHVolume of 10 (%), sulfurLevel of 30 (ppm), benzeneContent of 0.7 (%Volume) or lower, and RVP of 6.8 (psi) in summer months. If you know more fuel characteristics, such as aromaticContent, etc., you can use these to refine your choice of fuel, as well.

As for the "marketShareCV" field, this is designed to be used if the "Estimate Uncertainty" option is selected on the Output Emission Detail panel (CV stands for coefficient of variation). Since we do not expect users to utilize this function, this field can be set to zero.

Q: Can the MOVES model accommodate registration data files for each individual county?
Or, when creating a custom domain that contains a number of individual counties, would we need to combine the registration data files for each county into one file that represents the entire custom domain?

A: A custom domain is handled similarly to a single county, in that a single age distribution, a single set of temperatures and a single set of average speeds are used. The advantage is the ability to completely define your domain independently from the default county definitions. If you intend to use the Custom Domain to represent multiple counties, then you will have to assume that the various parameters you enter apply equally to all the counties in your domain.

Q: Can we model jurisdictions with different fuel requirements in one custom domain?
We have a number of nonattainment/maintenance areas in our state comprised of counties with different fuel requirements. For example in one area, 11 jurisdictions use RFG and 2 jurisdictions use convention gasoline.

A: One can enter multiple fuel market shares so that all the jurisdictions can be modeled in one custom domain, but the results cannot be disaggregated to see the emissions from the jurisdictions with different fuel formulations.

Q: What is the best methodology to use multiple custom domains to accommodate county-specific registration data and/or fuel requirements?

A: The methodology is fairly simple. Each independent area (county) should be modeled separately with its own run specification and input database using the County Data Manager. You can execute each run specification manually or use the batch mode to execute all of the run specifications at once. The results from each run specification can be routed into the same output database so that the results from each county will be found in the same output tables for easy analysis and aggregation.

Q: Where do I find the SourceTypePopulation table? I have found a sourcetypeagepopulation Table under the MOVESEXECUTION Database, but I am unable to find the template for the SourceTypePopulation table mentioned on page 49 of the MOVES User Guide. Does a template of the table even exist before the population data is imported? As I understand it data could reside an temporary databases, worker, or other system databases, but I should only modify tables and data in my user created scenario specific database. Is there a map for where things are located so I could copy what I want to modify to the scenario specific database? An ERD usually addresses what is in a single database, but MOVES uses more than one database. Is there any trick to navigating the MOVES databases?

A: The template spreadsheet for the SourceTypePopulation table is created by the County Data Manager (CDM) in the Pre-Processing menu.

You have to begin with a run specification using the County Scale option. Once you have a run specification (runspec) that defines the time, location and other run details you can go to the County Data Manager to import your local data. From the CDM you create a database to go with the runspec that will contain all of the data you import using the CDM.

The Source Type Population tab of the CDM has a "Create Template" button that can generate a template for the SourceTypePopulation table that is consistent with your runspec. Be sure to use a file name ending with the XLS extension if you wish to have a spreadsheet template.

Since the template is customized for your runspec, there is no default template for any of these tables. Most of these tables exist in the default database, but the CDM does not alter any tables in the default database. The changes you make are put into the database you created to go with your runspec.

All of the databases (default, CDM, execution and worker) are all stored together in the MySQL\Data folder on your computer. You can easily view these databases and tables using the MySQL Query Browser application that comes with the MOVES installation Installation Suite. The Query Browser also can export tables directly into spreadsheets.

We have not been using MOVES long enough to have developed standard procedures for handling data. However, we recommend keeping data you want to use for specific counties in a series of spreadsheets or workbook. These can be easily copied and edited. When you use the County Data Manager to import the contents of these spreadsheets, be sure to save the results using the XML option in the Tools tab of the CDM. You have to do this saving at the time you enter the data. Once the CDM is closed, the information about the names of the spreadsheets is lost. This will save a script that can be used to update your CDM database using your spreadsheets automatically using a single command line entry. You can then set up a batch file to update several counties at once. Now, if you update the contents of the spreadsheets you can update all of your county databases by invoking a single batch file.

Part of the documentation in the output database created by a MOVES run is the names of any databases used in the run, including the CDM database name.

Q: Why does MOVES not properly handle a large output data file generated by using the Emission Rate option? The computer freezes when the emission rate outputs are to be displayed on the monitor. The MySQL Query Browser also crashes due to the size of the emissions rate file

A: As MOVES can generate huge output files, failures such as these are likely caused by the computer running out of physical resources necessary to complete the task requested. The most common cause is insufficient computer memory. To work around this, try to select subsets of your requested data.

Q: How do I avoid mistakes when a table contains multiple runs? I've noticed that if a table includes output from multiple runs, it is very easy to mistakenly sum them together, thereby drastically increasing emissions.

A: You should always "GROUP BY" MOVESRunID when summing output results.

For example, use "SELECT MOVESRunid, Pollutantid, sum(emissionquant) FROM movesoutput GROUP BY MovesRunid, Pollutantid;"

top of page

Input - I/M

Q: How do I delete extra processes in the I/M Program Coverage Records? I'm struggling a bit with some of the input files for MOVES. In particular, editing/importing/deleting the processes within the I/M Program Coverage Records. I've tried to create that file by just adding the specific OBD Data that we use: Compliance Rate = 96%; Oldest Vehicle Age = 15 years; and Newest Vehicle Age = 0 Years. When I do create a file, then import it in, the data appears. But, the file appears to be quite messy with all of the extra processes (IM240 and the other OBD processes that are not valid here). Also, I cannot delete any of the extra, unusable processes either.

A: The problem is that those records appearing are in the default IMcoverage table, so they cannot be "deleted" by your data entry. The existing records in the default database can only be "ignored". What you can do is: highlight everything; click the "Ignore I/M" button; and, then import the OBD only program with a different program ID from any other the default programs. You will still get a "Warning: Duplicate Active Program ..." message to inform you of what you did, but that is normal and will not affect the results. The "Error" message (having two programs without ignoring the duplicates) will cause problems.

A feature of the way MOVES works is that all user supplied data is simply "added" to the existing default data. This is handy, since it allows you to change a small part of the contents of the MOVES inputs, rather than requiring that all inputs be provided. When the data already has a default value, your inputs replace the default values. However, if you add information (such as I/M program elements), the existing, default information still resides in the input data. This requires you to alter the existing program information (set to ignore) in order not to conflict with your new information. This "feature" is good to keep in mind when dealing with other inputs (such as default fuel information) as well.

Q: Where can I locate the descriptions for IMProgamID codes? Appendix J is titled "MOVES Decoder" and it provides translations for several MOVES codes, however, the IMProgamID is not one of them. Where can I locate the descriptions for IMProgamID codes? I am attempting to adjust the I/M file.

A: The IMProgramID codes are arbitrary numbers and do not have any particular significance. They are used to identify a combination of begModelYearID, endModelYearID, teststandardsID, and inspectFreq (inspection frequency) within a county/year. The IM program attributes may vary in different counties or calendar years even though the same IMProgramID is given. The IMProgramID is used to assign a single value to an IM program so that it can more easily be identified in other tables instead of having to always identify the program by the 4 parameters mentioned earlier. There is some additional information provided in section 2.3.3.4.10 of the MOVES User Guide.

The testStandardsID is the field in the IMCoverage table that defines what type of test is performed by the IM program. The tests associated with each testStandardsID can can be viewed in the MySQL Query Browser using the following query: SELECT * FROM MOVESDB20091221.imteststandards.

top of page

Input - AVFT

Q: Can MOVES model Hybrid-Electronic vehicles?

A: The design of MOVES allows for different vehicle technologies to be included in the fleet with their penetration and performance modeled separately. The intention was to allow us to add in any advanced technology vehicles as needed.

However, EPA has not yet settled on the overall emission and fuel economy impacts of hybrid-electric vehicles, so no default estimate for their performance has yet been included in the model. Once emission and fuel economy estimates are available, they can be easily added to the database and will then become available to the user.

top of page

Input - Fuels

Q: Is MOVES able to model emissions from E85 vehicles,? I am interested in comparing tailpipe emissions from E85 powered vehicles to those of conventional gasoline vehicles. I notice that MOVES2010 includes the option to change the ethanol content of the fuel. What is the source of data for those values? I understand that the EPA has been in the process of measuring the E85 emissions. Would it be possible for me to obtain a copy of that study, or the related data?

A: MOVES2010 is only designed to estimate the effects of ethanol in gasoline up to 10% by volume. We are planning on evaluating recently completed and ongoing studies using E85 this year in order to add an E85 option to the next version of MOVES.

top of page

Input - Road

Q: In the roadway classifications for MOVES2009, is Off - Network meant for driveways, local roads not listed in the travel model network or does it mean centroid connector and intrazonal VMT from the travel model?

A: We have reserved the "off-network" road type to identify all emissions generated by highway mobile sources that do not occur during travel activity. This would include emissions that occur while parked (with the engine off), during engine start (which we assume occurs instantly), and due to vehicle refueling or during extended idle by long-haul diesel trucks (hoteling). None of these processes involve distance.

We assume that all emissions that occur during travel (distance) occur on one of the four roadway types modeled by MOVES. This would include any travel on any non-network roads such as local roads not listed in the travel model network, centroid connectors and intrazonal VMT from the travel model. These non-network roads would be accounted for by their contribution to the average speed distribution provided for each roadway type.

Q: What is the best methodology for doing multiple runs in order to treat local and arterial roadtypes separately? On pages 27 and 28 of the Technical Guidance, sections 3.6.2-3.6.4, there is a discussion of doing multiple runs in order to treat local and arterial roadtypes separately. The other option is to come up with one distribution for restricted road types and one for unrestricted road types. Have you done any sensitivity runs to see what is gained by doing different runs? We are looking at trying to incorporate the speeds for the 12 different roadtypes, using the fraction of VMT from the 12 different roadtypes to come up with distributions of speeds into the various speed bins for restricted (freeways and interstates) and unrestricted roadtypes (arterials and locals).

A: Mathematically, if the distributions supplied are carefully calculated, there should be no difference in the aggregate result if you run each road type separately or combine all road types into the four road types used by MOVES.

Imagine that you had only two road types and that the average speed distribution resulted in a different single average speed for each road type. If you modeled them separately (one average speed) or together (two average speeds with weighted fractions), you would get the same result. This same idea will work for any number of distinct roadway types, since ultimately they will all map into one of the four MOVES road types. The trick is to get the average speed distribution to properly reflect the contribution to the whole from each roadway.

Of course if you require results separately for each roadway type, it will be difficult to manipulate the internal allocations to make sure the output properly reflects the known contribution of each roadway. It may be easier to just model each roadway as a separate run.

top of page

Output

Q: Why are the Summary Reporter results different from the results reported in the database? I have been testing MOVES2010 (actually MOVES20091221), and I have a question for you about value of distance in summary report table vs. that in movesactivityoutput table. I realized that executing "summary report" provides more accurate distance value other than the original distance value shown in either movesactivityoutput or decodedmovesactivityoutput. For example, I got 12,260,000 as a distance from either movesactivityoutput (decodedmovesactivityoutput simply adds descriptions of ID-based values, as you know), while I got 12,260,030 from "summary report" body table.

A: Do we have an official answer for this?

Q: Is something hard-wired into Emission Rate Calculation of MOVES to automatically output emission rates at all speeds? I ran MOVES at the County Scale for Emission Rate Calculation for a single county and imported data through the County Data Manager in the GUI. Most of the data I imported were defaults that I extracted from the MOVES database, but the average speed distribution I edited manually to set all vehicle speeds to 30 mph on unrestricted roads and 60 mph on restricted roads. The fractions corresponding to those speed bins were set to 1, the rest were set to 0. When I looked at the results (which were not intended to examine speed effects), I saw emission rates at every speed bin on all roadways. Is something hard-wired into Emission Rate Calculation of MOVES to automatically output emission rates at all speeds? This is not a problem for us at all; we just won't attempt to limit the number of speeds per roadway type in our work.

A: Yes, this is a feature. Choosing the Emission Rate output will produce emission rates for all average speed bins, even when using the County Data Manager (CDM) which requires the input of average speed distributions. The information in the user supplied average speed distributions are not used by MOVES when generating the emission rates for the average speed bins.

Q: Can you help with an error I received while running the decodedMOVESoutout sql script? Today, I encountered an error message while running your "decodedMOVESoutput.sql" as a GUI-based post-process. My run includes PM2.5 result, which has long pollutantName. The error message is "ERROR: Exception occurred running post-processing scriptcom.mysql.jdbc.MysqlDataTruncation: Data Truncation: Data too long for column 'pollutantName' at row 1". I haven't seen this error before with DRAFTMOVES2009.

A: There are two parts to the solution.

  1. The current script does not delete the existing table. This means that any attempt to change the format of the table at the time of creation will be ignored. You can either drop the table manually (right click on the table in the MySQL Query Browser) or add a line to the DecodeMOVESOutput.sql script that drops the table each time before it is created:
    2. drop table if exists decodedmovesoutput;
  2. Once the old (bad) table is removed, then changing the table creation command will fix the problem. Adjust the size of the pollutantName variable to match the size used in the Pollutant table of the default database:
    3. pollutantName CHAR(50),

Making these two changes should get the script working again for you. The scripts will be updated with the next release of MOVES.

top of page

Files

Q: Can other types of files be stored in the MySQL database folders without causing MySQL errors? For example, can users store the spreadsheet(s) containing county-level input data in the same folder as the county input database?

A: In MYSQL, each table in a database is stored as a set of three files with the following extensions: .frm, .myi and .myd. Generally, MySQL will ignore non-database files contained in the MySQL database folder. You will notice that we keep a folder containing information about the database in a subfolder (ReadMe) of the MySQL database folder.

Q: Can users set up a different path/drive for the MySQL input and output databases? For example, if users wish to direct all files associated with a series of runs to a specific folder (e.g., C:\\PM attainment demonstration runs), what would be required to achieve that? Also, can users set up the MySQL folders on a server other than "localhost", such as an external hard drive?

A: It is not be possible to have MySQL "see" databases in different locations at the same time. This means you cannot have the default database in one location and the input and output databases located elsewhere during a run. However, MySQL will allow you to move database folders into and out of the data folder without complaining and without damage to the data. This means that you can move the results of your runs along with any input databases to another location (or media) and restore them by simply making a copy back to the data folder. This feature of MySQL makes it very easy to make backups and archives of MOVES databases.

You can specify a server other than "localhost" by modifying the "my.ini" file per the instructions found on the MySQL web site. However, we would expect this approach to significantly slow down model runtime due to communication time between devices. EPA does not recommend or support this approach.

Q: Why is the MOVES folder named MOVESYYYYMMDD and not MOVES2010? I downloaded MOVES from the web and installed using the installer I also uninstalled the previous version I had. The installation was really easy - the installer works great! But I noticed that the folder it creates is MOVES20091221 and the version is also listed as MOVES20091221. I understand the need to properly date the version, but it may create confusion for users to install MOVES2010, but see to it referred to as MOVES20091221.

A: Because the versions of MOVES change frequently, it can become confusing as to what version of the program and/or database you are actually using. Therefore, for our production release of MOVES2010, we decided to retain the date naming protocol we use internally during our development activities. If the user moves the cursor to the listed text "MOVES20091221" and stays for about one second, a "tool-tip" "The version of MOVES2010 source code" appears. (see example screen below). This tool-tip helps to explain what "MOVES20091221" means.

top of page

Process

Q: Can you tell me what I might use for long haul combination trucks idle rates in grams per hour? I understand that MOVES doesn't produce idle rates in grams per hour.

A: MOVES does not produce idle emission rates as a separate output, although it is possible (with some difficulty) to force the model to generate output for each operating mode, including idle.

However, extended idling of diesel long haul combination trucks is considered a separate operating mode and has it's own output records both for inventory (in mass units) and for emission rates (in grams per hour).

Q: Where are the two refueling emission processes reported in MOVES? I was expecting to see refueling emissions appear in the rateperdistance lookup table (or perhaps in ratepervehicle), but the two refueling emissions processes are not reported in any of the tables. Am I doing something wrong, or was this an intentional decision for refueling emissions in MOVES?

A: We did not intend that any processes be excluded from the lookup table reports. However, we were able to verify that, at least in the cases we tried, you cannot get emission rate output for the refueling processes.

We will add this to the list of features we might add in future versions of the code.

As a workaround, you can select inventory output with activity output and generate your own emission rate estimates from those values.

top of page

Inner Workings

Q: How does MOVES aggregate information? My issue has to do with the way that MOVES aggregates information depending on the parameters of the runspec. For example, when I do a run for just source/fuel type diesel - refuse truck; the output does not differentiate emissions by processID or sourceType. Upon looking at the MOVES execution table for that run I can see that in addition to refuse trucks, activity was generated for both types of Single Unit trucks, but again due to the lack of information from the output table I can't tell if some of those emissions were "generated" by the other vehicle types that I did not ask for, but were at least partially modeled. I noticed a similar behavior when I was doing an otherwise identical run on transit busses.

A: Emission rates within MOVES are stored by "regulatory classification" rather than source type. If you ask for only one source type within a classification, MOVES calculates emissions for all source types within that classification. Then, MOVES "filters" the results so that your output contains only the source types for which you asked. Asking for one source type or all source types will not affect the answer for any single source type result.

If you want the results to label the processes and source types, you must select them in the Output Emission Detail panel of the MOVES graphical user interface (GUI). Otherwise, even if you only selected a single process and source type, those fields will be NULL in the output tables.

Q: What is currently assumed for future year fleet fuel efficiency? Are the assumptions based on the 2007 CAFE standards. Or are they from earlier adopted standards? Will the CAFE assumptions change with the upcoming release of MOVES?

A: MOVES2010 reflects all CAFE standards through the 2008-2011 model year truck standards passed in 2006.

The recently passed 2011 Car/Truck Standards and the 2012-2016 Proposed GHG standards are not yet in the model. There is also not a 1:1 correspondence between the source types in the MOVES model and the vehicle classifications used in the CAFE rules.

Q: Does MOVES have an internal table with default mileage accumulation by model year? I don't see one in the default database, but perhaps I am missing something. I ask because the disaggregation of emissions and activity from source and fuel to SCCvtype depends on model year. We'll now need to set up our scripts to have MOVES output emission rates by model year instead of having MOVES perform that step. We would then re-aggregate over model year ourselves after mapping the emission rates to SCCs. Thus, we'll need to generate model year travel fractions (mileage accumulation X age distribution) to weight emission factors before summing over years. We'll have age distribution from the county inputs, but we do not have mileage accumulation by model year. MOBILE6 had model defaults for mileage accumulation, but I do not see such information contained in MOVES.

A: In MOVES, the mileage accumulations are calculated as a function of the total mileage for an HPMS class for a year, the vehicle population & age distribution, and the "relative mileage accumulation rate" that describes the relative differences in mileage accumulations of different sub-classes (moves sourcetypes) and ages. See the draft MOVES Fleet & Activity report http://www.epa.gov/otaq/models/moves/techdocs/420p09001.pdf for more on how these are determined.

Because the total VMT and the vehicle population grow independently of each other, the annual mileage accumulations change from calendar year to calendar year, but the relationship between mileage accumulations at different ages stays the same.

The best way to get average miles per average vehicle by sourcetype and model year would be to run MOVES for a single pollutant for exhaust running and start emissions for all the hours, daytypes and months of the calendar years of interest and to request activity output of "distance" and "population" with detail by model year (but not by hour, day or month). The movesactivityoutput table will include an estimate of vehicle population and distance for each model year and, depending on the size of your output and your SQL skills, you can export to a spreadsheet or use MYSQL commands to divide one by the other.

Q: Where are the latest mobile source GHG emission factors? I have just downloaded MOVES2010 and am looking for a data table that includes the emissions factors found in Mobile6.2. I cannot find these factors. Could you let me know where I can find the CO2, N2O and CH4 emissions factors for mobile sources using the latest EPA tool?

A: The new MOVES emissions model calculates the GHG emission factors based on vehicle activity information (engine starts, soak times, acceleration, idle, etc.). Although there are default activity estimates in MOVES, we have not run MOVES to generate at table of what the GHG emissions would be for the default case. The default activity used in MOVES is not the same as the regulatory driving schedule used to determine the official fuel economy estimates for vehicles.

We would suggest running MOVES for the scenario in which you are interested and getting the results directly from the output. You should consider making the scenario as simple as possible to avoid long run times and large amounts of complicated, detailed output.

Q: Are there hours in which there are no emissions? I've run a National Scale Inventory Calculation MOVES run for a single county to compare importance of various emission processes for hydrocarbons. While looking at the results, I noticed that for 3 vehicle classes (School Bus, Single Unit Short-Haul Truck, and Transit Bus) there are no emissions for the early and late hours of the day for start emissions (and crankcase start). For these source types, emissions only occur for hours 5 through 20. I selected all 24 hours in my runspec file, and other emission processes appear in all hours. Am I missing something in here?

A: Yes, there are not start emissions for these source types in certain hours of the day.

You can check this by looking at the SampleVehicleTrip table. This table is used to determine the number of starts and when they occur. It also calculates soak times. For these source types (42,43 & 52) there are no trips beginning in hours 2 through 4 and 21 through 24. You can change this by adding trips to the table, but this will affect soak times if you add trips for specific vehicles. The source type is the first two digits of the vehID values.

We anticipated that users might want to directly define the number of starts in each hour and their soak times. You can enter alternative number of starts and their soak times using Core Model Input Tables (CMITs) using the Manage Input Data Sets in the GUI. However, we have not written instruction for how to do this and we have not tested that approach.

Q: Is there a description for every engine technology defined in MOVES? On Page 39 of the MOVES manual, there is a table about the technologies available in MOVES. In there, there are the options of Hybrid, and Electric separately. So what does the Hybrid in that case mean? I was under the impression that Hybrid is the same as H-E? Is there a description for every engine technology defines in MOVES? If so, could you tell me were in the manual it is.

A: Table 2.2.9.6 in the User Guide lists technologies which we intended to ultimately include in MOVES. However, we have not populated emission rates or fuel consumption rates for any of the fuel and technology combinations other than electric, conventional gasoline and conventional diesel. So, you cannot get MOVES to estimate emissions from the other combinations at this time.

In the future we will have to refine our definitions to come up with the emission rates. "Hybrid" can mean many things and we need to be explicit if we are going to assign emission rates to that category as a separate technology. We have not yet made these decisions.

Q: I am trying to demonstrate the dependence pollutants have on average vehicle speed Is MOVES able to perform this type of a run? I am trying to demonstrate the dependence pollutants have on average vehicle speed. To demonstrate this I have chosen the national scale with the inventory calculation type, nation for the region, and with all other defaults present. The only default which I have changed is the average vehicle speeds over the course of fifteen hours for gasoline passenger cars and diesel single unit short-haul trucks. After completing the run to determine emissions as a function of average vehicle speed, the results attained are unexpected. Of particular concern are the emissions of CO2, CO, and NOx. Or, could I possibly be doing something incorrectly?

A: If you are using the inventory calculation type, the units of the output will be in terms of mass per time unit (such as grams emitted in that hour). However, the activity in each hour is affected by the distribution of activity across the day. It is usually necessary to "normalize" the mass emissions by some activity unit (such as miles traveled) in order to compare results. For example, if you ask for emissions in grams in each hour of the day, you can divide the emissions by the miles traveled in each hour of the day to get a gram-per-mile rate in each hour. These rates can then be reasonably compared. Be careful in comparing results from different hours, since the temperature differences (and other activity, such as speeds and number of engine starts) in each hour of the day affect emissions.

MOVES does have a "emission rate" calculation option that reports the emission rates for the 16 average speed bins used by MOVES for each hour of the day and additional emission rate output that may be of interest.

top of page

This page is maintained by EPA's Office of Transportation and Air Quality (OTAQ).
For more: About Us | Get E-mail Updates | Browse the A to Z Subject Index.

Local Navigation

Jump to main content.