Ok - I put in a libMesh pull request for my fix for all of this here:
https://github.com/libMesh/libmesh/pull/38
Like I say there, if you want to wait until after the 0.9 release to merge
it, that's fine with me. But, this is a real bug which probably should be
fixed. It's up to you guys (mainly talking to Ben, Roy and Paul here).
Derek
On Mon, Feb 4, 2013 at 4:13 PM, Dmitry Karpeev <karp...@mcs.anl.gov> wrote:
> 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
