On Thu, 2 Jan 2014, Derek Gaston wrote:
One of my users brought an issue to my attention: libMesh is not properly
handling multiple nodes occupying the same
position when writing out xda/xdr files for the solution vector.
I am attaching a mesh and main.C that show the issue. If you look at the
resulting eq_sys.xda file you will see that it
has two zeros at the end of the solution vector. Those two zeros should be
"4.0".
The mesh has 2 pairs of nodes that are "duplicated". They are at (0, 0.5, 0)
and (0.5, 0.5, 0). What I mean by
duplicated is that there are two nodes in the same physical position (so there is a
"slit" in the mesh). Think of it
like a "crack" in the mesh...
Solving on a mesh like this works just fine... but something about the XDA/R
output routines doesn't like it (I suspect
it's the Hilbert space reorder... but that's just a guess). Note that the
Exodus output looks perfectly fine - as does
the print of the solution vector. It really is an issue just with XDA/R
I would really appreciate help on this one!
IIRC there was a problem with find_neighbors() that was causing meshes
with slits to fail at AMR, and so I've never really investigated the
compatibility of the rest of the library with those cases. I'd
definitely also suspect the Hilbert reordering as the culprit here.
---
Roy
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
