On Thu, 12 May 2011, Derek Gaston wrote: > On May 11, 2011, at 11:46 PM, Roy Stogner wrote: > >> What happens when you add the solution->close() but leave the >> communication to VecScatter rather than VecCopy? > > Dunno... I'll give it a whirl.
Thanks. >> Either way, I think we might want to assert(closed) rather than adding >> a usually-redundant close call here. > > assert() won't work. We don't want it to die. assert() doesn't mean "we want to die", it means "we want to detect any bug here that needs to be fixed". Then we ideally avoid the bug in the first place (making sure each update() is called on a System with a closed solution in this case) or we slip up, catch it once, fix it once, and it doesn't die again. It's not like this is the AMR code, where there are a hundred different corner cases that might or might not be triggered depending on your solution and heuristic parameters and phase of the moon; generally a vector is either closed or it's not and it'll be the same way on the next run on the same code. We'd probably catch most of the unclosed cases via "make run_examples", the rest would require a single not-even-full-scale run of your app code. > What we need is to detect that it's not closed and close it. I > don't know how to do that. By testing _is_closed. If _is_closed isn't in sync, then that's the root bug we need to fix. > This is a PetscVector that we might have made from a raw Vec (That's > what happens in PetscNonlinearSolver).... we don't exactly know the > state of it... Hmm... now *here* we may need to add a potentially-redundant close(), in PetscVector::PetscVector(Vec). That constructor *ought* to work for closed and/or unclosed Vec arguments, but right now it just assumes the Vec is closed and sets its flag accordingly. If there's no more efficient way to test for a completed assembly via PETSc (and I doubt there is; how would one processor know whether or not another processor has tried to change some values without a communication step, at which point you might as well just do the VecAssemblyBegin/End?) then the only safe options seem to be assuming it's unclosed or having the PetscVector constructor close it. --- Roy ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
