CHEMKIN
Chemkin
is a very large body of software that is designed and used
to analyze chemical kinetics and molecular transport, especially
in processes that involve chemically reacting flow and heterogeneous
reactions at surfaces. It has also been extended to also include
plasma processes in addition to charge-neutral, thermally
driven processes.
Work on Chemkin began at Sandia National Labortories in the
late 1970s and has been continually extended and enhanced
since then. Until recently, Chemkin was freely distributed
by Sandia and has enjoyed very widespread use worldwide. Chemkin
is now maintained, enhanced, and distributed by Reaction Design,
Inc. , which is a software company.
Some documentation is available through downloadable pdf files
on Chemkin's page on Sandia's web site. Also, Reaction Design
intends to make up-to-date documentation available on request.
Most of the theoretical underpinnings as well as discussion
on the computational methods is now documented in the new
book by Kee, Coltrin, and Glarborg, "Chemically Reacting
Flow: Thoery and Practice," John Wiley, New York, 2003.

Brief
Histrical Perspective on CHEMKIN
Professor Kee's Welcoming Remarks at the Chemkin Workshop
(preceeding the 27th International Combustion Symposium)
University of Colorado
August 2, 1998
Good
morning, and welcome to this workshop. I have two objectives
in my brief comments this morning: one is to provide a brief
historical perspective of Chemkin, both technically and administratively,
and the other is to look into the future.
In the mid 1970's, Jim Miller and I began working together
on combustion modeling. This was just as Sandia's Combustion
Research Facility was in the proposal stages. Initially, we
were particularly concerned with how elementary chemical kinetics
affected the structure of hydrogen-air diffusion flames. It
was my job to implement these models in software, and we were
writing explicit Fortran code to represent the reaction mechanisms.
I soon recognized that chemists could never make their minds
up about reactions mechanisms and were changing them several
times a day. This was frustrating and time consuming for me,
since I was writing the software. At the same time, we were
starting to look at other combustion situations -- premixed
flames, shock tubes, stirred reactors, etc. Again, I was getting
overwhelmed at the software level because of the inherent
inefficiency in our process.
By 1978, we stood back and looked critically at what we were
doing. Three observations led to the design of the present
Chemkin architecture. With these observations in mind, we
set out to design the Chemkin architecture. We needed to handle
increasingly complex chemistry and transport in a general
way, independent of the particular type of flame. We needed
to increase the efficiency with which we developed new models
for different combustion situations.
We could isolate the solution techniques from physical model,
thereby benefiting from the rapid advances in computational
mathematics and software. The next major step was the recognition
that we needed to increase the sophistication of our numerical
solution techniques. This was done first with the hiring of
Mitch Smooke and Linda Petzold, and later with Joe Grcar joining
the effort.
By this time, the Combustion Research Facility was beginning
operation and many combustion researchers were visiting Livermore.
Many of these visitors though that Chemkin would prove valuable
in their own research, and we shared the software with them.
Even at that time, however, DOE had restrictions on software
distribution. By policy, all software had to be distributed
through the Federal Energy Software Exchange, housed at Argonne
National Laboratories. For Chemkin, we were granted an exemption
to share the codes directly with colleagues or visitors at
the CRF.
As Chemkin became more widely known, we were accepting more
and more requests for sharing. We began to blur our definition
of a CRF visitor and colleague. Was a one-week visit sufficient?
How about a two-hour visit? Soon a telephone call met the
criteria. By the mid 1980Õs we were clearly in the
software distribution business, and the software was having
noticeable impact on combustion research.
As distribution grew, the needs for support also grew. My
telephone was ringing a lot, and I enjoyed talking with people
about their modeling activities. However, as my management
responsibilities grew, I found that there was less and less
time available for broad-based Chemkin support.
Others in the group began picking up the load. Of course,
this also led to a de-facto program cost -- one that we had
no identified budget to support. By the late 1980s, my interests,
and that of my group, moved increasingly to materials processing
using chemical-vapor deposition techniques. This shift fostered
the development of major new capabilities into the Chemkin
framework. Collaborations with Juergen Warnatz (U. of Heidelberg)
and Graham Dixon-Lewis (U. of Leeds) led to the molecular-transport
packages. Working with Mike Coltrin, we designed and developed
the Surface Chemkin to deal with elementary heterogeneous
chemistry at deposition surfaces. By the mid 1990s, Ellen
Meeks was actively working on plasma processes. She led the
design and development of Plasma Chemkin, which is now embodied
in the Chemkin III software.
Even though we had never intended to be a software developer
and distributor, we found ourselves by the mid 1990s with
well over 1000 copies of Chemkin floating around the world.
While they were all called "Chemkin," the distributed
software was a very heterogeneous mix of old and new code,
much of which was modified locally by researchers for special
purposes. Our support costs were growing steadily. My real
costs to support external users exceeded $200K annually. For
each release sent out, the real costs were several hundred
dollars to cover printing, shipping, etc. Finally, it was
decided that we could not continue to incur these costs and
the system had to change.
Sandia began licensing Chemkin for a fee. This action changed
fundamentally the Sandia's relationship with the Chemkin users,
who were now a paying customer. What was reasonable support
for a collegially shared software was not reasonable support
for a purchased product. Moreover, by now, people expect to
receive purchased software on a CD, pop it in, click on an
installer, and five minutes later have a simulation running.
As you all know, Chemkin did not meet these expectations.
While the architecture was certainly ahead of its time in
the 1980s, it has not kept up with modern software practice.
This lag is a function of resource availability and Sandia's
strategic intent in combustion research. Large-scale software
development, distribution, and support simply is not in the
Laboratories mission.
Recognizing the value of the software and the need to continue
development and support, Sandia decided to license Chemkin
to Reaction Design. This decision provides the vehicle to
keep Chemkin alive and well. Reaction Design is committed
to the development and support role. I'm quite sure that they
looking forward to this meeting and will use the results to
help fashion the next-generation software to meet the needs
of the combustion community.
I'm sure that all of us have ideas about what sort of software
and functionality will be needed in the future. I am most
anxious to hear about these ideas throughout the course of
the day. A couple of directions are high on my own list. One
is to develop spread-sheet (Excel) interfaces that provide
chemical functionallity in cells. Such interfaces would radically
reduce the programming time for certain applications. There
is some early work along these lines from Tom McKinnon, my
colleague at the School of Mines, Dave Goodwin at CalTech,
and Mike Coltrin at Sandia. Another important need is for
high-fidelity transient simulation. This capability is an
enabler for model-based process-control development and real-time
implementation. Intelligent active control is realizing some
maturity in semiconductor processing and, I believe, holds
real promise for combustion as well.
|