On Sun, 6 Oct 2019, Renato Poli wrote:
> I am trying to clone a mesh so I can remesh the clone and transfer the > solution from the original mesh to the new one. (is that the best way to > do??) It depends on how extensive the remeshing you plan is. If you can create the new mesh via isotropic Adaptive Mesh Refinement / Coarsening of the old one, then just using our built-in AMR/C facilities is the best way to go. If you need to do anisotropic refinement but you're doing something like edge splitting, writing your own interpolation code to go along with that might be easy enough and would definitely be most efficient. But if you're creating a drastically different mesh then yeah, a clone and transfer is probably best. > I am seeing a segmentation fault while calling 'ghosting functors' inside > 'prepare_for_use'. > (I do have 'coupling functors' attached to the original System.) > I believe it should work ... Do you agree? I agree that it should work, in the normative if not the positive sense of "should"... but I can see why it might not work the way you expect; I might not have been getting clone() right with GhostingFunctor objects, since we don't have much test coverage using both. So let's see... when we clone a ReplicatedMesh or a DistributedMesh, a big hunk of that work is getting done by the (defaulted) UnstructuredMesh copy constructor, which will in turn call the MeshBase copy constructor. The _default_ghosting gets created anew, but the _ghosting_functors set just gets a shallow copy. > 302 gf->mesh_reinit(); This is presumably a call to a dangling pointer, then? You add a ghosting functor to the old mesh, but you (or the old mesh's _shared_functors map) have it get deleted afterward, and then we get a segfault when the new mesh tries to still call it? Could that be what's going on? --- Roy _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
