Changing the name of `mesh_doctor`

[TotoGaz]

The initial goal of mesh_doctor was to be able to diagnose issues in the mesh, but also provide some fixes when possible. It appears that the selected name misleads users who await too much from what merely is today a mesh validator.

As such, while I kind of like the name, I propose to switch to something that describes the tool with less ambiguities.

What's your opinion on this? Do you have propositions for a new name? As a matter of fact, this tool can be used to

• detect issues in a mesh
  • negative volumes
  • self intersecting elements
  • ...
• provide simple (or not so simple) fixes like
  • changing the ordering of the support nodes of an element in case of error with left/right hand rules
  • reorienting the normals of polyhedra such that they all points outwards
  • maybe clamp some fields to acceptable physical ranges
  • generate global ids for vtk
  • split and duplicate the nodes for faults and fractures
• eventually, we may want to include tricky mesh conversions like from corner point grids or RESQML. (to be discussed)

So what would a good name be? mesh_artisan (artisan is the same name in both French and English), check_mesh like everybody else 🤣 (but it's a bit more than a check)...

[herve-gross]

I like check_mesh because it is a name that users recognize, even if it does more than checking.

[rrsettgast]

I propose that there should be a "check" option to just let the user know they have problems, and the mesh is not acceptable, and a "fix" option to apply the simple (or not so simple) fixes.

So other than having separate front ends, mesh_check and mesh_fix, a single mesh_clean with flags? If we want to tap into users Microsoft PTSD, we could do mesh_wizard 😁 ...or mesh_clippy

[castelletto1]

geos_mesh_toolkit

[TotoGaz]

@rrsettgast The tools is organized with several separated checks and fixes; all the parameters can be accessed through CLI arguments. Having a category only visible to a mesh_check and another to a mesh_fix is OK.

@castelletto1 With a toolkit we can't be wrong 🎉 🤣

@herve-gross I'm afraid that some people will hear about check_mesh at the coffee machine and would miss the fact that the it may contain "building" features that could help them, not trying to investigate the tool.

@jeannepellerin What do you think would better fit our users? I think your input is key here.

[rrsettgast]

I think toolkit is fine, but then we may be on the hook to provide a functional "toolkit". I personally would rather throw the responsibility on the person generating the mesh to provide a valid mesh.

So is the intent to tell users that the mesh is invalid, or to fix it for them? If we are providing a "toolkit" then we should have a comprehensive development plan for expanding the deficiencies that the mesh_toolkit will fix?

[TotoGaz]

I think toolkit is fine, but then we may be on the hook to provide a functional "toolkit". I personally would rather throw the responsibility on the person generating the mesh to provide a valid mesh.

I think we all agree on this. The thing is that for some situations, pragmatically, providing a few tools can make the process of providing us with valid meshes easier can oil the wheels. (Not to mention that it can also help us investigate without waiting).

We can have a toolkit entry point and a check one.

So is the intent to tell users that the mesh is invalid, or to fix it for them? If we are providing a "toolkit" then we should have a comprehensive development plan for expanding the deficiencies that the mesh_toolkit will fix?

I we have a look at the IX process, there are a lot of mesh precomputing. If, to some extent, we want to mimic some of this pattern, we'll have to deal with the development appropriately.

[rrsettgast]

btw....I don't actually dislike the name mesh_doctor. It lets you know what is wrong, and can help with minor fixes. In some cases it will tell you that you have a bigger problem and need to make a lifestyle (i.e. workflow) change.

[TotoGaz]

Same, I really like the mesh_doctor name. I like the idea that it's personified, like an artisan, inspector, reviewer, surveyor...

[AntoineMazuyer]

I am ok with mesh_doctor, it's not misleading as doctors can't always fix you :D

[jeannepellerin]

Can't they ? I hope that their success rate is higher than mesh_doctor (whose responsability is not to fix all possible illnesses).

I agree with Randy that the toolkit may make the users expect too much. And it is their responsability to provide valid meshes and to fix (or make another tool fix the mesh).

What about 2 entries: mesh_diagnosis (check) and mesh_doctor (fix) ? The diagnosis being potentially still bad after seing the doctor.

[jeannepellerin]

@TotoGaz So, the feedback from users, is that

• geosx / geos should be added to the name.s
• 2 entries make the 2 steps clear. No preference for the name, as long as the command and all options have a manual.

[TotoGaz]

OK, thanks for the feedback. Since geos will be in the name, we surely don't want something too long. I propose

• geos_check_mesh
• geos_tweak_mesh

Does that sound good?

[rrsettgast]

are the checks specific to geos? Without stating a good reason, I would just leave the geos out of it. But it is your call.

Again, without providing a logical argument... if you are changing the name from mesh_doctor, I would keep mesh first. I.e. mesh_check and mesh_tweak, but instead of tweak which is sort of a funny slang, I would suggest mesh_repair?

[TotoGaz]

are the checks specific to geos? Without stating a good reason, I would just leave the geos out of it. But it is your call.

Actually, some checks are specific to geos. I'm thinking of the supported elements (are standard vtk cells supported by geos and can the polyhedron be converted into prisms up to 11 faces). Also our check for conformal meshes is quite specific. And others may follow, like finding some holes in the mesh, or some quality metrics that may be directly related to the equations we solve. A lot of other checks are not specific to geos though.

Again, without providing a logical argument... if you are changing the name from mesh_doctor, I would keep mesh first. I.e. mesh_check and mesh_tweak,

I was thinking of check_mesh because it checks the mesh.

but instead of tweak which is sort of a funny slang, I would suggest mesh_repair?

The standard meaning of tweak really is what we intend to do with that tool. There seems to be some slang meaning, yes. Is it a big deal? git and gimp software do not seem to care too much. As GoogleX and SpaceX do not care about their trailing X 🤣