>> solution->localize(*current_local_solution); >> >> Shouldn't this either be a call to the version of localize that takes the >> send_list? Or more likely just call update()... > > At first glance I'd say yes - this looks like a huge bug in the > original version of this function. I'll wait for Ben to weigh in, > though.
Agreed. > Shouldn't the (later) introduction of ghosted PetscVectors have > ameliorated the problem? They've got all the send_list information > implicitly built-in to the vector. It seems like it should be > possible to avoid the excess communication even when users don't > provide a send_list. Or is it that they have the send_list > information on sending processors, only on receiving processors, so > sending processors can't pre-filter what they send? I don't think so - the call to localize implemented in the PetscVector with no send list builds up a unity send list, effectively localizing the whole thing: http://libmesh.sourceforge.net/doxygen/classlibMesh_1_1PetscVector.php#aa608 bc0dad18db41e2441111129bf57d So this should be changed to use the real send list - now hopefully there are no bugs in there about it being incomplete for projection! -Ben ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
