we are currently working on improving both the intuitiveness as well as the capabilities of the meshing workflow. Subsequent releases shall help to make meshing on SimScale more powerful, faster and easier.
In a very simple, first step we plan to rename and reorder the current meshing operation types, that are:
- Fully automatic tetrahedralization
- Parametrized tetrahedralization
- Automatic snappyHexMesh for internal flow
- Automatic snappyHexMesh for external flow
- Tetrahedral meshing with prismatic viscous layers
- Tetrahedralization with refinements
to a more consistent and clearer naming and order:
- Tetrahedral automatic
- Tetrahedral parametric
- Tetrahedral with local refinements
- Tetrahedral with layer refinements
- Hex-dominant automatic for internal flow (only CFD)
- Hex-dominant automatic for external flow (only CFD)
- Hex-dominant parametric (only CFD)
Are these names clearer to you? Are all words (e.g. “Hex-dominant”) clear to you? Would you choose a different name for one of the operations that would make it even easier to understand for new users?
If you’ve got any improvement suggestions for these names, it would be great if you share them!
Thanks a lot,
The new proposed names are better to understand. I would recommend an info windows with a typical picture of the mesh to see the difference e.g. Hex-dominat and Hex-mesh. Tetrahedal is clear for me but it doesn’t hurt if you show this mesh as well
I definitely agree on the value of a “mesh preview” image! Thanks for your input!
I think the new naming reordering is much clearer.
I would like to see Parametrized tetrahedralization and Tetrahedralization with refinements merged into the one operation. It seems to me that both operations are globally parametrized, just one has the option for refinements. Is there any reason why they cannot be merged into the one operation and refinements are made optional rather than mandatory?
great, that the new names are clearer to you!
I agree that merging those two operations would remove complexity while preserving all capabilities. The current work goes even further towards a more integrated way of specifying the mesh generation mechanism, but it’s a bit too early for details. So in a first step, the operation structure might stay the same, but in a second or third step, also the structure will be improved. I’ll share details for a discussion soon.
Quick update: Talked to some more users and everybody was of the same opinion that the new naming is more intuitive. Will be in production soon!
Thanks again for your thoughts!
Another step in terms of mesh generation UX improvement made