Subject: [FEniCS-dev] DUNE

From: "tomtzigt" <[email-masked]>
Date: Sun, 17 Sep 2006 09:54:26 -0400

Are any of you familiar with the DUNE project? It looks like FEniCS could
benefit from this effort. I came across them because the key players of DUNE
are involved in the BOOST.MPI library review.

<http://www.dune-project.org <http://www.dune-project.org/> >

Most finite element or finite volume software is built around a fixed mesh
data structure.

Therefore, each software package can only be used efficiently for a
relatively narrow

class of applications. For example, implementations supporting unstructured
meshes

allow the approximation of complex geometries but are in general much slower
and

require more memory than implementations using structured meshes. In this
paper we

show how a generic mesh interface can be defined such that one algorithm, e.
g. a finite

element discretization scheme, can work efficiently on different mesh
implementations.

These ideas have also been extended to vectors and sparse matrices where
iterative

solvers can be written in a generic way using the interface. These
components are available

within the "Distributed Unified Numerics Environment" (DUNE).

It may be beneficial to invite them to Delft in November.

Theo

---

From: Anders Logg <[email-masked]>
Date: Mon, 18 Sep 2006 11:19:46 +0200

Yes, I've looked at it. It's one of a handful of projects that have
some similarities with the FEniCS project. But I don't see any
immediate use for it right now, except for possibly using ALUGrid for
adaptive mesh refinement.

/Anders

On Sun, Sep 17, 2006 at 09:54:26AM -0400, tomtzigt wrote:
> <http://www.dune-project.org>
> 
>  
> 
> Most finite element or finite volume software is built around a fixed mesh data
> structure.
> 
> Therefore, each software package can only be used efficiently for a relatively
> narrow
> 
> require more memory than implementations using structured meshes. In this paper
> we
> 
> show how a generic mesh interface can be defined such that one algorithm, e. g.
> a finite
> 
> solvers can be written in a generic way using the interface. These components
> are available
> 
> within the “Distributed Unified Numerics Environment” (DUNE).
> 
>  
> 

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

---

From: "tomtzigt" <[email-masked]>
Date: Mon, 18 Sep 2006 09:06:46 -0400

The way I look at it is as follows: To solve real problems you need the
following pieces:

Geometry
Geometry kernel
Mesher
Assembly
Solver
Data interactivity

The FEniCS effort has mainly focused on assembly. Unfortunately, the
abstractions used in the grid data structure are not as good as they could
be. The DUNE folks have focused on that, so why reinvent the wheel: why not
leverage their skills and work and bring them on board and work towards
similar goals and strengthen the overall effort?

I remember a long discussion last year that didn't go anywhere about the
relationship between FEniCS and Sundance. Clearly, this suggestion between a
DUNE/FEniCS relationship will touch on many of the same topics, most
importantly, that of relevance. IMHO, computational software will only be
relevant if the environment is so good that it allows the practitioners to
ignore the underlying algorithms. Neither FEniCS or DUNE have proven that
yet, but since the grid data structure is so central to all the algorithms
in the mesher and the data interactivity modules, DUNE has a good change of
survival.

I also want to at least bring up the different dynamics that play in
academics vs industry since it can explain the behavior of open source
projects. The focus in academics is to bite of a small piece of the problem
and solve it cleanly and innovatively. This requires isolation from the
overall messy problem. Industry focuses on the economic value of a problem
and isolated solutions have no value. As a consequence, the typical dynamic
of a development group in industry is to rape and pillage anything in sight
that could solve a piece and duct tape it all together. It typically is the
duct tape that provides the added value. And that is my world.
	Except for Johan's work on turbulent flow, I haven't seen a FEniCS
roadmap. So I am not aware of any grid abstractions that you might have in
mind for FEniCS. But from where I am sitting, DUNE looks like a better mouse
trap for working with grids, and since the mesher and data visualization are
both sizable pieces of software, DUNE has some really attractive features. 

Theo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Logg
Sent: Monday, September 18, 2006 5:20 AM
To: [email-masked]
Subject: Re: [FEniCS-dev] DUNE

/Anders

> Most finite element or finite volume software is built around a fixed mesh
data
> Therefore, each software package can only be used efficiently for a
relatively
> require more memory than implementations using structured meshes. In this
paper
> solvers can be written in a generic way using the interface. These
components

---

From: 'Anders Logg' <[email-masked]>
Date: Mon, 18 Sep 2006 15:27:28 +0200

We just added a new mesh library, see src/kernel/mesh/dolfin/NewMesh.h
in DOLFIN and are planning extensions of this mesh library that will
include adaptive mesh refinement and full support for ALE problems
(mesh smoothing etc).

I'd like to give the new mesh library a chance before thinking about
dropping it.

/Anders

---

From: "Johan Hoffman" <[email-masked]>
Date: Mon, 18 Sep 2006 16:44:48 +0200 (MEST)

I connection to this I'd like to add a loose roadmap for the KTH activity
the coming 6 months which will be related to mesh algorithms:

- reimplement local mesh refinement/derefinement algorithms for the new
mesh structure
- mesh moving algorithms connected to ALE fluid-structure interaction (FSI)
- FSI solving different equations (flow + structure) on different subdomains
- mesh smoothing
- surface integration including mesh information for boundary conditions

/Johan

>> > benefit from this effort. I came across them because the key players
>> of
>> DUNE
>> > show how a generic mesh interface can be defined such that one
>> algorithm,
>> e. g.
>> > a finite
>> >