-
Notifications
You must be signed in to change notification settings - Fork 15
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
Inaccurate cuts with disk #43
Comments
Hi, Oriol! I have not faced similar issues, because I have always used uniform Cartesian meshes. But as soon as I prescribe an anisotropic Cartesian mesh, I reproduce the behaviour you have identified. using Gridap
using GridapEmbedded
const R = 0.42
geom = disk(R,x0=Point(0.5,0.5))
partition = (9,3)
domain = (0,1,0,1)
bgmodel = CartesianDiscreteModel(domain,partition)
cutgeo = cut(bgmodel,geom)
Ω = Triangulation(cutgeo)
writevtk(Ω,"trian") |
Hi @oriolcg, I am not sure that this is a bug. Marching cubes has some geometrical error (it considers piecewise linear approximations), and perhaps you are seen this error. can you try with a levelset with a piecewise linear 0-isovalue ? like
|
Thanks for the answer @fverdugo, I'll try with How is the Marching cubes implemented? I would expect that the intersection between element edges and an analytical geometry would be exact. It's true that Marching cubes does a linear approximation, but that's the reconstructed element and it shouldn't affect the accuracy of the intersection point. |
Indeed, |
I think I see where is the problem, and it is not related to the Marching cubes algorithm. I thought that the intersections were obtained from intersecting the background grid edges with the analytical geometry, but they aren't. They are obtained from the levelset function interpolated from the levelset values at the background grid points. For the mesh that I was testing this approach results in big errors because the levelset gives the closest point distance (orthogonal to the circle), while one would be interested on the distance following the edge direction. I presume that this issue will appear for all geometries that are not linear. The errors can be large for background grids in which at least one of the directions does not capture well the geometry (even if all the other directions are fine enough). Does it make sense? A solution for this problem would be to find the actual intersection between each edge and the analytical geometry. But this is quite involved and may be more expensive. |
I'm getting inaccurate cuts when intersecting with a
disk
geometry, see attached figure. You can see that only the intersection with vertical edges are well captured, while the intersection with horizontal edges seems to be following another geometry.Did anyone faced similar issues?
The text was updated successfully, but these errors were encountered: