<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: Performance degradation after upgrade to 3.0.0</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>Thanks for the explanation.<BR>
<BR>
-----Original Message-----<BR>
From: Matthew Knepley [<A HREF="mailto:knepley@gmail.com">mailto:knepley@gmail.com</A>]<BR>
Sent: Wed 2/4/2009 10:46 PM<BR>
To: PETSc users list<BR>
Cc: petsc-maint Maintenance; Billy Araújo<BR>
Subject: Re: Performance degradation after upgrade to 3.0.0<BR>
<BR>
On Tue, Feb 3, 2009 at 4:35 PM, Billy Araujo <billyaraujo@gmail.com> wrote:<BR>
> "Can you send the matrix and rhs as PETSc binary output, and I will find out<BR>
> what the difference is. It looks to me like the default ICC ordering<BR>
> has changed.<BR>
<BR>
Okay, I have the explanation. The default factorization options<BR>
changed in 3.0.0.<BR>
No, by default, we use a diagonal shift to remedy zero diagonal elements, like<BR>
<BR>
-pc_factor_shift_positive_definite TRUE<BR>
<BR>
You do not have a zero per se, but you do have a singular matrix, which you can<BR>
check using -ksp_type preonly -pc_type lu, so the last row has a zero diagonal.<BR>
Since nothing is ever divided by it, it causes no problems if you do<BR>
nothing. However,<BR>
shifting generates a much poorer preconditioner. You can recover the original<BR>
behavior using<BR>
<BR>
-pc_factor_shift_positive_definite FALSE<BR>
<BR>
However, I would also advise uncovering the source of the singularity.<BR>
<BR>
Thanks,<BR>
<BR>
Matt<BR>
<BR>
--<BR>
What most experimenters take for granted before they begin their<BR>
experiments is infinitely more interesting than any results to which<BR>
their experiments lead.<BR>
-- Norbert Wiener<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>