- Info
Meeting Minutes 29.10.2004
Minutes of LifeV meeting on 29th Nov 2004 at EPFL
—
Plain Text,
5Kb
File contents
Meeting
=======
date: Fr 29.10.2004
time: 10:00
place: MA, EPFL
participants:
from MOX:
Vincent Martin (VM)
Alexandra Moura (AM)
Martin Prosi (MP)
from EPFL:
Erik Burman (EB)
Christophe Prud'homme (CP)
Gilles Fourestey (GF)
Christoph Winkelmann (CW)
I) Coupling
===========
Who does what, where are connections?
* multiphysics: MP, GF, CW
* multiscale: VM, AM, CV, MP
* multielement/multidiscretization: MP, VM
CV = Christian Vergara
current and planned work, as well as connections, per person, in more detail:
Martin Prosi (MP)
-----------------
current: mass transport with given (analytic) velocity field
* in 1 domain, with Galerkin elements
* in 2 domains
planned: couple to fluid solver (Navier-Stokes)
connections: needs IP stabilized NS solver, DG, Nitsche, Raviart-Thomas
Gilles Fourestey (GF)
---------------------
current: fluid structure interaction with Steklov-Poincaré algorithm
now there are 3 algorithms:
* Steklov-Poincaré
* rootfinding with Newton
* fixed point iteration
Steklov-Poincaré solved with nonlinear Richardson iteration
* stepsize from Aitken
* preconditioned with
- solid (working)
- fluid (in progress)
- linear combination of solid and fluid (in progress)
planned: * domain decomposition
* nonlinear structure model (not necessarily LifeV)
* instationary structure model (currently quasistationary)
* definition of clear interfaces (drivers and solvers) in
order to be able to couple to something else than LifeV:
o--------o
| Driver |
o--------o
exchange / LifeV \ exchange
- displacement / \ - displacement
- solid stress tensor / \ - fluid stress tensor
/ \
o------------------o o--------------o
| Structure Solver | | Fluid Solver |
o------------------o o--------------o
LifeV or other LifeV
connections: * domain decomposition works by VM in LifeV
* structure works by Marcela (Module F, PVM)
* nonlinear structure works by Miguel Fernandez in LifeV
Christoph Winkelmann (CW)
-------------------------
current: time dependent version of IP stabilized NS solver
planned: * two-phase flow with free surface
* treatment of free surface by level-set method
* IP stabilization for NS and level-set advection
connections: * MP needs IP stabilized NS solver
* MP needs NS solver for inhomogeneous fluids
- separate solver for nonconstant density,
treatment of its advection problem dependent
(discont. -> level set, cont. -> std. density advection)
- keep it separate from solver with constant density (efficiency)
Vincent Martin (VM)
-------------------
current: one dimensional blood flow models with 2 tubes
planned: couple to three dimensional fluid structure interaction model
connections: FSI
Christophe Prud'homme (CP)
--------------------------
planned: * require simple, clear and clean interfaces
* externalize temporal loop (for coupling)
-> "A solver does one timestep"
Alexandra Moura (AM)
--------------------
current: coupling 3D NS with OD model, 2 strategies
planned: * coupling to 1D model
* coupling to fluid structure interaction
* put coupling interfaces (drivers and solvers) into LifeV lib
connections: * 1D model by CV
* FSI by GF
Christian Vergara (CV) reported by Christophe Prud'homme (CP)
----------------------
current: NS solver with flux BC, one flux,
implemented using current NS solver
planned: 2 fluxes. Big issue there: flow division ratio
connections: flux BC is important for coupling to lower dimensional models,
because they only provide mean values as boundary conditions
Christophe Prud'homme (CP) (continued)
--------------------------
planned: * coupling infrastructure: example:
3D Navier-Stokes solver
---->------>------>----
/ \
/ u(x) \ p(x)
/ \
o--------o ^ o--------o |
| OD->3D | | distribute | 3D->0D | | average
o--------o | o--------o v
\ /
\ mean flux / mean pressure
\ /
----<------<------<----
0D solver
* externalize data: e.g.
- 0D network (coefficents and structure, data are available,
CV has them from Vuk Milisic)
- 3D meshes
II) LifeV
=========
Goals:
* "We want to have simple code."
* Solvers should do only processing, no postprocessing
possible solutions:
-> provide access to data
-> observer pattern
* Linear solvers should be called only through the encapsulated solver classes