dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jan 05, 2009 at 02:48:33PM -0500, Shawn Walker wrote:
> 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.

Yes, something like this:

  <functionspace ...>
    <mesh ...>

    </mesh>
    <finiteelement ... />
    <dofmap .../>
    <coordinates>
      <function>
        <functionspace>
           ...
        </functionspace>
      </function>
    </coordinates>
  </functionspace>

> 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? 

No, not currently. It is currently assumed that the same element is
used for the whole mesh.

This is something that it is also desirable to extend. There is
currently an element() function in FunctionSpace. We could add
something like

  const FiniteElement& FunctionSpace::element(const Cell& cell) const;

which would be a mapping from a Cell to the FiniteElement used for
that cell.

> It seems that the mesh 
> function coordinates may require its own FunctionSpace.

Yes.

-- 
Anders


> 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;
>>
>>

Attachment: signature.asc
Description: Digital signature