Skip to content
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

Open
oriolcg opened this issue Jan 22, 2021 · 5 comments
Open

Inaccurate cuts with disk #43

oriolcg opened this issue Jan 22, 2021 · 5 comments

Comments

@oriolcg
Copy link
Member

oriolcg commented Jan 22, 2021

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?
image

@ericneiva
Copy link
Member

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")

@fverdugo
Copy link
Member

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 quadrilateral ?

function quadrilateral(;x0=Point(0,0),d1=VectorValue(1,0),d2=VectorValue(0,1),name="quadrilateral")

@oriolcg
Copy link
Member Author

oriolcg commented Jan 24, 2021

Thanks for the answer @fverdugo, I'll try with quadrilateral and let you know.

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.

@oriolcg
Copy link
Member Author

oriolcg commented Jan 24, 2021

Indeed, quadrilateral seems to work well. But I'm still not convinced about the Marching cubes argument. I'll try to investigate a bit more.

@oriolcg
Copy link
Member Author

oriolcg commented Jan 24, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants