Relative paths appearing in Gmsh .geo files are relative to the .geo
file, not relative to the cwd when the gmsh executable was invoked. This
is okay when using absolute paths with the default "Temporary
directories" mode, but if one selects (in Preferences -> FEM) "Beside
.FCStd file", then relative paths are written to the .geo file. This
causes a (suppressed in FreeCAD output) warning from Gmsh that the brep
file is missing as well as the error:
Unexpected error when creating mesh: File to load not existing or not readable: partname/FEMMeshGmsh/BaseFeature_Mesh.unv
In this commit we just use relative paths, which is also convenient if
users move these files elsewhere (e.g., to work directly with advanced
features in Gmsh).
The load of the current file in test_open_head is fine, but
open_de9b3fb438 goes into an OOM even in huge (e.g. 10GB) systemd.
This probably needs a proper fix by upstream in regard to the migration
modules that load the old code, but until then (since the rest works on s390x)
this unblocks the package self-test in Debian & Ubuntu.
Patch by Christian Ehrhardt <christian.ehrhardt@canonical.com>.
This is Debian bug https://bugs.debian.org/984952 and Ubuntu bug
https://bugs.launchpad.net/ubuntu/+source/freecad/+bug/1918474.
Been part of the Debian edition of FreeCAD since 2021.
I sometimes use the FEM workbench to create meshes for a problem that
I'll solve with an external FE solver that doesn't yet have workbench
integration, or to prepare a Gmsh file for tweaks from directly running
Gmsh. The .unv format is pretty limited on technical grounds so I rename
the file to .msh (can express everything Gmsh can) or a
parallel-friendly format. Explicitly setting Mesh.Format = 2 is
confusing because this line also needs to be fixed (or deleted) when
renaming the output file name.
The lupdate tool does not correctly parse Python string concatenation. Also, .format() calls should be made on the string returned from tr(), not on the string going into it.
