May 22, 2007 Conference Call
Great Lakes Regional Toxic
Air Emissions Inventory
Steering
Committee Conference Call Minutes
Participants
Illinois: Buzz
Asselmeier
Indiana:
Michigan: Dennis
McGeen, Jim Lax, Lori Franz and
Allan Ostrander
Minnesota: Michael Smith
New York: Carlos Mancilla
Ohio: Tom Velalis
Ontario: Cong Doan and
Peter Wong
Pennsylvania: Karen Gee
Wisconsin: Orlando Cabrera-Rivera
GLC: Jon Dettling
EPA: Suzanne King
Other: Mark Young
Emission Factor
and SCC tables
Prior to the call, Jon sent a draft
table showing a recommended scheme for grouping SCCs for purposes of reporting.
Building on the discussion at the Madison meeting, Jon's recommendation is that
a roll-up type approach be used for reporting data from the regional
repository, but that no requirements be imposed for SCCs used by states in
estimating emissions or for submitting and storing data in the regional
repository. In the recommended approach, a mapping table would be put together
that could be used as a part of queries being run to produce reports from the
repository. By reporting emissions at a more generic level of SCCs, the
consistency among states and provinces in the SCCs reported and the confusion
among audience members among which categories may or may not be included will be
greatly reduced.
The example table Jon sent had the
>1000 area source SCCs in the EPA's official table sorted so that there
would be <200 SCCs used for reporting.
Orlando said that he liked this
approach in that it will retain flexibility for the future as methodologies
change and are incorporated into how people estimate and report emissions. The
changes in the totals at the level of the SCCs used for reporting might be less
effected by such changes in methodology.
Orlando also
recommended that Jon look at WEBFIRE to see if there are any new SCCs since the
EPA published the master SCC table in 2004. Some were added in doing the 2002
NEI and others may have been added for other purposes. Jon agreed to take a
look at this.
Cong inquired whether a mapping
table could be included in the database. Jon stated that this was how he
envisioned this being implemented. Pending the group's approval of this
approach, he plans to prepare a table mapping all the SCCs to a more generic
set. This table would become a standard reference table in the RAPIDS system.
Jon noted that including a similar table for mapping material codes to the 211
pollutants/groups used in reporting would provide a similar benefit and is
essentially the same concept as what is being recommended for SCCs.
Allan asked whether this would
interfere at all with the estimation program. Jon responded that the way he is
recommending doing this, the roll-up would only be done in preparing reports
and that the original SCCs used by each state/province would be retained in the
system, so that even if estimation routines were done at the repository level,
this shouldn't have an impact.
The group agreed that the method
presented was a sensible way to handle the mapping and reporting of SCCs. Jon
will work on developing a mapping of the non-area sources, include any new SCCs
he is able to find, and produce a draft mappings table for inclusion in the
RAPIDS database
RAPIDS components
and programming languages
The group had discussed previously
the issue of programming languages. This issue was raised again recently by Minnesota in their
_expression_ of an interest in possibly programming some additional RAPIDS
components internally to meet MPCA needs. Their programming resources within
MPCA are fairly exclusive to the use of .Net. Jon emphasized to the group that
the choice of a programming language for the main RAPIDS desktop application
would not in anyway prevent the ability to program other components in other
languages that would use the RAPIDS database as a back-end. The only constraint
would be that those components would likely need to be run separately rather
than a part of the official RAPIDS program shell. Jon sent a RAPIDS data flow
chart based in the charts put together previously by Mark. This provides a
useful way to depict how different components could be programmed in different
languages.
In addition to Minnesota, there are some other states who
have expressed the possibility of wanting to program some additional
RAPIDS-related items in cases where their immediate needs are not necessarily
those of the regional project. These states are also generally oriented to the
use of .Net. The issue was raised of whether some of these items might
eventually be made a part of the main RAPIDS program, even if they are done by
or for individual states. It was discussed and concluded that it would be
advnatageous to be able to include some such components or parts of code into
the larger RAPIDS program. Being able to leverage these programming resources
at the state agencies is an important consideration and it would make sense to
program certain parts of the RAPIDS flow diagram, such as the imports and
calcualtion routines that are used heavily by the states/provinces in .Net.
Mark raised the issue that in
addition to the main programming in .Net or Java, some database processes will
be coded in PL-SQL, which is a part of the back-end database and is independent
of what programming language is used. He's already begun some of that coding to
support the database design and there will be many more components of that
type.
Mark also noted that there are
many languages, especially web-programming languages (asp, php, etc.), that
would be able to interact with the back-end database.
Representations
of Control Devices
Some people have advocated that
the system only needs one set of control information for each source,
regardless of how many devices physically exist. Others in the group would like
to have the ability to document that there are multiple control devices. Mark
proposed a compromise among the two, where an overall control efficiency would
be used for the calculation, but additional control devices could be recorded
in the system. Although at some point, this information could be used to
calculate the overall control efficiency and emissions, this wouldn't be the
original design. The states would need to be able to calculate these on their
own and enter them.
Orlando inquired whether
once the information is entered, there would be an ability to look at the
control groups that are entered and compute the overall efficiency. Mark
responded that at some point, a more complex scheme might be implemented that
could do this, but it seems to be unnecessary for the use of most states. This
is something that might be considered for a future enhancement.
The issue of parallel control
devices was raised and Tom questioned whether people actually have sources like
this and whether their system currently accounts for the controls being in
parallel. Orlando noted that Wisconsin has several instances of this and
can send an example.
Mark has modified the original
structure to add secondary control efficiency field and may modify this further
to include a combined control efficiency.
Other RAPIDS
design issues
Mark has been reviewing the EPA's
EIS documentation for the future directions of their data model for the NEI.
One significant thing he has found is an attempt by EPA to include a "connections"
structure to represent how various items are related. In the new model, it will
be possible to connect one process to multiple release points. Mark will make
some slight modifications in our current structure to accommodate this as well.
At this point, this is basically a planning-for-the-future type of change.
Mark also proposed that it would
be possible to have in each emission record in the emissions table the
uncontrolled emissions, the fugitives and the controlled emissions.
Next Call: June 6th 1:30 pm EST