Developing generalized reactor modules for a process simulator

Abstract

Reactors, essential in chemical process simulation, are complex equipment characterized by simultaneous heat, mass and momentum transfer, and by chemical reactions. Traditionally, reactors have been modeled on an individual basis determined by the reactor type and the application. A process simulator, however, requires complete reactor capabilities; the classical ap proach leads to a bewildering array of special reactor unit modules both expensive to develop and to maintain. Consequently, the authors have developed the concept of generalized reactor modules; this paper presents the concept and a methodology for implementing it. Conceptually, reactor simulation is divided into six parts: equipment, stoichiometry, kinetics, data, mathematical software and executive routine. The conservation and equilibrium relationships are built into the equipment modules; system stoichiometry and reaction kinetics are user defined; kinetic parameter data are either input by the user or can be read from a user-specified kinetic data file; quality mathematical software from commerically available packages is used to solve the model equations; and the executive routine puts all these pieces together, manages the calculations scheme, and outputs the desired results. Carberry' and Levenspiel2 discuss models for various reactor types as well as the reaction kinetics needed in these models; they also address the important issue of how these idealized models can be used to simulate real reactors. This approach has been applied in developing several reactor modules for a process simulator. These include steady state CSTR, plug flow, and dispersion reactors and a transient tubular dispersion reactor with continuous catalyst deactivation. Research and process engineers use these modules to simulate reactors with arbitrary stoichiometry, kinetics and kinetic data. An important feature of all these modules is that quality, commercially available software was used wherever possible. This allowed more time to be devoted to model formulation and user support and to quickly develop very sophisticated modules which are easily maintained.