Generic 2D/3D Periodic Triangulations

[MaelRL]

Summary of Changes

This PR adds a new type of 2D and 3D periodic triangulations whose base domain is not an iso_rectangle/cuboid, but a Voronoi face, thus greatly expanding the potential use cases.

This new class also uses the name Periodic_2_(Delaunay)_triangulation_2, and the choice between both implementations is done by looking at the domain type.

2D Periodic Triangulations are almost fully rewritten to use Bowyer-Watson rather than flips, and some other issues in periodic classes are fixed along the way (LINK TO ISSUES TODO). Also will make it almost trivial to add 2D periodic regular triangulations if somebody cares about it some day.

stash: https://gist.github.com/MaelRL/b8b4e7175f6461d8df12ae773ab980d0

TODO:

• filter-graph to remove all unintended changes (e.g. README.md)
• Insertion of ranges + vertex removal in P2T2
• Generic periodic without exact constructions
• Document + small feature
• Fix bugs (generic_p2t2 has assertions failing on some random runs)
• Fix second phase resulting in "twisted" periodicity
• Structural filtering for P2T2
• Spatial sorting for P2T2
• Fix draw_P2T2 (basic viewer)
• Tests
• Everything above for P3T3

EXTRA:

• Could implement P2RT2 for almost no effort now

TMP NOTE for exact generic w/o exact constructions:

• Both gt can be merged as one by inserting points during phase 1 in a local triangulation with Point = <Point, Offset> and translating back the connectivity (see also triangulation removal functions).

Release Management

• Affected package(s): Periodic_2_triangulation_2, Periodic_3_triangulation_3, misc
• Issue(s) solved (if any): fix P2T2/P3T3: Periodic Delaunay triangulations make wrong assumptions about edge length (was Assertion in Periodic_2_triangulation_2<Gt, Tds>::is_valid_too_long_edges ) #2780
• Feature (if any): TODO
• Link to compiled documentation (obligatory for small feature) wrong link name to be changed
• License and copyright ownership: INRIA

[mglisse]

Hi Mael, what is the status of this PR?
We were waiting until it is done to add a python wrapper in gudhi, since the API should be a bit different, but if it is stalled maybe we should just wrap the old P3DT3 (we have demand for the cuboid case)? Is the API in this PR roughly finalized (unless people complain in the small feature of course), so we can judge how to write our wrapper in a way that can be updated without breaking our users' code?

[MaelRL]

It's stalled due to lack of time, but there's no theoretical issue.

The API should be relatively stable, and pretty much the same as every other triangulations (even the current "master" periodic triangulations) for the usual functionalities such as insert, remove, move, number_of_X etc.

So far this PR is work only on P2T2 and is still missing quite a bit to finish. And then everything needs to be mirrored into P3T3...

[mglisse]

The API should be relatively stable, and pretty much the same as every other triangulations (even the current "master" periodic triangulations) for the usual functionalities such as insert, remove, move, number_of_X etc.

Yes, the interesting part is specifying the domain, the need sometimes to call convert_to_1_sheeted_covering or deal with the redundancy, etc.

Thank you for the information, we will probably go ahead without waiting then.

Good luck with finishing the PR when you find the time.

[MaelRL]

For the domains, nothing will (should) change for the flat torus.

It is also backward compatible: I replace e.g. Periodic_2_triangulation_2 by a more generic class that is templated by the domain, and by default the domain is the flat torus.