Pedro Mendes wrote:
> In article <33865943.D1BA850 at ix.netcom.com>, rphair at ix.netcom.com> says...
> >Does anyone here have experience with ODE solvers that can handle
> >hundreds or even thousands of state variables? Has anyone explored
> >the computability questions surrounding such large systems?
>> This is not a new problem. In physics they have to deal with this all
> the time. For example in computational fluid dynamics (CFD) there are
> usually very large systems of ODEs to solve. The standard solvers in
> ODEPACK are quite capable of handling very large systems. Specifically
> the one used in GEPASI and SCAMP, named LSODA, is very good for this.
> This integrator has an added advantage in that it measures the
> stiffness of the equations throughout the integration and uses either
> the BDF or Adams methods, if the equations are stiff or non-stiff
> respectively (it is a variable step size, variable order, variable
> method algorithm).
I just want to back up Pedro's point: System size, of itself, is no
longer a big deal. I routinely solve coupled systems of PDEs on a
fairly fine mesh using a relatively modest system (100 MHz
AlphaStation). The discretization of a PDE is a (usually large) set of
ODEs. My systems reduce to a few hundred ODEs and this is no problem.
On one of my newer Sun Ultra workstations (which are currently busy
doing something else), I could probably run systems of thousands of ODEs
without getting too bored waiting for the output.
System size can become a problem if the system under study is badly
behaved. What do I mean by badly behaved?
1. The system is stiff. Stiff systems no longer
need cause serious difficulties. Large systems
of equations (as mentioned above) aren't necessarily
a problem. However, systems which are large and
have more than three or four distinct timescales (common
in chemical systems of moderate size) can eat up
a lot of CPU cycles.
2. Variables need to be accessed randomly from a large array.
Systems arising from PDEs are often particularly
well-behaved because the variable references are
semi-local, i.e. to compute derivatives I need
access to variable values stored in memory near
each other. Even coupling of PDEs is OK because
we then tend to reference only a few slices of memory
and modern caching algorithms can detect that and
deal with it. Problems arise when the variables
are accessed more-or-less randomly. The memory
cache is constantly being missed and CPU cycles are
wasted waiting for appropriate data to be sucked in.
It seems to me that large metabolic models are likely
to fall into this category (especially if the equations
are generated automatically by a computer from a database)
unless some special effort is made to order the ODEs to
minimize this problem.
There are some other hardware and software issues. One of the
reasons that I use Unix workstations for my work is that this kind of
machine generally delivers much better floating-point performance than
Intel hardware. Clock speed isn't everything. Architecture
(pipelining, cache design and size, etc.) plays a big role, as does the
compiler. The Unix vendors generally have much more demanding customers
than Intel/Microsoft do (no slight intended, to anyone) so there's a
tendency for their software products to squeeze every last bit of
performance out of the hardware. (Note the words of caution used above:
"generally" and "tendency". I don't want to start a flame war.)
Marc R. Roussel
(roussel at henri.chem.uleth.ca)
Department of Chemistry
University of Lethbridge
