Weird patches of very small cells

[TPCollings]

I've noticed recently in a few different meshes I've generated areas of very, very small cells. I haven't been able to figure out a pattern for where they form so I'm not really sure what causes them. They seem more common in meshes in which I delineate channels, but I've also noticed them in fairly basic meshes which just use subtidal flow limiter, and distance away from the 0m contour to define the Hfun. They can be a problem as they cause schism to crash with a 'negative area error' in the mesh.

I've been able to get around it by plotting the same mesh but moving the initial contour that is meshed from - i.e. from 0m to -0.2m.

Any ideas what could be causing them? I've attached some figures to demonstrate. The smallest elements are usually smaller than 1/1000th of metre.

[SorooshMani-NOAA]

What version of jigsaw and jigsawpy is installed in your environment? I used to see this issue, I reported it to the jigsaw developer and he fixed it. If you're not using the latest repository version of jigsaw and jigsawpy, I'd suggest upgrading to the latest first.

[TPCollings]

Jigsaw is 0.9.14 and Jigsawpy is 0.3.3 which I've checked against conda and they look like they're the latest versions available on conda. Do you install them directly from github or from conda?

[TPCollings]

I think this issue is becoming more common. Before I'd notice it maybe 1 mesh in every 5, now its appearing a few times in every mesh I generate

[SorooshMani-NOAA]

Can you please try it from the GitHub repo as well? I think the latest is not released on conda, although the fix is from more than a year ago! At least version-wise I recall the version that had the fix was 0.3.6, but I don't know if conda versions are correctly aligned with the repo versions. I suggest installing both jigsaw and jigsawpy from repo, just to be sure. You can just download jigsaw-python repo and call python setup build_external and then pip install . in the repo rootdir. Note that for the build part you need GCC and CMake.

[felicio93]

I noticed that was still a problem and I started working on a solution:

I am wrapping up a script that: 1 - calculates all the element areas using pyschism's grd.elements.get_areas(), and select the invalid ones (<1e-10 square) 2 - converts all these elements into polygons 3- clips out all these invalid elements using ocsmesh's ocsmesh.utils.clip_mesh_by_shape 4 - remeshes these areas (either with cgal or jigsaw, I have to test that part)

Here is an illustration of how it works:

After the floodplain mesh is created, we screen it for elements <1e-10 square degree:

Convert those elements to polygon:

Create a buffer around those areas:

Create a mesh for these buffers using the hfun mesh (calling these meshes "patch meshes")

embed these "patches" into the floodplain mesh:

[SorooshMani-NOAA]

calculates all the element areas using pyschism's grd.elements.get_areas(),

@felicio93 please note that if you are adding something to OCSMesh, ideally we don't want to have pyschism dependency. Having it in river_in_mesh is also not desirable, but for now that should be OK

[felicio93]

Dear @TPCollings,

We just updated OCSMesh with a fix for the problem you identified.

You can now fix these "patches of very small cells" with the following: ocsmesh.utils.fix_small_el(mesh_w_problem, mesh_for_patch)

where, mesh_w_problem is the problematic mesh, and mesh_for_patch is that mesh that will be used to fix it.

I recommend using you hfun mesh as the mesh_for_patch, as: mesh_for_patch = ocsmesh.Mesh.open({PATH}+'hfun.2dm', crs=4326)

PR: #153