Numerical solution of DAE problems

Numerical solution of DAE problems
DAVIDE MANCA, GUIDO BUZZI-FERRARIS
CMIC Department, Politecnico di Milano P.zza Leonardo da Vinci, 32 – 20133 MILAN – ITALY
The paper describes a modern approach to the solution of Differential and Algebraic Equation (DAE) Systems
through a C++ routine: BzzDae belonging to BzzMath that is a freeware library. After an introduction on
BzzMath and the object oriented approach to numerical problems the manuscript focuses the attention on
the robustness and efficiency features that characterize BzzDae respect the Fortran routine counterparts. A
number of clarifications are given to describe the capabilities of BzzDae over the other solvers. Finally, a
quite simple but challenging case-study applied to catalytic oxidation is reported to quantify the performance
improvement of BzzDae while emphasizing its robustness.
Keywords: DAE systems, numerical solver, efficiency, robustness, object oriented programming.
The solution of applied numerical problems dealing with
the integration of Differential and Algebraic Equation (DAE)
Systems calls for the adoption of a suitable solver. The
complexity of the problem resides mainly in the intrinsic
stiffness of the DAE system as reported by Shampine in
1985. This means that specific attention has to be paid to
both numerical methods and solver routines. In fact, the
DAE problem is quite challenging, not only for the precision
required, but also in terms of robustness and efficiency.
For example, when combustion processes are involved,
the robustness feature can be referred to sudden ignitions,
steep profiles, high gradients, cool flames, and highly
discontinuous temperature, pressure, and concentration
profiles. On the other hand, the efficiency feature is mainly
concerned with numerical simulations that can take
several hours of CPU time. The relevant number of
equations, the structure of the Jacobian matrix (banded,
block, sparse) as well as its evaluation and update are of
paramount importance when trying to address the
efficiency feature. This manuscript presents the BzzDae
solver, which is an object oriented class written in C++,
belonging to the BzzMath library [6, 17].
Generally speaking, BzzMath can be though of a
software library for the solution of specific numerical
problems. Actually, BzzMath can be better defined as a
numerical project that was born more sixteen years ago
to address and solve applied numerical problems. Large
projects on scientific computing date back to the seventies
of last century with well-known packages such as IMSL
from Visual Numerics and NAG from NAG Ltd. Both libraries
were first developed in Fortran. In the following, less
successful and extended versions were ported also to C,
C++ and finally to Java. C++ was a catalyst for this rapid
evolution in the programming world. Both operating
systems and compilers, in a cyclic and virtuous interaction,
took advantage from object orientation and allowed
building new development tools that were more and more
powerful and user friendlier. As it is often recommended
when programming techniques are involved, a clear cut is
better than a progressive migration. A sudden switch from
old legacy code, developed in Fortran 66 and 77, to the
new way of thinking in C++ allowed starting from scratch
the BzzMath project. No previous Fortran code was ported
nor translated to C++. First of all a new way of conceiving
the implementation of a numerical algorithm within the
C++ language had to be understood and finally
implemented. There was need for organizing and
* davide.manca@polimi.it
410
structuring a numerical method into an object. Actually,
the procedural approach is put aside from C++; no more
separation between routines and data is allowed. A C++
object contains (encapsulates) both data and instructions.
A C++ object belongs to a class that exports methods and
properties to exchange data and actions with other objects.
A program puts together one or more objects that finally
interact with the user in terms of input and output data
(numbers, strings, diagrams, windows, objects).
The BzzMath project
Starting from the main three features of C++:
encapsulation, polymorphism and inheritance [15] an
articulate tree of classes was progressively coded into
BzzMath to cover the following numerical analysis topics:
vectors, arrays, complex numbers, linear algebra, root
finding, non linear algebraic systems, ordinary differential
equations and differential algebraic equations with initial
conditions, linear and non linear regressions, mono and
multidimensional unconstrained optimization,
interpolation and quadrature. Some algorithms are still
under development: constrained optimization, ODE
systems with boundary conditions, partial differential
equations. Each of the aforementioned numerical subjects
branches into several other subclasses that are meant to
solve dedicated problems whose structure is well defined
and peculiar.
One of the advantages of C++, i.e. inheritance, allows
to simply developing a new customized class of objects
that inherits the properties and methods of the parent class
while implementing new features and superimposing other
characteristics. BzzMath was developed with a main
objective in mind: analytical rigor in the implementation
coupled to easiness for the user. The user is guided and
preserved from common coding errors. It is rather
impossible to overwrite input data, to destroy reserved
properties or to make an inconsistent use of available
methods within a BzzMath object. This feature is of
paramount importance since it avoids either devious
runtime errors or semantic mistakes. A further objective
that deeply characterized the programming approach of
BzzMath is efficiency coupled to robustness. Robustness
is for sure preferred to efficiency in the sense that the first
issue to be addressed is the algorithm and code robustness.
Once robustness is achieved then comes efficiency that in
the world of numerical analysis means CPU time
optimization. This feature was always pursued by
REV. CHIM. (Bucureºti) ♦ 58 ♦ Nr. 4 ♦ 2007

numerically fine tuning the algorithm through
measurement of benchmark problems and comparison
with both freeware and commercial routines. Contrary to
common sense, it happens frequently to find public domain
routines that are far better than commercial counterparts
both in terms of features and performance. When we
speak of benchmark problems we do not refer to literature
case studies only, but also to applied and challenging
problems that require significant amounts of CPU time.
Frequently, the BzzMath project released new classes
specifically intended to solve and improve difficult
numerical problems coming from several branches of
chemical engineering calculus.
BzzMath is available on the Internet at
www.chem.polimi.it/homes/gbuzzi/ and is downloadable
as freeware software for non commercial use. A
compressed archive of about 20 MB contains hundreds of
files and dozens of directories well organized in a
hierarchical structure.
Numerical methods and routines for DAE systems
Before addressing the DAE subject, it is worth spending
some words on the numerical algorithms for the solution
of ordinary differential equation (ODE) systems. As the
ancestors of DAE packages, ODE solvers share several
peculiarities and a common theoretical background with
them. Starting from DIFSUB [12] and passing to GEAR [13],
LSODE [14], VODE [4, 9] and BzzOde [7], the improvement
in terms of the features and capabilities of ODE solvers
has been continuous, mainly in terms of robustness and
efficiency. As far as the DAE systems are concerned,
besides the well known LSODI routine [14], the most
recent decades were characterized by the evolution of the
DASSL routine [18] into DASPK [5] and by the introduction
of BzzDae ]16]. Other integration routines such as: LIMEX
from Nowak and Zugck [11], DAESOL from Bock [1] and
SPRINT [2] are also mentioned in the literature but are not
so widely diffused as the previous ones. The aim of this
paper is to present and discuss a few modifications and
numerical expedients introduced into BzzDae respect the
well known Fortran routines to increase the computational
efficiency of the methods while overcoming their
numerical instability.
Usually speaking, when chemical engineering problems
are involved, the dynamic simulation of a process/system/
equipment calls for the solution of a differentialalgebraic
equation (DAE) system. The differential equations, which
describe the time or space evolution of the investigated
system are often first order with initial value conditions.
The algebraic portion usually comes from equations of
state, chemical and physical equilibria, stoichiometric
consistency and boundary conditions. As before said, a
quite important feature of DAE systems is their intrinsic
stiffness [20]. As a consequence, a dedicated numerical
routine must be adopted when solving these stiff problems.
Often the simulation of such processes is quite challenging
in terms of: precision (unbalance in the dynamics of
reactants/products and radicals) efficiency (a simulation
can take more several hours and even days of CPU time)
and robustness (short-lived species, sudden ignition, steep
profiles, high gradients) here following is reported a rather
concise description of the main features of BzzDae.
On the robustness side BzzDae is characterized by the
following features:
1.If the real modeled problem is based on variables that
are physically bounded, the only Fortran routine able to deal
with constraints is DASPK. DASPK apparently allows
assigning a nonnegative constraint to the solution vector
REV. CHIM. (Bucureºti) ♦ 58 ♦ Nr. 4 ♦ 2007
y throughout the integration path. By setting an internal
index, when calling DASPK, the user can specify that
should not be negative. This option is the first step towards
the extended feature of BzzDae that allows specifying both
minimum and maximum constraints. With reference to
DASPK, if the model subroutine (FEX) comprises functions,
which cannot accept negative arguments, then the
integration program will abort during the execution, with a
floating point exception, as soon as y becomes negative.
This could seem to be nonsensical since DASPK has been
informed that negative y elements should be avoided. The
problem is that DASPK checks for nonnegative values,
setting the negative variables equal to zero, only after the
corrector procedure has reached the convergence within
the required precision limit. This means that if, during the
predictor step or the corrector iterations, any value of y
become negative, the solver will not take any action to
overcome the negative value problem. This is the reason
for the possible math error here described. The DASPK
solver also relies on another method to address this issue:
the user can check the consistency of input vector
through a communication status variable and immediately
return the control to the solver. In this case, DASPK reduces
the step size and checks again the convergence within the
corrector, but if the integration routine, at the last successful
step n, has found and then any predictor
action on the following n+1 step will be negative
: inducing DASPK to reduce the step size
indefinitely, until DASPK finally aborts the integration
procedure due to a step size h → 0. The correct approach
to the constrained problem should come from the DAE
solver in terms of decisions to be made at each step of the
integration procedure. This is the only way in which the
DAE system routine is safe and math errors are avoided a
priori. Within BzzDae the user (if required by the problem’s
nature) simply assigns the maximum and/or minimum
constraint vectors. The solver automatically handles the
constraints, taking care not to violate the assigned bounds.
The control is performed before passing any illegal values
to the DAE system routine. The correction vector, b, is
accepted only when the nonlinear system, resulting from
the DAE problem, is accurately solved within the assigned
precision and, at the same time complies with the
constraints. Doing so, the DAE function is always computed
with safe values.
2.BzzDae adopts a stabilization technique when
repeated convergence failures occur. The integration order
is automatically reduced to one and the DAE solver restarts
from the last successful convergence point. By doing so,
the numerical problem becomes completely consistent as
shown in detail by [7] and [16].
3.Both the order and step size are reduced when there
are convergence problems.
4.As suggested by [3] the order is reduced when the
elements of the Nordsieck vector are not decreasing.
On the efficiency side BzzDae is characterized by the
following features:
1.As it happens within DASPK, and contrary to LSODI,
there is a distinct memory allocation for both the Jacobian
matrix, J, and its factorization G =(I - hr o
J). A direct
consequence of such a feature is an overall efficiency
improvement since when a different step size or method
order is chosen, there is no need to reevaluate the Jacobian
matrix, J, and then superimpose its factorization, G, that
is needed by the nonlinear system solver based on the
Newton method. Most of the DAE chemical problems have
the following characteristics: (1) each function evaluation
(DAE system) is highly time consuming, (2) the Jacobian
411

