River meshing about oceanmesh HOT 5 OPEN

However, is there any reason you wrote custom code to use CGAL? Was any functionality missing from the SWIG generated bindings?

I had a lot of difficulty implementing and deploying SWIG and had some prior experience with pybind11.

from oceanmesh.

Hi Soroosh, I didn't finish the CGAL call (in cpp) to support constraining edges in the triangulation. If you're interesting in learning more about that, I can point you in the right direction.

I don't agree that the meshers should just "mesh". For numerical simulation, the user needs to understand how best to construct the model. Besides, this requires a small number of parameter selections inspired by the downstream application.

Anyway, I believe that automation shouldn't result in a loss of knowledge.

from oceanmesh.

Hi Keith, thank you for your response.

I started looking into using CGAL directly too. They have a nice SWIG binding package which covers most of the triangulation and meshing use cases (I still need to try it!).

In any case, I was wondering if oceanmesh already supports constrained triangulation-only use case? In my case there's an algorithm developed by VIMS team that provides optimal node location for river/watershed mesh. I just need a library to triangulate it. I failed to do so with jigsawpy through ocsmesh, so I tried oceanmesh where I was unsuccessful again. So I started looking into CGAL direct use.

If you believe this use case is not something relevant to oceanmesh I can close the ticket.

from oceanmesh.

Soorosh,

oceanmesh uses CGAL to do the Delaunay triangulation already.

What I'm saying is that I did not finish adding the functionality to constrain edges in the triangulation, as noted.

In this folder you can see the existing interface with CGAL.
https://github.com/CHLNDDEV/oceanmesh/tree/master/oceanmesh/cpp

additional code would need to be written to constrain edges.

Anyway, I think meshing rivers would ideally be a supported use-case.

from oceanmesh.

I think we're kind of saying the same thing, but there's a miscommunication:

Anyway, I think meshing rivers would ideally be a supported use-case.

The reason I thought you might not be considering this use case was what you said in the earlier comment that:

I don't agree that the meshers should just "mesh". For numerical simulation, the user needs to understand how best to construct the model. Besides, this requires a small number of parameter selections inspired by the downstream application.

Anyway, I believe that automation shouldn't result in a loss of knowledge.

oceanmesh uses CGAL to do the Delaunay triangulation already.

I know! And actually oceanmesh inspired me to look into using CGAL directly, and it looks like a great library with a lot of functionalities!

In this folder you can see the existing interface with CGAL.
https://github.com/CHLNDDEV/oceanmesh/tree/master/oceanmesh/cpp

additional code would need to be written to constrain edges.

I see that you're just inserting points in the triangulation, but not the constraint edges. So it looks relatively straightforward. However, is there any reason you wrote custom code to use CGAL? Was any functionality missing from the SWIG generated bindings?

from oceanmesh.