[Luyben] Process Mod.. - Student subdomain for University of Bath

90 COMPUTER SIMULATION
lation packages is usually significantly longer than when run on a FORTRAN,
BASIC, or PASCAL program written for the specific problem.
Proponents of these packages argue, however, that the setup and programming
time is reduced by using simulation languages. This may be true for the
engineer who doesn’t know any programming and uses the computer only very
occasionally and only for dynamic simulations. But almost all high school and
certainly all engineering graduates know some computer programming language.
So using a simulation package requires the engineer to learn a new language and
a new system. Since some language is already known and since the simple, easily
programmed numerical techniques work well, it has been my experience that it is
much better for the engineer to develop a specific program for the problem at
hand. Not only is it more computationally efficient, but it guarantees that the
engineer knows what is in the program and what the assumptions and techniques
are. This makes debugging when it doesn’t work and modifying it to handle new
situations much easier.
On the other hand, the use of special subroutines for doing specific calculations
is highly recommended. The book by Franks (Modeling and Simulation in
Chemical Engineering, John Wiley and Son, Inc., 1972) contains a number of
useful subroutines. And of course there are usually extensive libraries of subroutines
available at most locations such as the IMSL subroutines. These can be
called very conveniently from a user’s program.
4.2 COMPUTER PROGRAMMING
A comprehensive discussion of computer programming is beyond the scope of
this book. I assume that you know some computer programming language. All
the examples will use FORTRAN since it is the most widely used by practicing
chemical engineers.
However, it might be useful to make a few comments and give you a few
tips about programming. These thoughts are not coming from a computer scientist
who is interested in generating the most efficient and elegant code, but from
an engineer who is interested in solving problems.
Many people get all excited about including extensive comment statements
in their code. Some go so far as to say that you should have two lines of comments
for every one line of code. In my view this is ridiculous! If you use symbols
in your program that are the same as you use in the equations describing the
system, the code should be easy to follow. Some comment statements to point
out the various sections of the program are fine.
For example, in distillation simulations the distillate and bottoms composition
should be called “XD(J)” and “XB(J)” in the program. The tray compositions
should be called “X(N,J),” where IV is the tray number starting from the
bottom and J is the component number. Many computer scientists put all
the compositions into one variable “X(N,J)” and index it so that the distillate is
X(l,J), the top tray is X(2,J), etc. This gives a more compact program but
makes it much more difficult to understand the code.