FS issueshttps://gitlab.dune-project.org/flyspray/FS/-/issues2023-09-29T11:06:15Zhttps://gitlab.dune-project.org/flyspray/FS/-/issues/1714FS#1714 Generalize intersection concept for network grids2023-09-29T11:06:15ZOliver Sanderoliver.sander@tu-dresden.deFS#1714 Generalize intersection concept for network grids
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 4, 2015 10:50 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Operating Sys...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 4, 2015 10:50 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
Together with Timo Koch and Natalie Schröder (and a few others), I have recently put some work into FoamGrid, a grid manager for 1d and 2d network grids.
Check it out at users.dune-project.org/projects/dune-foamgrid
As it turns out, the intersection concept in dune-grid is not quite general enough for network grids. Therefore, I request certain generalizations to the dune grid interface to improve working with network grids. On the way, these changes also solve a few issues we have had with dune-grid-glue.
The requested changes are not very invasive, but they are a bit subtle. To ease the discussion, and to make sure we are all talking about the same thing, I have tried to write a semi-formal change request document. This document, which I will attach here, gives the reasons why I want to change the interface, and the requested changes in as much detail as possible (to me). Additionally, it describes one alternative approach to the same problem, which I am not proposing, but which was part of the discussion for a while.
It is quite a long document for a small change. It is open for discussion in all regards. Once we settle on something, the document shall make sure that we all remember the details of what we agreed upon.
# Attachments
* [dicr-multiple-intersections.pdf](/uploads/6ca4d93c76c35c23d11cdd97cfca0c16/dicr-multiple-intersections.pdf)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1709FS#1709 Add test for subentity orientation2023-09-29T11:05:40ZCarsten Gräsergraeser@math.fau.deFS#1709 Add test for subentity orientation# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Aug 19, 2015 13:58 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating S...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Aug 19, 2015 13:58 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
On the developer meeting 2013 we decided that subentities should always have a unique orientation which is in general not consistent with the orientation provided by the reference element embedding.
Checkindexset.hh must be extended to test for this consistency guarantee.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1550FS#1550 Make Geometry default constructible2023-09-29T10:58:56ZMartin NolteFS#1550 Make Geometry default constructible
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jan 9, 2015 10:54 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspeci...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jan 9, 2015 10:54 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
Geometries are now copy constructible and copy assignable objects. However, in some situations it, like storing geometries in a vector indexed by the index set, a default constructor would be extremely convenient.
As a geometry can always model the identity, there seems no design principle speaking against such default constructibility. Only the return value of "type()" needs to be implementation-defined.
Since nobody will use a default constructed geometry, I would even propose to specify undefined behavior for all methods. This way, implementations simply storing a pointer internally remain trivial.
Are there any reasons not to add this default constructor to the interface?
Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/flyspray/FS/-/issues/1615FS#1615 Geometry interface not elaborate enough for hessian computation2023-09-29T10:55:53ZChristian EngwerFS#1615 Geometry interface not elaborate enough for hessian computation
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Apr 14, 2015 09:13 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System |...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Apr 14, 2015 09:13 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
If I want to compute the hessian of a discrete function I have to map from local to global coordinates. In this case I need in addition to the jacobianInverseTranspose the same for second derivatives.
This issues is in the first place a reminder for the interface problem ;-)https://gitlab.dune-project.org/flyspray/FS/-/issues/1285FS#1285 semantic of maxLevel2023-09-29T10:51:16ZAndreas DednerFS#1285 semantic of maxLevel
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Apr 23, 2013 21:05 |
| Type | FAQ |
| Version | 2.2 |
| Operating System | Unspecified / All |
# D...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Apr 23, 2013 21:05 |
| Type | FAQ |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
In a parallel run is the semantics of maxLevel
1) the maxLevel for the local partition?
2) the maxLevel of the grid over all processors?
ALU takes the second view at the moment but I think the first makes more sense and I would like to change ALU's behaviour (no way to make backward compatible...)
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/355FS#355 Introduce variable "category" in Dune::Preconditioner (ISTL)2023-09-28T20:48:10ZFlyspray ImporterFS#355 Introduce variable "category" in Dune::Preconditioner (ISTL)
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Thomas Witkowski (thomas.witkowski@tu-dresden.de) |
| Reported at | Feb 22, 2008 12:13 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Op...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Thomas Witkowski (thomas.witkowski@tu-dresden.de) |
| Reported at | Feb 22, 2008 12:13 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Markus Blatt (markus@dr-blatt.de) |
| Last edited at | Feb 22, 2008 16:57 |
# Description
I would propose to introduce the variable "category" in the virtual class Dune::Preconditioner. Otherwise it is not possible to introduce a general pointer to a preconditioner and to use it later in a call to a solver constructor.
Thomashttps://gitlab.dune-project.org/flyspray/FS/-/issues/1347FS#1347 Move constructor and move assignment operator for dynamic matrices an...2023-09-28T07:16:46ZChristoph GersbacherFS#1347 Move constructor and move assignment operator for dynamic matrices and vectors
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Gersbacher (gersbach@mathematik.uni-freiburg.de) |
| Reported at | Sep 3, 2013 07:37 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | U...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Gersbacher (gersbach@mathematik.uni-freiburg.de) |
| Reported at | Sep 3, 2013 07:37 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
Hi,
the dense Dune::DynamicVector and Dune::DynamicMatrix are built on std::vector. They would thus heavily benefit from the new move semantics. We already have a HAVE_RVALUE_REFERENCES preprocessor macro which is used e.g., in dune/common/mallocallocator.hh.
The patch attached adds move constructors and move assignment operators to these classes inside #if HAVE_RVALUE_REFERENCES. I added the usual assignment operators as well (assignment has been implemented through the DenseMatrix/Vector interfaces up to now).
# Attachments
* [dynamic_matrix_vector_move_semantics.patch](/uploads/eedd837ac7c2e373d5bc23d689789e4f/dynamic_matrix_vector_move_semantics.patch)Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/flyspray/FS/-/issues/1713FS#1713 CMake: @GRID_CONFIG_H_BOTTOM@ not at bottom of generated config.h.cmake2023-06-12T09:50:01ZMartin NolteFS#1713 CMake: @GRID_CONFIG_H_BOTTOM@ not at bottom of generated config.h.cmake# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Sep 3, 2015 08:54 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operati...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Sep 3, 2015 08:54 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
The "grid type magic for DGF parser" differs between CMake and the autotools. The autotools attached the grid type definitions at the bottom of config.h, while CMake adds it at the end of the dune-grid section (see config.h.cmake in dune-grid).
This has a subtle effect on SPGrid: Using the "grid type magic" with SPGrid causes the grid to be included before the definition of the dune-spgrid version macros. But these macros are used within SPGrid to tag the backup/restore file format. After the inclusion of the SPGrid headers, the version macros will be used before they are defined.
https://gitlab.dune-project.org/flyspray/FS/-/issues/412FS#412 Capability for Communicatable Codimensions2022-11-02T19:11:26ZMartin NolteFS#412 Capability for Communicatable Codimensions
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jul 2, 2008 06:42 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Opera...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jul 2, 2008 06:42 |
| 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 | Jan 17, 2010 19:20 |
| Closed by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Closed at | Jan 17, 2010 19:20 |
| Closed in version | Unknown |
| Resolution | Implemented |
| Comment | In revision 6159 |
# Description
A Parallel Grid is not required to be able to communicate all codimensions. An example would be YASPGrid, which can only communicate codimensions 0 and dim (because the entities are missing). There might be other grids only capable of communicating codimension 0 despite having entities for all codimensions.
For many numerical schemes like DG, FV or 1st order FEM it is totally sufficient to be able to communicate one codimension (here 0 respectively dimension).
My suggestion is to add a new capability (e.g., CanCommunicate< Grid, codim >), telling the user which codimensions can be communicated by the grid. Of course, one might add the redundant flag CanCommunicateAll for convenience (it is a few lines for codes using arbitrary dimension)
https://gitlab.dune-project.org/flyspray/FS/-/issues/533FS#533 GenericReferenceElements are buggy2022-08-20T20:54:27ZCarsten Gräsergraeser@math.fau.deFS#533 GenericReferenceElements are buggy
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Apr 7, 2009 12:16 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating Syste...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Apr 7, 2009 12:16 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Last edited at | May 7, 2009 10:57 |
| Closed by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Closed at | May 7, 2009 10:57 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment | Christian fully implemented the singleton pattern. |
# Description
The singelton GenericReferenceElements::general seems not to be defined anywhere.
https://gitlab.dune-project.org/flyspray/FS/-/issues/587FS#587 ReferenceElements should use unsigned for indices, sizes etc.2021-01-21T22:02:53ZJö Fahlkejorrit@jorrit.deFS#587 ReferenceElements should use unsigned for indices, sizes etc.# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Aug 20, 2009 13:49 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecifie...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Aug 20, 2009 13:49 |
| 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 | Nov 20, 2013 07:31 |
# Description
The ReferenceElements should use an unsigned type such as `unsigned int` or `std::size_t` for things like subentity indices, subentity counts and possibly even codimensions (though that is an `int` in a lot more places than just the `ReferenceElement`s). All these quantities can never be <0. As an alternative, `LocalKey` from dune-localfunctions should change to using an `int` instead of `unsigned int`.https://gitlab.dune-project.org/flyspray/FS/-/issues/1650FS#1650 QuadratureRules sometimes cause runtime error on Ubuntu 14.04 2020-09-22T22:20:53ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deFS#1650 QuadratureRules sometimes cause runtime error on Ubuntu 14.04
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Reported at | May 12, 2015 13:10 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Oper...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Steffen Müthing (steffen.muething@iwr.uni-heidelberg.de) |
| Reported at | May 12, 2015 13:10 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating System | Linux |
| Last edited by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Last edited at | Jun 12, 2015 22:56 |
| Closed by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Closed at | Jun 12, 2015 22:56 |
| Closed in version | 2.4 |
| Resolution | Fixed |
| Comment | Fixed in master.
Fix was cherry-picked to releases/2.4. |
# Description
When using the QuadratureRules from dune-geometry without using any other feature that requires a symbol from libdunegeometry, the resulting program aborts on Ubuntu 14.04 with an error message because the call_once assertion has detected a system exception. After some fun investigation by Dominic and me, it turns out that the -Wl,-as-needed "feature" of Ubuntu (as described by Ansgar in https://dune-project.org/flyspray/index.php?do=details&task_id=1611#comment6249) causes this problem. I think it comes up because the guard variable introduced by the call_once() call in the assertion inside libdunecommon is private to that library, and because of that, the linker doesn't find a dependency of the program on libpthread if there are no other places requiring libpthread and doesn't link the executable against pthread even though -pthread was specified on the command line.
This is *really* ugly, because users will be totally lost. And as Ubuntu 14.04 is not exactly an exotic distribution, this *will* bite some users.
I suggest brute-forcing this and checking whether we are on Ubuntu and in that case dropping -Wl,-no-as-needed into the compiler flags.
Are there any better ideas?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1698FS#1698 Improve GmshReader interface2020-03-07T23:19:08ZJö Fahlkejorrit@jorrit.deFS#1698 Improve GmshReader interface# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Jul 19, 2015 10:26 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Jul 19, 2015 10:26 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
The `GmshReader` interface has some really counter-intuitive aspects.
For instance, it allows you to read physical entities, even though you did not specify a grid factory. This makes it impossible to later access the physical entities, since you need the grid factory used for creation of the grid to determine the indices into the vectors of physical entities. Users have run into this a few times, they usually try to index the vector with whatever looks like an index to them (e.g. `IndexSet`, `Map`, the index induced by the iteration order) and wonder why their physical entity numbers are all garbled.
As another example, (e.g. FS#1696): why is it possible to specify `insertBoundarySegments=false` together with a vector to store the boundary physical entities into? You won't be able to access this vector, even if you specified a `gridfactory`, because automatically generated boundary intersections do not have an insertion index.
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/1561FS#1561 transportproblem.hh documented but transportproblem2.hh actually used2020-02-13T08:53:25ZJö Fahlkejorrit@jorrit.deFS#1561 transportproblem.hh documented but transportproblem2.hh actually used# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Feb 5, 2015 11:05 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
#...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Feb 5, 2015 11:05 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
The PDF suggestively documents transportproblem.hh, but never actually uses it in any code. Instead, transportproblem2.hh is used. This will most probably puzzle any readers.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1677FS#1677 Replace VirtualFunction by std::function2020-02-13T08:49:47ZOliver Sanderoliver.sander@tu-dresden.deFS#1677 Replace VirtualFunction by std::function# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Jun 30, 2015 09:19 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Uns...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Jun 30, 2015 09:19 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Last edited at | Jun 30, 2015 09:19 |
# Description
dune-common contains the rarely used class `VirtualFunction`, which serves as an abstract interface to dynamically polymorphic functions. C++11 has brought us `std::function`, which does something similar, but seems much more powerful. Can we drop the former for the latter (by the usual procedure etc)?
https://gitlab.dune-project.org/flyspray/FS/-/issues/1586FS#1586 Documentation of template parameters for class GridFunctionSpace is n...2020-02-13T08:49:38ZOliver Sanderoliver.sander@tu-dresden.deFS#1586 Documentation of template parameters for class GridFunctionSpace is not up-to date# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Mar 9, 2015 10:18 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecifi...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Mar 9, 2015 10:18 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
The class `GridFunctionSpace` has a template parameter
```
typename P=DefaultLeafOrderingTag
```
The corresponding documentation says
```
tparam P Parameter type. Possible types are
* link GridFunctionGeneralMapper endlink (arbitrary number of unknowns per
* entity) or link GridFunctionRestrictedMapper endlink (fixed number of unknowns per
* entity) or link GridFunctionStaticSize endlink (number of unknowns per
* entity, known at compile-time)
```
Apparently code and documentation do not match.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1429FS#1429 Linker fails for external grids with CMake2020-02-12T21:23:52ZChristoph GrüningerFS#1429 Linker fails for external grids with CMake# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Feb 5, 2014 13:52 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
|...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Feb 5, 2014 13:52 |
| 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 | Feb 7, 2014 10:55 |
# Description
With current trunk I get the following error message:
```
[ 77%] Building CXX object lib/CMakeFiles/dunegrid.dir/__/dune/grid/io/file/dgfparser/blocks/projection.cc.o
[ 88%] Building CXX object lib/CMakeFiles/dunegrid.dir/__/dune/grid/io/file/dgfparser/blocks/simplex.cc.o
[ 88%] Building CXX object lib/CMakeFiles/dunegrid.dir/__/dune/grid/io/file/dgfparser/blocks/simplexgeneration.cc.o
[100%] Building CXX object lib/CMakeFiles/dunegrid.dir/__/dune/grid/io/file/dgfparser/blocks/vertex.cc.o
Linking CXX shared library libdunegrid.so
/usr/bin/ld: /temp/gruenich/dune/cmake/dune-geometry/build-cmake/lib/libdunegeometry.a(referencedomain.cc.o): relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/temp/gruenich/dune/cmake/dune-geometry/build-cmake/lib/libdunegeometry.a: error adding symbols: Bad value
clang-3.4: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libdunegrid.so] Error 1
make[1]: *** [lib/CMakeFiles/dunegrid.dir/all] Error 2
```
Same happened with UG and ALBERTA instead of ALUGrid.
I assume this was introduced by commit core/dune-common@75e2716be3141cb97e3fca165068d937f9fbd411. Adding
`-DBUILD_SHARED_LIBS:BOOL=OFF`
to my CMAKE_FLAGS fixes the issue as it is like reverting the mentioned commit.
Christoph GrüningerChristoph Grüningerhttps://gitlab.dune-project.org/flyspray/FS/-/issues/1018FS#1018 RFC Patch: allow different convergence criteria in dune-istl2020-02-12T17:26:31ZFlyspray ImporterFS#1018 RFC Patch: allow different convergence criteria in dune-istl
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) |
| Reported at | Jan 16, 2012 16:23 |
| Type | Feature Request |
| Version | 2.1 |
| Operating System | U...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Lauser (andreas.lauser@iws.uni-stuttgart.de) |
| Reported at | Jan 16, 2012 16:23 |
| Type | Feature Request |
| Version | 2.1 |
| Operating System | Unspecified / All |
# Description
Hi,
Although we at LH2 are generally really happy with the solvers of Dune-ISTL, we would like to use a different convergence criterion than the reduction of the two-norm of the residual. I've prepared a proof-of patch which makes the criterion pluggable and did some measurements with Dumux. In the end, the whole simulation was about 25 % faster (see the attached logfiles).
note, that this patch is currently more a proof of concept against dune 2.1 and I would appreciate some feedback. the patch description is the following:
it works by adding a template argument 'ConvergenceCriterion' to the
solver. The default criterion is to look at the reduction of the
defect for the current iterative solution. This is the behaviour of
the ISTL solvers before this patch, so no code needs to be changed if
the current behaviour ought to be kept. The patch adds a second
criterion which checks whether the weighted difference between two
iterations is below a given threshold. This second criterion is called
'FixPointCriterion' and shows better performance (at least for Dumux,
where the Newton-Raphson solver uses a relative convergence criterion).
So far, only the BiCGStab solver has been modified. If this patch has
any chance of getting merged into the Dune trunk, I will also modify
the other solvers.
# Attachments
* [0001-Make-the-convergence-criteria-pluggable.patch](/uploads/5365f2f575f0737ff4a2ccc139b0bf89/0001-Make-the-convergence-criteria-pluggable.patch)
* [ifp_2d_fixpointcrit.log](/uploads/cabd184b5a642fb528698a7087e01a16/ifp_2d_fixpointcrit.log)
* [ifp_2d_residreductioncrit.log](/uploads/fc165dc498da40de86757f06fbdce0bc/ifp_2d_residreductioncrit.log)