[SciPy-dev] Abstract vectors in optimization

Robert Kern robert.kern@gmail....
Tue Jan 6 15:53:22 CST 2009


2009/1/6 Ben FrantzDale <benfrantzdale@gmail.com>:
> David,
>
> Thanks for the reply. Let me describe the problem I've thought most about to
> give you a sense of where I am coming from:
>
> The optimization problem I have worked most with is atomistic simulation
> (particularly relaxation) in which you have millions of atoms all
> interacting with a force function. The force function is sparse but as the
> atoms move, the sparseness pattern changes (with sparseness structures that
> can be updated automatically when the state vector is "moved"). Furthermore,
> the atoms can be distributed via MPI, so while they happen to be a size-3n
> array of doubles locally, local atom 1,234 at one moment may not be the same
> atom as local atom 1,234 at the next step. (I don't know the details of
> PyMPI or how garbage collection might interact with MPI, but using SciPy for
> massively-parallel optimization is another motiviation for this post.)
>
> A common solver to use to relax the state of this sort of system is
> nonlinear CG. However, I've seen many separate implementations of CG
> hand-written to operate on these data structures. As a software engineer,
> this is sad to see; really one nonlinear CG solver should be reusable enough
> that it can be dropped in and used. I tried writing a sufficiently-generic
> CG solver in C++, but designing the right family of types, particularly with
> memory-management issues in mind, got out of hand. Given the cost function
> is the expensive part of the sorts of problems I am interested in, the
> overhead of Python is tiny, and SciPy has nice optimization libraries, which
> lead me to consider generalizing SciPy functions.

The solvers in scipy.sparse.linalg are already black-boxed enough for this.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


More information about the Scipy-dev mailing list