Effective development of a finite-element solver at the University

Effective development of a finite-
element solver at the University
Romain BOMAN,
Luc PAPELEUX,
Jean-Philippe PONTHOT
University of Liège
Departement of
Aerospace and Mechanical Engineering
ICSAAM
August 28-31, 2018 – Tarbes, France

2
J.-P. Ponthot
Our lab within the university
• Numerical simulation
• Solid mechanics
• Finite element method
• Software development
Computational Mechanics
hydroforming of a tube
Dept of Aerospace and
Mechanical Engineering
(Faculty of Applied Sciences)

Our main simulation code: Metafor
3
Implicit Finite-Element solver
for the numerical simulation of large deformations of solids
•ALE Formalism, remeshing.
•Thermomechanical time-integration schemes.
•Modelling of cracks,
fracture.
•Contact algorithms.
•Nonlinear constitutive laws.
•Mesh generation from medical
images.
•Fluid finite elements.
•Monolithic schemes.
•Coupling with extenal
solvers.
Metal Forming applications Crash / Impact
Biomechanics Fluid/structure
interaction

Typical simulation
4
Modelling of a roll forming mill
(forming of beams and tubes from steel sheets)

Current team
5
D. Boemer
(PhD student)
R. Boman
(Senior Researcher)
M.L. Cerquaglia
(PhD student)
L. Papeleux
(Senior Researcher)
3 PhD students – 2 senior researchers – 1 visiting academic
P. Flores
(visiting academic)
C. Laruelle
(PhD student)

Former developers
6
http://metafor.ltas.ulg.ac.be/dokuwiki/team
A. Stephany E. Biotteau C. Laurent J. Xhardez L. Vigneron L. Adam
L. Noels L. Ziane M. Mengoni O. Karaseva P. Bussetta P.-P. Jeunechamps
R. Koeune S. Hannay S. Trichon V.Q. Bui V. d’Otreppe W. Guo
25 contributors to the present code – from 2000
C. Canales Y. CarrettaY. Crutzen G. Deliége C. Hennuyer P. JorisG. Wautelet

7
Industrial partners
= owns a Metafor license

Scope
8
1. Practical Management of Simulation Codes
• Metafor… from 1992 to 2018
2. Numerical Applications
• Introduction to ALE formalism
• Thixoforming
• Continuous Roll forming
• Friction Stir Welding
• Additive manufacturing
3. Conclusions

Scope
9
• Thixoforming
3. Conclusions

My PhD project in 1997
10
Metafor
Ponthot’s PhD
doc
1992
Metafor
+powders
Metafor
+contact
Metafor
+optimisation
1997
Metafor
+shells
Metafor
+thermal,
+3D
tests
Metafor
+remeshing
1996
My PhD
project!
Good luck!
PhD supervisor

State of Metafor in 1997
11
Source Code?
• “Spaghetti” code (Fortran 77)
• Several versions of the code
Portability?
• Depends on a library only
available as binaries on
supercomputers.
• Post-processing with a non-free
product.
Regression testing?
• Non-automatic and
incomplete procedure.
Documentation?
• An outdated technical
report from 1992
printed on paper.
Input files?
• Home-made input files.
• Error-prone obscure syntax.
Extensibility?
• None.

…and then?
12
During 3 years I did almost no research at all!
In 2000, I seriously considered stopping my PhD research...
FORTUNATELY,
my supervisor gave me the opportunity to solve all these problems and
build a framework that would allow us to avoid the errors from the past.
One unique version
since 2001.
Almost no loss of
development since
then!
TODAY
How?

13
Source Code?
Portability?
supercomputers.
product.
Regression testing?
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.

14
Source Code?
• Manual management of revisions
Portability?
supercomputers.
product.
Regression testing?
Documentation?
report from 1992
printed on paper.
User friendliness?
Extensibility?
• None.
All these problems have very elegant solutions
in the “computer science” world
BUT
…we are neither “computer scientists” nor “IT specialists”!
I’m here to
“do science”,
not coding!
Even worse:
• Some of my colleagues do not want to learn
how it works.
• Moreover these things are not taught in class
(in ULiège).

