Skip to content

Detection and promotion of geometric sink points.#188

Merged
allegroLeiden merged 3 commits intolime-rt:masterfrom
allegroLeiden:sink_points
Nov 17, 2016
Merged

Detection and promotion of geometric sink points.#188
allegroLeiden merged 3 commits intolime-rt:masterfrom
allegroLeiden:sink_points

Conversation

@allegroLeiden
Copy link
Copy Markdown
Contributor

Fixes #101.

This is designed to fix issue lime-rt#101. Sink points of the number specified by the user are initially constructed on a spherical surface of the specified radius. However it is possible for points located inside this radius also to be sink points, because the true geometric definition of a sink point is that it is a vertex of a triangular face of a Delaunay cell which lies on the outer surface of the model.

In the example model.c which comes packaged with the code, the desired number of sink points is specified via par->sinkPoints as 4000. This is a relatively and almost anomalously high number, since it leads to a mean distance between points on the surface which is much lower than the mean distance between internal points just adjacent to the surface. The knock-on effect of this is that most of the Delaunay cells which have one face on the surface may be expected to be very extended in the radial direction. In the absence of explanation for this high value of par->sinkPoints it has been speculated that this was to reduce the chances of a point with r<par->radius from being geometrically a sink point. With the new code in the present commit this requirement for a large par->sinkPoints is abolished.

Some tests showed that promotion of an internal point to a sink point was unlikely to happen with the example model unless par->sinkPoints was reduced to <100.

I also added the characters 'Qt' to the flag string sent to qhull() in grid.c in order to ensure that all of the resulting Delaunay cells were simplicial (i.e. that they were all tetrahedra).
@tlunttil
Copy link
Copy Markdown
Contributor

tlunttil commented Nov 11, 2016

Shouldn't the sink check be also done in delaunay calls during smoothing iterations? Smoothing moves points around, so isn't it possible that a non-sink point ends up belonging to the convex hull?

@allegroLeiden
Copy link
Copy Markdown
Contributor Author

It doesn't matter during the smoothing (I don't think so anyway), thus it only needs to be done in the final delaunay after the smoothing.

@tlunttil
Copy link
Copy Markdown
Contributor

Yes, ok. Somehow I thought that smoothing happened later that the delaunay call with sink checking, but now I see that isn't true.

@allegroLeiden
Copy link
Copy Markdown
Contributor Author

It used to be that way.

@allegroLeiden allegroLeiden merged commit 455542d into lime-rt:master Nov 17, 2016
@allegroLeiden allegroLeiden deleted the sink_points branch February 1, 2017 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants