Elmer Integration (GSoC) - Activity Log

[ickby]

Hello,

nice progress, and nice to see you use the VTK postprocessing On small remark: as you override the result on each new computation it is rather hard to make comparisons. Maybe we should implement a "copy pipeline" that also copies all filters? or do that automatically for each elmer recompute? What would you think is best?

Inconsistend update handling of VTK objects:[/b] My solver implementation always calles recompute on the tip of the vtk pipeline. In the video above it works because the wrap filter updates the 3d view when recompute is called. However it doesn't work if only a pipeline object is used. It this intentional?

No, this is not intentional. Actually the 3d view should update whenever there is new data set to the pipelines property. This is actually the same as for the filters, but there recompute is needed, as new data is only generated on recompute. So no update on changed data is a bug.

A Pipeline.write method in addition to the read method would be very nice. Would you (ickby) be willing to implement this?

Yes that would actually be very nice. I currently have little time to code, and have to manage two GSoC students on my own, so don't count that I can do that in the next time. It is reall ysimple, as vtk offers the export methods already, it should be only a few lines of code. So feel free to trie it if you need it in the next time.

FreeCAD segaults on an attempt to select geometryids as the Field in the vtk filter task panel. The vtu file containing the geometryids field is attached together with the traceback in the tar.gz below.

Ok, never tried that during developing. I would need to debug it to see there the error comes from.

[m42kus]

Nice videos and nice solver! How do you plan to incorporate the multi physics support of Elmer? Is this a target for your efforts at all? looo and I started a generic solver project for FreeCAD. This project is somehow on ice since looo is doing the Python 3 conversion and I am still implementing the mesh transfer for Fenics. But if we awake this generic solver project again, can you write down some tips and tricks for us and pitfalls you came over? In particular the communication between solver and FreeCAD would be interesting. Or are your GSoC logs available somewhere?

Hi Johannes,

Yes, multi-physics support is a important goal of this project. Nice to hear that you are interested into it as well! I'm going to make a detailed post about my code later today. The code itself is already avaliable: https://github.com/drhooves/FreeCAD phase2. It's far from perfekt and probably still has a lot of bugs but more about that later.
I'm very interested in your project. Is there code avaliable somewhere? Is your goal a library kind of thing or something directely integrated into FreeCAD? Maybe we can help each other out

Regards,
Markus

[m42kus]

nice progress, and nice to see you use the VTK postprocessing On small remark: as you override the result on each new computation it is rather hard to make comparisons. Maybe we should implement a "copy pipeline" that also copies all filters? or do that automatically for each elmer recompute? What would you think is best?

Thanks! And the standard copy (Ctrl-c) already asks the filters (dependen objects) should be copied too. I think that sould cover this feature?

No, this is not intentional. Actually the 3d view should update whenever there is new data set to the pipelines property. This is actually the same as for the filters, but there recompute is needed, as new data is only generated on recompute. So no update on changed data is a bug.

Alright, I'm going to do some more inventigation and create a bug on the tracker.

Yes that would actually be very nice. I currently have little time to code, and have to manage two GSoC students on my own, so don't count that I can do that in the next time. It is reall ysimple, as vtk offers the export methods already, it should be only a few lines of code. So feel free to trie it if you need it in the next time.

Ok, no problem. For now I'm going to focus on my gsoc project, but if I find the time I'll add it myself.

[m42kus]

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 phase2.

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.

Model Creation

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.

Postprocessing

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:

• 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.

Elmer specific files:

• 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.

What must be done to implement a new solver?

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 ++++++++++++

[joha2]

Hi markus!

Thanks for the nice explanation posts! I will put a link in the wiki of the generic solver project. Btw. our code base is by far not as usable as yours. In fact it only consists of a few notes and some dummy files. The main repo is hosted on looos fork:

https://github.com/looooo/FreeCAD/tree/genericSolver

If you have some suggestions I'm sure they are very welcome! Furthermore I am also interested in multi physics support for FreeCAD since the project itself is very nice and due to the highly customizable user interface it provides sufficient degrees of freedom for such an FEM framework. Anyways I am not an FEM expert and I have a serious lack of experience and because of this I will learn a lot from such a project which is also one of my main goals

Best wishes
Johannes

[yorik]

Excellent tour! Thanks!

[bernd]

@m42kus:

How is it possible to edit the input file for the solver?

[m42kus]

How is it possible to edit the input file for the solver?

This is atm not possible. I should probably remove the button till this feature is implemented.

[m42kus]

Hello, I spent the last few days doing a little generic work on the fem workbech, preparing the pull request for phase2 and implementing initial multiphysics support. The code can be obtained from my fork in the multiphysics branch. Later this week I'm going to post a update (incl. a video ) concerning the multiphysics support.

[m42kus]

Hey, the multiphysics update was delayed because my mentors and I decided that porting calculix to the new solver framework has a higher priority. Thats because we decided to delay the merge till all solver use the same framework (to avoid maintaining two frameworks at the same time). The port is now finished and can be tested together with my initial multiphysics support in the multiphysics branch of my repo (https://github.com/drhooves/FreeCAD.git). A video showcasing multiphysics will follow soon.