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

Improve meshing #173

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Conversation

duarte-jfs
Copy link
Contributor

The present changes are meant to correct the meshing along lines, and prevent overrefinement, giving users more control on the mesh sizes.

The addition of the

gmsh.model.mesh.field.setNumbers(
                n + 1,
                "CurvesList",
                meshtracker.get_gmsh_xy_lines_from_label(label),
            )

Allows us to see a significant change on the mesh due to changes in the resolution definitions of LineStrings, and the second part follows from the gmsh manual, in chapter 1:

Note that when the element size is fully specified by a mesh size field, it is thus often desirable
to set
Mesh.MeshSizeFromPoints = 0;
Mesh.MeshSizeFromCurvature = 0;
Mesh.MeshSizeExtendFromBoundary = 0;
to prevent over-refinement inside an entity due to small mesh sizes on its boundary.

This will allow us to go from this kind of meshing when distance=0:

image

To this:

image

Which can be desirable.

Disclaimer: I'm not sure how much of a mess the commit history of my fork is. If it's too much trouble I'd be happy to close this PR and you guys can just make the necessary changes, if you see this would benefit the package as a whole.

@HelgeGehring
Copy link
Owner

Looks great! I looked over the last days also in this kind of refinement :)

We wanna migrate longterm to using meshwell for the meshing instead of the meshing in femwell. But as it'll take quite a bit of work to switch, it makes sense to keep maintaining the meshing within femwell until then :)

@simbilod could you have a look? To me it seems as if we can just merge it (whereas I don't know if the last three lines might be redundant (?))

@duarte-jfs
Copy link
Contributor Author

I agree. I tried to use meshwell, but found it easier to work with the mesh_from_OrderedDict for now as I was more used to it. The transition should be gradual to allow users to adapt

@simbilod
Copy link
Contributor

simbilod commented Aug 2, 2024

Looks good!

@HelgeGehring
Copy link
Owner

maybe we should just think of a implementation of mesh_from_OrderedDict which uses meshwell? 🤔 then noone would notice the transition? :D

Comment on lines +369 to +371
gmsh.option.setNumber("Mesh.MeshSizeExtendFromBoundary", 0)
gmsh.option.setNumber("Mesh.MeshSizeFromPoints", 0)
gmsh.option.setNumber("Mesh.MeshSizeFromCurvature", 0)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@simbilod didn't you put those options already somewhere? Or is that only in meshwell?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@duarte-jfs is there a reason why you add the last three lines again?

it's already done in (and the two following lines)

gmsh.model.mesh.MeshSizeFromPoints = 0

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

Successfully merging this pull request may close these issues.

3 participants