Currently, the matrix is deleted after every sweep or timestep. It would be very easy to maintain a copy of the matrix. However, figuring out whether to rebuild the matrix or not will not be so easy. I guess you could keep a record of whether the coefficient has changed and only rebuild whenever that occurs. Also, if you know a priori the matrices that are fixed then you could pass a user controlled flag.
Confining calculations to certain rows or blocks of the matrix would be difficult and I'm not sure how much it would save. At some point every entry needs to be queried to see if it needs to be updated and another array needs to be maintained that knows the cells that have changed, There are really two aspects. The first is rebuilding the numpy arrays that are used to populate the matrix and the second is actually putting the values into the matrix. I'm assuming that it is these operation that need to be localized. Correct? Do you have some profiling data that you can post back to the list. This would be very helpful. On Sun, Dec 28, 2008 at 8:46 PM, Angus Hendrick <[email protected]> wrote: > 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 >> > > -- Daniel Wheeler