matrix, J, is evaluated numerically by finite differences, (3)
the number of equations is quite relevant. From this point
of view, it is evident that function evaluations have the
greatest impact on the CPU time [15]. The Jacobian
evaluation becomes more and more exacting when the
equations number increases.
2.BzzDae follows a different criterion with respect to
DASPK in determining when to update the Jacobian matrix.
The first significant difference is that BzzDae checks
whether J is out of date through the following equation:
, where
are the variables at the and iterations n +1 and is the
time derivative of the DAE system. When the equations
number, n eq
, is high, the Jacobian numerical evaluation is
rather time consuming so it is advisable to delay the update
of J as far as possible. Conversely, if the system has few
equations, it is convenient to evaluate J more frequently
in order to increase the Newton method efficiency with a
reduced effort. Due to these considerations, BzzDae
evaluates a new Jacobian matrix at most after m steps,
with m function of n eq
. Since the Jacobian consistency is
controlled in a deeper and more accurate way, respect to
the conventional DAE routines, it is also safer to increase
the maximum allowed steps performed, by keeping the
Jacobian matrix constant.
3.DAE systems characterized by sparse and not
necessarily structured Jacobian matrices can be easily
solved by exploiting the automatic memory allocation and
matrix rearrangement of the C++ classes.
The aforementioned features improve the overall
performance of BzzDae when dealing with problems
characterized by:
DAE systems with Jacobian matrices with complex λ
eigenvalues having a negative real part Re(λ) < 0 and a
large imaginary part |Im(λ) >>1. Physically speaking this
means: highly oscillating problems;
DAE systems with large discontinuities in the derivatives
(i.e. discontinuous or piecewise physical properties, IF …
THEN structures, code branching);
DAE systems that require constrained integration
variables, i.e. the dependent variables, , must belong to a
feasible interval defined by lower and/or upper bound
vectors.
BzzDae integrates DAE systems of index 1 and 2 in the
form: .
In contrast with the DASSL/DASPK approach, BzzDae
normalizes the algebraic portion of the Jacobian matrix by
the step size: . With reference to the Jacobian matrix, G, of
the nonlinear system, the BzzDae formulation exploits the
following structure:
as opposite to the DASSL/DASPK structure:
where: y 1
are the differential variables, y 2
are the algebraic
variables, h is the stepsize and r o
is the first coefficient of
BDF method. In [3] the user is suggested to divide the
412
algebraic equations for a constant proportional to h. The
DASPK guide (Brown et al., 1992) suggests to multiply the
algebraic equations by a constant which is proportional to
the inverse of the stepsize . Since the second row elements
of the original G matrix are multiplied by h, it is correct
and advisable to automatically simplify such elements
through an a priori division by h. This simple trick
significantly increases the robustness and precision of the
solver.
An applied case-study: Methanol oxidation to
formaldehyde in a gas-solid tubular catalytic reactor
For the sake of conciseness, we will report only one
applied numerical case-study. A larger number of casestudies
can be found in [16]. The proposed case-study is
based on the simulation of a fixedbed catalytic reactor.
Catalyst pellets of a few millimeters are placed in small
diameter tubes. Process gas flows through the catalyst and
an external fluid removes reaction heat. The catalytic
oxidation of methanol, as well as the successive oxidation
of formaldehyde on a Fe-Mo catalyst, were studied and
modeled by [10]. Relevant kinetic and catalyst data are
given in that paper.
The DAE system, describing the mass and energy
balances on gas and solid phases is constituted by only 7
differential and 6 algebraic equations[16]. This system is
numerically solved by five different numerical routines:
BzzDae, DASPK, LSODI, SPRINT and VODEBUNLSI. The
coupled VODEBUNLSI routine solves the algebraic
equations within the differential system with a very efficient
nonlinear algebraic solver: BUNLSI [8]. Two different
conditions are here considered. The first, and most severe
one, allows the robustness of BzzDae to be demonstrated.
Actually, this routine was the only one capable of finalizing
the integration. The second situation (mild condition), still
very simplified, compares the relative performances of the
different codes.
Case 1- Severe operating condition
A stream containing 5% molar fraction of methanol in
air feeds the aforementioned tubular reactor.
Concentration is rather close to the lower flammability limit
of the mixture. The integration is performed for one of the
several thousands of tubes that are externally refrigerated
by a cold fluid at constant temperature.
Table 1 shows how BzzDae is able to integrate the DAE
system up to the total reactor volume, evaluating 1035
functions and 17 Jacobians. On the contrary, DASPK,
LSODI, SPRINT and VODEBUNLSI fail the integration due
to a recurring problem in the molar fraction of methanol
that, being consumed by the partial oxidation, becomes
numerically negative. Since the kinetic equations require
the square root evaluation of the molar fractions, it is
evident that a mathematical error takes place as soon as
such variables become negative. No effective improvement
is taken in DASPK even if the user specifies that the
dependent integration variables should be positive. As
discussed in the previous section, such lower nonnegative
bounds are considered only after a successful step is
performed. In this case, it is necessary to preserve the
system consistency along all the numerical evaluations
since no negative mass fractions should be assumed.
It seems relevant to observe that it is not convenient
and it would not be correct, in terms of both numerical
consistency and physical conditions, to force or to modify
the integration variables within the system routine. For the
sake of clarity, it is not convenient to force negative
variables to zero or to assume absolute values, when a
REV. CHIM. (Bucureºti) ♦ 58 ♦ Nr. 4 ♦ 2007

