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).
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.
- fix bug that changing constraint type in dialog lost flux value
- accept and not immediately save any changed value
- make the temperatures a PropertyTemperature to get rid of hacks
- also fix some too long code lines
- for the first time ever you get now for every time step a result in FreeCAD
- this way also change output filename prefix to "FreeCAD" to avoid we depend on the default name Elmer gives and that was already changed in the past and to distinguish the *.vtu files from those created e.g. directly by ElmerGui
- also remove an unnecessary output to the case.sif file
- different time results were never output, only the final one
the reason is that the Output Intervals intervals property was missing
- a second reason was that the result scaling solver must be executed every time an output should be generated
- the BDF Order property is a transient-only property
- the heat capacity of water was wrong
- also specify just thermal expansion, this make that water is recognized as material and then all water parameters will be available
(that the analysis fail despite CalculiX reports everything went well s is another issue, I will investigate later)
- when looking at the Elmer input file 'case.sif' it is extremely helpful to thee also the name of the material
Since the name is only form info, this does not change the actual simulation
- output equation-specific values only if this equation is used
- use Elmer's default for BDF order as default for FC too and allow to change it
- don't hardcode to Steady State. Transient must be possible too, this way add parameters to run a transient analysis
- the usually mandatory setting DisplaceMesh was missing leading to imprecise results. Now the calculated faceload is almost the exact same as with CCX
- also add most of the other settings Elmer 9 provides
- also add tooltips
- we must not hardcode the number of coincidence vector places
The user must have a chance to change this setting for the iterative solvers according to the Z88 docs.
We use as default the number Z88 uses in its distributed example.
(I doubt that it is sensible to check if a hardcoded memory value is written. The test will fail if you use a non-default memory setting on your FreeCAD. The CI uses of course the default)
- since we use consistently SI units (as recommended my the Elmer forum), we need to scale the input mesh (we use ElmerGrid that has an option fur this purpose)
- Since the result will be in the scaled mesh, we need to scale it back
With this PR, one gets now correct result independent of
- the used unit scheme
- the simulation type (electrical or thermo-mechanical)
Fixes two errors introduced in/due to 7621382272ae712ebf4493d996d1a1a918e95df7.
First one is a typo. The writer used "translations" where the reference file for
the test used "translation". Went with "translation" since that was mentioned in
the comment just above.
Second one is some missed out new lines in the reference file
`.../constraint_transform_beam_hinged.inp`. These lines were added in
`.../frequency_beamsimple.inp` but not here.
