Hi, My use of fipy entails using it as an engine inside an iterative optimization scheme. In a domain with a fixed source and set of boundary conditions, I repeatedly solve the diffusion equation on a domain where I am changing the conductivity (subject to constraints). Most of my optimization algorithms are variations on simulated annealing wherein I am changing only two cells in the domain at each iteration.
Given that the slowest part of the solving process is building the matrix, it seems like it would be productive (for me) to develop a modification to the fipy matrix builder that updates rather than rebuilds the matrix based on changes to the conductivities. I'm going to try to tackle this and I'd be grateful for any pointers. Best Regards, Angus Hendrick On Sun, Dec 28, 2008 at 3:51 PM, Daniel Wheeler <[email protected]>wrote: > > > Hi Angus, > > On Sat, Dec 27, 2008 at 4:51 AM, Angus Hendrick > <[email protected]> wrote: > > Hello: > > > > Attached is a suggested revision to the fipy/tools/inline/__init__.py > file. > > The change creates another way to invoke inline using an environment > > variable called FIPY_INLINE, which can be set to "true" or "false". I > use > > fipy in a multi-core environment to run parallel jobs using ipython. I > > don't know how to control sys.argv on the different engines, but they can > > all see the environment variables, so this works. > > This is a good idea. It makes sense that command line arguments should > also be set via the environment and this is mostly the case in fipy. > I'll take a look at your changes and try and include them > > > Also, I have noted that the pysparse solvers can sometimes produce bad > > results for diffusion problems with variable properties, but the trilinos > > LinearGMRESSolver has been robust and about 2-4x as fast. > > My experience also. I also have even better results when I employ the > Trilinos preconditioners. You might note that Dominique Orban is > giving pysparse a good overhaul and some of the changes that are > planned involve fixing the CGS solver for one thing. > > > Finally, for anyone else using Trilinos 9.0.1 with Python 2.5 (or later) > in > > a 64-bit machine where dl.so is not built, the first try clause in the > > __init__.py file for PyTrilinos needs to have the two exceptions grouped > > with parenthesis, as the two exceptions are not implicitly tupled. (I > sent > > this to the Trilinos folks too). > > Thanks for the note, I've just rewritten the trilinos installation > instructions so I'll include this tidbit. You might also like to note > that I recently rewrote a few of the trilinos multilevel > preconditioner classes in fipy to correctly set the parameters for > common preconditioner types as stated in the ML manual. > > < > http://matforge.org/fipy/browser/branches/termMultiplication/fipy/solvers/trilinos/preconditioners/multilevelDDMLPreconditioner.py > > > < > http://matforge.org/fipy/browser/branches/termMultiplication/fipy/solvers/trilinos/preconditioners/multilevelDDPreconditioner.py > > > < > http://matforge.org/fipy/browser/branches/termMultiplication/fipy/solvers/trilinos/preconditioners/multilevelNSSAPreconditioner.py > > > < > http://matforge.org/fipy/browser/branches/termMultiplication/fipy/solvers/trilinos/preconditioners/multilevelSAPreconditioner.py > > > > Cheers > > -- > Daniel Wheeler > >
