On Jun 10, 2011, at 9:35 AM, Roy Stogner wrote: > Almost. This call is crucial if the solution vector is ghosted and > not already closed. But it's also redundant global communication if > the solution vector is already closed, which (without any special > effort in user-level code) is the case for every update() call in our > examples and in the apps I've tested.
> Could you identify where in your failure case the solution vector is > getting left open? This happens during the call to update() in the Petsc callback to compute the residual (and other callbacks). It's not from user code at all. Petsc is actually giving us a vector that isn't closed. > If there's some place in the library that should be closing vectors > but is failing to, then that's where we ought to fix it. (e.g. I > caught one of those in our NOX interface yesterday) It could be that we need to do the closing in the Petsc interface..... I was working under the supposition that we had been localizing non-closed vectors for a long time and didn't know it... but I suppose that since your recent change still used operator= for ghosted vectors but didn't do the closing and you weren't seeing errors that must not be happening. Are you using Petsc 3.1 in your test suite? Because it directly gives an error if you try to use operator= for non-closed vectors (sometimes Petsc 2.3.3 will let you get away with it in serial). If operator= is working for you in localize() without a close() then we should maybe think about moving this close to the PetsC interface. Or, like I said in my email earlier... just let it ride for a bit until I get some more clarity on the thing that made us move to operator= in the first place. > If not, then there's some place in user code that should be closing > vectors but is failing to, and IMHO that's where you ought to fix it. Not the case here. > We could instead just apply another close()... but there are dozens of > places in the library where we assert that a vector or matrix is > closed. If we're going to start replacing some of those with > usually-redundant close() calls, why do it piecemeal? Does anyone > want to replace them all? I don't think this is necessary... Derek ------------------------------------------------------------------------------ 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
