Thread Subject: condition number of FE matrix -> improving iterative solver

Hi,

I'm working on a FE software and right now I'm stuck with the solver.

I'm both trying cholmod2 (from Tim Davis' package) and standard pcg.
Right now, i've got a text matrix, which is just a beam with about 30 000dof and cholmod2 wins hands down. However, when using larger matrices, I can't use cholmod2 because there isn't sufficient memory.

However, I noted a few things which actually surpise me.
First of all, when using condest on my FE matrix of the beam, the condition number is in the order of 1e8. When checking the statistics of cholmod2, it returns the reciprocal of the condition number as about 1e-3. What is the cause for the big difference in the condition number? I have been told that the condition number for structural problem usually is somewhere arounc 1e4 to 1e5, so I think that the 1e8 is rather high. Especially since it's a simple problem with a regular mesh.

For the pcg I'm using a incomplete lu factorization with zero fill-in. Why is pcg so much slower than the direct solver, even if I use a preconditioner?

Are there any other tricks to improve the condition number of the my FE matrix, or ways to improve the solution speed of pcg? I need it for problems with more dof? Or is there a way to make cholmod2 use less memory (though it already applies reordering...)

Thanks for any help on my problem!!

"A B" <gitsnedbutzi@hotmail.com> wrote in message <hd6pba$84c$1@fred.mathworks.com>...
> Hi,
>
> I'm working on a FE software and right now I'm stuck with the solver.
>
> I'm both trying cholmod2 (from Tim Davis' package) and standard pcg.
> Right now, i've got a text matrix, which is just a beam with about 30 000dof and cholmod2 wins hands down. However, when using larger matrices, I can't use cholmod2 because there isn't sufficient memory.
>
> However, I noted a few things which actually surpise me.
> First of all, when using condest on my FE matrix of the beam, the condition number is in the order of 1e8. When checking the statistics of cholmod2, it returns the reciprocal of the condition number as about 1e-3. What is the cause for the big difference in the condition number? I have been told that the condition number for structural problem usually is somewhere arounc 1e4 to 1e5, so I think that the 1e8 is rather high. Especially since it's a simple problem with a regular mesh.

The condition number get bad if you forget to impose appropriate (boundary) condition to make the problem well posed. If boundary is correctly setup, then note that the condition number goes up when mesh size decreases. However a typical characteristic is the smallest eigenvalue of your stiffness matrix is inferior bounded, and the largest eigenvalue goes to infinity as the square of the mesh size for a second order operator.

If you have the mass matrix, check for the first eigenmode, which is the lowest "resonance" mode of your operator. The shape of such eigenmode should look *physical*, whatever it means. This ensures that the boundary condition is correctly setup.

Bruno

>
> For the pcg I'm using a incomplete lu factorization with zero fill-in. Why is pcg so much slower than the direct solver, even if I use a preconditioner?
>
> Are there any other tricks to improve the condition number of the my FE matrix, or ways to improve the solution speed of pcg? I need it for problems with more dof? Or is there a way to make cholmod2 use less memory (though it already applies reordering...)
>
> Thanks for any help on my problem!!

"A B" <gitsnedbutzi@hotmail.com> wrote in message
news:hd6pba$84c$1@fred.mathworks.com...
> Hi,
>
> I'm working on a FE software and right now I'm stuck with the solver.
>
> I'm both trying cholmod2 (from Tim Davis' package) and standard pcg.
> Right now, i've got a text matrix, which is just a beam with about 30
> 000dof and cholmod2 wins hands down. However, when using larger matrices,
> I can't use cholmod2 because there isn't sufficient memory.
>
> However, I noted a few things which actually surpise me.
> First of all, when using condest on my FE matrix of the beam, the
> condition number is in the order of 1e8. When checking the statistics of
> cholmod2, it returns the reciprocal of the condition number as about 1e-3.
> What is the cause for the big difference in the condition number? I have
> been told that the condition number for structural problem usually is
> somewhere arounc 1e4 to 1e5, so I think that the 1e8 is rather high.
> Especially since it's a simple problem with a regular mesh.
>
> For the pcg I'm using a incomplete lu factorization with zero fill-in. Why
> is pcg so much slower than the direct solver, even if I use a
> preconditioner?
>
> Are there any other tricks to improve the condition number of the my FE
> matrix, or ways to improve the solution speed of pcg? I need it for
> problems with more dof? Or is there a way to make cholmod2 use less memory
> (though it already applies reordering...)
>
> Thanks for any help on my problem!!

