On Wed, 8 Jun 2011, David Andrs wrote:

> Some of our tests here at INL started to fail after we updated libMesh. I 
> tracked the problem down into TransientSystem::re_update where r4500
> commented out the if-statement on line 152. Without it the code execution 
> continues into localize of older_local_solution and we have
> first_local_dof = 0 and end_local_dof = 0, thus it fails on assert in 
> PetscVector::localize on line 873, size is 0 and last_local_dof is max
> integer value.
> 
> Attached is the patch that reverts one hunk from r4500 to fix this issue for 
> us.

Simply reverting things would cause a regression for me with ex10 and
ParallelMesh.  I'm actually surprised it wouldn't cause a regression
for you guys too.  I suppose the misbehavior I saw may be
PETSc-version-specific or MPI-stack-specific.  But it's definitely not
a PETSc or MPI bug: we can't expect both to recover nicely when we try
to perform an operation on COMM_WORLD but one of COMM_WORLD's ranks
never joins in.

Would it be sufficient to change that assert from
libmesh_assert(last_local_idx < this->size());
to
libmesh_assert(last_local_idx+1 <= this->size());
?

As long as local_size is calculated correctly as 0, the rest of the
localize() method should work, and even with UINT_MAX local_size ought
to be calculated correctly.  Relying on an int underflow to cancel out
a previous overflow gives me the willies, but the C standard seems to
guarantee modular arithmetic for *unsigned* ints.  The only other way
I can see to get the right behavior would be deprecating
localize(uint,uint,vec<uint>&) and replacing it with a
(differently-named) localization function using begin/end semantics
instead of begin/last semantics.
---
Roy

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to