Thanks much for that, it was very helpful. I'll proceed to update fipy and numpy in an organized fashion and make sure I don't break anything. I believe PyAMG requires svn versions of numpy, so probably not ready for prime time. However, my my impression is that it is a black-box solver system (suitable for people like me), as opposed to PyTrillinos which from the reading I've done seems to require a little more careful handling and setup. I'd be interested to hear how challenging it is to get up and running with PyTrillinos.
Retreating to more mundane topics, I'm solving the heat equation on a grid of discontinuous conductivities. Though I initially thought of the problem as having a conductivity in every cell, I realized that this is only a "shadow" of the problem as it is solved by FiPy, since the cell variables are converted to face variables. To make sure I had control over this process, I went ahead and explicitly created a FaceVariable conductivity and used the getHarmonicFaceValue (vice getArithmeticFaceValue) to convert my CellVariable conductivities into the appropriate FaceVariable values. Based on how the solver is thinking about the problem, I've concluded that the right way to visualize the results is by plotting big dots whose colors correspond to temperatures at the cell centers, and then connect the dots by lines whose widths are proportional to the conductivities between the cells. My question is this: since i'm using a rectangular non-square mesh, do I need to adjust the face values I stored by some geometric parameter to get the right conductivities for my visualization? Best Regards, Angus Hendrick On Wed, Oct 8, 2008 at 1:18 PM, Jonathan Guyer <[EMAIL PROTECTED]> wrote: > > > 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. > > >
