[petsc-dev] PETSc LU, Lapack and Preconditioning Matrices
Barry Smith
bsmith at mcs.anl.gov
Sat Dec 17 10:43:41 CST 2011
On Dec 16, 2011, at 10:26 PM, Dave Nystrom wrote:
> Barry Smith writes:
>> Dave,
>>
>> Band solvers (like in LAPACK) handle all the matrix entries from the band
>> to the diagonal as nonzero (even though in your case the vast majority of
>> those values are zero). General purpose sparse solvers like PETSc, MUMPS,
>> SuperLU etc explicitly handle only the nonzero values and fill induced by
>> those nonzero values. By first reordering the matrix sparse direct solvers
>> end up having much much less fill than a bandsolver and hence are much
>> faster. Band solvers only make sense when the matrix is dense within the
>> band and not mostly empty like with PDE problems.
>
> Hi Barry,
>
> Thanks for this detailed and useful explanation. That helps a lot. I'll
> cross band solvers off my list of things to investigate. Should I expect
> much improvement using MUMPS or SuperLU via PETSc?
Not sequentially. But they run in parallel so can do much larger problems.
Barry
> I'm looking forward to
> giving them a try. I'm also looking forward to seeing what I can do with a
> separate preconditioner matrix.
>
> Thanks again for your reply.
>
> Cheers,
>
> Dave
>
>> Barry
>>
>> On Dec 16, 2011, at 6:12 PM, Dave Nystrom wrote:. .
>>
>>> Matthew Knepley writes:
>>>> On Fri, Dec 16, 2011 at 9:37 AM, Dave Nystrom <dnystrom1 at comcast.net> wrote:
>>>>
>>>>> I'm trying to figure out whether I can do a couple of things with petsc.
>>>>>
>>>>> 1. It looks like the preconditioning matrix can actually be different from
>>>>> the full problem matrix. So I'm wondering if I could provide a different
>>>>> preconditioning matrix for my problem and then do an LU solve of the
>>>>> preconditioning matrix using the -pc_type lu as my preconditioner.
>>>>
>>>> Yes, that is what it is for.
>>>
>>> Thanks. I think I will try that and see what sort of results I get. This
>>> sounds like a very encouraging discovery to me.
>>>
>>>>> 2. When I build petsc, I use the --download-f-blas-lapack=yes option. I'm
>>>>> wondering if petsc uses lapack under the hood or has the capability to use
>>>>> lapack under the hood when one uses the -pc_type lu option. In particular,
>>>>> since my matrices are band matrices from doing a discretization on a 2d
>>>>> regular mesh, I'm wondering if the petsc lu solve has the ability to use
>>>>> the lapack band solver dgbsv or dgbsvx. Or is it possible to use the
>>>>> lapack band solver through one of the external packages that petsc can
>>>>> interface with. I'm interested in this capability for smaller problem
>>>>> sizes that fit on a single node and that make sense.
>>>>
>>>> We do not have any banded matrix stuff. Its either dense or sparse right
>>>> now.
>>>
>>> OK. I had always been used to thinking of a banded system as sparse,
>>> relatively speaking, when compared to a full system. Based also on Barry's
>>> response, I guess I am not well enough educated on the nuances of sparse
>>> versus banded. For instance, when I use "-ksp_type preonly -pc_type lu" to
>>> solve one of my systems, I had assumed that the LU factorization computed by
>>> petsc was really filling in the 2*nx+1 bandwidth even though petsc might not
>>> be explicitly using the banded nature of the matrix. So I am not sure at all
>>> what is going on under the hood in petsc for this set of solver options. Nor
>>> do I really know how to find out without reading the source code which might
>>> be fairly daunting.
>>>
>>>>> 3. I'm also wondering how I might be able to learn more about the petsc
>>>>> ilu capability. My impression is that it does ilu(k) and I have tried
>>>>> it with k>0 but am wondering if one of the options might allow it to do
>>>>> ilut and whether as k gets big whether ilu(k) approximates lu. I
>>>>> currently do not understand the petsc ilu well enough to know how much
>>>>> extra fill I get as I increase k and where that extra fill might be
>>>>> located for the case of a band matrix that one gets from discretization
>>>>> on a regular 2d mesh.
>>>>
>>>> We do not do ilu(dt). Its complicated, and we determined that it was not
>>>> worth the effort. You can get that from Hypre is you want. Certainly, for
>>>> big enough k, ilu(k) is lu but its a slow way to do it.
>>>
>>> Thanks. I need to experiment more with ilu(k) on a couple of my linear
>>> systems.
>>>
>>>> Matt
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> Dave
>>
More information about the petsc-dev
mailing list