Table 1
METHANOL OXIDATION: SEVERE OPERATING CONDITION
Table 2
METHANOL OXIDATION: SMILD OPERATING CONDITION
square root is involved. Actually, the usermodified system
can generate unexpected discontinuities either in the
functions or in the derivatives, with the consequent failure
of the multi-value solver.
Case 2 - Mild operating condition
A simpler and smoother solution is obtained when the
inlet stream has a lower methanol fraction (2% mol). In
this case, the five routines were able to cover the whole
integration interval and produced the same results. Table
2 reports the statistics of the computations in terms of
relative CPU time, integration steps, function and Jacobian
evaluations. In this example, the enhanced efficiency of
BzzDae is still evident.
Conclusions
When addressing DAE problems, the presented
examples clearly single out two major points. It is very
advantageous to make use of DAE solvers and to avoid any
decoupled implementation of the differential and the
algebraic portions. The performance losses are evident
when solving the algebraic portion inside the ordinary
differential system.
A second relevant aspect refers to the boundaries on
the integration variables. As a matter of fact, the direct
manipulation made by the solver itself of the lower and
upper limits within the predictor/corrector steps is a critical
feature in terms of both robustness and efficiency.
Robustness and efficiency are not two antithetic terms.
Conversely, when the numerical solver encompasses a
crisis, during the DAE integration, the increment in
robustness is tightly coupled to a performance
enhancement. In this sense a robust numerical routine
REV. CHIM. (Bucureºti) ♦ 58 ♦ Nr. 4 ♦ 2007
should be able to debottleneck several stagnant situations,
with evident performance improvements.
The adoption of C++ classes for the solution of both
ODE and DAE systems is not a problem also working in
Fortran. A mixed language approach makes the integration
seamless and effective. There is no need to modify the
Fortran structure of the program. A direct call to the C++
numerical solver is even simpler than calling the Fortran
counterpart.
References
1. BAUER I., F. FINOCCHI, W.J. DUSCHL, H.-P. GAIL , J.P. SCHLÖDER,
Simulation of chemical reactions and dust destruction in protoplanetary
accretion disks, Astron. Astrophys., 317, 1997, p. 273
2. BERZINS M., R. M. FURZELAND, A User’s Manual for SPRINT - A
Versatile Software Package for Solving Systems of Algebraic Ordinary
and Partial Differential Equations: Part 1 - Algebraic and Ordinary
Differential Equations, Report TNER.85.058, Shell Research Ltd,
Thornton Research Centre, Chester, 1985
3. BRENAN K. E., S. L. CAMPBELL ,L. R. PETZOLD, Numerical Solution
of Initial-Value Problems in Differential-Algebraic Equations, North-
Holland, New York, 1989
4. BROWN P.N., G.D. BYRNE, A.C. HINDMARSH, VODE: A Variable
Coefficient ODE Solver, Siam J. Sci. Stat. Comput., 10, 1989, p, 1038.
5. BROWN P.N., A.C. HINDMARSH, L.R. PETZOLD, A Description of
DASPK: A Solver for Large-Scale Differential-Algebraic Systems,
Lawrence Livermore National Report UCRL, 1992
6. BUZZI-FERRARIS G., Scientific C++: Building Numerical Libraries
the Object-Oriented Way, Addison Wesley Longman, New York, 1993
7. BUZZI-FERRARIS G., D. MANCA, BZZODE, A New C++ Class for the
Solution of Stiff and Non Stiff Ordinary Differential Equation Systems,
Comp. & Chem. Eng., 22,11, 1998, p. 1595
413

