|
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
|