dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Aug 27, 2008 at 10:55:20AM -0400, Shawn Walker wrote:
> After looking at the various XML* files, I noticed that the part that  
> reads finite element functions is implemented with "cheating".  at least  
> there is a comment in XMLFile.cpp that says:
>
> void XMLFile::operator>>(Function& f)
> {
>   // We are cheating here. Instead of actually parsing the XML for
>   // Function data nested inside <function></function>, we just ignore
>   // the nesting and look for the first occurence of the data which
>   // might be outide of <function></function>
>
> If I am to read in function data under the <coordinates> tag, I guess I  
> will need to call this function when parsing the mesh.xml?  Or should 
> this be re-written since it is a "cheat"?

The reason we do this is that we want to reuse the existing code for
reading the objects that make up a Function: Mesh, Vector, finite
element, dof map. The best would be to rework the XML parsing so this
is possible without cheating.

What happens now is that we read the entire file for each of the
objects that we expect, where we should really look for a <vector> tag
nested inside <function> etc.

I don't know if it is easy to make this work with some minor changes
or if it requires some major surgery to the XML parsing.

> Also, in a prior email, you said that the actual dofmap should be used in 
> the function definition.  Could we not use the dofmap assumed by FFC, and 
> just adhere to that standard when creating the higher order mesh?  Since  
> FFC will need to interface with it eventually, that seems to make more  
> sense.

The problem is that even if we follow the dof map used by FFC, it will
generate a dof map that depends on the numbering of the mesh entities
(in particular the edges) and that numbering depends on the algorithm
implemented in TopologyComputation. Even if it's not likely that this
will change, I don't think it's a good idea to base a file format on
it.

So I suggest that the entire dof map is stored, that is, for each cell
in the mesh we list the local-to-global map explicitly (the numbers).

-- 
Anders


> - Shawn
>
> On Tue, 26 Aug 2008, Anders Logg wrote:
>
>> On Mon, Aug 25, 2008 at 06:14:49PM -0400, Shawn Walker wrote:
>>> So, would this function be read into a variable inside the MeshGeometry
>>> class?  if so, then I will try to modify the XMLMesh file to account for
>>> reading a <coordinates> tag.  Although I am still a little confused on
>>> how the proposed <dofmap> tag in <function> works.
>>>
>>> - Shawn
>>
>> Yes, I'd suggest that we add a (private) member variable
>>
>>  Function* coordinates;
>>
>> to the MeshGeometry class and rename the current array
>> coordinates to vertex_coordinates.
>>
>> It should be set to zero if there are no higher order coordinates
>> available.
>>
>>
>>
>>> On Mon, 25 Aug 2008, Anders Logg wrote:
>>>
>>>>>> 2. It also makes an assumption about the numbering of degrees of
>>>>>> freedom (and mesh entities) always being the same. This can be handled
>>>>>> by adding a new tag <dofmap> under <function> that contains the dofs
>>>>>> explicitly (not the signature of the FFC dof map).
>>>>>>
>>>>>> The XML format could be something like
>>>>>>
>>>>>>  <mesh celltype="triangle" dim="2">
>>>>>>    <vertices size="2868">
>>>>>>      <vertex index="0" x="0.534923" y="0.326073"/>
>>>>>>      ...
>>>>>>    </vertices>
>>>>>>    <cells size="5400">
>>>>>>      <triangle index="0" v0="76" v1="914" v2="1153"/>
>>>>>>      ...
>>>>>>    </cells>
>>>>>>    <coordinates>
>>>>>>      <function>
>>>>>>
>>>>>>      </function>
>>>>>>    </coordinates>
>>>>>>  <mesh
>>>>>
>>>>> ok, I guess you would need to add an attribute to the `function' to
>>>>> specify what kind of finite element it is.  You could also add a boolean
>>>>> function to the <coordinates> section that would indicate whether the
>>>>> element is indeed curved or not.
>>>>
>>>> Yes, we could do something like
>>>>
>>>> <coordinates degree="2">
>>>>
>>>> and then have the boolean affine="true"/"false" inside the cell tags.
>>

Attachment: signature.asc
Description: Digital signature