8. BUZZIFERRARIS G., E. TRONCONI, Comp. & Chem. Eng.., 10, 1986,
p. 129
9. BYRNE G.D., A.M. DEAN, The Numerical Solution of Some Kinetics
Models with VODE and CHEMKIN II, Comp. & Chem. Eng., 17 (1993)
297-302.
10. DENTE M., R. Poppi, I. Pasquon, Chim. Industria, 46,1964, p. 1326
11.DEUFLHARD P., U. NOWAK, Extrapolation Integrators For Quasilinear
Implicit Ode’s, University Of Heidelberg, SFB 123, Tech. Rep. 332, 1985,
12. GEAR C.W., Algorithm 407, DIFSUB for Solution of Ordinary
Differential Equations, Comm. ACM, 14, 3, 1971, p. 185
13. HINDMARSH A.C., GEAR: Ordinary Differential Equation System
Solver, Report UCID 30001, Rev. 3, Lawrence Livermore Laboratory,
Livermore, CA, 1974
14. HINDMARSH A.C., LSODE , LSODI, Two New Initial Value Ordinary
Differential Equation Solvers, ACM SIGNUM Newsletters, 15 , 1980,
p. 10
15. MANCA D., T. FARAVELLI, G. PENNATI, G. BUZZI FERRARIS AND E.
RANZI, Numerical Integration of Large Kinetic Systems, ICheaP-2 Conf.
Ser., ERIS, 1995, p. 115
16. MANCA D., G. BUZZI-FERRARIS, T. FARAVELLI, E. RANZI, Combust.
Theory Modelling, 5, 2001, p. 185
17. MANCA D., G. Buzzi-Ferraris, BzzMath: an Object Oriented
Numerical Project, Proceedings of ICheaP 7, Taormina Italy, 15-18 May,
2005
18. PETZOLD L.R., A Description of DASSL: a Differential/Algebraic
System Solver, Scientific Computing, R. S. Stepleman et al. (Eds.), North-
Holland, Amsterdam, 1983
19. RADHAKRISHNAN K., A. C. HINDMARSH, Description and Use of
LSODE, the Livermore Solver for Ordinary Differential Equations, NASA
Ref. Publ. 1327, Livermore, 1993
20. SHAMPINE L.F., What is Stiffness Stiff Computation, R. C. Aiken
ed., Oxford University Press, New York, 1985
Manuscript received: 10.04.2007
414
REV. CHIM. (Bucureºti) ♦ 58 ♦ Nr. 4 ♦ 2007