dolfin team mailing list archive

[Dag Lindbo <dag@xxxxxxxx>]

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. 

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

> /Johan
> 
> 
> >
> > /Anders
> >
> >
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> >
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev