dolfin team mailing list archive

[Shawn Walker <walker@xxxxxxxxxxxxxxx>]

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

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.

- 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.
>
> --
> Anders
>
>
> > 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.