[petsc-dev] GASM

Dmitry Karpeev karpeev at mcs.anl.gov
Thu Mar 29 11:54:56 CDT 2012


Incidentally, any call to XXXReset() is, presumably, to be followed by a
call to XXXSetUp():
why not roll the former into the latter?  One argument against this would
be that in between
the calls the user might want to call XXXSetYYY(), which might otherwise be
rejected until
after XXXReset(), but in this case building a whole new XXX from scratch
might be the right
thing to do: we are no longer reusing the configuration.

Dmitry.

On Thu, Mar 29, 2012 at 11:45 AM, Dmitry Karpeev <karpeev at mcs.anl.gov>wrote:

> Pushed: http://petsc.cs.iit.edu/petsc/petsc-dev/rev/76f5543c7e89
>
>
> On Thu, Mar 29, 2012 at 11:07 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>
>>  I think Jed is suggesting changing:
>>
>> PetscErrorCode  KSPDestroy(KSP *ksp)
>> {
>>  PetscErrorCode ierr;
>>
>>  PetscFunctionBegin;
>>  if (!*ksp) PetscFunctionReturn(0);
>>  PetscValidHeaderSpecific((*ksp),KSP_CLASSID,1);
>>  if (--((PetscObject)(*ksp))->refct > 0) {*ksp = 0;
>> PetscFunctionReturn(0);}
>>
>>  ierr = KSPReset((*ksp));CHKERRQ(ierr);
>>
>>
>>
>> to
>>
>>
>> PetscErrorCode  KSPDestroy(KSP *ksp)
>> {
>>  PetscErrorCode ierr;
>>  PC                         pc = (*ksp)->pc;
>>
>>  PetscFunctionBegin;
>>  if (!*ksp) PetscFunctionReturn(0);
>>  PetscValidHeaderSpecific((*ksp),KSP_CLASSID,1);
>>  if (--((PetscObject)(*ksp))->refct > 0) {*ksp = 0;
>> PetscFunctionReturn(0);}
>>
>>
>>  pc = (*ksp)->pc;
>>  (*ksp)->pc = PETSC_NULL;
>>  ierr = KSPReset((*ksp));CHKERRQ(ierr);
>>  (*ksp)->pc = pc;
>>
>>
>>   Since KSPDestroy() doesn't need to have  PCReset() called. This doesn't
>> require any special code for users.
>>
>>   Barry
>>
>>
>> On Mar 29, 2012, at 10:38 AM, Dmitry Karpeev wrote:
>>
>> >
>> >
>> > On Thu, Mar 29, 2012 at 10:13 AM, Jed Brown <jedbrown at mcs.anl.gov>
>> wrote:
>> > On Thu, Mar 29, 2012 at 08:28, Dmitry Karpeev <karpeev at mcs.anl.gov>
>> wrote:
>> > Back to the original problem: how shall we prevent a shared pc from
>> being gutted by an unprotected PCReset() cascading from a KSPDestroy() on
>> one of the containing ksps?  I can factor out
>> KSPReset_Private()/PCReset_Private() as indicated before, unless there are
>> objections.
>> >
>> >  What do you think of my suggestion of masking ksp->pc when KSPDestroy
>> calls KSPReset? Then KSPReset does not call PCReset if ksp->pc does not
>> exist.
>> > I guess that works too, but I thought your suggestion applied to
>> userland code right before calling KSPDestroy(&ksp)?
>> > I suppose that will fix Mark's problem.  Maybe that's the right
>> approach: he got himself into this mess by reusing a pc
>> > in the inner ksp, he should know how to extricate himself :-)
>> >
>> > Dmitry.
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120329/30502a8b/attachment.html>


More information about the petsc-dev mailing list