[Dune] Quo vadis Dune ?
Jö Fahlke
jorrit at jorrit.de
Thu Dec 3 09:53:37 CET 2009
Am Thu, 3. Dec 2009, 09:37:46 +0100 schrieb Oswald Benedikt:
> Could you please make available information on future Dune developments for us ?
> Is the protocol accessible somewhere ?
I'm sending the protokoll to the list so it will be available from the list
archive.
Jö.
======================================================================
===== Major Topic =====
==== Boundary/GridFactory ====
=== index translation for coarse grid creation ===
Data stored in files must be associated with entities in a grid-file. The GridFactory must provide the necessary infrastructure...
Two proposals:
- 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).
Arguments:
* (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
Vote:
- insertion order: 5
- indexSet: 6
- abstained: 3
=== boundary IDs/indices ===
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.
Vote:
- coarse boundary index: 11
- boundaryIDs: 0
- abstained: 3
Additional details:
* bool wasInserted(Level-0-Intersection)
* boundarySegmentIndex() replaces boundaryID() on the intersection
=== BoundarySegment vs. BoundaryProjection ===
Refinement towards the boundary. You have to project newly inserted vertices onto the boundary.
Two options:
- 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)
Arguments:
* (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
Votes:
* local to global: 14
* global to global: 0
Additional Information:
* 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
=== parametrized elements ===
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
Votes: agreed
==== new dune-geometry module ====
Proposal ([[http://www.dune-project.org/flyspray/index.php?do=details&task_id=604|FS#604]], [[http://www.dune-project.org/flyspray/index.php?do=details&task_id=538|FS#538]]):
- 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
==== dune-localfunctions ====
=== 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
=== static/virtual interface ===
Proposed solutions:
- (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, [[http://www.dune-project.org/flyspray/index.php?do=details&task_id=449|FS #449]]
proposed changes:
- 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) =====
* 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?
===== Medium Topics =====
==== UG license issues ====
SKIPPED
==== Extension of grid interface ====
SKIPPED
* node->element relation
* EntityKeys
* 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 ====
* "Vorwarnzeit"
==== 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.
--
If God had intended Man to Smoke, He would have set him on Fire.
-- fortune
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20091203/90fc8b96/attachment.sig>
More information about the Dune
mailing list