[petsc-dev] sor smoothers

[Jed Brown]

"Mark F. Adams" <mfadams at lbl.gov> writes:

> OK, is this the plan:
>
> 1) I should add a residual method to Mat, make a MatResidualDefault,
> and have all (yuck) SetUp_MatXXX set this default.  I guess there is
> no base class SetUp ….  then make a MatResidual_SeqAIJ that just does
> a dumb residual for now.

Yeah, can skip MatResidual_SeqAIJ until it is different from MatResidualDefault.

> 2) PCMGResidualDefault call MatResidual instead MatMult, then VecAYPX.

Yes.

> 3) Add fields in Mat: mat_res_state, vec_res_state, vec_res_id.  I need to know the types but I can do this in the next phase.

I would put these fields in Mat_SeqAIJ rather than top-level Mat.

> BTW, if we have 64 bits for State then it seems like we could fold the ID into this State ...

Perhaps you could pack bits, but the reason for using 64-bit state is
that 32 bits could overflow in a long-running program.  You could argue
that 48 bits won't overflow, but even that would be possible in an
application that ran for weeks.  Meanwhile, the total number of objects
created can also be large, possibly overflowing 32 bits on its own.  So
they should both be 64-bit counters.

> These steps can be one checkin and Jed can do the above State and ID
> stuff, then I can make a new branch and write the local code to have
> MatResidual_SeqAIJ look at the ID and States and call the SOR residual
> of we match up.  And this will be hardwired for SOR in that if we have
> a match we assume it was done by SOR.

Sure.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130909/152e973c/attachment.sig>