Hi,

Be careful what you are comparing. cond, condest and rcond in MATLAB all
compute different things.

1-norm and 2-norm, the quantity or its reciprocal, "exact" or estimate.

The doc will help you distinguish. Add another package like cholmod2 to the
mix, and you have more information to read.

In general, the (preconditioned) iterative methods only win when you do not
have the memory to compute the factorization via a direct solve method. Yes,
they are slow, but you get there eventually, which is faster than not at all
:-)

Good luck.

Penny.

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hd8g6a$pi7$1@fred.mathworks.com>...
> "A B" <gitsnedbutzi@hotmail.com> wrote in message <hd6pba$84c$1@fred.mathworks.com>...

> The condition number get bad if you forget to impose appropriate (boundary) condition to make the problem well posed. If boundary is correctly setup, then note that the condition number goes up when mesh size decreases. However a typical characteristic is the smallest eigenvalue of your stiffness matrix is inferior bounded, and the largest eigenvalue goes to infinity as the square of the mesh size for a second order operator.
>
> If you have the mass matrix, check for the first eigenmode, which is the lowest "resonance" mode of your operator. The shape of such eigenmode should look *physical*, whatever it means. This ensures that the boundary condition is correctly setup.
>
> Bruno

A number of appropriate boundary conditions is imposed, to lock rigid body motions, and so there isn't a solution which would result in a zero energy. Unfortunatly I'm not calculating the mass matrix, so I can't check the lowest mode.

What I noticed however is that incomplete factorization lead don't result in good preconditioners, no matter how I set the drop tolerance and other options. Using pcg without any preconditioners surprisingly gives better results. If I rescale the matrix with a left and right preconditioner, being the inverse of the square root of the main diagonal elements (as a result the main diagonal will be scaled to ones), the convergence slightly improves.

Why is it that incomplete factorization preconditioners don't perform that well?
Aren't they well suited for problems from structural mechanics?

"A B" <gitsnedbutzi@hotmail.com> wrote in message <hd9brc$7gk$1@fred.mathworks.com>...
> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hd8g6a$pi7$1@fred.mathworks.com>...
> > "A B" <gitsnedbutzi@hotmail.com> wrote in message <hd6pba$84c$1@fred.mathworks.com>...
>
> > The condition number get bad if you forget to impose appropriate (boundary) condition to make the problem well posed. If boundary is correctly setup, then note that the condition number goes up when mesh size decreases. However a typical characteristic is the smallest eigenvalue of your stiffness matrix is inferior bounded, and the largest eigenvalue goes to infinity as the square of the mesh size for a second order operator.
> >
> > If you have the mass matrix, check for the first eigenmode, which is the lowest "resonance" mode of your operator. The shape of such eigenmode should look *physical*, whatever it means. This ensures that the boundary condition is correctly setup.
> >
> > Bruno
>
> A number of appropriate boundary conditions is imposed, to lock rigid body motions, and so there isn't a solution which would result in a zero energy. Unfortunatly I'm not calculating the mass matrix, so I can't check the lowest mode.
>
> What I noticed however is that incomplete factorization lead don't result in good preconditioners, no matter how I set the drop tolerance and other options. Using pcg without any preconditioners surprisingly gives better results. If I rescale the matrix with a left and right preconditioner, being the inverse of the square root of the main diagonal elements (as a result the main diagonal will be scaled to ones), the convergence slightly improves.
>
> Why is it that incomplete factorization preconditioners don't perform that well?
> Aren't they well suited for problems from structural mechanics?

Actually, I found that the best preconditioner for a pccgls
solver on some of my problems was indeed an incomplete
cholesky.

John

> Actually, I found that the best preconditioner for a pccgls
> solver on some of my problems was indeed an incomplete
> cholesky.
>
> John

Hi John,

was this also for structural mechanics?
For thermal problems it works great (though they also have less dof), but for structural I can't seem to get them working right.

FYI, I have solved structural problems with stiffness matrix of size about 70000. I can't recall having problem with PCG.

Bruno