Thanks for quick replies.
I used a work around as:
Mesh Old(dim), New(dim);
// define old
MeshBase::const_element_iterator el =
const MeshBase::const_element_iterator end_el =
Old.create_submesh(New, el, end_el);
This seems to work fine and the New mesh will have be of the same level
whereas the Old mesh may be of multiple levels if it is refined. I am
concerned though about the hanging nodes. In the case that the New mesh is
derived from a refined Old mesh, the constraints used to be active in the Old
mesh for the hanging nodes are no longer active in the New mesh. Will this be
a problem when the New mesh is used in an equation system to solve some PDE?
How to remedy then?
Another thing I found over the weekend is that the inverse_map() when used for
a BoundaryMesh may fail. In my case, the boundary mesh is for a square
[-10,10]x[-10,10]. The inverse_map for the physical point (-10, 10, 0)
returned a local point mapping to (-10, -10, 0). The reason is that inverse
map ignored the second coordinate. Any fix available?
On Monday 19 September 2005 08:46, John Peterson wrote:
> Roy Stogner writes:
> > On Sat, 17 Sep 2005, Min Xu wrote:
> > > The natural way to duplicate a mesh in libmesh seems to be:
> > >
> > > Mesh Old(dim);
> > > // Old mesh is defined
> > > ...
> > > // Duplicate Old
> > > Mesh New(Old);
> > >
> > > The problem of the above code is that when New mesh is refined, the
> > > active element list in the _Old_ mesh is also affected. Is this a bug
> > > or desired feature of libmesh?
> > I'd definitely consider it a bug, but the copy constructor is written
> > in such a way that it could be a deliberate design decision. Ben,
> > John?
> Instead of a bug, can we call it a heretofore unused feature? ;) While
> there might actually be a case where you would want two meshes to share
> an elements and nodes vector, I can't think of one off the top of my head.
> Furthermore, the expected behavior of a copy constructor is deep copy, so
> I agree the current code is wrong.
> > That looks like a non-trivial effort to me (we'll need new "virtual
> > constructor" clone methods for the Elem classes, for example), so I'm
> > not going to start writing it unless you're sure you need it (because
> > you do adaptive refinement before duplicating the mesh, say).
> As you point out, there is not currently a good way to copy construct
> one element from another, so the Mesh copy constructor would need to be
> put on hold at least until this issue is cleared up. In the mean time,
> I suggest we disable the copy ctor for mesh to prevent it from being
> used in a non-intuitive way.
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> Libmesh-users mailing list