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

mesh generation in rings example errors #305

Closed
fedeinthemix opened this issue Nov 22, 2024 · 3 comments
Closed

mesh generation in rings example errors #305

fedeinthemix opened this issue Nov 22, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@fedeinthemix
Copy link

Description

The file examples/rings/mesh/mesh.jl defines the function generate_ring_mesh. Among the keyword parameters there are rot_center, rot_axis and rot_\theta. However, the function body uses rc, ra and \theta instead. Therefore, calling the function errors out.

Even correcting the names, the gemerated mesh doesn't gemerate the same mesh as the one included in palace 0.13.0. In particular, differently from the distributed rings.msh file, the generated one does not include any physical group.

Environment

OS: NixOS 24.05
Palace: 0.13.0
Gmsh: 4.13.1
Julia: 1.11.1
Julia-Gmsh: 0.3.1

@fedeinthemix fedeinthemix added the bug Something isn't working label Nov 22, 2024
@fedeinthemix
Copy link
Author

Regarding the physical groups. I did a mistake and did set the mesh file extension to ".mesh" instead of ".msh". After I corrected this, the physical groups do show up. Sorry

@hughcars
Copy link
Collaborator

hughcars commented Nov 22, 2024

Hi @fedeinthemix,

Thanks for the catch on the variable names, you're right they don't match the arguments, there must've been rebasing issue at some stage. These mesh generation scripts aren't part of CI and are mainly for demonstration of how to create these relatively simplistic geometries in case they're of use to users. Consequently we are at risk of things like this creeping in.

Aside from noting that bug (again, thank you), rerunning the script will not generate an identical file to the original msh file, because the HXT algorithm gmsh.option.setNumber("Mesh.Algorithm3D", 10) is not deterministic. Namely rerunning will give a different answer each time. The suspicion is this relates to their approach to thread parallelism, but this remains just a suspicion. If you want full determinism, algorithm 1 uses a serial Delaunay algorithm which is more predictable (if significantly slower).

I'm not sure why changing the extension like that would alter the presence of physical groups, as the mesh format ought to be fully specified by gmsh.option.setNumber("Mesh.MshFileVersion", 2.2) but I am glad it is working for you now. Feel free to try the fix in #306

@fedeinthemix
Copy link
Author

Hi @hughcars

Thanks for the explanation about the meshing algorithm. I'm new to Palace and Gmsh and the mesh generating scripts are very useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants