Meeting Minutes DUNE Developer Meeting 2015
Table of Contents
- 1. Preliminaries
- 2. Review of 2013 meeting
- 2.1. Licensing
- 2.2. CMake vs. Autotools
- 2.3. Supported Compilers
- 2.4. Release is out.
- 2.5. QuadratureRuleKey in dune-geometry
- 2.6. EntityIterators are true STL forward_iterators.
- 2.7. Entity pointer removal.
- 2.8. Intersections are now copyable.
- 2.9. Gridcheck headers renamed.
- 2.10. Need to remove boost checks from dune-common/dune-istl
- 2.11. Getting rid of Dune::istl_assign_to_fmatrix
- 2.12. Change the template argument list of the geometry
- 2.13. Getting rid of the PartitionType template parameter on the GridView
- 2.14. Duplicated methods on Grid and GridView
- 2.15. geomTypes() on the IndexSet
- 2.16. Range based for
- 2.17. parallel features of the grid interface
- 2.18. Capabilities.
- 2.19. intersectionIds
- 2.20. hasBoundaryIntersections()
- 3. General
- 4. Build system
- 4.1. CMake version in the 3.0 release will be 3.0.*
- 4.2. Abolition of the magic that builds test during "make test"
- 4.3. Parallel tests
- 4.4. Documentation of the CMake build system will be written by Dominic!
- 4.5. Use named arguments in CMake.
- 4.6. Remove enable trick
- 4.7. Alberta worldim will set at configure time.
- 5. Request for new features
- 6. Clarification of interface
- 7. Change requests for interfaces
- 7.1. Functional subroutines
- 7.2. dune-common
- 7.3. dune-geometry
- 7.4. dune-localfunctions
- 7.5. dune-grid
- 7.6. dune-istl
- 8. Infrastructure
9 persons vote yes. No one against. Ergo we promote Dominic officially to core developer status. Congratulations, Dominic!
There is an ongoing discussion about the licensing (due to the GPL2 and LGPL3+), there is consent that LGPL3+ is an option but Christian needs to ask all previous contributors. He promises to do this in due time.
Thanks to Christoph the official installation notes do now discuss CMake. Considered more or less done.
Will come later in the meeting.
Hooray!!! Thanks Carsten. dune-alugrid master will be made compatible to 2.4. There will be a dune-pdelab, dune-fem (?) 2.4 release in due time.
To be revisited.
They can return a proxy object.
Done, but needs to be kicked out of master. Robert will doe this.
Kill *.cc files. -> Christoph Grüninger
Still there. Markus will do it.
Due for 3.0
Deprecated for 2.4. Needs to be removed. Martin does it.
Remove now without deprecation. Steffen.
Martin removes it now.
Improve static_assert error message. Steffen for 2.4.1
Still needs to done.
Needs to be done. martin.
Written proposal needed. Later.
Makes sense. Move to GridView and rename to mightHaveBoundaryIntersections(). Postponed to later.
Next major release in 1.5 years with major changes. Parallel support for 2.4.* releases and 3.0. Maybe preview snapshot releases with new major features (e.g. module namespaces, more value semantics, …) to ease porting code. previews will be tagged with preview-0,…, preview-N Release (freeze) in 1.5 years: End of March 2017!
Useful andidates are 4.7 (not C++11 compatible), 4.9 (C++11 compatible), 5.0 (C++14 compatible). 4.8 is missing the following features: - Generic lambdas (Needed e.g. in the datahandle to use one lambda with different types/codims). - const constexpre (incompatible changes)
Nobody insists on gcc-4.8 compatibility. gcc-4.9 will be the target compiler for the 3.0 release. C++11 is completely allowed, experimental C++14 features in gcc-4.9, too! Clang 3.5 is definitely C++14 compliant. ICC >= 15.1 should be supported.
Christoph will change the build system for C++14 compatibility.
In the master branch gcc-4.9 compatibility can be enforced from today!
For 2.4 we will a write a DUNE release paper with inviting substantial contributors to DUNE as authors. Robert will prepare a repository and a list of possible authors.
test will not build during make test. Introduce meta targets build_tests, tests ( build_tests && test). We introduce a variable BLA_BLUBB_TEST to activate building tests during make all. Concordantly agreed.
Add possibility to dune_add_test to run parallel tests. Introduce an upper bound for the processor number (default: 2) for parallel tests. Running tests in parallel should not have side effects. Whether we also need an upper allowed runtime after which we kill the test remains open. Concordantly agreed.
Will be done by Dominic in sphinx (see example). Concordantly agreed.
instead of position dependant ones for all user callable functions. Due in 3.0. Will be done by Dominic. Concordantly agreed.
Christoph. Concordantly agreed.
Christoph Grüninger and Martin.
Three developers sincerely want to have this. We need to hide implementation details from doxygen and the DUNE namepace (consent). Proposals: - all modules get a sub namespace. - all modules except common get a sub namespace. - istl, and localfunctions get sub namespaces. - the core modules are the only ones allowed to be in DUNE.
There is not enough consent to introduce namespaces in any kind to the core modules to warrant this amount work. duneproject will create a sub namespace for each new module automatically.
move make_array to Dune::STD
Yes, even if not data needs to be moved.
Later we might want to have a nicer interface. See FS#266. Move to faq
All vertices have to be inserted before any elements.
Move to faq!
For Joe threadsafe means that if a method takes a const reference, then this method will (not really) change the object, i.e. despite e.g. locking. If a user concurrently passes it as a mutable reference to another method then this is a usage error and he is on his own.
Problems/Questions: - A View is threadsafe if all of its objects are threadsafe. This is the natural C++11 approach. - Each iterator may hold a reference to a grid and cannot be used concurrently to modifying the grid (not even dereferencing it). Maybe we need markThreadSafe. - OpenMPi has a bug. Therefore we need to initialize threads in MPI via MPI_Init_thread with MPI_THREAD_SERIALIZED (supported by all tested MPI versions). We will demand this from the MPI implementation. - Each grid has a reference to a communicator (communication layer). Each communication on it is a modification of it and has to be executed sequentially. The user has to ensure this. Nevertheless one can iterate over a grid and use it read only during a communicate call. - Any modification modifies the communication layer instance referenced by the grid. The following mthods may communicate - Grid::communicate(), and GridView::communicate() - Grid::preAdapt(), Grid::adapt(), Grid::postAdapt() - Grid::loadBalance() - The mark method may not communicate.
See attachment FS#1717 Joe will implement the flag and thread safety with YaspGrid.
Add a function that takes a requirements object and an entity to get the according quadrature rule. There is a consensus that this might be a good idea. Christian and Martin will work on a proposal for discussion partly based on Carsten’s code
Currently one gets the reference element from a container. The question is raised whether it is possible to get it via ADL. Possible overloads need to be provided in the namespace of the grid. We will use decltype to detect wether such an overload exists.
The interface will be defined in geometry and the first overload in grid.
The reference will be returned by value. (No: 0 Abstentions: 2) Martin will do this change.
For now it will just forward to the member functions. Agreed.
OS: Should be used instead of the currently used
Carsten does it.
Without any regard to backwards compatibility Martin will do this.
See presentation of Aleksejs: - if mydim < cdim, always return true - if mydim = cdom run Newton - if found values is inside return it and true - if method result lies outside return false - if convergence is too slow return false
Actually Alecsejs needs to be able to call the method with values that are outside and needs know somehow that they are outside. (He did not tell so at first, though.)
Oliver’s understanding is that it is a misuse/undefined if the requested coordinate is outside of the element. An algorithm should be chosen such that the computed value is always inside. What we want to have is a value the minimises the distance on the plane. Peter’s proposal is to return a bogus outside value if the computation fails and signal the failure. Andreas wants extrapolation for outside values if feasilbe and a boolean telling whether the value is correct.
Our proposal: The method should be a best effort that - return the solution if it is unique. - return one solution if the solution is not unique. - Always minmise the distance to the real solution. - Do something id there is a failure (e.g. convergence issue) that might be NAN, or a bool. But will be discussed after an improved propsal from Aleksejs.
For geometries with geometry type None.
Christian will work on this.
Currently its argument is a vector with coordinate direction per partial derivative. This should be switched to a multiindex with number derivatives per coordinate direction in accordance with global finite elements. (This more like describe in your favorite math textbook.) Agreed concordantly.
Needed for Ck-space with k>0. Done.
There is funding to improve UG and move it nearer into dune-grid, i.e. - Extract the actual grid from ug and - move it to dune-grid into a subdirectory, - make a module dune-uggrid. According to Oliver this module would be needed to made a mandatory core module to ease DUNE’s test on unstructured simplicial grids.
Currently no agreement can be reached what to do with uggrid within DUNE.
FS#1714 Generalize the dune-grid intersection concept for network grids.
Draft proposal is in the picture of the flip chart. It is a consensus, But we need to polish it and compare with all use cases in the current grid. Use cases will be provided by at least Christian and Robert.
FS#1591 - Unique Intersections.
Covered by the proposal above.
FS#1369 - Add id( intersection )
Additional methods that we (might) want
- Communicate on intersections
- IdSet adapted for intersection.
- It is consensus to add a method intersectionInOutside() to get the same intersection in the other element. It can be used to get e.g. the normal or the geometry. Ergo this might make the …InOutside() superfluent and these could be removed (not decided yet). Of course this could have negativer side effects. (E.g. for a cell-centered finite volume method one might only want to get the entity of the other element.)
Everything that could be done with a subentity of codim 1 should also be possible with a intersection.
Reduce redundancy in exported integers of intersection interface
OS: Currently, the Intersection interface class exports four integer numbers:
- codimension: The codimension of the intersection in the grid (always 1)
- dimension: The grid(!) dimension. (Also present in the entity.)
- mydimension: the dimension of the intersection itself
- dimensionworld: The dimension of the world space of the grid This list is a bit redundant. Also, the fact the Intersection::dimension is not the dimension of the intersection has confused quite a number of people. Can we do some cleanup?
Vote: Remove all: 3 Remove dimenion, codimensions: 7 (Abstentions 5, against 0) Ergo the propsal is to remove codimension, and dimension.
SM: Add an operator bool() for entities and intersections to check whether the object was default-constructed.
Add an operator bool() for entities and intersections to check whether the object was default-constructed (returns false) or contains data of an actual entity / intersection (returns true).
Has been declined.
http://gohugo.io for the website instead of wml.
website will be maintained as markup in a repository. Building the website will be triggered via a push. For parts of the website contributors will be able to use merge requests.
Heidelberg University will setup the system, evaluate, and get back to us.
Christian wil find a suitable coordinated with Heidelberg.
Do we want to add gitlab to our workflow to allow merge requests and subsequent pushes by core developers? Directly pushing might still be possible. The SVNManager will die with the introduction of gitlab. Yes: 10 No: 0 Abstention: 2
Can we get rid off flyspray and use the bug tracker of gitlab? Consentently agreed.
We will try to use dedicated feature branches even more then already now. This comes natural with the preferred gitlab pull request based development model.