fenics team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

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


> 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
> _______________________________________________
> FEniCS-dev mailing list
> FEniCS-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/fenics-dev
>