- the current implementation only considers explicitly given binaries (with full path) and ignores the setting to check the environment paths
- also remove 2 trailing whitespaces
- 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
- load the results depending on the used cores, not always the multi-thread results
- avoid unnecessary console output - this info is already output in tasks.py
- handle number of cores as int to save in total 2 conversions
- for an not yet known reason the result from Elmer are only for eigen analyses a factor 1000 (we send the mesh scaled to Elmer and it seems the eigen solver does not notice this)
Therefore scale these results
- after a simulation was run, the pipelines and its childs are recomputed but its shape coloring is not updated.
- also update XML documentation
- also remove comment in tasks.py for now
- it seems that we will need to scale result values (probably for the Elmer Eigen solver)
This PR adds the framework to do this. It is meant for Elmer but designed versatile.
- on recomputing scalar or warp filters the information about the field was lost.
This is because the validity of an array was tested before it is actually filled
- also fix MSVC warning of using a C++ keyword as variable
- also avoid an unnecessary recompute after Elmer solver was run
- reverts commit 73fba1b7 - the scaling it correct
- there is a bug in Elmer that the heat source is not aware of the scaling
- write the scaling directly to the solver, not to the mesh itself. (make in principal no difference but we are closer to the solver)
- the mesh scaling was a hack to work around the fact that FC's mesh is in mm while all input units are in SI. It turned out that this made more problems than it solved because Elmer checks the length unit and makes internal recalculations. So the mesh must not be scaled when send to Elmer (despite the ElmerGrid docs doesn't state this).
forum thread: https://forum.freecadweb.org/viewtopic.php?p=614162#p614162
- while for CCX we output the eigenfrequency, for Elmer the user had to perform the calculation of a sqrt of the complex result.
This is inconvenient and error-prone and also requires the knowledge where the result is output by Elmer and in what format. (cast me more than an hour to find this out)
Therefore perform the calculation for the user and output the result.
- when the binary was not found, the function called the non-existing binary
- also push error message for Elmer and Z88 to the status info so that user gets feedback also when report view console is not shown
- uniform wording to 'binary'
- avoid unnecessary console output
- this needs proper testing, especially on a non-Windows system
- note that for some tasks multi-threading requires non-standard additional solvers like MUMPS. Ideally the user should be informed about this, depending on the equations he uses. But this should not block this PR, meaning to use multi-threading in general.
- for Elmer and Z88 on Windows several windows pop up (console windows). This is maybe annoying and the user is wondering what is going on, but the main problem is that when you close them, you break the solving process.
Therefore, on Windows only, hide the empty popup windows.
