Manifold id step0

This is the first backward compatible version of the manifold id branch. Four methods were added to a class named Manifold<dim,spacedim>, which contains a subset of the  Boundary<dim,spacedim> methods. Boundary<dim,spacedim> is now derived from FlatManifold<dim,spacedim>. This fixes issue #27.

The new methods are:

get_new_point_on_cell
get_new_point_on_hex
get_new_point
project_to_manifold

all functions get_new_point_on_* are now made such that by default they call get_new_point, which in turns query project_to_manifold with the averaged point.

This sounds a little intricate, but it is a way to keep backward compatibility while starting with the new idea about manifolds (seen as collection of points with a metric), where by default the new point is created by averaging the surrounding points, and projecting back the result to the manifold.

Simple implementations can implement the

Manifold::project_to_manifold

function, and everything should work out of the box. More complex implementations should implement

Manifold::get_new_point

New implementations should not need to go behyond this. 

ManifoldChart<dim,spacedim,chartdim> is a special implementation in which push_forward and pull_back mechanisms are used to determine the location of new points. All surrounding points are pulled_back, then averaged, and the result is pushed_forward. This is a standard concept in continuum mechanics, and it is the standard way in which geometry points are computed in isogeometric analysis. 

The old Boundary class is still kept around. It is still used for normals to surfaces. This concept it typical of codimension one manifolds, and it is therefore not embedded in the Manifold class itself, but left to the derived class Boundary<dim,spacedim>.


Ah, now that's a good question. In the past (and I think this is a reasonable set of semantics), cell iterators have always worked with a (bi-/tri-)linear mapping. Functions such as 
  cell->center()
  cell->diameter()
  cell->measure()
have never used any kind of mapping, whether they are at the boundary or not. Anything that would use a more complicated mapping always needed to go through the MappingX classes or, more generally, through FEValues.

What you propose is to change this in a significant way, but I don't think you can do this in any kind of consistent way. For example, functions such as center() or measure() can really only compute an approximation of the correct answer because they would have to sample and/or integrate. I think we can have a discussion whether we want to change this, but my personal preference is to keep this part as it is: whenever you go through cell/face/edge iterators, you get a Q1 mapping. In this model, obj->center() simply returns an average of some kind (with fixed weights) of the locations of vertices that bound the object.