← Back to team overview

dolfin team mailing list archive

Re: New release

 

ok, let me just go over this in detail just to be sure.

1. The FunctionSpace and coordinate data should be stored in the same file.

2. FunctionSpace will include an additional 'function' variable: coordinates. This function will be defined in terms of a particular finite element, say a 3rd order lagrange element. Can a FunctionSpace have different finite elements defined within it? It seems that the mesh function coordinates may require its own FunctionSpace.

This last part is kind of critical.  Am I making sense there?

- Shawn

On Mon, 5 Jan 2009, Anders Logg wrote:

On Mon, Jan 05, 2009 at 01:14:31PM -0500, Shawn Walker wrote:

On Mon, 5 Jan 2009, Anders Logg wrote:

On Fri, Dec 12, 2008 at 08:53:22AM -0500, Shawn Walker wrote:
I have not been saying much during all of this, but I have been listening
a bit.  :)

I would like to know if the new function space stuff is ready to be used
in implementing higher order meshes.  I started looking into this a long
time ago, but then there was this big re-work.  The stuff I did before
was kind of a hack, so hopefully this new function space interface will
allow for easily reading in higher order mesh info.

At this point, I just want to read in a higher order mesh and have that
info be available to the matrix assembly.  And nothing else.  I'm also
not proposing that this go into your release.

Any comments?  I will have to relearn this new interface.

Sorry about the long delay.

Now problem.

The new class FunctionSpace makes it possible to put the information
about the higher order mapping either into the mesh or into the
function space. So there seem to be three options:

1. Add the extra information for higher order meshes into
MeshGeometry. I think this is what was planned before.

2. Add the extra information as auxiliary mesh data in the MeshData of
a Mesh.

3. Add the extra information as an additional member in FunctionSpace,
in addition to a Mesh, FiniteElement and DofMap.

I don't have a clear view on how to do this and haven't thought much
about it for a long time so let's hear some opinions.


It seems that #3 is the most logical.  A higher order mesh will affect
the domain shape and also the way the edge facets are shaped.  As long as
all of this information is available to the assembler, then that should
be fine.

However, in using iso-parametric elements, one needs a 'reference' mesh
to define them.  So would one use a reference functionspace here?  I
think we agreed way back that the higher order mesh data should be stored
as a finite element function.  But then you need a functionspace, right?

But before a function space is even declared, we need to create a mesh
with the higher order data stored somewhere.  Probably, we will still
need either #1 or #2.

Any other comments are more than welcome!

I forgot about storing the coordinates as a Function. Yes, that seems
to be the best choice.

The question is then where to store this Function, either in the Mesh
or in FunctionSpace. I would suggest storing it in FunctionSpace to
avoid dependencies from the mesh library to the function library.

We can already read in Functions from file, so it should not
require much work to read in an additional variable (the function) and
store it in say a variable named coordinates in FunctionSpace.

We then need to add capabilities for reading and writing
FunctionSpaces. This can then also be used when reading and writing
Functions. We currently cheat a bit there as you may notice in a
comment in dolfin/io/XMLFunction.cpp.

If we get this in place, we should be able to do things like

 FunctionSpace V;
 File file("higher_order_function_space.xml.gz");
 file >> V;

--
Anders



Follow ups

References