#604 move reference element related stuff to separate module
Metadata
| Property | Value |
|---|---|
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Sep 25, 2009 09:52 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | May 10, 2012 12:38 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | May 10, 2012 12:38 |
| Closed in version | 2.2 |
| Resolution | Implemented |
| Comment | The remaining sub-tasks have their own spin-off tasks #959 (closed) and #1102 (closed). |
Description
This is a replacement task to #538 (closed): instead of moving things to dune-common, we could introduce a new dune module (name suggestions welcomed) which contains:
- parts from the generic geometries (generic construction classes, corner mappings...)
- the geometry type
- the generic reference elements
- the quadratures
- a geometry interface class
- ... 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.
Activity
IMO this would be a nice solution. As this module would contain all grid-independent stuff related to geometries (which is more than just the reference elements) I suggest 'dune-geometry' as name.
However, before introducing a new official module it would be nice to have a decision on #386 (closed).
For the record: the corresponding entry in the meeting minutes from the 2009 meeting can be found at https://www.dune-project.org/wiki/doku.php?id=protokoll_nov._2009#new_dune-geometry_module. Since not everyone has access there, I'll reproduce it here:
Proposal (#604 (closed), #538 (closed)):
-
a new DUNE module for gemetry related components
-
shall contain GeometryType, (Generic)Geometries, GenericReferenceElements, QuadratureRules, VirtualRefinement
-
the Geometry facade class stays, an interface is introduced in dune-geometry and used in dune-grid
-
not necessarily right now, but once someone finds time.
Vote:
- leave it as it is: 3
- move the necessary stuff to dune-common: 0
- create the proposed new module: 6
- abstained: 3
-
-
Does anybody have a good idea how to move the GeometryType? All the other stuff is relatively straight forward. My best approaches are:
-
Move everything GeometryType-related to Dune-Geometry and leave compatibility headers with a deprecation warning in Dune-Common. These headers include the real stuff from Dune-Geometry. This is ugly because it means Dune-Common includes stuff from a module it can't depend upon.
-
Move everything GeometryType related to Dune-Geometry and have compatibility headers <dune/common/geometrytype.hh> etc. inside Dune-Geometry. This is ugly because it means that Dune-Geometry infridges on Dune-Common's namespace. Also, to anybody who isn't automatically using Dune-Geometry it will look like <dune/common/geometrytype.hh> simply vanished without any real clue what has been going on.
Since most users are likely to use Dune-Localfunctions or Dune-Grid, dunecontrol will tell them they need Dune-Geometry, so everything should work seamlessly for both approaches in the vast majority of cases.
-
Shouldn't the following work for the transition phase: suggest dune-geometry in dune-common in dune-common/geometrytype.hh
- test if dune-geometry was found YES: give a warning that common/geometrytype.hh is deprecated and include geometry/geometrytype.hh
- NO: give an error stating that dune-geometery is needed if geometrytype.hh is to be used (or give a warning and include some common/geometrytype_deprecated.hh file which contains the GeomtryType class as it is in the 2.1 release) In this way nothing changes for people using dune-common but not needing geometrytype (whoever that is). The others get the right kind of information, i.e., at least install dune-geometry.
I like the basic idea of Andreas suggestion. The problem is: Circular dependencies don't work as far as I know (not even through suggestions). Nevertheless, we may test for HAVE_DUNE_GEOMETRY in dune-common, because it is set in a previously included config.h from some application module. So the suggestion is:
- move dune/common/geometrytype.hh to dune/geometry/type.hh (geometrytype.hh would be redundant, here)
- add a new header dune/common/geometrytype.hh containing the following lines: #if HAVE_DUNE_GEOMETRY #warning "dune/common/geometrytype.hh is deprecated; include dune/geometry/type.hh instead" #include <dune/geometry/type.hh> #else #error "the GeometryType has moved to the new module dune-geometry (dune/geometry/type.hh)" #endif
-
Suggesting dune-geometry in dune-common should yield interesting results. AFAIK, if a suggested module is found dunecontrol will make sure it is build before the module suggesting it. So this would lead to a loop in dunecontrol.
The "warning if found, error if not found" behaviour can be achieved by my first approach without any autohell-magic:
#warning This header is deprecated. Use <dune/geometry/geometrytype.hh> from #warning the new Dune module Dune-Geometry instead. #warning #warning If the following include statement gives you an error, you need to #warning install the new Dune-Geometry module, and make sure that your module #warning depends on it. #include <dune/geometry/geometrytype.hh>
The only missing thing is the automatic fallback to a compatibility implementation of GeometryType in Dune-Common. To achieve this I see three possibilities:
-
Check for Dune-Geometry in Dune-Common's configure. This is most probably unrealiable, if at all feasible.
-
Try to shadow Dune-Common's <dune/common/geometrytype.hh> by providing a header with the same name and path in Dune-Geomtry as well. Again, this is probably unreliable, and it requires that the -I flags are given in a certain order.
-
Have a flag --enable-old-geometrytype in Dune-Common's configure, which people must set explicitly. This may play havoc with out-of-source builds, and since the user has to take action anyway, he could just as well install Dune-Geometry and add it to his application module's dependency list.
For each of the possibilities I wonder whether they are worth the trouble.
-
-
Hmm, there is still a small problem, though: suppose someone has his own module Dune-Foo which depends only on Dune-Common and uses Dune::GeometryType. His application module depends on both Dune-Foo and Dune-Grid. If Dune-Foo has a library, the binary code in that library will use the fallback GeometryType, while everything else will use the new GeometryType.
-
Switching to a fallback implementation should, of course, not be done singularly by a preprocessor macro due to the scenario sketched be Jö. From my point of view, a fallback implementation is not even necessary. In case we do decide differently, we should make them differ in type (e.g., Dune::GeometryType vs. Dune::Geo::Type).
I don't like the namespace Geo , though. One reason big is that GeoGrid had to be renamed to GeometryGrid for consistency reasons. I think the same reasoning applies here.
I agree about the naming. Namespaces encapsulating entire modules should have the same name as the module, to avoid user confusion. And this will not lead to clashes: The namespace Dune::Geometry will not clash with the type Dune::Geometry if we put that one in the dune-grid namespace Dune::Grid::Geometry.
-
Urgh. changing everything without transition would probably really annoy pretty much everyone using dune. It wouldn't be quite as bad as the reference numbering (probably), but still.
We could decide to skip the deprecation period for Dune::Geometry only. I suppose it's only use is in Grid implementations. But there are a lot of external grid modules around nowadays, so still plenty of people to annoy. And maybe even some end-users too, if someone checks whether a class is an instance of Dune::Geometry to find out whether it is a geometry (that was the reason why Dune::MockGeometry isn't a real geometry class).
-
In the case of Dune::Geometry we have a change pending anyway. They will be copyable in the next release. Therefore, I guess renaming that class to Dune::Grid::Geometry is not really a problem. But: Dune::Grid is also a class - and this one might be a problem. Considering all the problems, it seems to me that we should not introduce a namespace into dune-geometry, yet. Instead we should postpone any decision on namespaces to the next developer meeting. I think this transition requires a little more thought than "ok, let's just do it and call everything DUNE 3.0".
-
For the record: I'm think we should postpone the namespace issue as well.
As to the GeometryType issue: I just thought of another way of handling this. We keep the implementation in Dune-Common for now but make sure a warning is emitted every time <dune/common/geometrytype.hh> is included directly. Something along these lines:
== dune/common/geometrytype.hh ======================================= #ifndef DISABLE_GEOMETRYTYPE_DEPRECATION_WARNING #warning #include <dune/common/geometrytype.hh> is deprecated. Use #warning #include <dune/geometry/type.hh> instead. You may need the new #warning Dune-Geometry core module. #endif // DISABLE_GEOMETRYTYPE_DEPRECATION_WARNING
#ifndef DUNE_COMMON_GEOMETRYTYPE_HH #define DUNE_COMMON_GEOMETRYTYPE_HH [...] #endif // DUNE_COMMON_GEOMETRYTYPE_HH
== dune/geometry/type.hh ============================================= #ifndef DUNE_GEOMETRY_TYPE_HH #define DUNE_GEOMETRY_TYPE_HH
#define DISABLE_GEOMETRYTYPE_DEPRECATION_WARNING #include <dune/common/geometrytype.hh> #undef DISABLE_GEOMETRYTYPE_DEPRECATION_WARNING
#endif // DUNE_GEOMETRY_TYPE_HH
After the deprecation period is finished, we can simply move the contents of <dune/common/geometrytype.hh> to <dune/geometry/type.hh>. That should really allow for a clean transition.
-
I'm currently trying to test what Christoph Grüninger has implemented. The procedure is as follows: compile all modules required for and including dune-grid-howto, dune-grid-dev-howto, and dune-pdelab-howto normally, as far as possible. Then, using a skript, try to compile every program and run every test in those modules and note the result. Then compare the results for a baseline set of revisions and the geometry branch.
As the baseline set I'm using the following revisions:
dune-common/trunk@6523 dune-grid/ basically trunk trunk@7730, but with the patches trunk@7729 and trunk@7723 left out since they were causing problems dune-grid-howto/trunk@362 dune-grid-dev-howto/trunk@97 dune-localfunctions/trunk@1025 dune-istl/trunk@1504 dune-pdelab/trunk@1666 dune-pdelab-howto/trunk@491
The list of to-be-compiled programs and to-be-run test in the baseline is attached. Also attached is a skript to compile all these programs.
Attachments
-
Attached is the raw result of compiling all baseline programs[1]. Also attached is a skript to run all tests.
One more version number I forgot to mention: mpirun (Open MPI) 1.4.2.
[1] WTF? Virtual memory exhausted while compiling the raviartthomas-test in dune-localfunctions??? No matter right now.
-
-
Attached is the result of running the tests in the baseline.
For the test on the branch, I'm using the following versions:
dune-common/branches/develop-r6501-introduce-dune-geometry@6525 dune-geometry/trunk@19 dune-grid/branches/develop-r7678-introduce-dune-geometry@7738 dune-grid-howto/trunk@362 dune-grid-dev-howto/trunk@97 dune-localfunctions/branches/develop-r1006-introduce-dune-geometry@1026 dune-istl/trunk@1504 dune-pdelab/trunk@1666 dune-pdelab-howto/trunk@491
These have all the patches for baseline test merged (that is, trunk@7729 and trunk@7723 have not been merged for dune-grid).
Attachments
-
-
-
Looking only at the lines marked 'XXX' in the logs, I see the following differeneces:
+XXX COMPILE OK dune-geometry/dune/geometry/genericgeometry/test/testsubtopologies +XXX COMPILE OK dune-geometry/dune/geometry/genericgeometry/test/testmatrix -XXX COMPILE OK dune-grid/dune/grid/genericgeometry/test/testsubtopologies -XXX COMPILE OK dune-grid/dune/grid/genericgeometry/test/testmatrix +XXX RUN OK dune-geometry/dune/geometry/genericgeometry/test/testsubtopologies -XXX RUN OK dune-grid/dune/grid/genericgeometry/test/testsubtopologies
This is expected, the tests have been moved to dune-geometry
+XXX COMPILE OK dune-geometry/dune/geometry/test/test-quadrature +XXX COMPILE OK dune-geometry/dune/geometry/test/test-genericquadrature +XXX COMPILE OK dune-geometry/dune/geometry/test/referenceelementstest +XXX RUN OK dune-geometry/dune/geometry/test/test-quadrature +XXX RUN OK dune-geometry/dune/geometry/test/test-genericquadrature +XXX RUN OK dune-geometry/dune/geometry/test/referenceelementstest
This is somewhat unexpected, those test apparently have been copied to dune-geometry. This should get fixed.
+XXX COMPILE OK dune-grid/dune/grid/albertagrid/test/test-alberta3d-refine +XXX COMPILE OK dune-grid/dune/grid/io/file/dgfparser/utils/dgf2dgf +XXX COMPILE FAIL dune-grid/dune/grid/io/file/dgfparser/utils/gmsh2dgf +XXX RUN FAIL dune-grid/dune/grid/albertagrid/test/test-alberta3d-refine
These are some files I apparently overlooked in the baseline. I'll have to test whether gmsh2dgf compiles and test-alberta3d-refine works in baseline.
-
dune-grid/dune/grid/io/file/dgfparser/utils/gmsh2dgf fails to compile in baseline as well dune-grid/dune/grid/albertagrid/test/test-alberta3d-refine segfaults when run in baseline
The three tests
dune-geometry/dune/geometry/test/test-quadrature dune-geometry/dune/geometry/test/test-genericquadrature dune-geometry/dune/geometry/test/referenceelementstest
have been removed, since they are in dune-geometry now.
I would say 1) to 4) are done.
-
Is an open discussion. Currently only dune/grid/common/geometry.hh exists which is in dune-grid due to its template arguments, cf. #959 (closed).
-
Thanks to Christian who lately took care of #851 (closed), virtual refinement does no longer depend on a grid. But it still includes dune/grid/common/geometry.hh.
If I got the comments right 5) won't be done before Dune 2.2. Can we move 5) and 6) to separate tasks for future releases and close this task?
-
mentioned in issue #676 (closed)
mentioned in issue #959 (closed)
mentioned in issue #1102 (closed)
