search

CHLNDDEV / OceanMesh2D

A two-dimensional triangular mesh generator with pre- and post-processing utilities written in pure MATLAB (no toolboxes required) designed specifically to build models that solve shallow-water equations or wave equations in a coastal environment (ADCIRC, FVCOM, WaveWatch3, SWAN, SCHISM, Telemac, etc.).
https://github.com/sponsors/krober10nd
GNU General Public License v3.0
183 stars 65 forks source link

Reversal of boundary segments #167

Closed krober10nd closed 3 years ago

krober10nd commented 3 years ago
WPringle commented 3 years ago

I also encountered this strange ordering before but I remember depending on the clockwise/anticlockwise choice would produce different results. Would be good to find out the source of the error instead of the ad-hoc adjustment at the end.

krober10nd commented 3 years ago

It isn't ad hoc but it does suggest other changes. The edges are ordered in a way that creates this problem

Perhaps we should get rid of this CW and CCW option and instead just make people switch the ordering of the inputs. It's not clear what CW and CCW always mean for complex polygons and most people (including me) simply guess.

krober10nd commented 3 years ago

Perhaps the default should be 1 and leave it like that.

WPringle commented 3 years ago

Right so tell people they have to enter it in Clockwise ordering? Which is 1 again? I still would like to see where the wrong ordering is coming from and I'm worried that this doesn't always apply. It must be right most of the time because doesn't often produce this error.

krober10nd commented 3 years ago

Right so tell people they have to enter it in Clockwise ordering? Which is 1 again?

Yes something like. Just get rid of this option in the API.

In the file utilities/extract_boundary.m I describe the algorithm for the "traversal". We can have a closer look at it, it's been years since I wrote it.

krober10nd commented 3 years ago

Running the JBAY example and picked an arbitrary segment just switching the order of the input indices keeping the order set to 1.

Screen Shot 2020-12-23 at 3 22 19 PM Screen Shot 2020-12-23 at 3 22 33 PM
krober10nd commented 3 years ago

I think I've found the origin of the problem. Line 66-67 of utilities/extract_boundary adds the entire selected edge to the polygon list ignoring the v_start and v_next while all other segments consider this.

krober10nd commented 3 years ago

Okay put in a fix. If v_next doesn't appear as the last entry of the first edge selected, the edge is flipped so that is the case.

WPringle commented 3 years ago

Ok cool so it definitely works for normal open boundary selection as well as small river like segments?

krober10nd commented 3 years ago

I've tested it with a one edge segment with order=0 and order=1 on two different meshes and they all worked. I've also tested segments for length 3 vertices and on larger domains as well and the original problem did not crop up.