SSOR problem

[Barry Smith]

   1) It looks like you are using an old version of PETSc. We highly  
recommend upgrading to petsc 3.0.0; we are not going to debug old  
versions of PETSc

   2) the column indices are ALWAYS sorted (for each row). The  
MAT_COLUMNS_SORTED option was only for the column values passed into  
MatSetValues() it had nothing to do with how the values are actually  
stored.

    Barry

On Apr 27, 2009, at 1:45 PM, SUN Chun wrote:

> Hello,
>
> Sorry to raise the question again. It’s a bit detailed..
>
> I was trying to make the column indices a->j sorted for each row for  
> my SEQAIJ Matrix (reason explained below). I looked up the source  
> code and found MAT_COLUMNS_SORTED option, and I can do a  
> MatSetOption to set that. However, even now with a- 
> >sorted=PETSC_TRUE, I still see my a->j’s unsorted for each row  
> after a bunch of MatSetValues. Is there a particular procedure that  
> I should follow to have each row of my matrix sorted? Or I have to  
> do it outside PETSc?
>
> I should not care how PETSc store matrix, however, the reason that I  
> need it to be sorted is that in SSOR implementation, there seems to  
> be an assumption that the column indices being sorted for zero  
> initial guess ( n=diag[i]-a->i[i]; in MatRelax_SeqAIJ )… I suspect I  
> might have misunderstandings here. But at least I would like to try  
> a sorted matrix on SSOR to clarify.
>
> Any suggestions?
>
> Thanks,
> Chun
>
> From: petsc-users-bounces at mcs.anl.gov [mailto:petsc-users-bounces at mcs.anl.gov 
> ] On Behalf Of Matthew Knepley
> Sent: Monday, April 27, 2009 11:33 AM
> To: PETSc users list
> Subject: Re: SSOR problem
>
> The function MatMarkDiagonal_SeqAIJ() takes care of this.
>
>   Matt
> On Mon, Apr 27, 2009 at 9:34 AM, SUN Chun <Chun.SUN at 3ds.com> wrote:
> Hello,
>
> I have an update to this problem:
>
> I found that in MatRelax_SeqAIJ function (mat/impl/aij/seq/aij.c), I  
> have:
>
> diag = a->diag and:
>
> diag[i] is has exactly the same value of a->i[i] for each row i.  
> This gives me n=0 when doing forward pass of zero initial guess.  
> That explains why setting -pc_sor_forward will give me identical  
> results as if I run pure DSCG.
>
> I assume that this a->diag[] stores the sparse column index of  
> diagonal entries of a matrix. Now it seems to be improperly set. I  
> will pursue this further in debugger. Do you know which function it  
> should be set during the assembly process? That would point a short- 
> cut for me....
>
> Thanks again!
> Chun
>
>
> -----Original Message-----
> From: petsc-users-bounces at mcs.anl.gov [mailto:petsc-users-bounces at mcs.anl.gov 
> ] On Behalf Of SUN Chun
> Sent: Monday, April 27, 2009 9:13 AM
> To: PETSc users list
> Subject: SSOR problem
>
> Hello,
>
> I have an *particular* Ax=b which I want to solve with CG  
> preconditioned
> by SSOR using PETSc. Then some specific strange things happen. Please
> allow me to describe all the symptoms that I found here. Thanks for  
> your
> help:
>
> 0) All solves are in serial.
>
> 1) A 20-line academic code and another matlab code converge the  
> solution
> with identical residual history and number of iterations (76), they
> match well. If I run without SSOR (just diagonal scaled CG): PETSc,
> academic code, and matlab all match well with same number (180) of
> iterations.
>
> 2) PETSc with SSOR seems to give me -8 indefinite pc. If I play with
> omega other than using 1.0 (as in Gauss-Seidel), sometimes (with
> omega=1.2) I see stagnation and it won't converge then exceeds the
> maximum iteration allowed (500). Residuals even don't go down. If I
> don't say -ksp_diagonal_scale, I get -8 too. So, PETSc with SSOR  
> either
> gives me -8 or -3.
>
> 3) The above was run with -pc_sor_symmetric. However, if I ran with
> -pc_sor_forward, I got a convergence curve identical to what I have
> without any preconditioner, with same iterations (180). If I ran with
> -pc_sor_backward, it gives me -8 indefinite pc.
>
> 4) If I increase any of the number of -pc_sor_its (or lits) to 2, it
> converges (but still don't match the matlab/academic code).
>
> 5) The matrix has good condition number (~8000), maximum diagonal is
> about 6, minimum diagonal is about 1.1. There's no zero or negative
> diagonal entries in this matrix. It's spd otherwise matlab won't be  
> able
> to solve it.
>
> 6) The behavior is independent of rhs. I've tried random rhs and get  
> the
> same scenario.
>
> 7) Here is the confusing part: All other matrices that we have except
> for this one can be solved by PETSc with same settings very well. And
> they match the academic code and matlab code. It's just this matrix  
> that
> exhibits the strange behavior. I tend to eliminate the possibility of
> interface problem because all other matrices and other preconditioner
> settings work well.
>
> We're running out of ideas here, if you have any insight please say
> anything or point any directions.
>
> Thanks a lot,
> Chun
>
>
>
>
>
> -- 
> What most experimenters take for granted before they begin their  
> experiments is infinitely more interesting than any results to which  
> their experiments lead.
> -- Norbert Wiener