On Mon, Apr 27, 2009 at 11:26:13AM +0200, Kent Andre wrote: > On lø., 2009-04-25 at 00:14 +0200, Anders Logg wrote: > > On Wed, Apr 22, 2009 at 05:28:30PM -0400, Shawn Walker wrote: > > > Here is the changeset that adds a `higher_order_coordinates' variable for > > > storing higher order mesh data. This is a very minor change so please > > > push this. > > > > > > A changeset for DOLFIN is coming immediately after this. > > > > > > - Shawn > > > > I'm not sure what to do about this. It's problematic to add > > experimental work to UFC since it must be stable. In particular, any > > small change to ufc.h means that all forms must be recompiled > > everywhere for everyone. > > > > So before we make a change to UFC, we need to know exactly what we > > need. Which also means I can't import your DOLFIN patch since it > > depends on the UFC patch. > > > > I see you've added > > > > double** higher_order_coordinates; > > > > to ufc::cell. This is analogous to what is now implemented in > > MeshGeometry and the mesh XML format so I think it's good. > > > > The question is what other information we need. As it works now (for > > the standard ufc::cell), UFC code generated by a form compiler knows > > what to expect from for a ufc::cell argument. If higher order mappings > > should work the same way, then the generated code and thus the form > > compilers need to know which mapping should be used and also the > > length of higher_order_coordinates. Is this what you were thinking? > > > > Before we do much more about it, more people need to weigh in on it as > > it affects DOLFIN, UFC, SyFi and FFC. > > > > > But is there any other way around this. It would be nice with higher > order meshes and UFC should not stop this. > > An alternative to changing the cell class would be to make a subclass > of cell. Would this work ?
How about just using the current ufc::cell data structure as it is but let coordinates hold all the coordinates? This could also be the final solution. Then everything that's needed is an extra argument to tabulate_tensor that tells the generated code whether the cell is affinely mapped or not. The flag could simply be an integer: 1 means affine, 2 means quadratic etc. -- Anders
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
