fenics team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

The geometry engine is a missing piece in FEniCS, which we have not got to
yet. But of course this should be done. Today we only work with a given
mesh, which may have been generated from a complicated CAD geometry in the
first place (we have more comlex geometries that cylinders, for example a
full model of a car), but today the original geometry description is not
used in mesh refinement/movement; if the mesh is refined/moved, no update
is made with respect to the original geometry. But as I said, this is what
we want. In an old code I added these things manually, but for DOLFIN we
want to take a general approach.

We have a project running now on fluid-structure interaction (FSI) with
ALE where the mesh is moving. I have attached a few movies from
preliminary tests on model problems of ALE for the flow part, we are
currently working on the full FSI problem.

The standard approach to FSI is (as you say) to iterate between a fluid
and structure solver in one way or another; for refs. see e.g. the group
of Alfio Quarteroni in Lausanne/Milan. In our project we are trying a
somewhat different approach, which I will keep you updated on (e.g.
through the fenics-list), and the algorithms will be implemented in
DOLFIN, in an experimental version rather soon I hope.

We also have a project in collision of cars for animation/simulators,
where the goal is real time and interactivity. For a flow problem I'd say
that the computational cost is today still too significant for
interatcivity of a reasonably fine model, but that we should be able to
address in the future I think, in particular with a superfast Stillwater
machine...

/Johan

> CAD geometry is specified in terms of primitive shapes and Boolean
operators. A "geometry engine" is the black box that defines some set of
primitives and operators to construct arbitrary shapes and the ability
to
> determine if a point is inside/outside or on the surface. Typically the
geometry engine also provides the ability to extract a surface mesh for
display.
>
> I am becoming comfortable with the task of generating a mesh generator
(or
> better said: rip one off from CGAL or CAMAL), and I understand the GUI
issues. I don't comprehend the amount of work of the other two you
mentioned: the variational formulation and the solver. The solution I
was
> thinking along is that of a two domain solver where one iteratively
solves
> the fluid flow, extracts the boundary conditions, and applies them to
the
> structure. I haven't found any material that describes a coupled system
yet.
> Are you aware of such a reference?
>
> Theo
>
> -----Original Message-----
> From: fenics-dev-bounces@xxxxxxxxxx
[mailto:fenics-dev-bounces@xxxxxxxxxx]
> On Behalf Of 'Anders Logg'
> Sent: Wednesday, December 06, 2006 4:12 PM
> To: fenics-dev@xxxxxxxxxx
> Subject: Re: [FEniCS-dev] AMR
>
> On Wed, Dec 06, 2006 at 04:08:15PM -0500, Theodore Omtzigt wrote:
>> Yes, but putting the pieces together to make that happen would be
non-trivial.
>> /Anders
>> Is it non-trivial due to the lack of a geometry engine, or the lack of
moving grid functionality, or something else?
>> Theo
>
> I don't really know what you mean by "geometry engine", but you will
have to write a substantial amount of code to put everything together:
mesh, variational formulation of the fluid-structure interaction
problem, solvers etc, not to mention the graphical user interface for
interacting with the mesh.
>
> /Anders
> _______________________________________________
> FEniCS-dev mailing list
> FEniCS-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/fenics-dev
>
> _______________________________________________
> FEniCS-dev mailing list
> FEniCS-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/fenics-dev
>

Attachment: ale.mpg
Description: application/unknown

Attachment: mesh_pinch_move_velocity.mpg
Description: application/unknown

Attachment: mesh_pinch_velocity.mpg
Description: application/unknown