Subject: CGAL users discussion list
List archive
- From: Phil Weir <>
- To:
- Subject: Re: [cgal-discuss] Note of thanks re. polyhedral meshing
- Date: Thu, 18 Jun 2015 11:59:35 +0100
On 06/18/2015 11:37 AM, Laurent Rineau (CGAL/GeometryFactory) wrote:
Le Wednesday 17 June 2015 12:28:08 Phil Weir a écrit :Thanks.
A very late follow on, but just wanted to ping the list to expressThanks.
thanks for Laurent's input on 3D meshing in discussion at the FEniCS
workshop last year (Paris). For a number of reasons, we have only just
finished incorporating his suggestion today, but have noticed a
significant improvement.
In summary: as part of the Go-Smart EU-FP7 project,For information, for the other readers: http://www.gosmart-project.eu/
Indeed - nonetheless, that's helpful info!we are doingI agree. Since the beginnings of Mesh_3, I have modified a lot the class
polyhedral meshing prior to Elmer simulation - this may be relevant to a
couple of earlier posts this week, e.g. 'Best approach to create
Mesh_Domain_3 from multiple Polyhedral_3' and 3D-mesh creation
(Mesh_complex_3_in_triangulation_3) from *multiple* polyhedral surface
meshes...'. It sounds like Jane's suggestion has covered the use-case
there, but if intersection is required, such as in our case, I think
Polyhedral_mesh_domain_3 would need some wrapping, at least (if I
understand the documentation and remember previous experience correctly?).
templates Polyhedral_mesh_domain_3 and Polyhedral_mesh_domain_with_features_3,
but several features of them are not documented, because:
- either a lack of time,
- or because I am not really satisfied by the experimental API I have
added,
- or because I know that the API cannot be compatible with the new Surface
Mesh data structure that is slowly deprecating Polyhedron_3:
http://doc.cgal.org/latest/Surface_mesh/
Both Polyhedral_mesh_domain_3 and Polyhedral_mesh_domain_with_features_3 can
take in their constructors:
- a range of polyhedra,
- and a special polyhedron that will be the only one relevant for the
Is_in_domain_3 functor.
If you want to use that on Polyhedral_mesh_domain_with_features_3, then you
must iterate on the polyhedra, and call for each that method of
Polyhedral_mesh_domain_with_features_3:
void detect_features(FT angle_in_degree, Polyhedron& p);
BUT! that will certainly lead to crashes if the collection of polyhedra do
intersect, of if their featured edges are locally very close to each other.
(As you note below), these two are the primary advantages of the labelling-function approach, along with the relaxation of some polyhedron requirements. I can certainly see there would be theoretical challenges in doing the same thing efficiently from polyhedra. Another use case, a generalization of the spherical case I mention below, is mixing polyhedra and level-set functions.
You have also discovered that the IDs returned by the Construct_intersection
sub-functor of the domain can be related to the patch_id() function of the
facets of the polyhedra. That allows to have different labels for surface-
patches of the output mesh.
What is missing currently in those undocumented featured:
- Handling of intersections (and that is a difficult subject, I can tell!),
- And a way to have multiple sub-domain indices from a collection of
polyhedra. I have somewhere in Git a class that allows that for a collection
of non-intersecting closed polyhedra, but here again that would crash if the
polyhedra intersect or are close to each other.
So those features have remained in my TODO-list for years... From time to time
I try to improve the situation. For example, a lot of those undocumented
features were not even in the distribution of CGAL before version CGAL-4.3.
That sounds pretty nice. We actually realised we could save a bit of work and approximation by allowing our domain function to take a limiting radius parameter, as an outer bounding box, cutting down the number of required Point_inside_polyhedron calcs and providing a surface approximating a true sphere at all mesh densities.
Originally, we loaded STLs as Polyhedra, converted to Nef Polyhedra andIndeed. For the moment, domains using Labeled_mesh_domain_3 are the only easy
performed a series of Boolean operations, before converting back to a
domain Polyhedron and meshing. However, this was very slow and the
polyhedra requirements are quite restrictive, especially for converting
a Nef Polyhedron to the final domain polyhedron. Instead, we switched to
a Labeled_mesh_domain_3, using Point_in_polyhedron calls - this was much
faster, flexible and more robust, providing subdomain labelling (for MSH
output), effectively free.
way to have subdomains (with their own labels) in Mesh_3. Mixed with
Polyhedral_mesh_domain_with_features_3 one can implement hybrid domain
classes, that use for example the bounding box as Polyhedron_3, to have a nice
meshing of the outer box, and use Labeled_mesh_domain_3 for the inside of the
domain. I can show you such an hybrid domain.
That was a good workshop (thanks again to the organisers following this list!) - while the current project is primarily using Elmer, I have tried this tool with FEniCS simulations too (via the meshconvert utility), and it has worked fine.
However, labelling output boundaries by the original STL was harder -Your feedback is interesting. I really enjoyed meeting your group at the
Laurent's tip to re-use surface patches, which are actually filled by
the domain oracle (as I hadn't spotted!), made it far more efficient. We
combine this with a subclass (Signed_mesh_domain_3) that simply
overrides the Is_in_domain struct, allowing the labelling function to
return negative indices for external points. Negative return values are
preserved in the surface patch for future reference (at MSH output
time). The simulation component of this project is being open sourced
(including the CGAL-based meshing tool), although the tools are being
finished, tidied and documented over the course of this year (and are
still based on CGAL-4.3/4) - nonetheless, I hope this provides some
useful feedback for the moment.
FEniCS workshop, because it is at the same time exciting and challenging to
meet users of Mesh_3.
Ideally - this specific class is a very short alteration of Labeled_image_domain_3, so nothing too exciting, but modulo a little documentation and bug-checking (on-going), should be reusable generally. Apologies if this has been implemented upstream recently and I haven't spotted it, but the MSH export, with physical (volumetric+boundary) subdomains, may be useful also.
Do you think that some of your implementation is generic enough that it could
be contributed to CGAL?
All the best,
Phil
--
__________________________
Phil Weir | NUMA Engineering Services Ltd.
Block 1, Quayside Business Park,
Mill St, Dundalk,
Co. Louth, Ireland.
Tel: +353 42 9395821 | Fax: +353 42 9390220
_______________________
- [cgal-discuss] Note of thanks re. polyhedral meshing, Phil Weir, 06/17/2015
- Re: [cgal-discuss] Note of thanks re. polyhedral meshing, Laurent Rineau (CGAL/GeometryFactory), 06/18/2015
- Re: [cgal-discuss] Note of thanks re. polyhedral meshing, Phil Weir, 06/18/2015
- Re: [cgal-discuss] Note of thanks re. polyhedral meshing, Laurent Rineau (CGAL/GeometryFactory), 06/18/2015
- Re: [cgal-discuss] Note of thanks re. polyhedral meshing, Phil Weir, 06/18/2015
- Re: [cgal-discuss] Note of thanks re. polyhedral meshing, Laurent Rineau (CGAL/GeometryFactory), 06/18/2015
Archive powered by MHonArc 2.6.18.