index translation for coarse grid creation
Responsible: Andreas, Martin
Status: Interface updated, supported in AlbertaGrid
Data stored in files must be associated with entities in a grid-file. The GridFactory must provide the necessary infrastructure…
level-0 elements/vertices/(boundary-segments) are numbered in the order of insertion (only level-0-indexSet).
add some kind of indexSet to translate between insertionIndex and entityIndex (methods on the grid factory).
Both indices are only valid until you first modify the grid (e.g. refine, load balance).
- (1) is easier fo the user
- (1) principle of least surprise
- (1) helps for debugging
- (1) requires changes to the grid managers
- (2) imposes less restrictions on future grids
- (2) more efficient (for certain grids) during computation
- (2) requires reorder of data during setup phase
- insertion order: 5
- indexSet: 6
- abstained: 3
Responsible: Andreas, Martin
The user must be able to attach boundary information to the level-0 boundaries.
- Up to now the boundaryIDs allowed to associate an int with a boundary segament.
- The new proposal is to have an index with a boundary index. This is (more) consistent with the other indicies and allows to associate more or less any data with boundaries. The number would be inherited from the coarse grid.
- coarse boundary index: 11
- boundaryIDs: 0
- abstained: 3
boundaryID()on the intersection
BoundarySegment vs. BoundaryProjection
Refinement towards the boundary. You have to project newly inserted vertices onto the boundary.
- map from local to global coordinates (i.e. a parametrization of the boundary in coarse grid local coordinates)
- map from global to global coordinates (i.e. a geometric projections)
- (1) is safer for generic CAD data
- (2) can fail for arbitrary boundaries
- both approaches are equivalent in the sense that it is possible to compute local from global coordinates and the other way around
- (2) might lead to epsilon problems
- local to global: 14
- global to global: 0
- on insertBoundarySegment the parametrization of a boundary is optional (null-pointer == no parametrization, null is default)
- coherent handling of parametrizations in grids which don’t support it … gridFactory should through an exception.
- BoundarySegmentPointer is a shared_ptr<…>
- we might come back to this point when discussing moving boundaries
Oliver proposes to add a parametrization for elements.
- add “local to global” parametrization as an optional parameter to the insertElement method.
- BoundarySegment should be renamed
new dune-geometry module
- 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.
- leave it as it is: 3
- move the necessary stuff to dune-common: 0
- create the proposed new module: 6
- abstained: 3
naming convention/directory structure
name of the module/include
- local functions (5 votes)
- finite elements (2 votes)
rename the directory structur to dune/localfunctions/
how are associated local functions related to different element types stored in the directory hierarchy
- different elementtypes/dimensions in one file/directory
- one subdirectory for each header named “header-name minus dot-hh”
- files in these subdirectories are internal headers and should not be used directly
- (only) pure virtual methods (0 votes)
- static interface + virtual wrapper (4 votes)
Documentation of the virtual-wrapping-thing is missing.
For the virtual interface the interpolation should be based on the Fuvtion interface from dune-common.
For the virtual interface the CoefficientType must be specified. It should be template parameter. For the static interface it stays a parameter of the interpolation.
which static polymorphism to use?
- “Barton-Nackmann” (CRTP) approach (1 vote)
- stl-like engine approach (7 votes)
specialization for the engine/capabilities approach:
void foo(typename enable_if<hasCapabilityA::value,Type>::type); void foo(typename enable_if<!hasCapabilityA::value,Type>::type);
When to release?
- the module should published with the next dune release
- if the module is in the right shape it becomes a core module
- otherwise it is published as a technology preview
Generalized Entity types (Geometry Types, Reference Elements, …)
see Sintef, FS#449
- add a GeometryType::??? BasicType (agreed) none (8), general (6), arbitrary (4), unknown (1) … New name is “none”
- add a center/centroid() method for the center/centroid of the cell, exact semantics are discussed later (agreed)
- add unitOuterNormal() without local coordinate returning unitOuterNormal at center/centroid() (pro 11, con 1)
- make arbitrary intersections return “none” (postponed)
New DUNE release (2.0)
Responsible: Christian, Martin D.
- target end of feb. 2010
- show-stoppers: todays decisions (GridFactory, Geometry-stuff, automated-tests, flyspray)
- release manager: Christian (buildsystem), Martin Drohmann
- automated-tests: running, more test-systems needed
- flyspray: homework
- supported platforms: linux >= gcc 3.4.1, not 4.0, 4.1, 4.2, 4.3, 4.4, linux >= intel (7? or an other one), mac, libtool 1.5 & 2.x, autoconf/make (>= ??)
- try to speedup the dune-grid tests, leave out the test-programs
- Christian changes the buildsystem so that “make all” doesn’t build the documentation. The user has to call “make doc”.
- SVN access for Martin Drohmann (Mario is the sponsor)
- Vote via mail: Should Jö become core developer?
UG license issues
Extension of grid interface
- node→element relation
- Random entity access
- Richer interface for codim>0 entities
Semantics of certain interfaces/classes
- Ghost_Partitition (discussion postponed, via email)
- IDs: are they unique across codims? Not necessarily (Oliver updates the docs)
- What is the purpose of the PartitionType parameter of a GridView? (remove PartitionType-parameter, keep size-method)
- GridViews: Do they stay valid after refinement? GridViews and IndexSets are not valid after a grid change (adapt, loadbalance)
strategies for changes to core modules
Use of tr1 c++0x stuff
Dune::array: we agreed on the following: Dune::array will only substituted by std::array, but not by std::tr1::array. That way we avoid the aligmnent bug in std::tr1::array which is present in gcc 4.0, 4.1, 4.2. FieldVector can then safely inherit from Dune::array.