Tolerance too strict in _test_node_vertex_consistency_resampling about meshmode

[alexfikl]

What sort of meshes are these? I've only been able to trigger that if there was actually something weird with the mesh.

You can work around it from the outside by setting node_vertex_consistency_tolerance in the mesh constructor:

meshmode/meshmode/mesh/__init__.py

Line 919 in c1ff399

node_vertex_consistency_tolerance=None,

By default it uses 1.0e+3 * eps, I think.

[inducer]

Could we use the size of the bounding box of each element individually?

I like that idea. Since this is an element-scale error, comparing to another element-scale quantity is likely a better idea (and more robust) than anything to do with the overall mesh size.

@majosm, could you do a PR?

[matthiasdiener]

We have seen it most recently with this: https://github.com/illinois-ceesd/drivers_y2-isolator/tree/main/data/3D/eightX_injection

[alexfikl]

Hm, I don't think the gmsh reader has a way to pass down the tolerance (most things in mesh.generation do), so this might need a bit of work.

EDIT: It does by setting mesh_construction_kwargs!

meshmode/meshmode/mesh/io.py

Line 283 in c1ff399

output_file_name="output.msh", mesh_construction_kwargs=None,

[alexfikl]

@matthiasdiener I just tried that mesh with just

from meshmode.mesh.io import read_gmsh
mesh = read_gmsh("isolator.msh")

and it didn't throw an error for me, weirdly. What version of gmsh are you using?

EDIT: Also, the mesh that I get from calling make_mesh.sh seems to be different than the one that's in the repo, but both read just fine.

[matthiasdiener]

These errors seem to be dependent on rank numbers as well. I tried https://github.com/illinois-ceesd/drivers_y2-isolator/test_mesh/lazy/oneX with 32 ranks, which does not trigger the assertion above, but 64 ranks trigger it.

[alexfikl]

These errors seem to be dependent on rank numbers as well. I tried illinois-ceesd/drivers_y2-isolator/test_mesh/lazy/oneX with 32 ranks, which does not trigger the assertion above, but 64 ranks trigger it.

Do the partitions look reasonable?

The error in the check is relative tol * size, where size is the bounding box of the mesh and tol ~ 1.0e-13. The only way I can see that failing like in your original report is if the size is very small for some reason.. Hm..

[majosm]

Seems like we should change the definition of size to make it independent of partitioning? Could we use the size of the bounding box of each element individually?

[majosm]

@matthiasdiener Can you try #316 on some of your isolator runs? (It should be independent of partitioning now; just want to make sure the tolerance isn't too tight.)