Fenics as Solver

[looo]

integrate in FEM solver work flow. Add another solver

Personally I would like to go in this direction. But I don't know if it is the best way. For specifying boundary conditions I would like to go a more generic way, because we can not implement input tasks for every problem.
I have made some notes on a generic-fem-property tool in the proposel. Please have look: https://github.com/looooo/FreeCAD/blob/ ... roposal.md

However, that is why i talked about Generation fenics sscripts. Those self Container Python scrits can then be run by an external python prozess the same way like calculix now.

I do not fully understand your script approach. Maybe you can explain the work flow a bit more. Where are these generator-scripts coming from?

[ickby]

I do not fully understand your script approach. Maybe you can explain the work flow a bit more. Where are these generator-scripts coming from?

Currently the Solver objects generate a input file for the solver executables. Those input files contain the mesh, the boundary conditions etc., basicall the whole problem description that is needed for solving the problem. For fenics this would be a dolfin .xml mesh file and a python script. So you could simply build a new solver just like the calculix or z88 solver that generates those two files instead of the .inp files of for calculix. Than instead of running calculix in an external process you run python in an external process with the solver script supplied.

This has the advantage that one can change the scipt before executing, just like currently with inp files.

[looo]

If I understand this correctly, this adds the option to run everything outside of freecad. And there is the opportunity to run the simulation a second time with changed parameters but without recomputing the mesh.

I didn't think about this yet, but this should be possible with my proposed work-flow. Simple add some functionality to write the case to a file, plus generate a python script which runs the simulation... There are many options. I will try to add this to the proposal.
But I would make this an option and not the main work-flow. Most likely every solver needs it's own data-structure, so this can not be done in a generic way. So I would say the most generic way to get the data from mesher to solver is simple with python lists, dicts ... . The solver then implements the functions to write, load, process, the data.

Another question:
I would like to make the "generic-solver" a pure python class because freecad classes are not allowed to be inherited with the normal python inheritance. But to get a nice interface there is a need for proper solver inheritance. Does this make sense? So instead of adding multiple solvers to the current existing ones (calculix, z88, elmer) I would like to add only one additional generic solver, which links to a pure python solver-class. This maybe adds another layer of confusion but I think it will have some benefits... Else there would be hundreds of solver files.... (fenic_heat, fenics_heat_steady_state, fenics_poisson, ....)

[HoWil]

So you could simply build a new solver just like the calculix or z88 solver that generates those two files instead of the .inp files of for calculix. Than instead of running calculix in an external process you run python in an external process with the solver script supplied.

This has the advantage that one can change the scipt before executing, just like currently with inp files.

+1 Sounds great: simply exchanging the solver for 'the same problem definition' and double-check the results

[looo]

simply exchanging the solver for 'the same problem definition' and double-check the results

Ok, this is another use case. But I do not think our main goal is another solver for the same things we already can do with the FEM-WB. Fenics gives us the oppertunity to solve any pde, so we should take care to not restrict these possibilities.

[bernd]

So you could simply build a new solver just like the calculix or z88 solver that generates those two files instead of the .inp files of for calculix. Than instead of running calculix in an external process you run python in an external process with the solver script supplied.

This has the advantage that one can change the scipt before executing, just like currently with inp files.

+1 Sounds great: simply exchanging the solver for 'the same problem definition' and double-check the results

For z88 and calculix you do not even exchange the solver. They both can be in one analysis. Just select the solver and press the run button. The result object get a prefix calculix or z88. It is how it is implemented at the moment.

BTW: for linear calculatation and linear material with hexa and tetra elements and force and fixed constraint only, you get exact really exact the same results for Z88 and Calculix.

[JeffWitz]

We also really think to pass from our current Abaqus simulation to fenics, as it clearly simplify the process of adding new approaches. The main issues for fenics uses for us are the difficulty to make the preprocessing, indeed, being able to set boundary conditions graphically is mandatory. I think that the code generation approach is the best way to proceed as it allows one to custom pde and resolution process outside FreeCAD. There are a lot of things that can be tuned in a FEM computation from the solver you use to the model you choose. Software like AbaquesCAE allows to tune a lot of things inside the GUI, but it also lead to an extreme complexity for a simple analysis. I think that thinking together to a simple way to generate a code that can be easily tuned for more complex analysis is a real good idea.

I'm very enthusiastic to participate to such work !

[looo]

The main issues for fenics uses for us are the difficulty to make the preprocessing, indeed, being able to set boundary conditions graphically is mandatory.

That is one problem we are trying to solve. The idea is a mixed form of input (graphical for selection geo-entities, text input (dicts) for setting properties(material, bc, ...). I hope it's possible to make this work with the current methods to set boundary conditions and materials.

Currently I am working on a genericSolver which simple set some node values. To test things I wanted to set the temperature of a Fem::FemResultObject. But somehow the result isn't displayed. Is this property (temperature) based on nodes or cells?

[JeffWitz]

To test things I wanted to set the temperature of a Fem::FemResultObject.

I think that it is not the good way to proceed as FreeCAD seems to go to multi-physics simulations.
There are several kind of boundary conditions :

Dirichlet : set the quantities we want to compute at given nodes (First type),
Neumann : Set the derivative of the quantity at the nodes (Second type),
Cauchy : set both of them (Third type),
Robin : set both of them with a linear law (Third type).

I think that it is important to implement well the first and second type. If you want to make an abstraction that work for all the solver and for all the physics, I think that you will have to use this formalism and just label well this boundary conditions in the GUI.

[bernd]

start FreeCAD --> startwb --> load FEM 3D example --> run the calculation --> navigate in your filemanager to the frd file created by CalculiX --> close the document in FreeCAD --> open the frd in FreeCAD --> a result object and a mesh is created because a result object does depend on a mesh.

run the following code to change an node displacement vector ...

Code: Select all

import FreeCAD
res = App.ActiveDocument.getObject("results")
res.DisplacementVectors
tmp = res.DisplacementVectors
tmp[0] = FreeCAD.Vector(-16, 0, -190)
tmp[0]
res.DisplacementVectors = tmp
res.DisplacementVectors
App.ActiveDocument.recompute()

changed-results.FCStd

(23.37 KiB) Downloaded 91 times

screen.jpg (240.7 KiB) Viewed 3600 times