FS issueshttps://gitlab.dune-project.org/flyspray/FS/-/issues2017-06-07T03:28:21Zhttps://gitlab.dune-project.org/flyspray/FS/-/issues/1723New Conjugate Gradient Solvers2017-06-07T03:28:21ZFlyspray ImporterNew Conjugate Gradient Solvers# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Lars Lubkoll (lars.lubkoll@posteo.de) |
| Reported at | Oct 13, 2015 13:24 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating Sy...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Lars Lubkoll (lars.lubkoll@posteo.de) |
| Reported at | Oct 13, 2015 13:24 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
As promised at the User Meeting I want to share my CG-implementations. Now I need you!
Questions
=========
1. C++11 will be supported with Dune v3.0, so I can use it, right?
2. I was always wondering how relevant the Operator::category is. If it is required, wouldn't it make sense to treat it dynamically with exceptions?
3. I tested the cg-implementation against the version that is currently in Dune. Do you have some set of test-problems or tests for ISTL?
4. Any feedback is welcome. I did spent some effort to provide a clean, efficient and robust implementation, but probably you have some requirements that I did ignore. So tell me if there is something that you want to be improved.
5. There is some literature that I cite in the documentation. I personally like to have that in the doxygen documentation for being able to look up details. Thumbs up/down?
6. I believe that there are some parts of the code that should be better placed somewhere outside istl. In particular there is a compile-time sequence and some elementary operations on it. Moreover I typically use a set of mixin classes for adding parameters such as (absolute,relative) accuracy, number of steps, verbosity level... . These may also be better located at a more general place. The mixin approach I did not see in Dune, but I assume that you already have a place where you collect template meta-programming tools, right?
Short Intro
===========
Currently I implemented the conjugate gradient method and three versions that are relevant in nonconvex optimization (truncated CG, regularized CG, truncated regularized CG). Moreover there is a Chebyshev semi-iteration.
As termination criterion there is a residual-based (as before) and one that is essentially based on the relative energy error.
The rough structure of the implementation is as follows:
There is a generic iterative method and a generic step as basic building blocks for iterative methods.
a. The generic iterative method takes a step and a termination criterion and manages step computation, evaluation of the termination criterion and optionally restarts the computation.
b. The generic step allows to specify the details of the implementation of one step as well as additional interface functions and a data object. It seems that the structure of the generic step could be made cleaner. Any ideas are welcome.
Get code
========
See attachment or here:
git clone https://github.com/lubkoll/dune-istl-cg.git
# Attachments
* [0001-iterative-solvers-for-dune.patch](/uploads/a37fc29d3ae57720f873b6e42bf84247/0001-iterative-solvers-for-dune.patch)
* [0002-iterative-solvers-for-dune.patch](/uploads/d6740285f1da0a336a659cef2c1abfcb/0002-iterative-solvers-for-dune.patch)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1722FS#1722 Development previews for 3.02017-06-07T03:28:21ZCarsten Gräsergraeser@math.fau.deFS#1722 Development previews for 3.0# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Oct 6, 2015 09:29 |
| Type | Discussion |
| Version | Git (pre3.0) |
| Operating System | U...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Oct 6, 2015 09:29 |
| Type | Discussion |
| Version | Git (pre3.0) |
| Operating System | Unspecified / All |
# Description
On the 2015 developer meeting we decided that we wanted to provide preview tags for the master during the development of 3.0. These should _not_ be stable not be confused with release candidates or staple releases. Instead they should mark a semi-stable not-completely-broken state where a certain set of features has been implemented.
The purpose of this is to give users and especially module developers the possibility to follow the development of 3.0 and to adapt there modules to the changes step by step.
This task is for discussing these previews without cluttering FS#1669. However, there will hopefully be not to many discussions about this.
Carsten Gräsergraeser@math.fau.deCarsten Gräsergraeser@math.fau.dehttps://gitlab.dune-project.org/flyspray/FS/-/issues/1679FS#1679 [CMake] Run parallel tests!2015-11-02T16:45:16ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deFS#1679 [CMake] Run parallel tests!
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | Jun 30, 2015 12:59 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | Jun 30, 2015 12:59 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
Dear Dune,
I would like to open this task to collect opinions, ideas and experiences on the topic of parallel testing. We do have a lot of parallel infrastructure, which we do only test sequentially during make test right now. When reworking the test suite for 3.0 (see #FS1621), we should think about adding infrastructure for parallel testing.
Some points that come to my mind:
* CMake does offer all the info needed on how to run tests in parallel through FindMPI.cmake
* The number of processors to run a parallel test on should be specified by the test.
* The user should have the possibility to give an upper bound to the number of processors. All test requiring more than that will be skipped.
* Such mechanism can be perfectly integrated into an add_dune_test macro, which would make sense also in the light of #FS1621
* We have rewritten checkCommunicate in dune-grid to do more checking as a Yasp bug slipped through the current test.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1673FS#1673 Reworking the dune-project homepage2016-06-01T16:26:42ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deFS#1673 Reworking the dune-project homepage
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | Jun 25, 2015 13:29 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | Jun 25, 2015 13:29 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
Dear dune community,
we have decided to hire a student to rework the dune-project homepage. Our agenda is the following:
* evaluate other template engines as a replacement for wml
* implement such replacement, if a suitable replacement can be found
* make the build process of the homepage easier (to understand)
* use cmake to generate the documentation
* document the homepage build process
The cmake bullet is what brought this to our attention.
In this task, we would love to hear some of your ideas and experiences on the topic.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1669FS#1669 Release of dune 3.02016-11-25T19:34:23ZCarsten Gräsergraeser@math.fau.deFS#1669 Release of dune 3.0# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Jun 16, 2015 17:50 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecifi...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Jun 16, 2015 17:50 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Last edited at | Jun 16, 2015 17:52 |
# Description
This is for collecting stuff related to the 3.0 release.
(For the moment this task is only used to document the postponed features from 2.4.)
The followings features have been voted for 2.4 on the 2014 dev meeting but where postponed to 3.0:
- 11) Deprecate `overlapSize()`, `ghostSize()`, `communicate()` on grid.
- 17) Add `hasEntityIterator` capability
- 24) Remove C++11 compatibility code (See #1435)
- <s>21) Get rid of `istl_assign_to_fmatrix` (Christoph Ge.)</s> Removed by patches from Elias: istl: e3bcd560, common: 0d2a9d42
https://gitlab.dune-project.org/flyspray/FS/-/issues/1660FS#1660 (un)signedness of indices or dimensions2017-08-26T20:11:54ZMartin NolteFS#1660 (un)signedness of indices or dimensions# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jun 4, 2015 12:41 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operati...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jun 4, 2015 12:41 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
Currently the signedness ofdimensions or indices in the DUNE core is arbitrary. Sometimes a codimension is an `int` (e.g., in the `Codim` structures), sometimes it is an `unsigned int` (e.g., in the `indexSet.subIndex`). Similarly, subentity indices are sometimes `int` (e.g., `refElement.subEntity` returns an `int`), sometimes they are `unsigned` (e.g., `LocalKey.subEntity`).
The different signedness frequently triggers gcc warnings. These in turn need to be circumvented by an explicit `static_cast`, unnecessarily cluttering the code.
I think it is time for a final decision on this signedness issue. I'm fine with either of them, but the mixture is a mess.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1656FS#1656 Merging UG into dune-grid2016-06-01T20:44:48ZOliver Sanderoliver.sander@tu-dresden.deFS#1656 Merging UG into dune-grid# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | May 25, 2015 18:35 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Opera...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | May 25, 2015 18:35 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
I'd like to merge the UG grid manager code into dune-grid before releasing dune 3.0.
Rationale:
- One external dependency less for dune-grid
- An unstructured grid in dune-grid itself
- Merging the code would allow much more drastic code cleanup (which I would like to see for future bugfixing and maintainability) in the UG grid manager, without completely mutilating UG itself.
Due to the spaghetti nature of (parts of) the UG code it is difficult to judge how much code would be added to dune-grid. sloccount suggests an upper bound of about 80000 lines of code, but I have the feeling that the final number will be much lower. Also note that this is C code, and compiles considerably faster than an equivalent number of lines of Dune code.
Before I do the merging I would like to know other people's opinions. In particular, are there objections?
I would not object to having a build system switch that completely disables building UGGrid, if that is desired.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1646FS#1646 GridTraits: IndexType for IndexSets hardcoded to default value2017-08-26T20:11:54ZAnsgar Burchardtansgar.burchardt@tu-dresden.deFS#1646 GridTraits: IndexType for IndexSets hardcoded to default value# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Ansgar Burchardt (burchardt@igpm.rwth-aachen.de) |
| Reported at | May 8, 2015 15:10 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Op...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Ansgar Burchardt (burchardt@igpm.rwth-aachen.de) |
| Reported at | May 8, 2015 15:10 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
The GridTraits traits class contains the following typedef:
```
typedef IndexSet<const GridImp,LevelIndexSetImp> LevelIndexSet;
```
This hardcodes the 3rd and 4th template parameters for `IndexSet` to its default values:
```
template< class GridImp, class IndexSetImp, class IndexTypeImp = unsigned int, class TypesImp = std::vector< GeometryType > > class IndexSet;
```
UG makes use of this: if defines `IndexTypeImp` to `UG::INT`. This works as long as `unsigned int` and `UG::INT` are compatible; this is not the case on the ppc64el architecture.
I see several options:
1. Require `IndexTypeImp` to *always* be `unsigned int`. Not sure what this means for UG.
2. Add additional template parameters for `IndexTypeImp` and `TypesImp` to the `GridTraits` class, with default parameters. This would extend the grid interface, but be backwards-compatible. Raises the question if `Leaf-` and `LevelIndexSet` need to have the same `IndexType` or not.
3. Let grid implementations pass the full `IndexSet<...>` type instead of just the implementation. This is certainly not backwards compatible.
Ansgar
https://gitlab.dune-project.org/flyspray/FS/-/issues/1637FS#1637 Homebrew recipies for DUNE2015-05-25T18:20:28ZFlyspray ImporterFS#1637 Homebrew recipies for DUNE
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Timo Betcke (timo.betcke@gmail.com) |
| Reported at | May 7, 2015 08:57 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All |
| La...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Timo Betcke (timo.betcke@gmail.com) |
| Reported at | May 7, 2015 08:57 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Last edited at | May 25, 2015 18:20 |
| Closed by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Closed at | May 25, 2015 18:20 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment | Added Timo's text to the main download page. Thanks again! |
# Description
Dear All,
I have made Homebrew recipes available to easily install DUNE on Mac. These can be accessed via
brew tap bempp/homebrew-bempp
and then
brew install dune-common
brew install dune-grid
etc...
The repository is at:
https://github.com/bempp/homebrew-bempp
A couple of notes:
- They are relatively basic in the sense that I am not allowing options to be passed on and rely on CMake detecting everything. This was sufficient for our purpose but may not be enough for others.
- I still needed to include the patches already proposed in FS#1480 for Mac. Otherwise, there are linking issues on Mac.
- We also have to patch dune-localfunctions due to an issue with complex data types. I will open a separate bug issue for this.
- Alugrid is currently installed from a tarball that we created from our own repository. I will make patches available for the Dune alugrid repository separately. We had some issues with the size of the Alugrid repository due to some old data files being present in its git history. I communicated this already to Andreas Dedner.
If there is any interest from your side feel free to copy the Homebrew recipes and make them available for others.
Best wishes
Timo
https://gitlab.dune-project.org/flyspray/FS/-/issues/1621FS#1621 Don't build executables on make test2015-10-29T08:36:44ZTimo KochFS#1621 Don't build executables on make test
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Apr 17, 2015 12:07 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / Al...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Timo Koch (timo.koch@iws.uni-stuttgart.de) |
| Reported at | Apr 17, 2015 12:07 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Oct 29, 2015 08:36 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Oct 29, 2015 08:36 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | by Domoinic. The macro to build all tests on make is DUNE_BUILD_TESTS_ON_MAKE_ALL. Thanks again, Dominic! |
# Description
The CMake default way to build and execute tests is
make all
make test
where "make all" builds all executables (in the current directory), "make test" (only) runs all the tests (in the current directory).
In Dune some magic (that I didn't look into) is used to compile all tests on make test.
This has the disadvantage that all tests build also if only one test is desired to run (with ctest -R my_test).
Furthermore it checks all dependencies of all the tests (in the current directory) and not just the one I want to run.
This is a problem when there are more than one test in the same directory and I want to just build and/or run one.
The CMake way has advantages that get lost by contracting build and execution:
- In an automated build the compilation and execution can fail/pass separately
- One test can be build and executed separately if desired (make my_test, ctest -R my_test)
This is particularly bothering if a ctest consists of more than just the execution of one executable, e.g. 5 runs of the executable and an output check, or comparison of an output file with a reference file through a python script, a cmake macro, ...
Then I can't just run ./exec instead of ctest -R my_test.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1619FS#1619 Minimal required CMake version2015-11-02T16:46:35ZChristoph GrüningerFS#1619 Minimal required CMake version
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Apr 17, 2015 07:52 |
| Type | Discussion |
| Version | Git (pre2.4) [cmake] |
| Operating...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Apr 17, 2015 07:52 |
| Type | Discussion |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
With Dune 2.4 we promise to stay compatible with CMake 2.8.6 which was released in October 2011. You can find the complete list of release dates at [1].
In contrast to Autotools, CMake barely has external dependencies, it is easy to build locally, and Kitware provides binaries that work out of the box [2]. We wanted to limit the support for older compiler versions with Dune 3.0. I'd like to discuss the minimal required CMake version for Dune 3.0.
I propose to go with CMake 3.0. This will be part of Debian "Jessie" 8. Please keep in mind that Dune 3.0 probably won't be released in 2015.
[1] http://www.cmake.org/Wiki/CMake_Released_Versions
[2] http://www.cmake.org/download/
https://gitlab.dune-project.org/flyspray/FS/-/issues/1616FS#1616 Use a saner way of declaring exported libraries in Dune modules2023-09-28T21:09:49ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deFS#1616 Use a saner way of declaring exported libraries in Dune modules# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Reported at | Apr 15, 2015 14:19 |
| Type | Discussion |
| Version | Git (pre2.4) [cmake] |
| Opera...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Reported at | Apr 15, 2015 14:19 |
| Type | Discussion |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
| Last edited by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Last edited at | Apr 15, 2015 14:20 |
# Description
After digging around the build system for some time, it looks to me like a module (e.g. dune-common) declares the fact that it exports the library libdunecommon by adding "-ldunecommon" to dune-common.pc.in. That isn't exactly intuitive (or really documented... ;-) ).
After 2.4 (and with autotools out of the way), we should handle this in a more explicit way. This bug is mostly a reminder for discussing this new way. Maybe by handling it in dune_add_library (and adding a flag to that macro to be able to not auto-export problematic libraries like Alberta)?https://gitlab.dune-project.org/flyspray/FS/-/issues/1607FS#1607 CMake based tarballs2016-10-06T11:34:17ZChristoph GrüningerFS#1607 CMake based tarballs# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Apr 1, 2015 18:18 |
| Type | Discussion |
| Version | Git (pre2.4) [cmake] |
| Ope...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Apr 1, 2015 18:18 |
| Type | Discussion |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
I have investigated the way CMake handles creation of tarballs. I want to share my insights and discuss the changes to future tarballs.
## How to create a tarball
1. Make sure no file are part of the source directory that do not belong there like left-over Makefile.in's.
2. Go to the build directory and run "make package_source"
3. Several types of tarballs are created. You'll find an additional directory in your build folder "_CPack_Packages". It contains a copy of the module which is created prior to its packaging. Delete it, as dunecontrol get confused by it (it contains copies of the dune.module file).
## Details
First I was surprised that CPack is not involved, but I start to see the rationals behind it.
1. The process is like "git archive" are simply using tar for whole source directory. There are no generated files. Neither for configuration nor for documentation.
2. This means neither the PDFs nor Doxygen class documentation are part of the packages. We could fiddle that into the tarballs. My question is, do we mind? I never used the documentation from the tarball. I either generated them myself or used the Dune homepage to get them.
3. CMake is necessary anyway. As there is no autoscan, configure script or automake involved, this is not a downside. Actually, we could drop the distinction of Dune from Git and Dune from tarball. Then we could drop this magic stamp mechanism.
What do you think? Are documentation still necessary in the tarballs? Do you need further information?
Flyspray Dune 2.5.0https://gitlab.dune-project.org/flyspray/FS/-/issues/1602FS#1602 IteratorFacades hard code PointerType as V*2017-08-26T20:11:55ZChristian EngwerFS#1602 IteratorFacades hard code PointerType as V*# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Mar 16, 2015 20:44 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Mar 16, 2015 20:44 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
When dealing with on-the-fly objects, we don't have real references and pointers, but have to wrap them...
Currently the user can specify a different reference type, but not a different pointer type. This breaks for the new entitypointer/entity classes, which use a wrapper class as pointertype.
One option is to add the pointertype as an additional themplate parameter, but it is hard to get this right, if we want to stay compatible with the old code and at the same time have it readable.
Option? Opinions?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1559FS#1559 [CMake] Clarify how to switch between sequential and parallel builds2015-03-13T23:47:32ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deFS#1559 [CMake] Clarify how to switch between sequential and parallel builds
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | Jan 30, 2015 14:27 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | Jan 30, 2015 14:27 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Mar 13, 2015 23:47 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Mar 13, 2015 23:47 |
| Closed in version | 2.4 |
| Resolution | Implemented |
| Comment | |
# Description
I had a look into switching opts files from configure to cmake flags during the last days. Using the compatibility layer works fine, but when you switch to pure CMake flags, some problems arise. I already fixed the most critical issue in http://cgit.dune-project.org/repositories/dune-common/commit/?id=b57a46c0adabdfe4dae8cc6d04972ee66ee76e84 .
However, the variable USE_MPI that the compatibility layer defines is not used throughout the project. So - from CMakes point of view - the issue is the following:
1) If you dont provide anything, the build is parallel if an MPI implementation was found, and sequentially otherwise.
2) To have a sequential build even with MPI present, you have to add CMAKE_DISABLE_FIND_PACKAGE_MPI=TRUE
However, this contradicts the current Dune-way of having a sequential build by default. To implement this without additional variables, the user could force a parallel build by setting CMAKE_DISABLE_FIND_PACKAGE_MPI=FALSE. Double negation however is a very bad thing!
So, I propose to actually use a variable to toggle between sequential and parallel builds. Not setting the variable will result in disabling the MPI check => sequential build. Setting it, will reenable the check => parallel build.
We now have the opportunity to change this name (as USE_MPI wasnt used anyway). First of all, I would like its value in the documentation to be BOOL (ON/OFF and TRUE/FALSE are equivalent anyway, we might as well be consistent). I like DUNE_PARALLEL as a variable name, because it indicates that it is specific to our build system in contrast to the CMAKE_* variables being features of CMake itself.
Feedback on the issue and the naming is highly appreciated, as this is must have for 2.4 IMO.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1538FS#1538 Handling skipped tests2016-11-23T10:05:52ZChristoph GrüningerFS#1538 Handling skipped tests# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 2, 2014 12:41 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | U...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 2, 2014 12:41 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Last edited at | May 6, 2015 12:01 |
# Description
In Autotools one can indicate a skipped test with the magic return code 77. This is useful, when a external dependency like MPI or Alberta is not found or the the current environment does not support a feature i.e. range-based for loops.
This is used in dune-common for parallel tests. In dune-grid many tests are disabled with Automake conditionals when the external grids are not found.
CMake 3.0 gained the feature to interpret a return code as a skipped test, using the test property SKIP_RETURN_CODE.
How should we treat skippable tests in the future?
* A) Let the build system exclude them, people can virtually not find out how many tests were skipped.
* B) Let them fail.
* C) Mimic with CMake the behavior of Autotools and let _all_ tests return 77 if they are not run. For CMake 3.0 or newer there is a way to mark the tests as skipped. For CMake 2.8.12 and older..
* Ci) ..we can treat them as errors (like currently in dune-common).
* Cii) ..exclude them silently (like currently in dune-grid).
Christoph GrüningerChristoph Grüningerhttps://gitlab.dune-project.org/flyspray/FS/-/issues/1535FS#1535 CMake macro for copying files to build tree2015-02-06T10:00:24ZCarsten Gräsergraeser@math.fau.deFS#1535 CMake macro for copying files to build tree
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Nov 26, 2014 09:28 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating Syst...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Nov 26, 2014 09:28 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Last edited at | Feb 6, 2015 10:00 |
| Closed by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Closed at | Feb 6, 2015 10:00 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | Merged in 7175e4f27d154e30e4ba9bb3bf70256821c20c19 |
# Description
In dune-fufem we have a little macro that helps copying files to the build tree. It's best explained by example:
dune_fufem_add_copy_dependency(mytarget foo.bar)
This will introduce a new target for copying foo.bar to the build tree and make mytarget depend on it. This may also be helpful to others.
I did not find something like this in dune-common. Maybe someone more involved with the cmake build system can comment on if its a good idea to pull this into dune-common.
# Attachments
* [CopyDependencyMacro.cmake](/uploads/1ab2603683af668f95f9bded5afe417e/CopyDependencyMacro.cmake)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1511FS#1511 Copyable entities and intersections2015-02-26T14:51:16ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deFS#1511 Copyable entities and intersections
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Reported at | Oct 9, 2014 12:59 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| O...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Reported at | Oct 9, 2014 12:59 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Last edited at | Feb 26, 2015 14:51 |
| Closed by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Closed at | Feb 26, 2015 14:51 |
| Closed in version | 2.4 |
| Resolution | Implemented |
| Comment | |
# Description
In Berlin, we decided to make entities and intersections copyable in 2.4. IIRC, that feature wasn't optional, and as it requires changes to both the grid interface and all grid implementations, I think we should really get to work on this...
Dominic will start on porting YaspGrid, but we have identified some points regarding the facade that aren't completely clear from the protocol of the developer meeting:
Constructors / Assignment Operators in the Facades
================================
Do we want to be clever here and only enable the move variants if the grid explicitly enables movability? We'd probably need a capability for that. I'd say we don't bother - if you explicitly don't want to support movability, just delete the move versions with
Entity(Entity&&) = delete;
That syntax is supported by GCC 4.4 and up, and the move constructor of the facade class will automatically fall back to the copy constructor of the implementation (I verified that).
So I propose always providing public copy constructors, copy assignment operators, move constructors and move assignment operators for the Entity and Intersection facades, but allowing grid implementors to explicitly delete the move versions in the implementation classes.
Return Type when Dereferencing Iterators / EntityPointers
===================================
What should the user get when dereferencing an iterator? A const ref or a temporary? For intersections, the protocol says that starting from 3.0, the user will get a temporary, so for consistency, entities should work the same. For 2.4 I propose staying with const ref. Being clear about this is important because the choice has to be consistent across the facades and the implementations: If the facade returns a const ref, but the implementation returns a temporary, the user gets a const ref to an undefined memory location!
Default-Constructibility of Entities
=====================
When users can copy entities, they will start storing them in containers, which is easier if Entities are default-constructible. Should we support that? I don't like the idea, but maybe there are people out there with good use cases?
Until someone turns up with such a use case, I propose keeping the facade classes non default-constructible.
EntityPointer / Entity Interoperability
=======================
The whole EntityPointer deprecation and transition is still bothering me as well. As we want to get rid of the EntityPointer in 3.0, I think it would be really beneficial to have some kind of deprecation in place to help users locate all the places where they use one.
I had the following idea:
* Return an Entity everywhere where we currently return an EntityPointer
* Add deprecated operator* and operator-> methods to the Entity which return a copy (in the case of operator* - remember, we said we don't want to leak references) or a pointer to the Entity (in the case of operator->, where the pointer shouldn't hurt because you can't normally store it)
* Add EntityPointer(Entity&&), operator=(const Entity&) and operator=(Entity&&) to make sure user code that expects to be handed an EntityPointer from the interface continues to work
* Deprecate *everything* on the EntityPointer
I'm not sure if this will work correctly, but I think the only way to find out is by implementing it and testing it against existing code. Unless someone opposes this for something other than technical reasons (or comes up with a clear technical killer problem), I'd suggest implementing this for the facades and for YaspGrid (in a branch, of course) to make sure it works. This change would definitely need some kind of per-grid capability switch as well to avoid breaking grid implementations that aren't ported yet.
Discuss! ;-)
PS: We should really vote on each of those points later on, but I wanted to put the issues out there first, in particular the last one.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1510FS#1510 Rename dunecontrol commands "make" and "all"2015-07-27T07:11:14ZChristoph GrüningerFS#1510 Rename dunecontrol commands "make" and "all"
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 8, 2014 10:06 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operat...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 8, 2014 10:06 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Jul 27, 2015 07:11 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Jul 27, 2015 07:11 |
| Closed in version | Unknown |
| Resolution | Deferred |
| Comment | Maybe we want to do this in the future. Currently we hope to get rid of dunecontrol within the next release cycle. |
# Description
Whenever I explain dunecontrol to people, who have never written their own make files, they have difficulties to grasp the meaning of the command names.
I propose to introduce new command names for Dune 2.4 and remove the old ones together with autotools after Dune 2.4.
- "autogen" is a technical term from autotools. It will vanish anyway as CMake does not require it.
- "configure" seems fine to me, CMake calls it the same.
- "make" is only obvious if you have ever used make. For clarification and because other build tools are possible with CMake, I propose "build" as a substitute.
- "all" is a usual make target name. But it is often confused with building all modules. Unfortunately there is no catchy name. Proposals are "full", "complete", "entire", "whole".
Or we stick to "all" but take it as a default in the case no argument is given.
What do you think?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1501FS#1501 Release of dune 2.42016-01-26T14:44:56ZCarsten Gräsergraeser@math.fau.deFS#1501 Release of dune 2.4# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Sep 29, 2014 10:13 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operati...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Sep 29, 2014 10:13 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Last edited at | Oct 6, 2015 09:12 |
| Closed by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Closed at | Oct 6, 2015 09:12 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | Release has been published. |
# Description
This is for collecting stuff related to the 2.4 release.
On the 2014 dev meeting the following features have been voted for 2.4:
* 2) Add all (despite well-founded exceptions) flags by default. (Markus)
The following have been voted w/o dedicated release number but may also be suited for 2.4:
* 21) Get rid of istl_assign_to_fmatrix (Christoph Ge.)
The followings features have been voted for 2.4 but where skipped for the release:
* 11) Deprecate overlapSize(), ghostSize(), communicate() on grid.
* 17) Add hasEntityIterator capability
* 24) Remove C++11 compatibility code
The followings task are done:
* 1) Make cmake the default and add --use-autotools in dunecontrol.
* 3) Deprecate SGrid (Oliver)
* 4) Remove Alberta 2 support.
* 5) Merge all-entities-yaspgrid.
* 6) Add global index set from Benedikt Oswald and check compatibility with scotch.
* 7) Make EntityIterators forward_iterators.
* 8) Make entities copyable.
* 9) Make intersections copyable.
* 10) Deprecate PartitionIteratorType paramter of gridviews (Martin)
* 12) Deprecate IndexSet::geomTypes()
* 13) Add types() on indexsets and gridviews (Martin)
* 14) Document and merge range based for (Steffen)
* 15) Deprecate map() and add index() subIndex() to mappers (Oliver)
* 16) Use Mapper::IndexType instead of plain int (Oliver)
* 18) Make gridcheck headers .hh (Steffen)
* 19) Rename monom.hh to monomial.hh (Oliver)
* 20) Only run boost check in dune-common if necessary.
* 22) Deprecate Geometry::dimension and Geometry::dimensionworld (Oliver)
* 23) Deprecate isParallel capability