This is sounding ok so far. Limiting ourselves to 2nd order (quadratic) at first is not so bad. We can then add more when things seem to be working.
I will look at that example. As far as reading in the new format, there will be a need to change XMLMesh.h/cpp to deal with the extra <coordinates> tag. And then there would be a modification of UFCCell.h to include another variable to store the mesh function. Is this correct? - Shawn On Mon, 25 Aug 2008, Anders Logg wrote: > On Mon, Aug 25, 2008 at 01:18:33PM -0400, Shawn Walker wrote: >> >> On Mon, 25 Aug 2008, Anders Logg wrote: >> >>> Actually, this would work and would require the least amount of >>> modification of current code. >>> >>> We can just store a vector-valued P2 Function for the coordinates (or >>> any other order). >>> >>> The XML format already handles input/output of Functions so this would >>> be easy. >>> >>> A couple caveats though: >>> >>> 1. This requires having the corresponding elements and dof maps >>> precompiled in DOLFIN. This should be ok, considering they are already >>> there. >> >> Just to clarify, you mean if we were to use 5th order continuous lagrange >> elements for the mesh element geometry, we must make sure this particular >> finite element is implemented. That is certainly reasonable! > > It's definitely implemented (in FIAT/FFC or SyFi) for general order, > but it also needs to be precompiled into DOLFIN so that DOLFIN knows > how to layout degrees of freedom and evaluate basis functions. > > This is done in dolfin/elements/, in particular the file elements.py > which defines the elements that are compiled into DOLFIN. We need to > be restrictive with which elements we include since it adds to the > compilation time for DOLFIN. > >>> 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. > >>> This would mean storing the vertex coordinates twice, but I think we >>> can live with that. The <coordinates> section would be optional. If it >>> exists, it will allocate a Function inside MeshGeometry which would >>> otherwise be null. >> >> As long as this function is easily accessible by the relevant routines >> (i.e. Tabulate_Tensor) this seems ok. Then it would just be a matter of >> how FFC implements the computation. > > The only place we need to worry about this is in UFCCell where we copy > the values from DOLFIN data structures (like Cell, Vertex etc) to the > UFC data structure ufc::cell. This is easy to modify. > >> Is there a specific demo that reads in a function similar to this? I >> would like an example to look at. >> >> - Shawn > > Yes, demo/pde/convection-diffusion/. > > -- > Anders > _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev
