← Back to team overview

dolfin team mailing list archive

  1. dolfin team
  2. Mailing list archive
  3. Message #13227

Re: [UFC-dev] added higher mesh variable

  Thread Previous • Date Previous • • Thread Next 

On Mon, 27 Apr 2009, Garth N. Wells wrote:




Anders Logg wrote:

On Mon, Apr 27, 2009 at 09:21:58AM -0400, Shawn Walker wrote:

On Mon, 27 Apr 2009, Anders Logg wrote:


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.
But you still need to modify the ufc::cell code, I think. There is also an implicit assumption that the higher order coordinates should contain the standard mesh vertex coordinates. Of course, this is true for most practical cases. But for more fancy mappings, maybe this is not the case. 

It seems to me that a reasonable assumption would be to limit the
cases to P1, P2, P3, etc, that is, mappings that can be written down
using standard Lagrange bases so then the vertices will always be
included. They would also be first in the list meaning that the code
would actually work (but might not give accurate results) even if it
were generated for affine mappings.


I am not totally against limiting it to Lagrange only...
Also, in the ufc::cell code, you currently read in the cell coordinates using info in MeshTopology. However, the higher order coordinate info resides in MeshGeometry (which is where it belongs). So you would still need to modify ufc.h. Remember, there is higher order cell data that is contained in MeshGeometry. 

Where is MeshTopology used for this? I looked in UFCCell.h which is
where the coordinates are copied to ufc::cell and there MeshGeometry
is used.
What I meant was that MeshTopology is used to get the local cell entities, and from that you get the local vertex coordinates (e.g. for a standard triangle with 3 vertices). But this is done in the DOLFIN code, so it isn't a problem.
Is it really that hard to change ufc.h? Other things have to be recompiled, but isn't that automatic? 

Yes, it's easy to change, but a main point with UFC is that we
shouldn't change it.
UFC will need to be extended as time goes on, but it is hard to know from the outset how it should be done. What about using some IFDEF's or non-pure virtual functions in the development version to allow experimentation? These can then either be removed or added to UFC at release time.
This might not be bad. Eventually, UFC will need to handle these higher order meshes, and so it should contain some kind of data struct to hold that info. 

- Shawn



------------------------------------------------------------------------

_______________________________________________
UFC-dev mailing list
UFC-dev@xxxxxxxxxx
http://fenics.org/mailman/listinfo/ufc-dev

References

  Thread Previous • Date Previous • • Thread Next