15
Source Code?
• Manual management of revisions
Portability?
supercomputers.
product.
Regression testing?
Documentation?
report from 1992
printed on paper.
User friendliness?
Extensibility?
• None.
For each problem, we have tried to find a compromise
between both worlds
Welcome to the
academic world!
Welcome to the
computer science world!
let’s code!let’s publish!
characters from http://geek-and-poke.com/

State of Metafor
16
Source Code?
Portability?
supercomputers.
product.
Regression testing?
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.

State of Metafor
17
Source Code?
Portability?
supercomputers.
product.
Regression testing?
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.

Source code
18
Very long tradition of Fortran 77 for implementing the finite element method...
... and a lot of other
computation programs.
(cfr BLAS: http://www.netlib.org/blas/
MUMPS: http://mumps.enseeiht.fr/ , etc.)
Still today, all the
famous older
brothers of Metafor
are written in
Fortran 77!
... also in the industry:

Source code
19
Yes, it is obviously possible to write a
good finite-element solver in Fortran…
BUT
• the language does not help you
produce clean/maintainable code
• the maintenance effort increases
with time!
Example of a subroutine call in Metafor written in Fortran
(2000)
Main problems of Fortran 77

Source code
20
• Memory management?
No dynamic memory allocation:
 any modification is very instrusive
• Modularity?
No easy way to gather similar
variables/ subroutines together
 structures?
• Features?
Necessity to learn another
programming language: (graphics, GUI,
use of libraries, network, etc.)
partially solved with
later versions of Fortran
remaining problem
We finally decided to rewrite Metafor in C++ and
take advantage of Object Oriented Programming
Main problems of Fortran 77

Source code
21
The resulting source code (300k lines) can be split into 33 dynamic libraries
HPC lib
lib GUI
CAD lib
Researchers/projects are
isolated into THEIR OWN
library.
 Limited risk of conflict.
 Bad/duplicated code
remains confined.
 Avoid the use of high-level
objects in low-level code.
Metafor.exe
executable
mtGeo.dll
geometry
mtMath.dll
math tools
mtFEM.dll
FE method
mtMaterials.dll
Constitutive laws
mtViz.dll
visualisationmtKernel.dll
access to data
mtThixo.dll
law from a PhD
Private
(NDA)
mtSabca.dll
Private routines
from a company
Not compiled on
supercomputers

set of tools commonly used
in the IT world
“version control systems”
gmail
set of tools commonly
used in academia
winzip
?
Source Code
22
Our goals
• One single reference version for everybody (4-10 simultaneous researchers).
• Try to gather all the results / code / models from past projects.
• Keep track of the whole history of modifications in the source code.
How to have one single set of source files?

Source Code
23
Repository
checkout:
get any version
as « working copy »
commit:
send changes and
create a new
revision
update:
retrieve and merge
modifications of
others
Version control systems - How does it work?
holds the
complete
history of
modifications
Most basic workflow
Daily usage should be
very easy and
intuitive because my
colleages will not
read the manual…
 No “branches”

Source Code
24
Repository
checkout:
get any version
as « working copy »
commit:
send changes and
create a new
revision
update:
retrieve and merge
modifications of
others
Version control systems - How does it work?
holds the
complete
history of
modifications
Most basic workflow
Additional safeguard:
 A series of tests
(“test suite”) should
succeed before any
commit.
 The latest version
is always stable.

State of Metafor
25
Source Code?
Portability?
supercomputers.
product.
Regression testing?
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.

State of Metafor
26
Portability?
supercomputers.
product.
Regression testing?
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
• Source Code Management
with Subversion.

State of Metafor
27
Portability?
supercomputers.
product.
Regression testing?
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.

Regression testing
28
Aims
• Non regression of the algorithms
and the numerical models.
• Avoid conflicts between people.
set of tools commonly
used in academia
manual testing
(when something is already broken)
set of tools commonly used
in the IT world
“continuous integration”
Travis CICTest CDash
shell scripts
?

Regression testing
29
Principles of our “test suite”
• In-house python script.
• Easy procedure – “just run the script!”
• Runs a series of about 3100 FE models, in parallel if the machine allows it.
• Lasts less than 1 night on a classical desktop PC (~75000s CPU = ~5h30 on a 4-
core PC).
• 4 configurations (various OS/compilers):
• Each test extracts “well chosen” results that are compared to the results of the
previous version of the code (these results are committed with the source code.)
1. It is forbidden to commit without a full
success of the test suite.
2. Any untested development can be destroyed
(adding tests becomes mandatory).
2 simple rules

State of Metafor
30
Portability?
supercomputers.
product.
Regression testing?
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.

State of Metafor
31
Portability?
supercomputers.
product.
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
• In-house script.

State of Metafor
32
Portability?
supercomputers.
product.
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.

Documentation
33
documentation
of changes
What was modified? When?
By whom? Why?
documentation
of the source
code
user
documentation
Usage of the program
3 types of
documentation
svn log!
Doxygen!
LaTeX!
???

Documentation
34
Wiki system: Dokuwiki
https://www.dokuwiki.org/
Strong points
• Created 14 years ago.
• Very easy installation
(text-based DB).
• Numerous plugins.
• Regular / automatic updates.
• ... and no need to read a long
manual to edit a page.
http://metafor.ltas.ulg.ac.be/

Documentation
35
As any wiki:
• Online editing.
• Keep track of all changes.
• Importation of images,
videos, etc.
javascript rendering engine for equations:
Print
Online view
Online editor

Documentation
36
Documentation of source code changes (“commits”)
Each commit is fully documented
by its author on the wiki.

State of Metafor
37
Portability?
supercomputers.
product.
Documentation?
report from 1992
printed on paper.
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.

State of Metafor
38
Portability?
supercomputers.
product.
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
Documentation?
• A wiki system on the
web.

State of Metafor
39
Portability?
supercomputers.
product.
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
Documentation?
web.

Portability
40
Windows
Linux
Rule: The code should be easily built/tested on any (recent) platform
macOS
OS of supercomputers
Less user-friendly
Most popular OS
Libraries should be recompiled
Popular OS
Libraries should be recompiled
It is very important to let
developers work in their
preferred environment
(which is rarely Linux), then
build their code on
supercomputers for heavy
calculations.
Main problems
• the build system should be multi-platform (CMake).
• the dependencies should be limited and multi-platform.

Visualisation
41
Initially, 2 aims
• To see what we are doing, anytime.
• To make the software usage easier for
students and the industry.
Features
• 1 thread exclusively dedicated to
graphics running in parallel.
• The state of the memory is continuously
displayed in 3D.
• Nothing is written to disk.
Multi-platform libraries:
windows /
menus / buttons
3D display of the
problem
Example: Real-time visualisation during the simulations

State of Metafor
42
Portability?
supercomputers.
product.
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
Documentation?
web.

State of Metafor
43
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
Documentation?
web.
Portability?
• Runs on any recent desktop
computer and supercomputers.
• Own GUI / post-processor,

State of Metafor
44
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
Documentation?
web.
Portability?

Input files
45
geo = domain.getGeometry()
p1 = geo.add(Point(1, 0.0, 0.0))
p2 = geo.add(Point(2, 1.0, 0.0))
p3 = geo.add(Point(3, 1.0, 1.0))
p4 = geo.add(Point(4, 0.0, 1.0))
c1 = geo.add(Line(1, p1, p2))
• Parsing requires a lot of code.
• Error handling?
• New syntax to learn.
• Almost no source code at all!
• Error handling by python.
• Same syntax as internal C++.
Python scripts as input files
.poi
i 1 x 0.0 y 0.0
i 2 x 1.0 y 0.0
i 3 x 1.0 y 1.0
i 4 x 0.0 y 1.0
.cur
i 1 points 1 2
i 2 points 2 3
i 3 points 3 4
i 4 points 4 1
old home-made syntax python syntax

Input files
46
.poi
i 1 x 0.0 y 0.0
i 2 x 1.0 y 0.0
i 3 x 1.0 y 1.0
i 4 x 0.0 y 1.0
.cur
i 1 points 1 2
i 2 points 2 3
i 3 points 3 4
i 4 points 4 1
geo = domain.getGeometry()
def createCube(no, Lx, Ly, ox=0.0, oy=0.0):
p1 = geo.add(Point(1, ox, 0.0))
p2 = geo.add(Point(2, ox+Lx, 0.0))
p3 = geo.add(Point(3, ox+Lx, oy+Ly))
p4 = geo.add(Point(4, ox, oy+Ly))
for i in range(5):
createSquare(no=i, Lx=1.0, Ly=1.0, ox=i*2)
import myroutines
myroutines.createBeam()
What if I want to add:
• parameters?
• functions?
• branches, loops?
• …
old home-made syntax python syntax
“for” loop
call to a function
parameters
• all these features come at no cost!
Python scripts as input files
call to external
modules

Input files
47
No cost? Really?
Yes! a Python class is automatically created by
SWIG (free tool) for each C++ class.
from materials import *
mat = ElasticMat(E, nu)
model.setMaterial(mat)
model.run()
INPUT FILE
_materials.pyd
materials.py
class ElasticMat
{
double E, nu;
public:
ElasticMat(double, double);
T computeStress(T &strain);
…
};
ElasticMat.h
materials.i
%module materials
%{
#include "ElasticMat.h"
%}
%include "ElasticMat.h"

State of Metafor
48
Input files?
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
Documentation?
web.
Portability?

State of Metafor
49
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
Documentation?
web.
Portability?
Input files?
• Python.

State of Metafor
50
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
Documentation?
web.
Portability?
Input files?
• Python.

Extensibility
51
1. Extensibility with “Inheritance” in C++
class ElasticMat
{
double E, nu;
public:
virtual
};
ELASTIC MATERIAL
class ElPlastMat : public ElasticMat
{
double sig_yield, hardening;
public:
virtual
};
ELASTO PLASTIC MATERIAL
• In any object-oriented language, you can extend a class using “inheritance”.
• Example: extension of an elastic material to handle elasto-plasticity:
Purpose?
• The code using the material can be written without any conditional
statements and should never be modified.
 “ if the material is elastic, do this…. else, do that” is avoided.
• But, of course, the new code should be recompiled.

Extensibility
52
2. Inheritance of C++ classes in Python : “user subroutines”
Thanks to SWIG, the derived class can be written in Python!
class ElasticMat
{
double E, nu;
public:
virtual
};
ELASTIC MATERIAL (written in C++)
from materials import *
class ElPlastMat(ElasticMat):
def computeStress(self, strain):
# compute stresses
# from strains
# using python cmds here…
return stress
ELASTO-PLASTIC MATERIAL (derived in Python)
This python code will be called
from C++!
 Very useful for students (FYP)
A new constitutive law is
available without any
compiler!

Extensibility
53
3. Extensibility via “python as a glue language”:
coupling with another solver
David Thomas
Metafor
Solid solver (C++)
fluid –
structure
solver
metafor.py
SU2.py
SU2
Fluid solver (C)
fluid-structure interaction (FSI)
Prof. V. Terrapon’s lab
Prof. J.-P. Ponthot’s lab

Extensibility
54
• Less source code: no need to code a home-made parser,
• Safety: errors are never ignored and can be correctly
handled.
• Complete Language: possibility to use loops, conditional
statements, objects, functions, ... in the input file.
• Extensibility: inheritance of C++ classes.
• Glue language: call to external programs, solvers.
Summary – Advantages of the Python interface

State of Metafor
55
Extensibility?
• None.
Source Code?
• Modular (C++).
with Subversion.
Regression testing?
• Mandatory.
Documentation?
web.
Portability?
Input files?
• Python.

State of Metafor
56
Source Code?
• Modular (C++).
with Subversion.
Portability?
Regression testing?
• Mandatory.
Documentation?
web.
Input files?
• Python.
Extensibility?
• Python user-subroutines.
• Coupling with external
solvers.

Scope
57
• Thixoforming
3. Conclusions

Introduction to ALE formalism
58
Eulerian formalism
 Undistorted mesh
 Free boundaries are difficult to
track
 History-dependent materials
are difficult to handle
Lagrangian formalism
 The mesh can be rapidly
distorted
 Free boundaries are
automatically computed
 History-dependent materials are
easier to handle
Kinematic description of the motion

Introduction to ALE formalism
59
Kinematic description of the motion
Arbitrary Lagrangian Eulerian
(ALE) formalism
• Extension of both previous
formalisms
• The mesh motion is uncoupled from
material motion
• ALE can be crudely seen as a
continuous remeshing procedure
• Mesh topology does not change
• Remapping of variables is faster than
classical remeshing

2 Families of ALE Problems
60
• Helps us keep well-shaped elements
despite large deformations
• Most often remeshing is completely
avoided
Benefits of ALE vs. Lagrangian models
1. Problems involving excessive mesh distortion
Example: axisymmetric forging
Lagrangian model ALE model

2 Families of ALE Problems
61
2. “Quasi-Eulerian” models
• The size of the model is decreased in the flow direction.
• Loading is easier.
• The element size may be optimised in the flow direction.
• The contact regions do not change.
Benefits of ALE vs. Lagrangian models
Lagrangian model (1755 FEs)
ALE model (954 FEs)
Example: cold rolling fixed
free

Scope
62
• Thixoforming
3. Conclusions

Thixoforming
63
What is thixotropy?
• A thixotropic material behaves...
• … like a solid, at rest (a billet can sustain its own
weight).
• … like a liquid, during shearing (can be cut easily).
• Common examples: clays, muds, paints, tomato ketchup.
• Some alloys (Magnesium, Aluminium, Steels) exhibit a
semi-solid behaviour in a narrow range of T.
What is thixoforming?
• Taking advantage of this semi-solid state.
• The process combines advantages of casting and forging.

Thixoforming
64
Constitutive behaviour
cohesion degree
(microstructural state)
𝑓 = 𝜎 𝑉𝑀 − 𝜎 𝑦 − 𝜂 𝜀
𝑣𝑝
R. Koeune
modified yield stress
𝜎 𝑦 = 𝜎 𝑦( 𝜀
𝑣𝑝
, 𝜀 𝑣𝑝, 𝜆, 𝑓𝑙) 𝜂 = 𝜂 ( 𝜀
𝑣𝑝
, 𝜀 𝑣𝑝
, 𝜆, 𝑓𝑙)
apparent viscosity
𝜆 = 𝜆( 𝜀
𝑣𝑝
, 𝑓𝑙)
Both liquid and solid formalisms are
contained in the proposed models!
liquid fraction
(phase change)
𝑓𝑙 = 𝑓𝑙( 𝑇)
2NEWINTERNAL
VARIABLES
“Extended yield criterion” for thixotropy

Thixoforming
65
Double cup extrusion – process description
• Production of an axisymmetric H-shape part, starting from a cylinder.
• Temperature controlled by induction heating.
• Experiments made in PIMW, Liège in collaboration with ENSAM, Metz.
• Material: 100Cr6 steel alloy.
Example of (half) part

Thixoforming
66
Double cup extrusion – mesh management
cohesion degree l
ALE mesh management
(numerical trick):
 An initial thin squeezed mesh is
added to the top of the billet

Thixoforming
67
Double cup extrusion - results
Tdie = 170 °C
Tdie = 130 °C
Tdie = 180 °C
• Good agreement between
experimental and numerical results.
• The model is able to predict the
residual stresses after unloading and
cooling to room temperature.

Thixoforming
68
A PhD project built from the results of other projects
Modelling
of Thixoforming
Materials &
FE formulations
Visco-plasticity
Contact
algorithms
ALE
formalism
Thermal
problems

Scope
69
• Thixoforming
3. Conclusions

Continuous Roll forming
70
A metal strip is incrementally bent by sets of rolls (called “forming stands”)
until the desired cross section is obtained
Process description
 Key advantage: OK for Advanced High Strength Steels
Industrial roll forming mill
Post-cut-off press system
FE Modelling of roll forming is essential
(roll design, prediction of defects, residual stresses, springback, etc.)
… but very time-consuming!

71
Forming of a rocker panel (closed section)
Process parameters
• 16 stands - unsymmetrical shape
• Material: DP980 steel
• Inter-stand distance: 350 mm
• Strip: width:167mm - thickness:1.5 mm
• Length of the model: 6.26m
• Sheet velocity: 𝑣 = 200 mm/s
• Coulomb friction 𝜇 = 0.2
cutting machine
welding line
rocker panel

72
Drawbacks of Lagrangian modelling
• Non-realistic boundary conditions or friction coefficents to make the sheet move.
• The sheet hits the stands and gets sometimes blocked.
 Incremental modifications of the geometry of the tools by trial and error.
• How to model the welding and post-cut operation?
In a Lagrangian model,
the continuous strip is
modelled by a sheet of
limited length.
The setup of the Lagrangian model is very tricky and time-consuming!

73
Initial ALE mesh: interpolation of the flower diagram

74
Modelling of inline welding in ALE
• Actual physics in the welding process is heavily simplified.
• The initial mesh is built as a closed mesh.
Initial ALE mesh with
closed edges in the outlet.
Y. Crutzen

75
• Aims:
• release the final product from the
forming rolls
• Accurate computation of the
springback
• Perfect cut-off is assumed: deactivate
the finite elements located inside the
roll-forming machine.
• Switch from ALE to purely Lagrangian
formalism.
• Implicit dynamic integration scheme
with viscous damping to kill out the
oscillations.
Modelling of the post-cut operation in ALE
Y. Crutzen

76
View of ALE results from a downstream point of view
Welding line

77
• ALE and Lagrangian curves are very similar, except in the inlet region.
• Maxima values are close to each other.
Longitudinal strain along the 2 edges
Comparison to Lagrangian results

78
Shape defects predicted by the model:
• Bending radii in the lower part are much larger than the desired ones.
• Upper part is not perfectly planar.
Without welding
With welding
Final shape of the cross-section extracted at mid-length of the product
Influence of the welding operation and analysis of the final section
not planar
too large radii

79
Shape defects predicted by the model:
• A slight longitudinal bow defect appears after post-cut.
• No significant twist defect (torsion)
Middle of the web
Analysis of the final shape of the cut-to-length strip
bow
twist

80
A project built from the results of other projects
Tools import
from CAD files,
Experiments
Enhanced
Assumed Strain
finite elements
Dynamic time-
integration
ALE
formalism,
parallelism
Parallel contact
algorithms
ALE model of
continuous roll
forming

Scope
81
• Thixoforming
3. Conclusions

Friction Stir Welding
82
Process description
• Solid-state joining process  better than classical welding.
• Tprocess < Tmelting.
• Non-consumable tool.
• Mechanical intermixing + friction heating.
• Well suited for alloys with low fusion temp.
FSW of aluminium alloy 2024
• rotation: 500 RPM
• advance: 25 cm/min
• tool angle: 1.5°

83
FSW modelling with the ALE formalism
Mesh management – 3 zones
1. The mesh moves with the tool – ALE formulation (red)
2. Remeshing (transition zone - white)
3. Fixed mesh – Eulerian formulation (grey)
P Bussetta

84
FSW (ALE) – Example of mesh motion
Constitutive law:
Norton-Hoff

85
Comparison between a solid and a fluid approach
collaboration with UPC, Barcelona
Solid approach – Metafor (ULiège) Fluid approach – COMET (UPC)
unknowns: displacements,
temperature
unknowns: pressure,
velocity,
temperature

86
Comparison between a solid and a fluid approach
• Temperature evolution is similar with
both approaches.
Point 2
Point 1
temperatureatpoint1temperatureatpoint2

87
Residual stresses with the solid approach
Stresses & temp. during the process
•  = 25
• K = 1.5 MPa sm (viscosity parameter)
• m = 0,12 (strain rate sensitivity parameter)
• Q = 155 kJ/mol (activation energy)
• Young modulus = E(T)
• Poisson ratio = 0.33
Sonne et al (2013) JMPT 213
𝜎 𝑦 = 𝜎0 𝑇 + 𝐴 𝑇 1 − 𝑒 𝜉 𝜀 + 𝐾𝑒
𝑚𝑄
𝑅𝑇 𝜀 𝑚
Plates (AA2024): thermo-elasto-viscoplastic

88
Residual stresses with the solid approach
Stresses & temp. after the process and cooling
Plates (AA2024): thermo-elasto-viscoplastic
•  = 25
• K = 1.5 MPa sm (viscosity parameter)
• m = 0,12 (strain rate sensitivity parameter)
• Q = 155 kJ/mol (activation energy)
• Young modulus = E(T)
• Poisson ratio = 0.33
Sonne et al (2013) JMPT 213
𝜎 𝑦 = 𝜎0 𝑇 + 𝐴 𝑇 1 − 𝑒 𝜉 𝜀 + 𝐾𝑒
𝑚𝑄
𝑅𝑇 𝜀 𝑚

89
Remeshing
Norton-Hoff
constitutive
law
ALE
formalism,
meshers
Friction Stir
Welding model
Thermal
problems
Materials &
FE formulations

Scope
90
• Thixoforming
3. Conclusions

Additive Manufacturing
91
Context and challenges
• New PhD thesis started a few months ago: Very first model of
an laser solid forming with Metafor.
• The thesis focuses on mesh and geometry management.
• Material law?
• for now: thermal calculations only.
• future: reuse of the constitutive law developed in the
frame of thixoforming.
Thermal study of an AM process using
Laser Solid Forming of Ti-6Al-4V metal powder
C. Laruelle
• Can we extend the “element deletion”
algorithm (developed to compute cracks)
to an “element addition” algorithm?
Reference results from Chiumenti et al.
(UPC, Barcelona)

92
Mesh management technique
Computation of new active mesh and boundary conditions
Activated
Element
Element to
be activated
Boundary Condition
(e.g. Convection/Radiation)
Heat Flux Laser
Position
Time t Time t + Δt
• Finite elements and boundary conditions are all created and
deactivated at the start of the simulation.
• Activation/Deactivation of finite elements and boundary conditions
based on the current laser position.
1. 2. 3. 4. 5.

93
Numerical results – Time evolution of the temperature field

94
Thermal study of an AM process using
Laser Solid Forming of Ti-6Al-4V metal powder
Results – comparison with literature
160 TEMPERATURE 800
Metafor
COMET
METAFOR
Good agreement of the temperature evolution between
COMET, Metafor and experimental measurements.
EXP
COMET
thermocouples on the lower surface
Final temperature distribution [°C]

95
Remeshing
Semi-solid
constitutive
law
X-FEM
Modelling of
Additive
Manufacturing
Thermo
mechanical
models
Crack
propagation

Scope
96
• Thixoforming
3. Conclusions

Conclusions
97
• The development of complex models/algorithms is always
the sum of the work of many researchers.
• Keeping their source code clean, effective, reliable, robust
and easily extensible is a difficult task which is usually
underestimated in the academic world.
• A lot of simulation codes are continuously lost and projects
based on previous work do not reach their goals.
• The presented tools and the resulting methodology have
the advantage to be rather simple and allow the researchers
to spend more time on “science” and less time on
“coding”.

Effective development of a finite-element solver at the University

More Related Content

What's hot (20)

Similar to Effective development of a finite-element solver at the University (20)

Recently uploaded (20)

Effective development of a finite-element solver at the University