George R. Brown Distiguished Professor

 
 

Engineering Division
Colorado School of Mines
Golden, CO 80401

Office: BB-306
Tel: (303) 273-3379
rjkee@mines.edu
 
home bio research publications chemkin classes

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.