From: Daniel W. <dan...@gm...> - 2012-05-17 16:54:52
|
On Thu, May 17, 2012 at 12:33 PM, Dominique Orban <dom...@gm...> wrote: > On Thu, May 17, 2012 at 12:18 PM, Daniel Wheeler > <dan...@gm...> wrote: >> Is it time for a new release? Dominique has done a lot of work since >> 1.1.1 if I remember rightly. I believe there was something holding up >> a release a year or two back, but I can't remember what that was. > > The last thing I did is use the version of UMFPACK that comes with > SuiteSparse. The code is in the suitesparse branch. My hope was to > pave the way to interfacing other factorizations (CHOLMOD and > SuiteSparseQR are my two targets), but time is short. > > Also I'm wondering if we should phase out SuperLU. I'm not having much > success with it. Its only advatange is to run in parallel. Just a > notion. I assume you mean that you would remove pysparse/direct/superlu and only have pysparse/direct/umfpack. I'll leave that up to you. The only requirement that I have right now is that the code snippet at then end of pysparse/__init__.py still works in some way that doesn't break everything in fipy. Probably, the best thing to do is to deprecate it now and remove it sometime in the future (or make it work with UMFPACK and give a warning that superlu is not using SuperLU but something else to do LU). The code snippet is this: {{{ class _superlu: @Deprecated('Use pysparse.direct.superlu.factorize instead.') def factorize(self, *args, **kwargs): import pysparse.direct.superlu self.factorizeFnc = pysparse.direct.superlu.factorize return self.factorizeFnc(*args, **kwargs) superlu = _superlu() }}} so that {{{ from pysparse import superlu }}} still works. Actually, I need to switch fipy over to the new import system of pysparse. I'll do that today or tomorrow while it is on my mind. Cheers -- Daniel Wheeler |