FreeCAD
FEM: Enable FreeCAD to generate mesh in different file formats
This is a preliminary step to this: https://github.com/FreeCAD/FreeCAD/issues/12675 . This will let users choose the mesh file format from Fem settings, enabling Gmsh to generate the mesh in the chosen format. Additionally, this mesh format property has been added to each solver's properties (currently, only has .unv format option ). This also includes functionality to read a .msh file.
Thanks for the PR! @marioalexis84 and @FEA-eng your comments would be welcome here. My read is that this is a feature addition, so should not be scheduled for integration until after we create the 1.0 branch.
If the format in preferences is set to .msh then the generated mesh can't be used with CalculiX - it seems that the elements are inverted.
While support for more mesh formats with Gmsh can be good and helpful for the integration of other solvers, I'm not sure if it should work this way. Why would a user need to change the mesh format for use with built-in solvers? They should have a fixed setting that always works with them and it should only be possible to change the format for export and for use with add-on solvers.
Btw. I would like to already say that, in my opinion, this rather niche (but interesting) Ratel code should be an add-on, not a built-in solver in FreeCAD FEM. We already have too many built-in solvers, often with support only to a small extent. I don't see enough needs for such a new tool in the core. However, FreeCAD has many great add-ons, also for FEM, and Ratel could become one of them, available from the add-on manager for anyone who wants to use it.
P.S. Here's another library for higher-order elements: https://stressrefine.wordpress.com/
What kind of high order elements do you want to manage? It should be kept in mind that the Fem::FemMesh class basically serves to access a Salome mesh object, which supports the following types of elements: https://github.com/FreeCAD/FreeCAD/blob/8f6798fcc1914889bfdad1b83f5a66d8651733d2/src/3rdParty/salomesmesh/inc/SMDSAbs_ElementType.hxx#L80
In relation to the code:
The FemMesh::Save function has nothing to do with solvers or mesh generators, it only serves to save the mesh data for later loading when reopening the project. I think we should maintain a fixed format with support for the element types used by Salome mesh. With the .unv format there is currently a limitation in the implementation of the UNV writer used by Salome for some types of elements (see: https://forum.freecad.org/viewtopic.php?t=13583) which is why I think we should migrate to a med or vtk file. (or try to fix the unv writer/reader).
What is important in relation to solvers/meshers is the ability of FemMesh objects to write/read mesh data in different formats (the more the better), so it is good to add .msh files among the options.
Currently, work is being done to simplify the interaction between the solvers and the Fem core, so I also think that it is best to incorporate Ratel as an add-on.
Thanks for your comments. Agreed about this being post-1.0. We wanted to get some feedback, but understand it can't merge during the feature freeze.
Regarding reading in the mesh, we feel the .inp workflow (reading from the mesh generator and then writing a file that contains the mesh, materials, and analysis parameters) is an undesirable IO and memory bottleneck. Ratel instead reads from the mesh file and takes analysis parameters from a yaml file (or other representations). It can be useful to read the mesh in, but mostly as a visual sanity check of its resolution. We'd rather this not be mandatory.
We have no problem suppressing the .unv default from the UI for the existing solvers. For Ratel, users may want to use formats that support parallel IO (mostly when launching parallel jobs). This is an advanced use case and we would be fine deferring that.
Regarding the choice of FEM Workbench versus add-on, the FEM Workbench has lots of useful things that we'd rather not re-invent or copy out and then have to maintain in the add-on. It looks like the existing addons are pretty bare-bones except for OpenFOAM, which has over 10kLOC.
We support arbitrary order hex and tet elements, and plan to support mixed topology (our mesh structure handles it, but it's not plumbed into Ratel). We most commonly use quadratic and cubic elements for solid (and fluid) mechanics, not because high-order is slower (it's not) but because one usually gets sufficient accuracy on the coarsest mesh that resolves the geometry. We see reading meshes into FreeCAD as optional and solely intended for visualization, not as the path to the solver (except for solvers that require it).
Regarding the choice of FEM Workbench versus add-on, the FEM Workbench has lots of useful things that we'd rather not re-invent or copy out and then have to maintain in the add-on. It looks like the existing addons are pretty bare-bones except for OpenFOAM, which has over 10kLOC.
Add-ons can still fully utilize the capabilities of the core FEM workbench without having to reimplement anything. Check how some of the existing ones (such as fcVM or beso) are implemented. IMO this would be the recommended way here.
(reading from the mesh generator and then writing a file that contains the mesh, materials, and analysis parameters) is an undesirable IO and memory bottleneck
I agree that some of the current implementation is suboptimal.
The goal is to expose the Fem core framework to Python in such a way that solvers can be added as plugins without having to reinvent anything. In fact, CalculiX, Elmer, etc. must be decoupled from the core. The only difference between the solvers currently used by the program and an external one should be the location of the files needed to generate the solver input. It would be excellent to know what needs a tool like Ratel may have in relation to the Fem core.
Thanks for the pointer to fcVM. Does it actually use the FEM Workbench? In the screenshots, I see it says "fcVM workbench" and does not inherit menus/icons from FEM Workbench. I see fcVM-specific dialogs for materials (like yield stress) instead of using the existing materials infrastructure. Is your vision for the existing FEM Workbench solvers to move out into the likes of "CalculiX Workbench" and "Elmer Workbench" while using core, or to have them as addons that show up as a different solver in the existing FEM Workbench? Are there any examples or an in-progress branch with the organization you want? If not, would it be sensible for us to develop Ratel solver support in a branch until core is ready to move our solver-specific things elsewhere? (I understand the branch might not be merged, but I want to avoid duplication or heavy refactoring outside of our domain of expertise.)
It would be excellent to know what needs a tool like Ratel may have in relation to the Fem core.
Here are some things we've been thinking about and may be relevant:
- We've been coordinating with Dave about design of the new materials system. We plan to expose more general finite-strain material models, including near-incompressible, phase-field fracture, poroelasticity.
- We'd like reading in the mesh back into FreeCAD (typically from Gmsh) to be optional (and purely diagonstic). We'd like to be able to display quality metrics as computed by Gmsh. We decouple solution order (which may be different for different fields) from geometric order.
- The space of parallel job configuration, iterative solvers, and GPUs is big. I think those would all be solver-specific.
- We've been adding support for material-point methods, though haven't thought yet about exposing that in FreeCAD.
- We think one-click "Postprocess in Paraview" would be useful. This is minor and could be solver-specific.
- We're interested in automated shape optimization from an under-constrained model. The idea would be that you could create an under-constrained sketch, then optimize (FEA-derived properties) over the null space of the constraints without being required to first constrain and label the free parameters. We could do this with gradient-based methods or derivative-free optimization.
Aakriti has moved on from our research group to a new role. I can rebase this branch, but it'll have to become a new PR since we can't update the source branch. Feedback on the questions above would be helpful for rebasing/updating other work she did this summer -- I don't understand the vision for taking solver support out of the FEM workbench other than to fork the whole workbench or to design a new plugin system.
@aakritisi will you resolve this PR or will you, @jedbrown create a new one?
@aakritisi will you resolve this PR or will you, @jedbrown create a new one?
bump
Hi, @maxwxyz. I'll rebase and create a new PR (as noted https://github.com/FreeCAD/FreeCAD/pull/14667#issuecomment-2484275151). What would be a better place to discuss these questions -- in particular I can't tell what is aspirational versus meant to be ready now without heavy refactoring of the FEM workbench?
@jedbrown usually @FEA-eng or @HarryvL or here: https://forum.freecad.org/viewtopic.php?t=85474
Sorry, been afk. I'm not sure what action here is expected from me, besides making a new rebased branch and opening a new PR. The forum thread seems targeted at users, not avoiding replication between different plugins (that is, out-of-tree solvers using the FEM Workbench). Another thing to consider there is desire to compare solvers without needing to set up all boundary conditions, etc., separately for each solver.