fenics team mailing list archive

['Anders Logg' <logg@xxxxxxxxx>]

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


On Mon, Sep 18, 2006 at 09:06:46AM -0400, tomtzigt wrote:
> 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: fenics-dev-bounces@xxxxxxxxxx [mailto:fenics-dev-bounces@xxxxxxxxxx]
> On Behalf Of Anders Logg
> Sent: Monday, September 18, 2006 5:20 AM
> To: fenics-dev@xxxxxxxxxx
> Subject: Re: [FEniCS-dev] DUNE
> 
> 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:
> > 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>
> > 
> >  
> > 
> > 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
> > 
> 
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> FEniCS-dev mailing list
> FEniCS-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/fenics-dev