dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

Attachment: signature.asc
Description: Digital signature