Great Lakes Regional Toxic Air Emissions Inventory
Steering Committee Meeting
Sept. 27-28, 2006
Toronto, Ontario
Participants
IL: Buzz Asselmeier
IN:
MI:Dennis McGeen (Jim Lax, Allan
Ostrander by phone)
MN: Chun Yi Wu and Dan Steber
NY: Carlos Mancilla and Ron Stannard
OH: Tom Velalis
PA:
WI: Orlando Cabrera-Rivera
GLC: Jon Dettling, Pete Giencke
and Roger Gauthier
ON: Kevin Yam, Yvonne Hall, Cong
Doan and Savio Wong (Ed Piche joined briefly)
Other: Mark Young
Benzo(a)pyrene
Report
A revision of the benzo(a)pyrene
report was sent out recently. Significant changes from the prior version
included some additional materials in the background section and other minor
updates throughout. There is still a need to update the sections for each
individual state/province and to formulate a results section once all updates
have been made in the repository.
State updates on benzo(a)pyrene
work:
Illinois
Buzz will draft up some additional
language describing what he's done. He will revisit the FCCU refinery data to
include an estimate, rather than none. All updates made to date have been
uploaded to the repository.
Michigan
Dennis has updated his emissions
for fireplaces ( conventional) and
commercial cooking. He will be working on municipal solid waste, wildfires and
prescribed burning. He has been creating RAPIDS import files, but hasn't
submitted them. They are looking into updating their emission factors in MAERS
to include SCCs for which a similar SCC has an emission factor. Dennis hasn't
been able to identify any factors for natural gas combustion (industrial).
Minnesota
Chun Yi sent an update of the NEI
emission information that might be used to include many emission factors for
other pollutants as well. Using, EPA's NEI augmentation, they have updated
several point source estimates. She has been dealing with someone from the MDI
industry and he is interested in working with the states to update their MDI
emissions. This person appears to have a lot of useful information. This is
under the American Polyurethane Institute's compliance assistance program. Chun
Yi passed out an article describing MDI emissions.
Chun Yi has added the on-road
mobile sources to the repository for b(a)p. She has also included wildfires and
prescribed burning. They haven't yet produced import files. They will
work on this soon after the meeting.
Chun Yi is still concerned about
the cremation emission factor. Orlando
noted that both the NEI and FIRE emission factors, are based on
the California Air Resources Board stack test report. Orlando has done the
estimate for his state with the CARB numbers and got a extremely
low state-wide b(a)p emissions - on the
order of thousandths of a pound per year. The report also
contains the weights of the people cremated during the tests and the
conversion.
Chun Yi has looked at the MARAMA
wood combustion report. She has already done estimates on this source category
and will not re-estimate them for the 2002. She may incorporate much of the MARAMA
information for 2005. Orlando
noted that they may want to look at the conventional fireplaces. NEI did not
include any b(a)p emission for these sources.
For the point sources that may be
missing emissions, Minnesota
does not have sources with the identified SCCs.
New York
Carlos has been following up on
the questions in the report. For the point sources showing emission, but with
no FIRE factors, these sources are using stack test data to estimate emissions.
For the area sources that are to be calculated, coal utilities (anthracite)
does not have any activity. The bituminous utilities have criteria emissions,
but the activity data is not available. They've also done estimates for
residential waste combustion.
They have looked at the MARAMA
report and are considering internally whether to adopt this information or to
keep their current estimates. The MARAMA report has much lower amounts of wood
burning. NYSDEC originally got their numbers from the DOE dataset. They will
keep looking into this dataset.
NYSDEC has recalculated emissions
data for the small point sources. There were several hundred of these. They are
also working on recalculating 2 non-road source categories.
Ohio
The nonroad emissions have been
fixed. Ohio
originally had very high nonroad emissions due to a data conversion problem. Tom
evaluated the information that Chun Yi sent from EPA and it appears that it
would change overall emissions by less than ten pounds. Ohio has not been including household waste
combustion because they believe that the current methodology is not good and
overestimates these emissions. Orlando
suggested taking the NEI emissions for this category and perhaps excluding
urban counties if they feel those numbers are wrong.
Another issue for Ohio is very high
emissions for FCCUs. Tom will look at this data and address it.
Ontario
No changes for point or mobile
sources. For fireplaces, they've used the MARAMA factors for conventional
fireplaces and the NEI factors for other wood combustion. They've also
recalculated a few other combustion categories.
Wisconsin
Orlando did estimates
for conventional fireplaces using the MARAMA factor. These emissions totaled
520 lbs. for the state. Orlando
has described previously their updates to the point source data. They have done
the cremation estimates and the amount was very low. They will also be looking
at commercial cooking, prescribed burning and commercial marine vessels. Orlando believes the
commercial cooking amount will be about 40-50 lbs. For the commercial cooking
factors, NEI has used an average emission factor based on factors specific to
various food types. There is only 1 refinery and the emissions were below the reporting
level. He will calculate them and include them.
Carlos inquired about the
percentage of bodies that other states cremate. Wisconsin's is about 29%, close to the
national average. New York's
is about 22%. Dennis noted a big difference between rural and urban areas.
Specific comments on the b(a)p
report draft:
- On
the report, Chun Yi noted that for point sources, it would be useful to
note that some sources are not present in some states.
- Orlando
noted that mentioning that benzo(a)pyrene is a carcinogen should be done
up front.
- Chun
Yi noted that we could include a table of toxicity metrics (RfD, TEL,
etc.)
- Change
"phenyl" to "benzene" rings?
- On
the study of lakes, mentioning the date of the study and the time period
would be relevant.
- Use words to
describe risk exposure to "one in ten
thousand" rather than using scientific
notation.
- Change
"over" to "during" at the botton of page five.
- Add
additional goals to the end of the first paragraph on page 6.
- On
page seven, the third paragraph should mention taking a look at outliers.
(Ohio's example).
- For
the SIC table, the data should be queried to include just point sources
(source type = f) . There are a number of sources that do not have
SIC, but NAICS codes.
- Some
other minor typos: change "factos" to "factors".
Remove Second paragraph, change "are" to "area" and
"smill" to "small." "scap" to
"scrap."
The issue of reporting thresholds
was raised. Many states do not have reporting thresholds. Orlando mentioned that thresholds other than
bap-specific thresholds may have an effect. For example, reporting thresholds
based on total emissions of a combinations of pollutants.
Tom suggested including a table
with the SCCs, emission factors and sources. There are a little over a hundred.
This had been suggest previously and is something that can be incorporated.
Changes should be made and
uploaded by Oct. 30th. A draft report will be prepared by November 30th. The
GLBTS b(a)p workgroup will be meeting in early December and Jon has volunteered
to present to them a preliminary report of our work and results. This is ideal
timing to receive some comments from them prior to finalizing the report.
Proposed
additions to materials code table
Several proposed additions to the
materials code table were emailed recently. They include PCBs at the
chlorination level and several
PAH compounds (non 16-PAH group). The material codes will be
for individual PCBs. The PAH are not part of the regional
inventory, but adding them to the materials code table would allow states that
may want to inventory them for their own purposes to do so.
Cong noted that methylpyrene is
already in the RAPIDS system. However, there is no CAS. A CAS should be added
to the existing record
The names for Dichloro,
nonachloro, and octachloro should have ",total" at the end of the
name.
The group agreed without objection
to add these new codes to the materials table, with the modifications to the
list noted above.
Cong raised the issue of what would
be done with the new codes. Orlando
noted that the past practice has been to distribute an import file. Chun Yi
will prepare an import file.
Emission
Estimation Tool
Tom Velalis presented to the group
an MS Access-based tool that Ohio EPA has been developing with the help of an
intern. The tool stores and estimates Area Source emissions data. After Tom
reviewed the structure of the tool and how it operates, the group agreed that
it was well-designed conceptually and may be of use to many of the state
agencies once the programming is complete. There are still several components
that still need to be programmed and bugs to inspect and repair. Jon mentioned
that the tool might be very useful for the project in cases where it is
feasible or desirable to estimate a certain category at the regional level
rather than having each state estimate their own. Tom will keep the group
informed as this discussion moves forward.
Meeting with OMOE
Director and Tour of Monitoring Division
The group met briefly with Ed
Piche, the Director of MOE’s Environmental Monitoring and Reporting
Branch. Ed discussed with the group the importance he sees in the inventory
project and his support for their current and future work in this area. Ed drew
on his experience to provide the group with some perspective on how the project
fits in with environmental management work within Ontario and in coordinating management
efforts across the international border, such as under the activities of the
International Joint Commission. It was pointed out that emissions inventory
information provides an important compliment to monitoring data because it is
impossible to monitor for all compounds of concern in all location. Ed expressed
a particular interest in seeing capabilities continue to be developed for
inventorying emissions of a growing suite of chemicals of concern for which the
Ministry is unable to monitor due to fiscal constraints.
The group took a tour of part of
the MOE monitoring division offices, including a presentation of the Pollution
Air Monitoring (PAM) program, which compiles real-time data to produce daily
and hourly forecasts of air quality across the province.
RAPIDS Redesign
Discussion
Mark Young joined the meeting by
phone. Mark had posted some discussion points and design diagrams on the
discussion forum website. The diagrams show the data flows in RAPIDS currently
and some proposed visions of how the data flow might change. There were also
diagrams of the NEI and RAPIDS data structure.
On Figure 1, the RAPIDS data input
flow is shown. The reference data is often decided on as a group and are
distributed to the group as a data release. These are then imported by each
user. Some of these reference items are relatively large, such as new FIRE or
SPECIATE releases. In addition to the reference data, each state has its own
state data system that it uses to create and format data for input into RAPIDS.
Some states use RAPIDS for data creation. Others are using other programs or
methods. There are many states who have programs to produce or convert data to
RAPIDS. (e.g., MIRROR, AFS and Ohio's
application). There are a few states who use RAPIDS exclusively in data
creation, at least for some categories, such as area sources. Minnesota is using RAPIDS to do the
point source inventory. Much of Minnesota's
point source information comes from DELTA and is imported into RAPIDS to do
emission calculations. In some cases, RAPIDS is being used to do some calculations,
such as speciating on-road data. Similarly, many states are using other
software to produce or convert their data to NEI data. New York has a system to produce NEI XML
files (for point sources); for area sources they use Access. Michigan can export data from MAERS in NEI
format. Wisconsin
uses RAPIDS for their area source HAPS NEI files. Ohio is currently re-constructing an
application that will generate NEI XML system. For Illinois, Buzz converts the data manually. Minnesota used RAPIDS
exclusively to produce NIF files and then uses EPA's converter to generate XML
files. Ontario
does not deal with NIF at all.
There are several data converters
within RAPIDS that allow importing of data in several formats into RAPIDS. The
current NEI import process, which involves a set of temporary tables, has some
significant performance issues and data integrity issues.
Figure 2 shows the data outflow
for RAPIDS. Most states use the standard export to get data to the regional
repository. Some states use the "GLNPO" export.
The NEI export had been tried for submitting data to the repository, but the
NEI import failed for large data files. As a result, the NEI files were
converted via RAPIDS to RAPIDS import for upload to the repository. It was
pointed out that most or all data are imported from a remote machine, rather
than being sent to the GLC system and being imported locally. As noted before,
some states are using RAPIDS to prepare their NEI submission, some are using
other software. The NEI export functions also have issues with data loss and
performance.
The Data Mart converter
application has been used with limited success for small data sets. The
application doesn't work with large databases due to either memory loss
and/or exponential growth
issues. For this reason, these tools can't be used at the regional level.
The geometric growth of the roll-up calculations is a serious issue that may
prevent this from working as it is currently designed. For reporting, there are
numerous processes by which some states extract data for various reporting or
analysis tasks. Orlando
noted that for the datamart, the "save as" feature currently saves
all roll-up data behind the report in addition to the summarized data.
It was noted that CAROL replicates
much of the reporting and roll-up functions that RAPIDS was intended to
provide. Much of this functionality can now be developed as part of CAROL and
needn't be within RAPIDS, although there may be some reports states may need
that CAROL cannot produce.
Mark asked how frequently the
database is queried on an ad-hoc basis for various purposes. Several states
responded that this is done very frequently. Many states noted that they have
separate data from the regional repository that they use to run queries. Ontario runs such
queries once in a while.
For Figure 3, the Regional RAPIDS
is shown along with the associated data flow. All importing is currently done
with standard RAPIDS files. Orlando
has been doing most of the Data importing remotely. There is a separate
instance of the entire database created for each inventory year. All of the
repository years support the current RAPIDS application. The GLC initiates the
CAROL roll-up routine locally. The roll-up prepares a preliminary table and
then a source-level roll-up table. The more expanded table gets overwritten
when the roll-up runs. The CAROL roll-up is a Solaris shell-script based on the
roll-up logic Wisconsin uses. Pete sent the
CAROL connection information to the group as a reminder.
CAROL can be either queried in an
ad-hoc fashion through various tools, or generate reports through the website.
Figure 4 shows the input data flow
based on Mark's current suggestions for a new system. As shown, reference data
would be imported into the system from various sources. For example, FIRE has
become more standardized over the years and we may be able to establish a
standardized import utility. Tom mentioned that Ohio anticipates working on a FIRE converter
also. Cong mentioned that EC has produced a Canadian version of FIRE with SI
units and added French descriptions. Mark noted that FIRE has made some
positive improvements in recent years, such as parsing throughput units into
multiple columns. Mark mentioned that there may be options for reference data
to be maintained centrally and to have the clients be updated when they
connect. Chun Yi noted that it would be important to find a way of doing this
without overwriting state's data.
The diagram also shows the flow of
state data into the RAPIDS program. In addition to importing NIF, it will be
necessary to have a more expanded data format that contains auxiliary data that
may be used. Mark has labeled this in the diagram as "standard import
files." Orlando
has done a cursory assessment and believes that there is much more information
than what is included in NIF and some additions would need to be made, as
suggested in the diagram. The NEI files should be able to be imported as they
are and should be handled natively by the system. Tom suggested that in
addition to the NIF, a user might be required to upload some addition
information to do calculations. For example, a VMT import file. Mark noted a
significant change in the import process. Currently data are both imported and
then converted (for NEI). In the new version, this would be a more streamlined
process, with data being imported, but not significantly changed in its
structure.
Figure 5 shows the output flows
from a proposed new system. The diagram shows the possibility of reference data
changes on the client being sent to the repository, where they would be stored
as state-specific information. The diagram also shows a standard export file
pathway, and an NEI data export feature. Mark pointed out that within a system
where the data format for transfer and storage are very similar, there
shouldn't be any data consistency issues as there are currently with RAPIDS and
NIF.
Mark raised the question of
whether the group saw retaining a data mart feature within the program. Several
people noted that this would be very useful for viewing the data, as well as
for programming tools to work with the database. The capability currently
exists at the repository level as part of CAROL. Whether this option will be
created within RAPIDS will be determined as the project goes along. Cong
pointed out that in some ways the datamart will be less essential with a
simplified data model, where many queries can be run on the database itself.
Mark also raised the issue of
"data access layers" this would include tables and views that
cross-reference the data and allow the users to more easily obtain common data
elements. The current v_rap_reports view does something similar to this. Cong
asked whether a view is similar to a data rollup in terms of functionality.
Mark explained that a view is much like a permanent query that users can
directly incorporate in other queries. Several people felt that roll-ups may be
more efficient for many purposes, but views could also be helpful in some
instances.
Figures 6-8 show the NIF entity
hierarchies. The key fields are shown for each level. In Figure 6, the
Transmittal level contains the major information for each submittal or
inventory. Chun Yi raised the issue of federal facility IDs and whether
these should be included along with the state facility IDs. Orlando also raised the importance of getting
rid of the state prefix requirements on the state IDs. Mark noted that there is
a dotted line in the diagram between emission release point and emission
process. This is because release point is a required field in the emission
process table, even though it is not part of the key. Buzz pointed out that
within NEI, each process can only be mapped to one stack. To map it to
multiple, a second process must be created and given half the emissions and
mapped to its own stack. Mark noted that just based on the mappings, you could
have multiple release points associated with an emission process within the Emissions
table. However, it's not clear if this would cause problems with data checks
that might look to see that these match with what is at the emission process
table. Tom stated that within their new system, if a process has multiple
stacks they only report one to EPA. There are very few of these and they are
handled as fugitives. Tom said that generally, the people they have dealing
with the emissions data do not feel that this work-around causes them any
problem.
Tom mentioned having an email
describing some of the proposed changes for NIF 4. He will send this to the
group.
Figure 7 shows the area/non-road
source entity hierarchy. Compared to the point sources, these files lack the
site, emission unit and emission release point. In addition, SCC is used as a
key for the emission process table. The mobile source hierarchy (Figure 8) also
eliminates the emission process and control equipment tables.
Figure 9 shows the RAPIDS entity
hierarchy and the RAPIDS logical data model. The looping at the stream level
with to and from streams creates many complications in the RAPIDS data model.
Figure 10 shows a detailed example
of the RAPIDS hierarchy. The non-shaded arrows show cases where the same stream
reappear within the hierarchy multiple times as both to and from streams.
Orlando inquired about
what the next step is and what input Mark needs from the group to move further
along. Mark mentioned going into more detail in looking at the NIF data model
and identifying what added data elements and reference tables are needed for an
operational RAPIDS system. Orlando
noted the importance of both considering people's current data use and to what
extent the data model can fulfill those needs, as well as the ability to
support emissions estimation.
Orlando noted that he
has recently attempted to do seasonal input streams to a process and produce a
single output stream.
There was agreement that the data
model issue is the first to be addressed. More thorough design documents will
need to be produced and there will be multiple iterations of review. Mark
inquired what the level of interest among the group was to support multiple
years' data within one database. Tom suggested that multiple years within a
single database would be highly useful for him. Pete added that from the
standpoint of database administration, it would be much more efficient to have
a single database instance. The repository server is currently running at close
to 100% capacity supporting the multiple RAPIDS instances. Orlando brought up the distinction between
being able to estimate emissions on multiple years and just storing and
accessing data for multiple years. Cong said that Ontario has a single database that maintains
the data from 1990-2000. Chun Yi expressed concern that database size may
become an issue with regard to efficiency if multiple years are stored at once.
Cong noted that the new system may be more efficient and the space occupied by
the data and efficiency of operation may be better. Orlando also noted that if the multiple year
system runs into performance problems, the user can always go back to creating
multiple instances. Allan stated that it would be preferred that if multi-year
capability were added, he would like to be able to lock past years' data so
that changes are not inadvertently made. Carlos noted that their AFS system
supports multiple years and it is very convenient to be able to access old
information.
Tom noted that Illinois has a system where emission factors
are given start and end dates so that multiple factors can be used over
multiple years. Tom also noted that in designing their new system, the size of
the database has never been a development concern, as this is generally no
longer a significant limitation.
Mark will follow-up with Buzz
regarding how the multi-year database is handled in ICEMAN. Buzz will send some
screen-shots of their system to the group with some explanation of how the
multi-year functionality works. Tom will send contact information for a person
in Iowa who
has worked with their SPARS system.
There was a discussion, raised by
Cong, on the ability to use source specific emission factors and FIRE factors
from different years simultaneously in the current system. It was concluded
that there is a problem in calculating past years' data if the date on FIRE
factors that would like to be used is after the year being calculated and there
are more recent source-specific factors.
Mark brought up the possibility of
adding something like an inventory code to distinguish different inventories or
scenarios. In this way, reference codes would still be used, but various
scenarios could be run. Allan mentioned that within their system, a
source-activity view has been created that raises a similar concept. Cong
inquired whether the concept was similar to the Transmittal level information
under NEI. This is indeed a similar concept, where information is all
associated together at a high level for each inventory. There were some
questions about how useful this would be and how complicated it would be to
implement. There will need to be some more thought to see if this is a feature
the group actually wants to incorporate.
Regarding the data model, the
suggested approach is to begin with the NEI and look at RAPIDS or other sources
to see what components would need to be added. There are some old design
documents that Windsor
had that detailed the current NEI-RAPIDS conversion. These may be a useful
reference in helping to understand how the two relate. There are likely many
fields that are not in the NEI, but may be required in the new RAPIDS
application. There may also be some fields in NEI that either are not present
in the RAPIDS framework or are typically left empty in RAPIDS. There would also
need to be some system data, such as reference tables, coversion factors, etc.
Mark suggested that the first
priority is to establish a database model and then to create import/export
features so that data can be stored and moved around.
Reference data sets will come from
a variety of sources and have a variety of formats. Much of this can use the
current RAPIDS reference tables as a starting point. There may be some
additional issues, such as possible revisions to pollutant groups, that would
be preferred to address as the design moves forward. Orlando noted that there is currently a field
in the material codes that shows if something is a VOC or a PM component and
these can be compared to total VOC or total PM.
The PostgreSQL database will be
used for prototyping and development of the system. The GLC server will be used
to develop a repository prototype. The stand-alone version should be
installable on individual computers. Minnesota
noted that their administrators are willing to maintain a PostgreSQL system on
their servers for internal use, but will need documentation and support. Cong
noted that although there is much documentation for PostgreSQL, but there is no
official technical support should there be a significant problem. Chun Yi
raised some concerns about MPCA's ability to support PostgreSQL and stated that
she would prefer to see Oracle continue to be supported. Several group members
saw this as inefficient, as the programming work to support multiple database
formats is substantial and little benefit is gained. It was pointed out that a
considerable amount of RAPIDS functionality is currently being used only by Minnesota and that
decisions need to be made to best meet the overall needs of the group.
The GLC will draft a letter to the
state agency administrators that will explain the upcoming changes and
directions in the RAPIDS software. It is important for the state agencies who
rely heavily on RAPIDS support to understand the current situation and the
projected timelines for various improvements.
The group discussed programming
languages. There are several issues being considered in deciding between use of
Java or .Net. Several states have been addressing this issue within their
agencies and have been making differing choices. There are still a number of
items that need to be addressed in making this choice. Mark will be discussing
this with some developers at the state agencies who have developed similar
applications at the state agency level. Pete emphasized that from the user's perspective,
the choice of a programming language is largely transparent, with little
difference between the two. The differences are at the level of development and
support of network tie-ins. Either can run on a Windows compatible computer and
would only require a simple RAPIDS installation routine, similar to the current
RAPIDS installation. Java has an advantage of being supported on all platforms
(Mac, Linux, Unix, etc.).
There will be a need to migrate
RAPIDS 2.4 data to the new RAPIDS. It was also mentioned by Buzz that it would
be more efficient if the importing process was done on the server side, rather
than on the client side, as is done now. Import files could be uploaded by FTP
or a similar process and the import routine could be run at the server.
There was a discussion on the use
of the new system for the 2005 inventory. The system would likely have some
fundamental import/export capabilities and could accept 2005 data, but not to
produce them.
The current NEI import does not
support importing seasonal emission records. This should be fixed within a new
system.
The question was raised of which
data importer should be developed first, NEI or RAPIDS 2.4. Different states
had differing views on this. It was determined that we don't have sufficient
information to determine this yet and both are high priority items. The group
will discuss this later, when a decision is more imminent. It is likely that
both of these functionalities will be implemented early-on in the development
and are central to establishing a regional repository on the new platform.
Mark will move forward on
beginning a data model.
Next call will be on October 18th,
2pm Eastern.