Hi everyone. This will be the biggest status update
yet. It starts off with a quick overview followed by a list of new features (compared to the state of the calculix solver) as well as a list of things that don't work yet. This should contain everything a user who wishes to test my code needs to know. The last part intends to provide a quick start for developers kind enougth to provide me with feedback about my design. The main reason for this update
is to gather testers and developers. I intend to merge the code as soon as possible. It's published in my fork: https://github.com/drhooves/FreeCAD
How do I spend most of my time?
Initially I spent most of my time working directely on the elmer integration. After the initial support was finished I focused on improving the Fem workbench as a whole. Every impovement descriped in the sections below is solver generic. As soon as a solver (calculix) uses the framework it shares all features (except generation of input files) with elmer. This phase is mostely finished now and the next weeks I'm going to focus again on improving the simulation results and implementing multi-physics support.
Not much changed here. It should be noted that not all constraints are supported by elmer atm. For unsupported constraints a warning will be shown when the solver is executed (a dialog window). Also elmer requires a gmsh mesh. A mesh created with netgen or an imported mesh won't work.
Solving the Analysis
Here it gets interesting. The backend used to implemented everything that happens after the user clicks "Run Solver" or issues the command from the toolbar was completely rewrittn. When I talk about a new execution framework I mean this newly written backend.
- A report window (shown at the end of the execution) summarizes infos, warnings and errors that happend during the generation of input files, solver execution and loading of the results. If a gui is avaliable it's displayed via a dialog window. If not the report is printed to the console. If there are errors during the execution the solving process is aborted and the report showen immediately.
- The new task panel for the solver, named "Solver Control Panel", doesn't do the execution itself. Rather it provides a view to a thread that does all the work in the background. This thread is the same no matter which command is used to start it. As a consequence one can start the simulation via the "Run Simulation" command in the toolbar and than check the status or abort the process via the "Solver Control Panel" at any time. This task panel can be used by every solver that uses the new execution framework.
- By default the framework uses temporary directories which are present on the filesystem as long as the document containing the solver is open and the solver iteslf is present (not deleted). This setting can be changed on a per FreeCAD session (open FreeCAD -> close FreeCAD) basis in the "Solver Control Panel" before clicking "Run Solver". Also there are multiple alternative default (rather than temporary) options avaliable in the Elmer tab of the Fem settings in the preferences dialog. The location of the setting doesn't have anything to do with elmer. It's just there to avoid conflicts with existing settings in the general tab. As soon as calculix uses the framework the setting will be moved.
- Solver remember the execution status (e.g. input files written, solver executed, ...) per directory (only one at a time). To make this useful there is now an implicit notion of a model of an analysis. The model contains everything that changes the outcome of the simulation. Excluded are for example result files. If the model of an analysis changes all solver of that analysis will reset their execution status. This can be observed by watching the button label of the "Solver Control Panel" (Write vs Re-Write and Run vs Re-Run).
- Solver processes are tracked by their solver object. This means that they are aborted when the containing document is closed or the solver deleted.
- The execution framework doesn't require qt to be installed. It uses the python threading module. Qt is only required in GUI mode. This mimics the rest of freecad (I think...).
- Some checks on the analysis (e.g. mesh present) are made before the input files are written. This is also implemented in a solver generic way. A new solver will get those checks almost for free.
Known shortcomings: The exported mesh may not be the same as the one displayed in FreeCAD. This is because it is remeshed when exported. There can be many race conditions that happen because I use the python threading module instead of the one provided by Qt. Please report every exeption you get even if you can't reproduce it. Constraints implemented in python (atm BodyHeatFlux and SelfWeight) aren't considered to be part of the model of an analysis.
In contrast to caculix elmer uses the vtk pipline directely and exclusively. Instead of a post file a pipeline
is created. The data is updated in place which means that filter added to a pipeline
are preserved on successive runs. Results of a frequency analysis must be extracted from the solver log (created just like the result pipeline
at the end of the execution)
Known shortcomings: The automatic update
of the visualization of the result doesn't work in every case. I'm going to file a bug report at some point (probably next week).
Overview of my Implementation
To give a feel for what changed I included a git --stat at the end of this post. The code I've written in the last two months can generally be split into three parts: a library called sifio.py which makes it easy to generate sif files from python, the solver generic execution framework and the elmer implementation for the framework.
The framework is implemented by the following files:
Elmer specific files:
- FemMisc.py: A collection of methods useful for the Fem workbench in general. (e.g. it contains methods to exract members of the analysis)
- FemReport.py: Contains a Report class that holds infos, warnings and errors. It is used to get info out of a separate thread and to the user.
- FemTask.py: A generic interface to different threading backends (atm only python threading). A task also provides a report object as well as status updates used by the "Solver Control Panel".
- FemSignal.py: A very lightweight implementation of signals used as a replacement for the Qt signal/slot mechanism.
- FemSolve.py: Provides a generic interface to different solver implementations in FreeCAD. Contains a class Machine which is a state machine used by the "Solver Control Panel" to manage the solving process of potentially different solver.
- FemSettings.py: Binary locations and other Fem settings can be retrieved easily via this module.
What must be done to implement a new solver?
- FemSolverElmer.py: The elmer document object. Has a method buildMachine which returs a generic state machine from FemSolve.py. The tasks of the machine are set to tasks fitting for elmer located in FemElmerTasks.py.
- ViewProviderFemSolverElmer.py: The elmer view provider. Also starts the "Solver Control Panel" in the doubleClicked method.
- FemElmerTasks.py: Contains the elmer specific task implementations for the different stages of the generic state machine.
- FemElmerWriter.py: Not mandatory for every solver. The process of writing input files could be completely implemented inside the appropriate task in FemElmerTasks.py.
First one must provide a document object for the new solver. Then implementations for all tasks comprising the state machine must be implemented:
- CHECK: This task checks the simulation before doing anything else.
- PREPARE: Write the input files into a directory managed by FemSolve.py.
- SOLVE: Execute the solver.
- RESULTS: Load the results into the document.
The solver object must provide a factory method buildMachine which returns a machine parameterized for the specific solver.
I hope that quick tour proves helpful to you. Please don't hold back criticizing my design
. I'm going to be on vacation for the next few days. I won't do any coding but reply in the forum daily.
Code: Select all
src/Mod/Fem/App/CMakeLists.txt | 18 +
src/Mod/Fem/CMakeLists.txt | 18 +
src/Mod/Fem/FemElmerTasks.py | 122 +++++
src/Mod/Fem/FemElmerWriter.py | 479 +++++++++++++++++
src/Mod/Fem/FemMisc.py | 60 +++
src/Mod/Fem/FemReport.py | 94 ++++
src/Mod/Fem/FemReportDialog.py | 71 +++
src/Mod/Fem/FemSettings.py | 87 +++
src/Mod/Fem/FemSignal.py | 31 ++
src/Mod/Fem/FemSolve.py | 374 +++++++++++++
src/Mod/Fem/FemTask.py | 146 +++++
src/Mod/Fem/Gui/AppFemGui.cpp | 2 +
src/Mod/Fem/Gui/CMakeLists.txt | 5 +
src/Mod/Fem/Gui/DlgSettingsFemElmer.ui | 529 +++++++++++++++++++
src/Mod/Fem/Gui/DlgSettingsFemElmerImp.cpp | 85 +++
src/Mod/Fem/Gui/DlgSettingsFemElmerImp.h | 50 ++
src/Mod/Fem/Gui/Resources/Fem.qrc | 2 +
src/Mod/Fem/Gui/Workbench.cpp | 6 +-
src/Mod/Fem/InitGui.py | 2 +
src/Mod/Fem/ObjectsFem.py | 21 +
.../PyGui/_CommandFemConstraintBodyHeatFlux.py | 60 +++
src/Mod/Fem/PyGui/_CommandFemSolverElmer.py | 65 +++
src/Mod/Fem/PyGui/_CommandFemSolverRun.py | 18 +
src/Mod/Fem/PyGui/_TaskPanelFemSolverControl.py | 389 ++++++++++++++
.../_ViewProviderFemConstraintBodyHeatFlux.py | 54 ++
.../Fem/PyGui/_ViewProviderFemSolverElmer.py | 59 +++
.../Fem/PyObjects/_FemConstraintBodyHeatFlux.py | 47 ++
src/Mod/Fem/PyObjects/_FemSolverElmer.py | 110 ++++
src/Mod/Fem/sifio.py | 332 ++++++++++++