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/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/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/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/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/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/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/1242FS#1242 Possible bug in Dune-ISTL's configure-time detection of SuperLU2013-01-31T03:56:54ZFlyspray ImporterFS#1242 Possible bug in Dune-ISTL's configure-time detection of SuperLU
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Bård Skaflestad (bard.skaflestad@sintef.no) |
| Reported at | Jan 30, 2013 19:23 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / A...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Bård Skaflestad (bard.skaflestad@sintef.no) |
| Reported at | Jan 30, 2013 19:23 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Jan 31, 2013 03:56 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Jan 31, 2013 03:56 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment | Fixed in r1778, thanks for the patch. |
# Description
All,
In tracking down a build issue in an unrelated, external module, I happened upon a latent issue in the DUNE_PATH_SUPERLU and DUNE_PATH_SUPERLU_DIST macros (dune-istl/m4/superlu.m4 and dune-istl/m4/superlu-dist.m4). Unless I am mistaken, these macros do not properly guard against possibility of someone specifying
--with-superlu=yes
at configure time.
Granted, the documentation for '--with-superlu' does state that the parameter be a (valid) path rather than some arbitrary string but as introducing the guard is simple (attached), may I suggest that a latent issue be avoided? In particular, the "eval cd" trick fails if "$withval" is invalid.
# Attachments
* [istl-superlu.diff](/uploads/32b502dc92c6b36725641802e535805a/istl-superlu.diff)
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/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/985FS#985 web page face lift2012-06-25T17:09:56ZAndreas DednerFS#985 web page face lift
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Dec 3, 2011 17:14 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Dec 3, 2011 17:14 |
| 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 | Jun 25, 2012 17:09 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Jun 25, 2012 17:09 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | The overhaul is done. Maybe it's worth to think about moving some stuff from the website to the user wiki. But that'll be another task. |
# Description
We discussed on the last meeting to give the web page an overhaul. A possible strategy is suggested here:
http://users.dune-project.org/projects/main-wiki/wiki/Dune_Homepage_Revamp
I would like to call a vote, to make sure that the general strategy outlined above is agreed upon. I am talking about the structure of the page not the design picture - let us leave that for latter...
I am in favor.
https://gitlab.dune-project.org/flyspray/FS/-/issues/2FS#2 Common code-formatting2016-09-30T14:49:57ZFlyspray ImporterFS#2 Common code-formatting# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Thimo Neubauer (thimo@macht.org) |
| Reported at | Aug 24, 2005 20:21 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System ...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Thimo Neubauer (thimo@macht.org) |
| Reported at | Aug 24, 2005 20:21 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
All of our editors use a different formatting which both makes changing a file in the style of the initial author and checking in minimal diffs complicated.
We're searching for a system which
a) runs on a large variety of systems
b) knows how to format C++ (this is where indent fails)
c) can be parametrized to our liking
https://gitlab.dune-project.org/flyspray/FS/-/issues/448FS#448 Naming scheme2016-10-06T11:29:25ZJö Fahlkejorrit@jorrit.deFS#448 Naming scheme# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Oct 28, 2008 11:45 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Un...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Oct 28, 2008 11:45 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Should the naming scheme be made STL compatible?
See http://lists.dune-project.org/pipermail/dune/2008-October/003696.html
https://gitlab.dune-project.org/flyspray/FS/-/issues/469FS#469 interface for periodic grids2015-11-18T16:17:41ZAndreas DednerFS#469 interface for periodic grids# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Nov 24, 2008 12:47 |
| Type | Unknown |
| Version | Git (pre2.4) [autotools] |
| Operating S...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Nov 24, 2008 12:47 |
| Type | Unknown |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
In the attached files two relevant cases (CASE 1,CASE 2 in the following)
from application are described where periodic grids are used.
So far there are two suggestions for implementing periodic grids:
1. use of ghost cells and communication
2. use of periodic `GridView`s (periodic index sets and intersections)
The `GridView` can always be implemented (we think) if the communication
method is available. For CASE 1 this is the simpler approach and it would
be a good idea to additionally provide a `PeriodicGridView`.
As far as we can see CASE 2 can not be realized using `PeriodicGridView`s
but with the communication method available in DUNE it is also
not clear how to implement this setting since the transformation from
one boundary to the other is required.
## Suggestion:
the method `scatter` should be extended:
```c++
template< class Buffer, class Entity, class Transformation >
void scatter ( Buffer &buffer,
const Entity &entity,
const Transformation &transformation,
size_t n );
```
This transformation should map a neighborhood of
the sending boundary to the receiving boundary and
implement the Jacobian (or Jacobian inverse transpose)
for the transformation of vector field. In the case of a simple
periodic topology transformation=identity and could be
implemented in a way that the compiler can remove any call to
the transformation (template argument).
---------------------------------------------------
Here are a few questions which should be answered by the DUNE
documentation — some of them are but a discussion over the last
few months show that a lot is still not clear):
* (1) equality of entity pointers (notation taken from periodic.eps)
e=e_g? f=f_g?
f'=f_g? f'=f?
* (2) id/index sets (same question as in (1))
* (3) intersection iterators:
* on e' should e or e_g be returned (different geometry)?
* on e' should boundary and neighbor be true or should this depend on the
grid view used?
* If a transformed geometry is used, should e_g allow an intersection
iterator to its neighbor (ghost or overlap behavior?)
# Attachments
* [periodic](/uploads/7e4286c266bcfbae43b673fc64b2e928/periodic)
* [periodic.eps](/uploads/95dcc1a02a27b9c24e073cfa05bc1466/periodic.eps)
https://gitlab.dune-project.org/flyspray/FS/-/issues/723FS#723 method order on basis2015-11-20T11:57:16ZAndreas DednerFS#723 method order on basis# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Jan 24, 2010 19:41 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operatin...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Jan 24, 2010 19:41 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Jul 9, 2012 20:27 |
# Description
What is the exact semantics of `order()`?
We would suggest to have two methods:
```
k=interpolationOrder(): P_k subset span<b_i>
K=maxOrder(): span<b_i> subset P_K
Example: RT_0 would have k=0, K=1
Q_p would have k=p, K=2p
P_p would have k=K=p
```
Note that the `maxOrder` is only meaningful for polynomial
basis functions (e.g. a sin/cos basis would have to have
k=0, K=infinity).
A third value which might be even more practical, is a bit
difficult to define and has something to do with the required
quadrature order. Assuming e.g. that a tensor product
quadrature is used on cubes then the quadrature order for
Q_p would be p=interpolationOrder();
but for RT_0 on simplex elements we need order 1=maxOrder().
Of course maxOrder always works but in the case of Q_p it
is much to large.
At the moment the order seems not consistently implemented:
```c++
Q1LocalBasis::order returns 1 (interpolation order)
RT0LocalBasis::order returns 1 (max order)
```
Our basis function return the ''quadrature order''.
https://gitlab.dune-project.org/flyspray/FS/-/issues/773FS#773 mesh readers and grid factory2015-12-14T14:39:36ZMartin NolteFS#773 mesh readers and grid factory# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Apr 14, 2010 11:22 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Op...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Apr 14, 2010 11:22 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Last edited at | Jun 21, 2012 09:54 |
# Description
Carsten (on the mailing list):
as decides on the last meeting the boundary segment index is
'the standard' way to attach data to parts of the boundary.
Since one can not attach the segment index by hand one needs
to know the insertion order and must then iterate over the
boundary and use boundarySegmentIndex() and insertionIndex()
in order to translate these indices.
In view of this one will in general need the factory.
Is there any way to obtain the factory from the mesh
readers (AmiraMeshReader/DGFParser)?
As the grid factory provides some information on the
grid that can not be obtained otherwise it would IMO
be natural to return a factory and let the user call
createGrid() instead of directly returning it.
https://gitlab.dune-project.org/flyspray/FS/-/issues/848FS#848 add index method to GeometryType2012-03-20T18:08:28ZAndreas DednerFS#848 add index method to GeometryType
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Dec 1, 2010 21:12 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Dec 1, 2010 21:12 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Mar 20, 2012 18:08 |
| Closed by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Closed at | Mar 20, 2012 18:08 |
| Closed in version | 2.2 |
| Resolution | Implemented |
| Comment | Judging from the comments this feature is implemented to everybodies liking. |
# Description
Here two suggestions for GeometryType - the first one is the central one:
A) To avoid some of the problems caused by the fact that each Topology is represented by two topologIds (due to the lowest bit) I suggest to add the following to the GeometryType:
size_t index() const { return (topologyId_ >> 1); }
size_t size() const { return (1 << (dim_-1)); }
static size_t size(int dim) { return (1 << (dim_-1)); }
This makes it easier to use the topologyId for vector storage
because one otherwise has to do the shift oneself or use twice as much storage and then runs into difficulties because each type uses two different sentries in the vector.
Furthermore it simplifies the rest of the GeometryType implementation, e.g.
bool operator==(...) { return other.dim_==dim_ &&
other.index()==index(); }
B) there are at least 7 ways to construct a 1d line:
1) GeometryType(1) (id=0)
2) GeometryType(1u) (id=0)
3) GeometryType(0,1) (id=0)
4) GeometryType(1,1) (id=1)
5) GeometryType(Simplex<Point>) (id=0)
6) GeometryType(Cube<Point>) (id=1)
7) makeLine (id=0)
Do we need the first two? (3) and (4) seem just as good...
They are used in onedgrid but apparently nowhere else in dune-grid at least.
and for consistency makeLine(int id=0) seems to make sense...
https://gitlab.dune-project.org/flyspray/FS/-/issues/959FS#959 Separate grid and geometry parts from (Basic-/Generic-)Geometry2014-06-24T14:20:32ZChristoph GrüningerFS#959 Separate grid and geometry parts from (Basic-/Generic-)Geometry
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 12, 2011 10:16 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Opera...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 12, 2011 10:16 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Last edited at | Jun 24, 2014 14:20 |
| Closed by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Closed at | Jun 24, 2014 14:20 |
| Closed in version | 3.0 |
| Resolution | Implemented |
| Comment | |
# Description
Currently I try to separate all geometry related stuff from common and grid in order to put them in a new dune-geometry modul. See FS#604 for more details.
I stumbled over grid/common/geometry.hh, grid/genericgeometry/geometry.hh and some classes using them. They provide geometry-related functions but need a grid as a template parameter. It would be nice if we could rewrite some of these functions as Martin Nolte mentioned in FS#957.
Some thoughts? Does anybody volunteer to do that in the near future?
https://gitlab.dune-project.org/flyspray/FS/-/issues/969FS#969 template lists of Grid interface classes are to restrictive.2015-12-14T14:30:58ZRobert KFS#969 template lists of Grid interface classes are to restrictive.# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Oct 31, 2011 08:47 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | U...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Oct 31, 2011 08:47 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
The template lists of the interface classes in dune-grid require implementations to have a specific template list. This is often a drawback when implementing new grids.
Martin and I would like to discuss new template lists for the interface classes, such as Entity, Geometry etc. that only
consists of codim, dimension, and one Traits class containing all the necessary information.
Example:
Current template list is
```c++
template<int cd, int dim, class GridImp, template<int,int,class> class EntityImp>
class Entity
```
We suggest that the template list should be:
```c++
template <int cd, int dim, class Traits>
class Entity;
```
This gives much more freedom for implementing new grids and maybe other things.
https://gitlab.dune-project.org/flyspray/FS/-/issues/970FS#970 Unify typedefs -- XyzType vs. Xyz2015-11-19T11:41:05ZChristian EngwerFS#970 Unify typedefs -- XyzType vs. Xyz# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Nov 6, 2011 10:29 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Nov 6, 2011 10:29 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | May 13, 2012 18:14 |
# Description
Most of the typedefs are something like
```
typedef GV GridView;
```
but some are
```
typedef GV GridViewType;
```
This comes as a surprise to many users, and even experienced users get confused quite often. We should clean this up. I suggest to go through the core modules and rename ([a-zA-Z]+)Type typedefs to 1.
Christian
https://gitlab.dune-project.org/flyspray/FS/-/issues/974FS#974 StructureGrid<Grid<2,3>> in vertexordertest.cc2020-02-13T12:30:21ZAndreas DednerFS#974 StructureGrid<Grid<2,3>> in vertexordertest.cc# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Nov 8, 2011 21:02 |
| Type | Bug Report |
| Version | 2.0 |
| Operating System | Unspecified...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Nov 8, 2011 21:02 |
| Type | Bug Report |
| Version | 2.0 |
| Operating System | Unspecified / All |
# Description
in dune/grid/utility/test/vertexordertest.cc
there is a test for the surface version of alugrid
which does not work.
The problem is the usage of the StructuredGridFactory.
We have in vertexorder.hh:
```c++
246 static const std::size_t dim = Grid::dimension;
247 typedef typename Grid::ctype DF;
248 typedef Dune::FieldVector<DF, dim> Domain;
250 Dune::array<unsigned, dim> elements;
251 std::fill(elements.begin(), elements.end(), 4);
253 Dune::shared_ptr<Grid> gridp = Dune::StructuredGridFactory<Grid>::
254 createSimplexGrid(Domain(0), Domain(1), elements);
```
while in structuregridfactory.hh:
```c++
198 static shared_ptr<GridType> createSimplexGrid(const FieldVector<ctype,dimworld>& lowerLeft,
199 const FieldVector<ctype,dimworld>& upperRight,
200 const array<unsigned int,dim>& elements)
```
but then again in a method used by structuregridfactory.hh:
```c++
83 static void insertVertices(GridFactory<GridType>& factory,
84 const FieldVector<ctype,dim>& lowerLeft,
85 const FieldVector<ctype,dim>& upperRight,
86 const array<unsigned int,dim>& vertices)
```
What is wanted?
* A: pass `FV<dimension>` to the create method (and all vertices are zero in the remaining components).
* B: pass `FV<dimworld>` to the create method (which 'plane' through lower,upper to take?)
I guess A is right and the create method has the wrong signature?
https://gitlab.dune-project.org/flyspray/FS/-/issues/984FS#984 Speeding up configure2012-03-11T10:23:19ZChristoph GrüningerFS#984 Speeding up configure
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 2, 2011 22:47 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operat...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 2, 2011 22:47 |
| 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 | Mar 11, 2012 10:23 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Mar 11, 2012 10:23 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | Documented in a newly created section in buildsystem-howto.
Added in recent changes on the homepage. |
# Description
I am annoyed by Dune's sluggish build process. I hoped CMake might speed up the autogen and configure part.
Lately Robert pointed [0] to autotool's configure cache [1]. I tried it and for
dunecontontrol --opts=... --module=dune-pdelab configure
it took 49 seconds without and 29 seconds with caching. I deleted the cache before the run and it was created by the first occurrence of a test. For my working configuration with dune-multidomain and dumux-devel I expect an ever higher benefit.
Because I would not like to waste 20 s a gazillion of times, I want to include caching in dunecontrol similar to the resume function. For every configure I would delete the old cache and use the cache only for successive dune modules in the same configure run.
Libraries like dunecommon are currently not cached because we use our own test DUNE_* instead of AC_CHECK_LIB / AC_SEARCH_LIBS. The latter has built-in caching [2] but I think we can include this in most of our own macros.
I will investigate this further and create patches in a not too remote future.
But I'm afraid of Donald Knuth statement:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"
[0] http://lists.dune-project.org/pipermail/dune/2011-November/009736.html
[1] http://www.gnu.org/s/hello/manual/autoconf/Caching-Results.html
[2] http://www.gnu.org/s/hello/manual/autoconf/Libraries.html
https://gitlab.dune-project.org/flyspray/FS/-/issues/989FS#989 Use C++11 instead of C++0X2014-06-21T18:11:24ZChristoph GrüningerFS#989 Use C++11 instead of C++0X
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 7, 2011 13:18 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operat...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 7, 2011 13:18 |
| 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 | Jun 21, 2014 18:11 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Jun 21, 2014 18:11 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment | |
# Description
We need to change from the outdated working title "C++0X" to the name of the current standard "C++11" [0,1]. This does not only apply to documentation. For example in dune-common/m4 several files are called cxx0x_* and one Test is called CXX0X.
It'll get tricky with the release of GCC 4.7 because they will change the compiler option from -std=c++0x to std=c++11 [2]. The C++11 support in GCC 4.7 will not be backwards compatible with the C++0X support in the already released GCCs [3].
Does someone know about other compilers like LLVM/clang or ICC? Are there Dune users using GCC 4.7 trunk?
[0] http://lists.dune-project.org/pipermail/dune/2011-August/009055.html
[1] http://en.wikipedia.org/wiki/C%2B%2B11
[2] http://gcc.gnu.org/projects/cxx0x.html
[3] http://gcc.gnu.org/ml/gcc/2011-12/msg00069.html
https://gitlab.dune-project.org/flyspray/FS/-/issues/1017FS#1017 New dunedesign for the homepage2012-03-14T06:34:56ZChristoph GrüningerFS#1017 New dunedesign for the homepage
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jan 15, 2012 19:25 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Opera...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jan 15, 2012 19:25 |
| 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 | Mar 14, 2012 06:34 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Mar 14, 2012 06:34 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | in dune-web r959/r960 |
# Description
After many things for the homepage were done in FS#985, I want to resume our discussion about the dunedesign image for Dune homepage. We had this topic in June 2011 with proposials from Felix, Andreas, Markus/Jö and me. I tried to respect the requests and included many different ideas.
Feel free to comment. Request for modification are welcome, I'll try to realize them for a better judgment.
# Attachments
* ![dunedesign_a1](/uploads/8d11444139cd9b548579eb9698c32955/dunedesign_a1.png)
* ![dunedesign_b1](/uploads/684d36097f813f7083c95c90ae39c48a/dunedesign_b1.png)
* [dunedesign_a1.svg](/uploads/b15d41939fe5b91b55544f416a8e6ac3/dunedesign_a1.svg)
* [dunedesign_b1.svg](/uploads/ac3f70d1847a6fc4a0d65a8c8fd48a8a/dunedesign_b1.svg)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1030FS#1030 Bounds checking2016-10-11T10:34:48ZElias PippingFS#1030 Bounds checking# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Elias Pipping (elias.pipping@fu-berlin.de) |
| Reported at | Jan 23, 2012 21:12 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operati...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Elias Pipping (elias.pipping@fu-berlin.de) |
| Reported at | Jan 23, 2012 21:12 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Transforming a mail I sent to the list, namely
http://lists.dune-project.org/pipermail/dune/2012-January/010085.html
into a bug so that the discussion can take place here.
Here's the original mail:
=========================
Hi,
I'd like to talk about classes like
* FieldVector from dune/common/fvector.hh,
* FieldMatrix from dune/common/fmatrix.hh
* DiagonalMatrix from dune/istl/diagonalmatrix.hh
and the likes for a bit.
My understanding -- until I investigated a bit -- was that those classes do not perform any bounds checking by default and that defines like `DUNE_FMatrix_WITH_CHECKING` and `DUNE_ISTL_WITH_CHECKING` were there just for that(*).
Apparently, it's not that easy. And the fact that some classes contain specialisations for the case where they only store a single element from the underlying approximation of a field (e.g. double) is adding to the mess.
Here's a sample program.
```c++
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <dune/common/fmatrix.hh>
#include <dune/istl/diagonalmatrix.hh>
int
main()
{
Dune::FieldVector<double,1> vec1;
vec1[0] = 0;
vec1[100] = 29;
Dune::FieldVector<double,3> vec3;
vec3[2] = 0;
vec3[100] = 29;
Dune::FieldMatrix<double,1,1> mat1;
mat1[0][0] = 0;
mat1[100][100] = 29;
Dune::FieldMatrix<double,3,3> mat3;
mat3[2][2] = 0;
mat3[100][100] = 29;
Dune::DiagonalMatrix<double, 1> diag1;
diag1[0] = 0;
diag1[100] = 29;
diag1.diagonal(0) = 0;
diag1.diagonal(100) = 29;
Dune::DiagonalMatrix<double, 3> diag3;
diag3[2] = 0;
diag3[100] = 29;
diag3.diagonal(2) = 0;
diag3.diagonal(100) = 29;
return 0;
}
```
The pattern is simple: For each of the aforementioned (three) classes, two objects are created -- once in three dimensions and once in 1D (to catch specialised implementations). Each construction is followed by one or multiple pairs of valid (`=0`) and invalid (`=29`) assignments (in that order);
All in all, there are eight invalid assignments in the above; which will be caught by default (ideal situation: none because bounds checking adds overhead) and how many are caught if both of the aforementioned defines are set? The current status appears to be:
* 4/8 always fail
* the aforementioned defines do not affect that number
Here is the body of the above program again, with annotations:
```c++
Dune::FieldVector<double,1> vec1;
vec1[0] = 0;
//vec1[100] = 29; // fails an assertion (fvector.hh:242)
Dune::FieldVector<double,3> vec3;
vec3[2] = 0;
vec3[100] = 29;
Dune::FieldMatrix<double,1,1> mat1;
mat1[0][0] = 0;
//mat1[100][100] = 29; // fails an assertion (fmatrix.hh:279)
Dune::FieldMatrix<double,3,3> mat3;
mat3[2][2] = 0;
//mat3[100][100] = 29; // fails an assertion (fmatrix.hh:177)
Dune::DiagonalMatrix<double, 1> diag1;
diag1[0] = 0;
//diag1[100] = 29; // fails an assertion (fmatrix.hh:279)
diag1.diagonal(0) = 0;
diag1.diagonal(100) = 29;
Dune::DiagonalMatrix<double, 3> diag3;
diag3[2] = 0;
diag3[100] = 29;
diag3.diagonal(2) = 0;
diag3.diagonal(100) = 29;
```
I've attached two patches (one to dune-common and one to dune-istl) that handle the other four cases with assertions that are guarded by
`DUNE_FMatrix_WITH_CHECKING`; whether that is the correct define is
questionable.
Whether the four cases whose assertions are not guarded by any defines (other than the absence of `NDEBUG`, naturally) should stay that way might be worth discussing as well.
For the discussion that led me to this investigation, see FS#1020.
Best regards,
Elias Pipping
(*) The latter is actually used in dune-common even if the name might
suggest otherwise; The former can e.g. be found in
`ScaledIdentityMatrix::mv()` from dune-istl, too;
https://gitlab.dune-project.org/flyspray/FS/-/issues/1106FS#1106 Revision of the parallel interface in dune-grid.2015-11-19T11:37:39ZRobert KFS#1106 Revision of the parallel interface in dune-grid.# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | May 14, 2012 15:26 |
| Type | Bug Report |
| Version | 2.0 |
| Operating System | Unspecified / All |
|...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | May 14, 2012 15:26 |
| Type | Bug Report |
| Version | 2.0 |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Jul 10, 2012 18:46 |
# Description
In the current implementation of the parallel interface in dune-grid there are several things missing:
1. Communication of data through Intersections. The current interface would not allow parallel grids with non-conforming refinement without ghost cells or overlap. However, is is required for efficient implementation of DG methods on super computers with a large number of cores and only a few number of cells per core.
2. Non-blocking communication or even asynchronous communication is currently not possible with communication methods on the Grid class.
Please add further things missing such that we obtain a list of possible improvements for the next meeting.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1140FS#1140 unify C++ type for dimension quantities2015-11-20T11:06:57ZMartin NolteFS#1140 unify C++ type for dimension quantities# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jun 24, 2012 05:35 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Op...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jun 24, 2012 05:35 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Within the core modules, dimensions are sometimes specified as int and sometimes as unsigned int (sometimes even as an enum). Examples include:
In class `Dune::Grid`:
```
enum { dimension = dim };
int size ( int codim ) const;
```
In class `Dune::IndexSet`:
```
IndexType subIndex ( const Entity &e, int i, unsigned int codim ) const
```
In the generic geometry code, `unsigned int` is used, while for historical reasons the `int` in `GenericReferenceElement` was kept.
I think this confuses users, leads to unnecessary signed / unsigned comparison warnings (in user code). Especially with template arguments, some compilers seem no to promote int to unsigned int correctly, when it comes to specialization.
In my opinion, we should decide on "the" correct type for dimensional quantities and stick to it throughout the interfaces.
PS: This might resolve FS#1135 for free.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1169FS#1169 constructing the geometrytype from the number of vertices2012-10-07T13:13:47ZChristian EngwerFS#1169 constructing the geometrytype from the number of vertices
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Aug 13, 2012 08:37 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Op...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Aug 13, 2012 08:37 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Oct 7, 2012 13:13 |
| Closed by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Closed at | Oct 7, 2012 13:13 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | |
# Description
The GeometryType can be constructed in various ways. One way which is need quite often (at least I do so), but is not part of the type code is the construction of the GeometryType for a given dimension and number of vertices.
Instead of copying the code again and again, I'd like to move this code to the GeometryType as a method
void makeFormVertices(unsigned int dim, unsigned int vertices)
This is first part. If nobody objects, I'd move this code during the next days.
One problem I stumbled upon when trying to change the code to support other dimensions than 0-3, is that from dim=5 on the TopologyId is not unique. I can find different TopologyIds to define an object with the same number of vertices. I'm not sure about the implications, but at a first glance it seems this will also lead to different ReferenceElements for the same object. Perhaps this is problem, perhaps not.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1181FS#1181 Naming in dune-geometry: Geometry vs. Mapping2012-10-25T19:24:09ZMartin NolteFS#1181 Naming in dune-geometry: Geometry vs. Mapping
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Sep 24, 2012 07:24 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Sep 24, 2012 07:24 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / All |
| Last edited by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Last edited at | Oct 25, 2012 19:24 |
| Closed by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Closed at | Oct 25, 2012 19:24 |
| Closed in version | Unknown |
| Resolution | Works for me |
| Comment | For me, we have a decision. Please reopen if further discussion is in order. |
# Description
Given FS#1180, I think the time has come to agree on a name for geometric mappings provided by dune-geometry.
The GenericGeometry stuff uses the name mapping for everything that is not inteded to be a dune-grid Geometry, i.e., for everything that should go into dune-geometry. FS#1180 suggests the name Geometry for such a mapping.
Once the naming is clarified, an interface class should be added to dune-geometry. This could be either Geometry, migrated from dune-grid, Mapping, or GeometricMapping.
After the naming has been clarified, we should also rename the method mapping on the reference elements accordingly.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1186FS#1186 DynMatrixHelper?2012-11-21T16:20:15ZFlyspray ImporterFS#1186 DynMatrixHelper?
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Arne Morten Kvarving (arne.morten.kvarving@sintef.no) |
| Reported at | Oct 3, 2012 16:09 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspec...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Arne Morten Kvarving (arne.morten.kvarving@sintef.no) |
| Reported at | Oct 3, 2012 16:09 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / All |
| Last edited by | Markus Blatt (markus@dr-blatt.de) |
| Last edited at | Nov 21, 2012 16:20 |
| Closed by | Markus Blatt (markus@dr-blatt.de) |
| Closed at | Nov 21, 2012 16:20 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | in rev, 7061 |
# Description
Hi,
I have had the need for eigenvalues of matrices, and the available utils are a bit lacking.
i have written some code structured on fmatrixev.[hh/cpp] and now i would like to contribute this back to the project.
since i don't know how you want the shed painted, i ask how and if before i waste time painting it up.
sources attached for reference. there is two sets of files; dynmatrixev.hh/cpp does complex eigenvalues for non-symmetric dynamic matrices, while fmatrixev_ext.hh/cc implements the same for fmatrices. of course lapack is used to do the heavy lifting.
please advice (whether it's wanted, and if so how to do it).
if this goes in, i can also contribute (basic but fully working) code to calculate gauss-lobatto-legendre quadratures if this is of interest (this is what i needed it for). currently dune needs alglib to do this, and alglib is marked as deprecated.
# Attachments
* [files.tar.gz](/uploads/0fb6dfd9cc6b7104eef1b8eec4e9b0db/files.tar.gz)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1194FS#1194 Allow Different Return Types for Entity::geometry and Intersection::g...2015-11-17T15:34:20ZMartin NolteFS#1194 Allow Different Return Types for Entity::geometry and Intersection::geometry# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 15, 2012 09:07 |
| Type | Feature Request |
| Version | 2.2 |
| Operating System |...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 15, 2012 09:07 |
| Type | Feature Request |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
Currently, the interface requires `Entity::geometry and Intersection::geometry` to return objects of the same type (`GridFamily::Traits::Codim< 1 >::Geometry`).
Unfortunately, intersection geometries can be far more complicated than face geometries.
Examples:
* (a) A hexahedral grid can only have quadrilateral faces, but intersections might be triangular (=> cannot optimize of the geometry type anymore)
* (b) A meta grid might want glue together grids of the same type. All entity geometries can be inherited from the host grid; the intersection geometries, however, need to exchanged.
The natural solution to me seems to split up the types. This could be resolved in two ways:
* (1) introduce a type `Codim<cd>::EntityGeometry` and an `IntersectionGeometry` on the grid view.
* (2) let the entity / intersection decide upon the type for `Geometry` (i.e., don't export it in the traits class).
Version (1) is in line with exporting all types in a central place, while version (2) is more modular. In my opinion (2) is more DUNE-like as we promote modularity. In both cases, I would suggest to deprecate the type `Codim<cd>::Geometry`.
What's the opinion of the others?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1204FS#1204 Make Implementations Non-Template Template Arguments of Intersection ...2013-01-10T15:18:23ZMartin NolteFS#1204 Make Implementations Non-Template Template Arguments of Intersection and IntersectionIterator
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 25, 2012 19:10 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 25, 2012 19:10 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / All |
| Last edited by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Last edited at | Jan 10, 2013 15:18 |
| Closed by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Closed at | Jan 10, 2013 15:18 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | |
# Description
I had hoped to write only one native grid view for GeometryGrid, templatized directly with the grid and the host grid view.
Unfortunately, this turned out impossible. One reason for this are the template argument lists of the Intersection / IntersectionIterator facades. They look as follows:
template<class GridImp, template<class> class IntersectionImp>
class Intersection;
template<class GridImp, template<class> class IntersectionIteratorImp, template<class> class IntersectionImp>
class IntersectionIterator;
So, the intersection has to find out what host intersection to use based solely on the type of grid - impossible. A simple way out of this misery is a slight change to the template argument list of these facades:
template<class GridImp, class IntersectionImp>
class Intersection;
template<class GridImp, class IntersectionIteratorImp, class IntersectionImp>
class IntersectionIterator;
This change would be in line with the template argument list of the EntityIterator. Moreover, it simplifies grid code and has (nearly) no impact on user code (unless they write their own grid or directly use the facade, e.g, to distinguish between an entity and an intersection). Notice that proper deprecation is not possible in this case.
Before coding anything in this direction, I would like the opionion of my fellow-developers on such a change.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1205FS#1205 Remove template argument pitype from GridView2016-01-22T16:43:52ZMartin NolteFS#1205 Remove template argument pitype from GridView
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 25, 2012 19:17 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 25, 2012 19:17 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
The extra template argument pitype of a GridView, specifying the default iterator of this view, seems to be rarely used (if at all). Since some grids now provide native grid views (e.g., Geometry), it causes an extra maintenance effort. Do we really still want this template argument or is it a relic from the original introduction of the GridView?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1213FS#1213 Change naming scheme for RT and BDM elements2012-12-27T11:12:39ZChristoph GrüningerFS#1213 Change naming scheme for RT and BDM elements
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 3, 2012 10:28 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operat...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 3, 2012 10:28 |
| 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 | Dec 27, 2012 11:12 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Dec 27, 2012 11:12 |
| Closed in version | 2.3 |
| Resolution | Implemented |
| Comment | In r1155.
Now are all names changes, convenience headers created, test moved, old headers deprecated. |
# Description
The current naming scheme for Raviart-Thomas elements is for simplices
raviartthomasMNd
and for cubes
raviartthomasMqNd
with M the order and N the dimension. The BDM elements follow this scheme.
I find the naming confusing and propose a change. I propose the change to
raviartthomasMsimplexNd
raviartthomasMquadNd
but would welcome more appropriate proposals.
BTW: I want to write a convenience header for RT and BDM that automatically picks the correct implementation, like other local elements have.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1214FS#1214 Avoid identifier "restrict"2012-12-05T09:40:08ZChristoph GrüningerFS#1214 Avoid identifier "restrict"
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 4, 2012 07:57 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operat...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Dec 4, 2012 07:57 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Markus Blatt (markus@dr-blatt.de) |
| Last edited at | Dec 5, 2012 09:40 |
| Closed by | Markus Blatt (markus@dr-blatt.de) |
| Closed at | Dec 5, 2012 09:40 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | In rev. 1738.
Appended Vector to the names and skipped deprecation. |
# Description
In the C99 standard "restrict" is defined as a keyword. At least the Cray C++ compiler does not accept functions named restrict, even if it is not a C++ keyword.
I found methods called restrict in these files:
dune-istl/dune/istl/paamg/amg.hh
dune-istl/dune/istl/paamg/transfer.hh
dune-istl/dune/istl/paamg/test/transfertest.cc
Can we rename (copy, rename, and deprecate) these? What would be a good name?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1236FS#1236 Evaluating continuous integration frameworks2016-09-02T08:15:10ZMarkus BlattFS#1236 Evaluating continuous integration frameworks
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Jan 22, 2013 12:13 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / All |
| Las...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Jan 22, 2013 12:13 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / All |
| Last edited by | Markus Blatt (markus@dr-blatt.de) |
| Last edited at | Jan 22, 2013 12:14 |
# Description
In the course of testing the bug-fix release 2.2.1, I have been looking at serveral continuous integration frameworks to maybe substitute our home-grown automatic tests.
Constraints
- written in a secure language, i.e. not Java/PHP
- support for build slave on different architectures
- support for at least Git and Subversion
- support for database backend
- support for automake and CMake
- (Add more if you want)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1277FS#1277 Reference Element Mappings / Geometries2018-06-26T13:37:26ZMartin NolteFS#1277 Reference Element Mappings / Geometries# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Apr 9, 2013 09:21 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Apr 9, 2013 09:21 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Last edited at | Apr 15, 2013 12:01 |
# Description
The reference element has a non-interface method called mapping. It returns the "geometry" (embedding) of a subentitiy (of a static codimension). It seems to me that this method is silently becoming an interface method.
Therefore, I propose to make it officially an interface method. In my opinion, it should be called "geometry", because the returned object satisfies the geometry interface (it actually is an AffineGeometry). Moreover, I suggest to return this object by value for consistency with dune-grid.
In consequence, the method "global" will become redundant and should be deprecated. It was for the implementation of "global" that the "mapping" was introduced originally.
Any comments, suggestions?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1373FS#1373 Perform (Par)METIS check in dune-grid2015-02-05T12:35:41ZChristoph GrüningerFS#1373 Perform (Par)METIS check in dune-grid
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 8, 2013 06:55 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecif...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 8, 2013 06:55 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Feb 5, 2015 12:35 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Feb 5, 2015 12:35 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment | |
# Description
Ss there a reason that dune-grid does neither check neither the presence of
(Par)METIS nor does it have an example/test using it.
I guess people using (Par)METIS rely on ISTL and ISTL perform the (Par)METIS
m4 test. At least that's the way it works with PDELAB.
This inflicts problems, e.g. FS#1367 and FS#1308.
Does someone object to perform the tests in dune-grid and add at least one
parallel ALUGrid test using ParMETIS?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1375FS#1375 Problems with New Namespace Dune::std2015-01-02T09:55:40ZMartin NolteFS#1375 Problems with New Namespace Dune::std
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 10, 2013 09:19 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Oct 10, 2013 09:19 |
| Type | Discussion |
| Version | 2.2 |
| Operating System | Unspecified / All |
| Last edited by | Markus Blatt (markus@dr-blatt.de) |
| Last edited at | Jan 2, 2015 09:55 |
| Closed by | Markus Blatt (markus@dr-blatt.de) |
| Closed at | Jan 2, 2015 09:55 |
| Closed in version | Unknown |
| Resolution | Deferred |
| Comment | until more problems occur.
Personally, I would have left this open. Closing bugs as fixed just because there was no activity still seems weired. |
# Description
On the developer meeting in Aachen we decided to move all STL-like classes and fallback implementations to the namespace Dune::std. This causes problems with the namespace lookup when using, e.g., std::cout within the namespace Dune.
As an example, I moved Dune::array into the namespace Dune::std in a private branch:
dune-common/p/mnolte/namespace-std
As a result of the presence of the namespace Dune::std, all tests including array.hh do not compile anymore, because no symbol (except for array) in the namespace std (which now resolves to Dune::std) is found by the compiler.
Maybe we should select a different name for the namespace after all. How shall we proceed?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1395FS#1395 Deprecate MPI 1 in Dune 2.3 and state that the next release will requ...2013-12-11T13:39:11ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deFS#1395 Deprecate MPI 1 in Dune 2.3 and state that the next release will require MPI 2.1
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Reported at | Dec 4, 2013 14:26 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| O...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Reported at | Dec 4, 2013 14:26 |
| 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 | Dec 11, 2013 13:39 |
| Closed by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Closed at | Dec 11, 2013 13:39 |
| Closed in version | 2.3 |
| Resolution | Implemented |
| Comment | Decided to go ahead with the deprecation in 2.3 after developer vote and added deprecation warning in dune-common ac6885f8a. |
# Description
Some time ago, I asked around whether there are still any users of an MPI implementation that is not compatible with MPI 2.1 (basically, an MPI that was released before 2009) [1]
I didn't receive any answers at that time, so I propose to state that MPI-1.2 is deprecated in the release notes of Dune 2.3 and that for the next release after 2.3, an implementation compatible with MPI-2.1 will be required.
I am aware that it is already rather late in the release cycle, but I think the user impact would be minimal (all versions of MPICH 2+, MVAPICH 2+ and OpenMPI support MPI-2.1). Getting rid of MPI-1 would take care of some #ifdefs we currently have in the MPIHelper and - more importantly - would allow us to rely on the presence of MPI_Init_thread() and support for checking whether MPI was already initialized / finalized by an external library (important for things like PETSc).
I've added a doodle for the DUNE developers at http://users.dune-project.org/doodles/10
[1] http://lists.dune-project.org/pipermail/dune/2013-October/012496.html
https://gitlab.dune-project.org/flyspray/FS/-/issues/1470FS#1470 Segfault for FieldVector with filedtype = FieldMatrix2016-10-14T08:12:41ZTobias MalkmusFS#1470 Segfault for FieldVector with filedtype = FieldMatrix
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Jun 4, 2014 06:38 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecifi...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Jun 4, 2014 06:38 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
The attached examples causes a segfault with the actual master and gcc 4.8.2.
This bug seems to be related to #1457 since gcc choses
template <typename ValueType>
typename std::enable_if<
std::is_convertible<ValueType, value_type>::value,
derived_type
>::type&
operator+= (const ValueType& kk)
{ ... }
instead of
template <class Other>
derived_type& operator+= (const DenseVector<Other>& y)
{ ... }
I was not abled to figure out why gcc makes this choice.
# Attachments
* [fvectoroffmatrix.cc](/uploads/136fc683dbd950b0191a381a05d765a2/fvectoroffmatrix.cc)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1475FS#1475 Abandon Alberta pre-3.0 support2014-10-22T17:00:42ZChristoph GrüningerFS#1475 Abandon Alberta pre-3.0 support
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jun 29, 2014 08:52 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspeci...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jun 29, 2014 08:52 |
| Type | Discussion |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Oct 22, 2014 17:00 |
| Closed by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Closed at | Oct 22, 2014 17:00 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | Feature branch is merged, pre-3.0 support is gone. |
# Description
As Alberta 3.0.0 is released and will be part of Debian 8 Jessie and is part of openSuse's Science repository, I don't see a need to keep compatibility code for Alberta 2.1 or Alberta 3 release candidates.
I am not sure whether we should deprecate the support first or simply drop it. What do you think?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1498FS#1498 Add Dune::Std::make_unique2014-10-14T13:05:48ZCarsten Gräsergraeser@math.fau.deFS#1498 Add Dune::Std::make_unique
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Sep 26, 2014 22:01 |
| Type | Discussion |
| Version | Git (pre2.4) [autotools] |
| Operating Syst...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Sep 26, 2014 22:01 |
| 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 14, 2014 13:05 |
| Closed by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Closed at | Oct 14, 2014 13:05 |
| Closed in version | 2.4 |
| Resolution | Implemented |
| Comment | Accepted by vote and implemented in a53989d. |
# Description
Since we make more use of unique_ptr now having make_unique would make code more readable. Unfortunately this is not even c++11 but c++14.
I propose to implement it as Dune::Std::make_unique in 2.4 (see attached).
# Attachments
* [0001-std-Implement-Dune-Std-make_unique.patch](/uploads/607e18d67a2d52ff7321e0c6210e3218/0001-std-Implement-Dune-Std-make_unique.patch)
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
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/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/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/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/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/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/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/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/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.