Open TotoGaz opened 1 year ago
I like check_mesh
because it is a name that users recognize, even if it does more than checking.
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
geos_mesh_toolkit
@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.
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?
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.
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.
Same, I really like the mesh_doctor
name. I like the idea that it's personified, like an artisan
, inspector
, reviewer
, surveyor
...
I am ok with mesh_doctor
, it's not misleading as doctors can't always fix you :D
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.
@TotoGaz So, the feedback from users, is that
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?
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
?
are the checks specific to
geos
? Without stating a good reason, I would just leave thegeos
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 keepmesh
first. I.e.mesh_check
andmesh_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 suggestmesh_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
🤣
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
vtk
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 acheck
)...