Kiva is is one of the earliest CFD-programs that could be used to compute the spray, ignition and combustion in the internal combustion engine. The first version of Kiva was published in the mid 80's.
Kiva is written in Fortran 77. It is sold as a source code.
In this article Kiva is evaluated from the programmer's point of view.
Kiva was bought to ICEL in the late 90's. I installed the program on different platforms. Kiva is delivered as a big single file. For that reason I used fsplit to split Kiva in its subroutines. After that I made the makefile with the makemake-script.
I have implemented the ETAB droplet breakup model in Kiva according to professor Tanner's advice to an older version of Kiva. I was the only one in ICEL, who was able to implement ETAB in Kiva without visiting MichiganTech.
I have written a Kiva-version, in which many drawbacks of Kiva are corrected. ICEL owns this code.
Kiva is the product of its time. In those days the computers didn't have much memory and the performance of the computers was poor. The code had to be optimized for these things. From the programmer's point of view, these make the code difficult to update and develop.
The original Kiva is written in lower-case letters. According to Fortran 77 -standard they should be capital letters. Kiva uses include-files, which are unknown to Fortran 77 -standard. I have never used a Fortran compiler that does not support these two unstandardized features. Thus Kiva can be compiled with most Fortran-compilers.
Kiva doesn't have strong encapsulation between its subroutines. This is a great drawback.
Kiva uses one huge comkiva.i file, which includes all the named common-areas. Almost every subroutine uses comkiva.i. This is one reason that everything depends on everything in Kiva.
The computed results must often be compared to a small number, which is usually the machine constant. The value of the machine constant depends on the computer.
In Kiva the small number is given as a number for example 1.0E-16 in every situation it is needed. It should be given as a constant in an include file. Now it is difficult and time-consuming to change the small number for different platforms.
In Kiva it is often tested, if two floating point numbers are equal to each other for example X1 .EQ. X2. This should never be done. The absolute value of the difference of these numbers must be compared to a small number for example ABS (X1 - X2) .LT. SMALL. If the absolute value of the difference is smaller than the small number, then the floating point numbers are assumed equal.
Kiva uses EQUIVALENCE-sentences to save the computer memory. These EQUIVALENCE-sentences are a potential error source. The error in EQUIVALENCE is very difficult to detect. There is no reason to use these sentences any more.
Kiva has a formatted input file. Every decimal point must be in the right column and so on. There exist no error check, if the values have any sense. The values must be given in the right order, but the code has no error checks for this order.
Many difficulties in Kiva computation are caused from errors in the input file. There is no reason, why the input file should be formatted.
The main programmer of Kiva Anthony Amsden has retired. The development of Kiva is not very active.
I don't recommend to use Kiva any more. Kiva has grown too large for its programming methods. It should be completely rewritten using modern programming methods. Both human and economical resources are wasted when working with the current Kiva. It has no future in this form.
I recommend to look at the free OpenFOAM-code instead of Kiva.