no facets defined for boundary of complex mesh
7 months ago by
My steps are:
1) generate the .mesh using a cgal script. An example script is the sphere at https://doc.cgal.org/latest/Mesh_3/index.html#Mesh_33DDomainsImplicitIsosurfaces
- use cgal to generate the mesh file out.mesh with:
cgal_create_cmake_script; cmake .; make; ./mesh_implicit_sphere
1b) if desired, convert to .msh by opening the mesh file in gmsh and using gmsh saving the mesh.
dolfin-convert out.mesh out.xml(or
dolfin-convert out.msh out.xml, for the gmsh file)
After this, the dolfin mesh file out.xml is created, but it contains only vertices, not facet information. The .mesh file does contain Triangle entries, which I understand would correspond to the boundary. Discussion of the conversion on websites indicates that an out_facet_region.xml file should also be created, which can be read into a FacetFunction, and identifies my boundary vertices. But no such *facet_region.xml is created.
dolfin-convert uses /usr/lib/python2.7/dist-packages/dolfin_utils/meshconvert/meshconvert.py. If I hack that, I see on l.468, where it tests
tags = tags_for_dim[highest_dim-1] if (len(tags) > 0) and (mesh is not None): physical_regions = tuple(tag for tag in tags) if not all(tag == 0 for tag in physical_regions):
that the tags read from my .mesh file have the form [0,1] . So "tag==0" and the facets are not processed.
Is there some complication in importing CGAL (or gmsh) meshes to dolfin that we haven't accounted for?
What we're trying to do is solve our system inside a nontrivial mesh. But because a FacetFunction isn't being defined during import of the mesh file, dolfin can't tell us where the boundary is, so we can't apply the correct boundary conditions.
Community: FEniCS Project
7 months ago by
nearto determine if x is on the boundary or not.
If instead I use the more explicit test,
then the boundary seems to work (at least, it gets set to 1 as required).
def sphereSurface(x, on_boundary): return bool( (abs(x**2+x**2+x**2-1) < 7.0E-3) and on_boundary)
Any tighter test, even < 6.0E-3, fails to detect the boundary.
This level of precision is quite a bit lower than I'd expect. Is it normal, for the mesh density (20) used in this example?
Please login to add an answer/comment or follow this question.