Subject: [FEniCS-dev] AMR

From: "Theodore Omtzigt" <[email-masked]>
Date: Wed, 6 Dec 2006 10:50:20 -0500

I have been studying the different algorithms for volume meshing and as far
as I can tell, there are two essential interactions with geometry for
meshing algorithms:

1-       Is a point inside or outside the volume delineated by some surface?

2-       Project a point onto the surface if you want to refine a mesh
element, or move a vertex

Secondly, I am trying to understand the issues surrounding moving grids as
they arise in ALE methods. So, here is the question: To do proper AMR on
moving grids wouldn't we need an abstract geometry interface to follow the
geometry properly, and wouldn't it be therefore necessary to start including
a geometry engine of some degree that is more sophisticated than a simple
cylinder object?

Maybe, it would also be good to introduce the background of what made me
struggle with this: I want to build an demo where we have a flow field and
an object in that flow field that can be interactively manipulated, all the
while the solver is going and forces on the object and the fluid are
properly calculated and visualized. Does the current state of FEniCS have
enough of the pieces to build that demo?

Theo

---

From: Anders Logg <[email-masked]>
Date: Wed, 6 Dec 2006 21:47:23 +0100

On Wed, Dec 06, 2006 at 10:50:20AM -0500, Theodore Omtzigt wrote:
> I have been studying the different algorithms for volume meshing and as far as
> I can tell, there are two essential interactions with geometry for meshing
> algorithms:
> 
>  
> 
> 2-       Project a point onto the surface if you want to refine a mesh element,
> or move a vertex
> 
>  
> 
> Secondly, I am trying to understand the issues surrounding moving grids as they
> arise in ALE methods. So, here is the question: To do proper AMR on moving
> grids wouldn’t we need an abstract geometry interface to follow the geometry
> properly, and wouldn’t it be therefore necessary to start including a geometry
> engine of some degree that is more sophisticated than a simple cylinder object?
> 
>  
> 
> struggle with this: I want to build an demo where we have a flow field and an
> object in that flow field that can be interactively manipulated, all the while
> the solver is going and forces on the object and the fluid are properly
> calculated and visualized. Does the current state of FEniCS have enough of the
> pieces to build that demo?

Yes, but putting the pieces together to make that happen would be
non-trivial.

/Anders

---

From: "Theodore Omtzigt" <[email-masked]>
Date: Wed, 6 Dec 2006 16:08:15 -0500

/Anders

Is it non-trivial due to the lack of a geometry engine, or the lack of
moving grid functionality, or something else?

Theo

---

From: 'Anders Logg' <[email-masked]>
Date: Wed, 6 Dec 2006 22:11:42 +0100

> moving grid functionality, or something else?

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

---

From: "Theodore Omtzigt" <[email-masked]>
Date: Wed, 6 Dec 2006 16:31:58 -0500

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: [email-masked] [mailto:[email-masked]]
On Behalf Of 'Anders Logg'
Sent: Wednesday, December 06, 2006 4:12 PM
To: [email-masked]
Subject: Re: [FEniCS-dev] AMR

/Anders
_______________________________________________
FEniCS-dev mailing list
[email-masked]
http://www.fenics.org/mailman/listinfo/fenics-dev

---

From: [email-masked] (Ridgway Scott)
Date: Wed, 6 Dec 2006 16:51:22 -0600 (CST)

>I haven't found any material that describes a coupled system yet.

There is a lot of literature on the fluid-solid interface problem.
In particular, check out the papers by Alfredo Bermudez and Rodolfo Rodriguez
on Google Scholar.

				Ridg

---

From: "Johan Hoffman" <[email-masked]>
Date: Thu, 7 Dec 2006 09:47:46 +0100 (MET)

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

operators. A "geometry engine" is the black box that defines some set of
primitives and operators to construct arbitrary shapes and the ability
to
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
non-trivial.

---

From: Angelo Simone <[email-masked]>
Date: Thu, 07 Dec 2006 17:57:59 +0100

Johan, it seems that something went wrong with the files you posted 
(their size is zero). Could you post them again? Thanks,
angelo

Johan Hoffman wrote:
>> I am becoming comfortable with the task of generating a mesh generator
>>     
> (or
>   
>> 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.
>   
>> From: [email-masked]
>>     
> [mailto:[email-masked]]
>

---

From: "Johan Hoffman" <[email-masked]>
Date: Mon, 11 Dec 2006 09:13:30 +0100 (MET)

Angelo,

You can download the movies at:
www.csc.kth.se/~jhoffman/pub/

/Johan