- vector must be initialized and vector size requires a const int
- also some sorting
- also some formatting changes to be consistent (either always "x." or "x.0")
- when the option "use this task panel" is not checked the edit fields must be disabled.
This also fixes the often hard to understand issue that while scrolling to the end of the dialog the material suddenly changes to "_transient" because the scroll wheel can trigger to change the edit fields.
- if pvtu file filtering is on, there is by design not on every call of WriteColorData() data
(on other occasions of GetArray(array) the result is checked, for two calls is was forgotten)
- also some automatic code formatting according to our current clang file
- it is sensible to filter by default, however, it turned out that on some complex models Elmer fails to compute if the mesh volume regions are too small (in most cases) or at a certain mesh region. By disabling the filtering, one gets at least for the latter case a visual feedback where the mesh volume of the different CPU are (by also setting a transparency to the result pipeline).
- To speed up analyses one calculates on several CPU cores. The result is a partial VTU file.
Unfortunately when applying a transparency the boundaries of the volumes computed by each CPU core are always visible. This makes it often unusable for visualizations.
The solution is to filter the results the same way a clip filter does.
- the ViewProvider sorting of the field can be different from the sorting in the dialog
- also hide a Contours property (I forgot this when the contours filter was added)
- sort the functions alphabetically to know where to scroll to - eases the reading at least a bit
- some automatic reformatting according to our current clang file
- split too long lines
- for harmonically driven forces, the results of course also have an imaginary part. Elmer outputs the real and the imaginary parts as separate result field. However, for several applications one needs the absolute (sqrt(Re^2+Im^2)
- therefore offer also absolute field if there are real/imaginary results
- the elctricforce equation is actually a postprocessor and thus should not be first in the list, but after the electrostatics equation (where it belongs to technically)
- also change menu name to be consistent with the other FEM menus
