On Oct 8, 2008, at 1:54 PM, Angus Hendrick wrote:
So I went to upgrade my Numpy from 1.0.4 to 1.2.0, and I ran into a
problem with fipy. In particular "from numpy.core import ma as MA"
was causing problems. I rolled numpy back and now I'm fine again,
but it leads me to a couple of questions...
1. What is the most recent version of FiPy, and does it represent a
speed improvement over version 1.2.1? What is the svn checkout
command I need to run to get it? (I tried getting "current," a few
of months ago when I thought there was a 2.0.1a version around, and
I got 1.2.1 again, so I'm screwing something up.)
The latest "released" version of FiPy 1.2.1.
The "trunk" is at 2.0a1, for whatever it's worth; that revision number
has held steady for quite awhile as development continues. Our plan is
to actually start moving the trunk toward release and official
endorsement soon, but other work has taken priority.
I don't think there's any particular speed advantage one way or the
other, but proper benchmarking and profiling is one of the things
that's held up releasing 2.0.
We use the trunk exclusively for our own research and have suggested
that a few users switch when they needed a functionality that won't
ever be back-ported, however it is not a properly vetted release and
it does require some syntax changes in your scripts (which is why we
skipped from 1.x to 2.0).
It is possible to use `svn switch` to change your FiPy 1.2.1 checkout
to a trunk checkout, but I would recommend just doing a fresh checkout
of trunk, instead, and then you can switch between them with your
PYTHONPATH.
$ svn checkout http://matforge.org/svn/fipy/trunk
General svn instructions are in the manual and at <http://www.ctcms.nist.gov/fipy/svn.html
>, but as you've found, we don't move tags/STABLE and tags/CURRENT
around very often.
2. What is the latest version of Numpy that the newest version of
FiPy works with? What about the 1.2.1 version?
Tony Yu provided a patch for trunk that was applied in r2550 in order
to support NumPy 1.1, but it never got merged back to branches/
version-1_2. I just took a stab at applying it, as well as an earlier
patch for NumPy 1.0.4 (that apparently weren't causing you any
problems). An `svn update` (assuming you are checked out from branches/
version-1_2) should do the trick. I don't think I made things any
worse, but this is not thoroughly tested, and particularly has not
been tested with older versions of NumPy yet.
I use the trunk with NumPy 1.1; testing against 1.2.0 is on the to-do
list.
FiPy 1.2.1 (until patch r2744 that I just checked in) gets run against
NumPy 1.0.4 (although somewhat imperfectly). It's probably really only
safe against NumPy 1.0.2 or something.
Also, on a completely separate note, has anyone looked at the PyAMG
solvers for use with FiPy? I confess I don't really understand the
differences between different solvers, as I'm not a high-powered
numerics guy, but they (whoever "they" are) say that multi-grid
solvers are among the fastest for non-linear problems. Is there an
"easy" way to plug these into fipy so I can check them out and give
some feedback. By "easy" I mean where there's a file or two in FiPy
that I could create/edit to invoke them in lieu of the standard
solvers, translating things in and out, as necessary to make them
work.
We (I, at least) have not looked at PyAMG. We have done a lot of work
with PyTrilinos, which offers multi-grid, as well as lots of
preconditioners and other sugary goodness. Daniel has lots more
practical experience with it than I do. To use the Trilinos solvers,
you'll need trunk. PyAMG certainly looks worth a look at adding to the
available solvers.
