From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20050125 20:47:51

You are absolutely correct. What is needed is another step... System::restrict_vector ? This step has not been required previously since, as you point out, the restriction operator for Lagrange elements is the identity operator. As for the local L2 projection, there should probably be a separate projection for each edge, face, and then element. In general the projection will be overconstrained (as you point out), but the system is solvable in the leastsquares sense by either a normal equations or QR approach. By breaking it up into an edgebyedge, facebyface, etc... approach we ensure that neighboring elements get the same values for edge, face, etc... DOFs. I'll look into the refinement code and see about adding a System::restrict_vector method and how best to fit it in... Other than that, is the outlined approach clear?  Benjamin S. Kirk benjamin.kirk@... NASA/JSC, Applied Aerosciences & CFD Branch 2814839491 Original Message From: libmeshdeveladmin@... [mailto:libmeshdeveladmin@...] On Behalf Of Roy Stogner Sent: Thursday, January 20, 2005 3:58 PM To: libmeshdevel@... Subject: [Libmeshdevel] System::project_vector bug I just realized that the behavior of nodes "changing identities" depending on whether they're edge, face, corner, or interior has another consequence: System::project_vector only handles mesh coarsening correctly for Lagrange elements: setting a coarse edge DoF to the value of a fine corner DoF probably won't work for anything else. I'm not sure how to fix that. From a mathematical perspective, the local L2 projection that we're using to go from coarse to fine meshes is an exact projection whenever the function space restricted to the fine child elements contains the entire function space from the coarse parent element, but if we were to use a projection to go from fine to coarse elements, the results couldn't be exact, and different elements sharing the same DoF might have different ideas about what its new value should be. We could just go with the projection result from whatever the first element we come across says (and since we're coarsening anyway, we have to expect to lose some accuracy), but it seems like there should be a better way. From a practical perspective there's a more immediate problem. I'm not even sure how to form a projection matrix. When refining, you have access to both child and parent elements; when coarsening, though, aren't the child elements already deleted by the time you project to the new mesh? Could we refine just one element at a time (ignoring level mismatch constraints), use the new children immediately for integration, then coarsen again?  Roy Stogner  This SF.Net email is sponsored by: IntelliVIEW  Interactive Reporting Tool for open source databases. Create drag&drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Libmeshdevel mailing list Libmeshdevel@... https://lists.sourceforge.net/lists/listinfo/libmeshdevel 