Re: [Libmesh-users] Problem of duplicating a mesh

[Min Xu <mi...@sc...>]

Thanks for quick replies. 

I used a work around as:
      Mesh Old(dim), New(dim);
      // define old
      ...
      MeshBase::const_element_iterator  el = 
AlphaMesh.active_elements_begin();
      const MeshBase::const_element_iterator end_el = 
Old.active_elements_end(); 
      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?

Best,

--Min




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.
>
>
> -John
>
>
> -------------------------------------------------------
> 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
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users