[Dune] Returning Geometries As Objects

[Martin Nolte]

Dear all,

as announced in December, there is now an implementation returning the 
geometry as an object and all grid implementations in dune-grid have been 
adapted accordingly. Therefore, I think time has come for discussion of the 
outcome.

The changes try to be as uninvasive as possible. However, due to code 
evolution, there are some unnecessary changes left. The greatest benefit for a 
developer is the possibility to create a new geometry object whenever the 
geometry is requested. This gives us essentially two types of geometry 
implementations:
(a) actually returned geometry implementations,
(b) references to the actual geometry (as was previously enforced).

To save an unnecessary wrapper class, the difference is reflected directly in 
the class Geometry. The developer can now choose whether Dune::Geometry shall 
store the actual implementation or store a reference to the actual 
implementation. To this end, I introduced a new kind of "capability" 
namespace, called FacadeOptions and added the option "StoreGeometryReference" 
which currently defaults to true (see dune/grid/common/geometry.hh). Of 
course, such naming is still open for discussion. In either case, the 
developer creates an implementation object (of type Geometry::Implementation) 
and passes it to the Geometry wrapper. If the wrapper just stores a reference, 
the implementation object must survive the geometry method.

Let us now have a short look at the necessary changes in a grid 
implementation. For simplicity, we will only consider the case where the 
geometry wrapper store a reference (default case). Currently, entity and 
implementation store objects of type Dune::Geometry< ..., GI >. With the new 
interface, they store objects of type GI< ... >. For the sake of presentation, 
I will assume that this variable is called geo_. If GI< ... > is default 
constructable, a positive side effect of the transition is that geo_ need no 
longer be initialized in the constructor:

Old MyEntity constructor (GI< ... > is default constructable)

MyEntity::MyEntity ( ... )
: ...,
   geo_( GI< ... >() )
{
   // ...
}

New constructor:

MyEntity::MyEntity ( ... )
: ...
{
   // ...
}

Moreover, geo_ can now be manipulated without using something like 
getRealImplementation, because the wrapper is only created as a last step in 
the geometry method. However, this method has to be slightly adapted:

Old geometry method:

const Geometry &geometry () const
{
   // ...
   return geo_;
}

New geometry method:

Geometry geometry () const
{
   // ...
   return Geometry( geo_ );
}

That it. The grid will now behave as it did previously.

As already mentioned in the announcement of the transition, there is also a 
subtle impact on user code. Geometry references may no longer be stored 
outside the scope calling the geometry method. For example:

const Geometry *pgeo = 0;
{
    const Geometry &geo = entity.geometry();
    pgeo = &geo;
}

worked with the current interface but will break after the transition. Notice 
that the compiler will now warn in such a situation and the resulting code 
will probably segfault. The good news is that the segfault is extremely likely 
(since, e.g., pgeo now points onto the execution stack). However, such code 
will be rare and probably only found in the higher discretization modules, 
such as dune-fem, dune-fufem, or dune-pdelab.

I also did some performance tests with gcc-4.6 (my usual explicit finite 
volume scheme from the dune-grid-howto - slightly adapted for performance 
measurements):

Grid                          trunk (r7850)       branch (r7845)
SPGrid                         28.945s              31.448s
IdGrid<SPGrid>                 39.527s              35.848s

YaspGrid                       43.394s              43.021s
IdGrid<YaspGrid>               80.378s              76.978s

ALUCubeGrid                    247.227s            238.604s
IdGrid<ALUCubeGrid>            275.215s            273.532s

SGrid                          225.179s            207.103s
IdGrid<SGrid>                  257.393s            217.859s

Notice that the SPGrid implementation no longer returns the geometry by 
reference, which seems to cause a small performance loss. However, this 
decision is now up to the grid developer! Unfortunately, there are some 
spurious performance gains with ALUCubeGrid and SGrid. Notice, however, the 
performance difference when wrapping with IdGrid (especially SPGrid and YaspGrid).

In my opinion, the performance results indicate that the change does not cause 
any performance losses. Moreover, they demonstate a performance gain for meta 
grids. For my point of view, the biggest gain, however, is the simplification 
of the grid implementations (no more getRealImplementation, no need to store 
the geometry on the entity / implementation).

Before doing any changes to the actual trunk, I would like to hear the opinion 
of the developers (and users) on this change. I hope the impact of the 
transition and its most important details became clear. Questions, 
suggestions, and hints will be welcome.

Best,

Martin

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany

_______________________________________________
Dune mailing list
Dune at dune-project.org
http://lists.dune-project.org/mailman/listinfo/dune