-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specifying mesh orthogonality threshold #265
Comments
Note: For the example below, I have used the mesh generated by (Example_1_NZ.m) for the ease of reproducibility.
Close ups of problematic elements (red), and the value of orthogonality displayed on the edge.
|
Thank you Nada. We will need to implement this formula inside the msh class to test mesh generation and improvement strategies. I would try reducing the gradation the g parameter to 0.15 in the mesh size function. This will improve the orthogonality constraint making it more amenable for simulation. |
I am attempting to compute the orthogonality of the New Zealand msh obj (acquired by running the example 1), however I am unsure which edge of the triangle is the "netlink" in your description. Is the netlink the edge that intersects the flowlink? If so then my code below calculates the ortho. but it's almost near zero indicating a good mesh, but perhaps my calculation is incorrect in some way. Note this script can be read with all the functionality inside MATLAB and the utils folder of OceanMesh2D on the general path. @NadaSulaiman Any ideas what may be wrong here?
|
I think the correct angle calculation is
where |
hm further inspecting this code a little bit more tonight, still coming up with low orthogonality (all < 0.5) values for a Delaunay triangulation of a random set of points.
|
Hi all, many thanks for the efforts. I have adjusted the code to obtain identical orthogonality values as it was displayed inside the DELFT FM grid generation module (RGFGRID). Summary of the steps:
In conclusion, the variables t, ee, and C which were imported directly from the DELFT FM grid seem to be different in values and/or dimensions from those computed in MATLAB. Very strange. Here are some side-by-side close-ups to compare between the orthogonality obtained from RGFGRID and the modified MATLAB code. I believe they are identical. |
Apologies for the unclear description. Perhaps this figure from Bomers et al. (2019) better illustrates the idea. |
Alternatively, instead of saving the mesh as .14. and then converting it to _net.nc, we could write it directly as DELFT mesh by adding those three lines to the end of Example_1_NZ.m script. (writeNet.m needs to be downloaded first)
|
Since
does not equal
Could anyone have a quick look at the definition of how the circumcenter of a triangle is computed from the D-Flow Flexible Mesh Technical Reference Manual (p.17) and confirm if it's the same method used for the MATLAB circumcenter function? I couldn't tell. |
Hey Nada, I'll take a deeper look but there should be only one definition of the circumcenter. Perhaps the grid is projected into a map projection by Delft RF grid? Could you share the netcdf files necessary to run the snippets of code you posted? The element table may also be orientated in a different way by RFgrid |
Hi Keith. The grid is uploaded in the zip file here [delftexport_net.zip]. You should be able to run the code with it. |
Indeed @NadaSulaiman the circumcenter calculation in MATLAB using the triangulation object produces different values for the circumcenters than what the utility you used above does. Interestingly some of the circumcenters are the same and some are not. |
I think DFM is placing the circumcenter on the boundary of the element if it's outside of the element while the MATLAB one is not. |
You are correct. I think it places it to the edge closest to the location of the circumcenter outside the element. |
@NadaSulaiman Yes, we can do that. One naïve way would be:
It seems that if the circumcenter falls outside the cell, then DFM sets the triangle's circumcenter to the edge's midpoint nearest to the circumcenter. |
Just wondering if there are any updates progress on this, or thoughts? |
Hi. Unfortunately no progress on my end. |
Hi, never had the motivation to finish this as new things always come through. It's unfortunate the scheme is so sensitive to the mesh. This is almost a fatal flaw IMO. I found this repo recently though with this code that calculates orthogonality. Someone could translate it to matlab. Someone (myself included) needs to write a mesh non-orthongality calculator. The optimization approach would basically involve flipping edges and moving nodes in patches that don't meet the quality threshold. |
Thanks for the responses. This is from the D-Flow manual: I am guessing it would have to be a pretty big task to have an orthogonality check, constraint and adjustment step in the mesh generation. |
Actually I don't think it would be too much work we just need to dedicate time. I also work on the applied side. I would be willing to set up a small project to work on this. |
Ok, sounds good. I spent some time yesterday using @NadaSulaiman's code, and some other bits, to inspect orthogonality values. As @NadaSulaiman mentioned, getting a match between RGFGRID and OM2D outputs is not straight forward and even then I still didn't get an exact match. Also, I spent ages manually adjusting a grid to get all orthog values below 0.5 and it still would not let me run the simulation. A function to established a rgfgrid-style_net.nc structure/variables with out manually saving off in RGFGrid may be a starting point. Happy to help where i can. |
Also found this that may provide some ideas: https://github.com/Deltares/MeshKernelPy/tree/main |
Not directly related to OceanMesh, but I've worked out a solution to this using the Deltares MeshKernal/ UGrid tools, which contain routines for orthogonalization. So the process is:
I'll post my terribly Python below in case it's helpful to someone immediately, and hopefully post a repo with a bit more detail on this method. I'm happy to submit a PR here, but since it's Python and relies on a ton of (windows only) external libraries, not sure it's a good fit for OceanMesh.
|
Delft FM has a strict grid orthogonality requirement to simulate.
Equation for orthogonality error: ....
Would like to be able to specify the maximum allowable orthogonality error for mesh generation and cleaning so that it can pass the Delft FM pre-simulation tests.
The text was updated successfully, but these errors were encountered: