CGAL users discussion list

[Phil Weir <>]

On 06/18/2015 11:37 AM, Laurent Rineau (CGAL/GeometryFactory) wrote:
> Le Wednesday 17 June 2015 12:28:08 Phil Weir a écrit :
> > A very late follow on, but just wanted to ping the list to express
> > 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.
> Thanks.
>
> > In summary: as part of the Go-Smart EU-FP7 project,
> For information, for the other readers: http://www.gosmart-project.eu/
Thanks.
> > we are doing
> > 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?).
> I agree. Since the beginnings of Mesh_3, I have modified a lot the class
> 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.
Indeed - nonetheless, that's helpful info!
> 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.
(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.
> > Originally, we loaded STLs as Polyhedra, converted to Nef Polyhedra and
> > 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.
> Indeed. For the moment, domains using Labeled_mesh_domain_3 are the only easy
> 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 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.
> > However, labelling output boundaries by the original STL was harder -
> > 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.
> Your feedback is interesting. I really enjoyed meeting your group at the
> FEniCS workshop, because it is at the same time exciting and challenging to
> meet users of Mesh_3.
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.
> Do you think that some of your implementation is generic enough that it could
> be contributed to CGAL?
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.

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
_______________________