Roadmap for version 2.1 Expand all | Collapse all
59% of 18 tasks completed. 8 open tasks:
- FS#540 - deprecate intersection iterators on entity Expand Collapse
-
Now that the intersection iterators are provided by the grid views, they are no longer necessary on the entity. More precisely, the entity would be more slim without these methods.
So, should we deprecate the old interface on the intersection?
If so, what about hasBoundaryIntersections? Does it belong on the grid view?
- FS#743 - Add a way to determine whether a grid is hybrid Expand Collapse
-
For meta-grids (like the GeometryGrid), it would be nice to know whether the underlying host grid is hybrid or not. In the non-hybrid case, the (constant) codim 0 geometry type would also be interesting (compile time constant).
Knowing the 2 things, GeometryGrid< AlbertaGrid, CoordFunction > could use the non-hybrid implementation of the generic geometries, saving some performace in explicit codes (2% in my last test, which is long ago).
One suggestion could be to add a GeometryInfo structure looking as follows:
struct GeometryInfo
{
static const int dimension = dim;
static const int dimensionworld = dimworld;
static const bool hybrid = false;
static const GeometryType::BasicType basicType = GeometryType::simplex;
};
Whether this structure can be obtained from somewhere within the grid or is a specialized structure outside the grid would, of course, need to be discussed. If this structure is not contained in the grid, we could provide a default implementation:
struct GeometryInfo
{
static const int dimension = dim;
static const int dimensionworld = dimworld;
static const bool hybrid = true;
};
Apart from meta-grids, there might even be other code pieces, where this information is desirable (e.g., the MGMC mapper could does not need to look up the gemetry type for non-hybrid grids).
- FS#674 - strict-aliasing warnings with gcc-4.4 Expand Collapse
-
If compiled with gcc-4.4 and '-O3 -Wstrict-aliasing' the grid checks test-ug and test-alu2dsimplex complain about violations of the strict aliasing rule.
Referring to http://gcc.gnu.org/gcc-4.4/porting_to.html gcc-4.4 seems to more strict.
- FS#764 - Allow user to override ALUGrid library directory Expand Collapse
-
The current Autoconf macro detecting ALUGrid unequivocally assumes that "libalugrid.la" is installed in "$ALUGRIDROOT/lib" where $ALUGRIDROOT is the PATH given to the --with-alugrid configure option. While typically the right thing, this particular assumption does prevent installing libalugrid.{l,}a in, e.g., "/work/lib64", for use in a multi-libbed (32 bit and 64 bit) environment.
Attached is a patch which implements a rudimentary "--with-alugrid-libdir" option to the DUNE_ALUGRID_PATH macro. This option will enable a sufficiently motivated user to override the default installation directory. The default configuration is not affected by this patch.
Would you consider this patch for inclusion in Dune?
Best regards,
Bård Skaflestad <Bard.Skaflestad@sintef.no>
SINTEF ICT, Applied mathematics
- FS#604 - move reference element related stuff to separate module Expand Collapse
-
This is a replacement task to
FS#538:
instead of moving things to dune-common, we could
introduce a new dune module (name suggestions welcomed)
which contains:
1) parts from the generic geometries
(generic construction classes, corner mappings...)
2) the geometry type
3) the generic reference elements
4) the quadratures
5) a geometry interface class
6) ...
both dune-grid and dune-localfunctions
would depend on this module.
It would increase the non-monolithic design
(removing geometry type from dune-common, quadratures and
reference elements from dune-grid) and would
make the dependency between modules a lot clearer.
The transition could be done smoothly by adding deprectaed headers in
the appropriate places.
- FS#768 - testgenericfem failes Expand Collapse
-
I tested the release 2.0 branch.
This needs to be fixed before the release.
- FS#784 - Remove 2.0-deprecated stuff from trunk Expand Collapse
-
Now the 2.0 release is out (thanks again to Christian), we should decide when to remove the stuff that was deprecated in 2.0.
Moreover, the following questions arise (feel free to add more):
- Should we also remove dune/grid/common/referenceelements.hh (old referenceelement)?
- Should we remove the old MPI_CPPFLAGS / MPI_LIBS?
- FS#787 - merge MPI-datatype stuff from istl and common Expand Collapse
-
For the generic construction of MPI datatypes there is one implementation called Generic_MPI_Datatype in dune/common/mpicollectivecommunication.h and another one called MPITraits in dune/istl/mpitraits.hh. Both implementation should be merged in dune-common.
I suggest to create new header for these.
Text Version