On Wed, Mar 18, 2015 at 8:03 AM, Oliver Haas
<oliver.sebastian.h...@googlemail.com> wrote:
> (Ignore the message earlier, I accidently hit send early)
> (Summary "TL;DR" at the end of the mail)
>
> Dear FiPy users and developers,
>
> I am currently solving a wider range of problems with FiPy and really like
> the package. I sincerely appreciate the work put into writing FiPy.
Thanks so much. It does help to have positive feedback from time to
time to help maintain our own interest and justify our work.
> However, solving even 2D problems can be rather slow, but I noticed some
> common traits in my simulations: Timestep, mesh and boundary conditions
> rarely or never change during a simulation run, thus the system matrix of
> the resulting equation system doesn't change. FiPy however creates the
> system matrix and does the LU decomposition (or another solver of course) at
> every time step.
> Instead it would be much more efficient to give an option in the solver to
> use the previous LU-decomposition for the new time step and only update the
> right hand side of the equation at every time step.
I believe this depends on whether the coefficients are changing, but,
certainly, when the coefficients don't change, there is no need to
rebuild the matrix. Even when the matrix does change, my understanding
is that the same preconditioner could still be used and fipy doesn't
do this currently. Our hope is that matrices could somehow behave like
Variable objects and only update when their dependencies change, but
that might be pushing the current framework too far. It might just be
easier to use the underlying matrix build and linear solve routines in
the script and allow the user to be explicit. It's a much simpler
change.
> I started implementing a solver which reuses the previously done
> LU-decomposition. This already works without any modifications to the rest
> of the FiPy code. The construction of the system matrix and right hand side
> however required me to modify some of the existing modules. Furthermore I
> would like to use cython to further speed up critical loops and
> calculations, which would further change some "core" FiPy modules and
> handling... In the end I think it is really worth it, considering I can see
> an up to a ~100 times speed up for simulations under the above mentioned
> conditions.
That's totally crazy. We should definitely figure out how to get your
changes merged back in.
I've used Cython on some bits of the code, but the changes were never
merged back in. This was to just implement lots of small matrix
operations efficiently, which is required for a Riemann solver.
See,
https://github.com/usnistgov/fipy/blob/riemann/fipy/tools/smallMatrixVectorOps.py
https://github.com/usnistgov/fipy/blob/riemann/fipy/tools/smallMatrixVectorOpsExt.pyx
I'm not sure whether this is the best way to structure things. Maybe
all the Cython functions should be kept separately in their own
directory. We can discuss though.
> I would appreciate contact to anyone who has developer experience with FiPy
> to discuss my implentations to keep them in line of the structure of the
> FiPy project/code.
Let's set up a video chat with Jon Guyer included. Email me offline
and we can set up a time.
--
Daniel Wheeler
_______________________________________________
fipy mailing list
fipy@nist.gov
http://www.ctcms.nist.gov/fipy
[ NIST internal ONLY: https://email.nist.gov/mailman/listinfo/fipy ]
