dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Sep 10, 2006 at 04:54:57PM +0200, Dag Lindbo wrote:
> On Sun, 2006-09-10 at 14:44, Johan Hoffman wrote:
> > >>> Apart from fixing various configure/compilation issues for 0.6.3, the
> > >>> time has come to replace the mesh library. There are two main
> > >>> options:
> > >>>
> > >>> 1. The first option is to just port everything right away to the new
> > >>> mesh library. This should be fairly straightforward, since the API is
> > >>> mostly the same and I have completed most of the functionality we use
> > >>> (but we'll probably discover something missing along the way). One big
> > >>> difference from before is that we can remove the templating in FEM and
> > >>> just iterate over facets.
> > >>>
> > >>> 2. One big thing is missing and that is adaptive mesh refinement. I
> > >>> have not ported the algorithms in MeshRefinement to the new mesh (but
> > >>> uniform refinement is implemented). The second option is to wait until
> > >>> we have adaptive mesh refinement in place.
> > >>>
> > >>> The choice would depend on how many are actually using adaptive mesh
> > >>> refinement and how much work we want to spend on porting the mesh
> > >>> refinement algorithms. The current implementation makes special use of
> > >>> the old mesh data structures (including the class PArray which is up
> > >>> for removal when the new mesh library has replaced the old).
> > >>>
> > >>> Any thoughts? Who is using adaptive mesh refinement?
> > >>
> > >> We are using local mesh refinement, and I believe this is a desireable
> > >> feature for many users. Maybe I'm wrong?
> > >
> > > I agree it is desirable and of course we need it, but the question is who
> > > is ready to port the existing (or an alternative) adaptive mesh refinement
> > > algorithms to the new mesh library?
> > >
> > >> I do not think we should brake the local mesh refinement algorithms. At
> > >> least there should then be the option of using the old mesh library
> > >> until
> > >> the local mesh refinement is in place in the new mesh format.
> > >
> > > There is always the option of using an old version.
> > >
> > >> If no one else is interested in this feature I will implement these
> > >> algorithms. It would fit well with our activity in other mesh
> > >> modification
> > >> algorithms.
> > >
> > > Sounds very good.
> > >
> > >> But I still think the option of using the old mesh should be there,
> > >> instead of breaking the local mesh refinement capability.
> > >
> > > With a reasonable level of commitment, we should be able to port the
> > > adaptive refinement pretty quickly. Do we want to implement the same
> > > algorithm as before or are there other options? It could for example be
> > > desirable to implement something that does not need to operate on the
> > > entire hierarchy.
> > 
> > We'll take a look at this the coming week. Feel free to come with
> > suggestions regarding good available algorithms, or desireably features in
> > a new algorithm.
> > 
> 
> I suggest thinking about how to transfer a discrete function from the
> 'old' to the refined mesh. There are two cases
> 
> *) All new degrees of freedom lie on the edges of the old mesh, i.e the
> refined mesh is created by splitting/merging on the old mesh. Setting
> the proper values at the new DOFs should not be impossible to do in a
> general manner if the refinement alg marks which edges has been split,
> for example. 
> 
> *) Projection between two potentially unrelated meshes. This would be
> the case if the mesh is deformed and it's then deemed necessary to
> completely remesh the domain. 

This is very important. I would add further that this needs to be
handled in such a generality that it is possible to project between
general function spaces, say from linears on one mesh to quadratics on
another mesh.

The key point is to be able to integrate the product vw of two
functions v and w which are defined on two different meshes.

> These are functions which I would need myself, and for this reason I
> would like to participate in the development process in some way.
> However, I probably lack in FEM-skills and of course in DOLFIN
> experince. 
> 
> /Dag

You are more than welcome to participate, any contributions are
welcome. You can either send patches, or publish your hg repository
somewhere so someone with write-access can pull from your repository.

We need to coordinate the development in some way since there are a
number of things we need to do:

 1. Adaptive mesh refinement
 2. Make the mesh work in parallel
 3. Projections

But probably one of the first things we need to do is to get some
experience with the new mesh library. I'm pretty happy with how it
turned out, but it has not been well-tested and a few basic things
might be missing.

An obvious first task is to make the new mesh class work with the FEM
class. This will probably reveal some weak points.

/Anders