dolfin team mailing list archive

[Kent Andre <kent-and@xxxxxxxxx>]

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 ? 


Kent