| Re: [eigen] ILU decomposition |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] ILU decomposition
- From: Peter Román <peterrom@xxxxxxxxx>
- Date: Sat, 5 Sep 2009 01:02:59 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=jDgXiMu4cqbsd1Eq5HkzkSl6wLhjz1US2Hgqleq00jo=; b=iqPJ/4kfDAoGakhA/fSNa82c9je5caClq/TfgnrcVNYl4xlI14ky9rQSiTYBAu5LQU QoDJqvHf2VsoNc65XnBPDJz72NPJB42RGFQCNYbKG+0NIXmtmJNpI/jE2qidqu4PJjlu RG8ThmX6DLjP9EYch68kTqLZpXIOGHhqp/iYE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=x5u2etMEq7d3lVZ1+32Wsl8vGkIjWQ1tLdeesxjqxZu/iPdh+v27KCxy7QRdszLlMD ZnPLqY3qTHIgPs6Nk0RZYXDyF0ndVrS5OFiQ4FTi/4H0d5uYbv6a6yuIxIZ8lYPgCgaB +CaB35x/JAAgnSZGjaHkwTln3YzpHE1/3CFqk=
Hi!
On Fri, Sep 4, 2009 at 5:56 PM, Gael
Guennebaud<gael.guennebaud@xxxxxxxxx> wrote:
> One (naive) question: why did you commented the line 399:
>
> m_sluEqued = 'B';
>
> I don't remember its purpose, so that's why I'm asking.
I commented it out because it does nothing, which had me confused.
The parameter is an input parameter if the system is already factored
(as in the solve function) and an output parameter when factoring. The
driver function will set it when factoring, indicating how the system
was scaled and pivoted. So specifying it doesn't make sense.
> On Fri, Aug 21, 2009 at 11:28 AM, Peter Román<peterrom@xxxxxxxxx> wrote:
>> I also looked into adding additional inputs for ILU specific option to
>> the SparseLU class, but it seems no two available ILU packages are the
>> same, so it gets messy.
>
> yes, but if some low level options which are specific to a given
> backend are quite important, then it is fine to add specific functions
> to control them.
I was looking into this. For simple uses of ILU, only providing a drop
tolerance is fine.
Adding a second drop criterion, giving the user more direct control
over memory consumption, could be nice. SuperLU has good support of
this, UMFPACK has none and with packages like ILUPACK, you can suggest
max memory consumption, but it will break it if it feels it's
necessary.
But I figured that for any non-trivial problem, the user would
probably need complete access to all options, anyway, so keeping it
simple seemed best. And at this moment, I personally only need very
basic ILU support :)
Perhaps there is some good way of exposing the options struct?
>> A (very minor) annoyance I have is that the default ordering method is
>> set as the default value of the flag parameter, so
>>
>> SparseLU<SparseMatrix<double>, SuperLU> ILU(A, IncompleteFactorization);
>>
>> leaves the ordering method undefined and thus generates an error message..
>
> yes, maybe using a unique union of bit flags was not a very good idea,
> and we should think to something more scalable, any suggestion is
> welcome.
Right now, I have other projects to worry about, but I will probably
need to use ILUPACK or maybe the ILU routines in ITSOL in the not too
distant future. At that time, I could look into writing backends for
those routines and improving ILU support in the SparseLU class
further.
Thanks :)
Peter