Re: Emissions Inventory Meeting Minutes - Sept. 27 -28, 2006 - Toronto

["Dennis McGeen" <MCGEENDD@michigan.gov>]

As a follow up to the discussion on cremation, I took a more detailed
look at % of bodies cremated related to the urban or rural nature of
counties.  Counties in Michigan with populations over 250,000 had
cremation rates which varied from 30% to 43%.  Counties with less than
250,000 residents had rates as low as 21% or as high as 65%, so there
was more variation among the rural counties than I initially thought. 
Counties with less than 20,000 residents seemed to exhibit the greatest
variability.

>>> "Jon Dettling" <dettling@glc.org> 10/09/06 1:56 PM >>>
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.

 

 

 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
airtoxics is hosted by the Great Lakes Information Network:
http://www.great-lakes.net
To unsubscribe from this list: send mail to majordomo@great-lakes.net
with the command 'unsubscribe airtoxics' in the body of your message. No
quotes or subject line are required.
About : http://www.great-lakes.net/lists/airtoxics/airtoxics.info
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *