I'm guessing the overhead with PCDestroy()/PCCreate() would be relatively
small relative to PCReset().
For example, PCReset_ASM() tears down all of the subdomain data structures
(subdomain ISs, scatters, submatrices and subdomain work vectors).  What
survives is essentially the user-defined configuration encapsulated in a
handful of parameters (number of subdomains, overlap, etc.) that would
enable us to rebuild the PC for a new matrix.

In the case of PCHYPRE ... PCReset_HYPRE() isn't defined, so only the
generic PCReset() is called, which tears down PC's pmat and marks it as not
setup.  Meanwhile, HYPRE-specific data structures (most notably, the
HYPRE-related matrix jac->ij) stick around, creating a somewhat
inconsistent state: when the new pmat is set with PCSetOperators() and
PCSetUp_HYPRE is finally called, it goes through the setup motions,
including copying pmat into jac->ij, which might not be correctly sized
anymore -- since the jac->ij was never destroyed, never zeroed out and,
therefore, not deemed in need of rebuilding with correct size.

An appropriate fix for this could be, perhaps,  to implement PCReset_HYPRE,
which would wipe out the internal HYPRE-related data structures.
 Alternatively, PCSetUp_HYPRE should always wipe out  jac->ij any time
setup is required. In the meantime, however, PCDestroy()/PCCreate() pair
would be nearly equivalent to that solution in terms of the amount of work
and memory management.

Dmitry.

On Mon, Feb 4, 2013 at 4:43 PM, Derek Gaston <fried...@gmail.com> wrote:

> On Mon, Feb 4, 2013 at 3:23 PM, Jed Brown <jedbr...@mcs.anl.gov> wrote:
>
>> I should add a test in PETSC if it doesn't. Is there a libmesh example I
>> can use to reproduce this?
>>
>
> There isn't... but there is a MOOSE test you can run
> (moose_test/tests/preconditioners/pbp/pbp_adapt_test.i).  This is all with
> PETSc 3.3.0-p4 BTW.
>
> If you really want a raw libMesh example I can probably make one.  Let me
> know.
>
>  Are you sure the PC was not being destroyed and recreated?
>>
>
> Well... looking back through the log, John did change something in there
> back in December (around when this started failing), but we didn't notice
> the problem until switching to PETSc 3.3.  I can only conclude that we were
> somehow "getting away with it" all that time.
>
> The fix with Destroy and Create works fine (even with Hypre).... and I'm
> going to change stuff on my end to make sure it doesn't happen every
> nonlinear iteration (I just looked at the code and we are calling init()
> way too much currently).
>
> Derek
>
>
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
>
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to