FS issueshttps://gitlab.dune-project.org/flyspray/FS/-/issues2017-08-26T20:11:54Zhttps://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/1658FS#1658 HierarchicSearch suffers from round-off errors2017-08-26T20:11:54ZFlyspray ImporterFS#1658 HierarchicSearch suffers from round-off errors# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Anton Schiela (schiela@zib.de) |
| Reported at | May 29, 2015 08:29 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Anton Schiela (schiela@zib.de) |
| Reported at | May 29, 2015 08:29 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
HierarchicSearch occasionally throws an exception, because a coordinate is found in the father element, but in
none of the children:
cf. hierarchicsearch.hh:
```c++
DUNE_THROW(Exception,"{" << className(*this) << "} Unexpected "
"internal Error: none of the children of the entity "
"{" << formatEntityInformation(entity) << "} contains "
"coordinate (" << global << "). Children are: "
"[" << children.str() << "].");
```
This usually occurs, if the coordinate is very close to a vertex of an element, so that at least
one of the local coordinates is very close to zero (approx. +-1e-14), and round-off errors couse a "wrong" result
of `checkInside`, i.e. `checkInside` is `true` for the father, while it is `false` for all children.
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/1643FS#1643 dune-alugrid should use static assertions to prevent use of non-confo...2017-08-26T20:11:54ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deFS#1643 dune-alugrid should use static assertions to prevent use of non-conforming cube grids.# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | May 8, 2015 11:59 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating Sys...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Dominic Kempf (dominic.r.kempf@gmail.com) |
| Reported at | May 8, 2015 11:59 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
| Last edited by | Robert K (robertk@posteo.org) |
| Last edited at | Jul 21, 2015 15:20 |
# Description
Dear dune-alugrid developers, please checkout the following minimum example:
http://conan2.iwr.uni-heidelberg.de/git/snippets/2
This compiles fine and gets through the factory process, but seems to be stuck in an infinite loop when trying to do the global refinement.
Tested on Ubuntu 14.04, g++ 4.8.2
EDIT: Changed title to reflect actual problem.
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/1601FS#1601 Headercheck does not restart if header changes2017-08-26T20:11:55ZTobias MalkmusFS#1601 Headercheck does not restart if header changes# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Mar 16, 2015 16:23 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | U...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Mar 16, 2015 16:23 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
For the current git master of dune-common (core/dune-common@1a9e7684882d59c416fa83701ec78c6132eb097d )
and cmake version 2.8.12.2 and the attached opts the headercheck does nothing if a header is changed after headercheck was called.
To reproduce this bug run `make headercheck` ones in the build directory of dune-common, change a header eg. dune-common/dune/common/visibility.hh and re run `make headercheck`.
I get the following output:
```
[ * ] Built target headercheck__***.hh
[ * ] Built target headercheck__***.hh
The headercheck feature is currently disabled. You can enable it by adding ENABLE_HEADERCHECK=1 to your cmake flags.
[100%] Built target headercheck
```
and no recompiling happens (See config.opts `ENABLE_HEADERCHECK=1` is set ).
This makes the headercheck useless for me.
# Attachments
* [config.opts](/uploads/b665edface7c407027a8cc24294fd862/config.opts)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1577FS#1577 Generic GridTraits forces IndexType=unsigned int2016-10-05T15:27:47ZFlyspray ImporterFS#1577 Generic GridTraits forces IndexType=unsigned int# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Aleksejs Fomins (aleksejs.fomins@lspr.ch) |
| Reported at | Mar 3, 2015 10:59 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Aleksejs Fomins (aleksejs.fomins@lspr.ch) |
| Reported at | Mar 3, 2015 10:59 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
## What:
Grid implementor is unable to freely choose `IndexType`
## Where:
dune/grid/common/grid.hh line 361:
Forwards-declaration of `IndexSet` forces `IndexType=unsigned int`
## When:
Problem occurs when using generic `GridTraits`. Avoided in several grids by implementing own `GridTraits` class.
## Proposed Solution:
Add `IndexType` as a template parameter to generic `GridTraits`. Pass `IndexType` in every grid that uses generic `GridTraits`.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1543FS#1543 Some Prism and Simplex Quadrature Rules limit accuracy to double2018-06-26T14:30:43ZJö Fahlkejorrit@jorrit.deFS#1543 Some Prism and Simplex Quadrature Rules limit accuracy to double# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Dec 11, 2014 21:14 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Un...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Dec 11, 2014 21:14 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Some quadrature rules do not use the general construction in `TensorProductQuadratureRule`, but have special implementations: Triangles up to order 12, Tetrahedra up to order 5, and Prisms up to order 2. These initialize their positions and weights from double values. This contrasts with the general construction, which does support arbitrary precision types. The accuracy is still arbitrarily limited to ~100 decimal places there, but that is much better than the ~16 decimal places for double.
The biggest problem with this is that the degradation in accuracy for arbitrary precision types happens silently, and that it happens only for some combinations of geometry types and quadrature orders, so it is easily overlooked.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1529FS#1529 valgrind reports invalid reads for umtv in densematrix2016-09-30T08:54:10ZFlyspray ImporterFS#1529 valgrind reports invalid reads for umtv in densematrix
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Felix Schindler (felix.schindler@wwu.de) |
| Reported at | Nov 11, 2014 18:39 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All ...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Felix Schindler (felix.schindler@wwu.de) |
| Reported at | Nov 11, 2014 18:39 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Felix Schindler (felix.schindler@wwu.de) |
| Last edited at | Nov 12, 2014 00:31 |
# Description
I found the following output when inspecting some DUNE code with valgrind (while looking for an unrelated error):
```
==27356== Invalid read of size 8
==27356== at 0x157F2D9D: umtv<Dune::FieldVector<double, 1>, Dune::FieldVector<double, 2> > (densematrix.hh:458)
==27356== by 0x157F2D9D: map2world (mappings_imp.cc:1033)
==27356== by 0x157F2D9D: map2world (geometry.hh:139)
==27356== by 0x157F2D9D: corner (geometry.hh:132)
==27356== by 0x157F2D9D: corner (geometry_imp.cc:126)
==27356== by 0x157F2D9D: corner (geometry.hh:178)
```
This was with a debug build (including -DDUNE_FMatrix_WITH_CHECKING=1) and the corresponding checks in `dune/common/densematrix.hh` did not throw an exception.
Please note that I am not sure that this is a bug or a problem. But since I could not find anything related already reported and I do not like these kind of messages from valgrind for quite central pieces of code I thought I would report this. The `GridType` in use was a `ALUGrid< 2, 2, simplex, conforming >` and of all core modules I use the git version on tag v2.3.1.
Please let me know if you require any additional information!
https://gitlab.dune-project.org/flyspray/FS/-/issues/1506FS#1506 move doc/grids/gridfactory/hybridtestgrids.hh2020-02-13T08:57:34ZAnsgar Burchardtansgar.burchardt@tu-dresden.deFS#1506 move doc/grids/gridfactory/hybridtestgrids.hh
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Ansgar Burchardt (burchardt@igpm.rwth-aachen.de) |
| Reported at | Oct 2, 2014 14:35 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Ansgar Burchardt (burchardt@igpm.rwth-aachen.de) |
| Reported at | Oct 2, 2014 14:35 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
Hi,
hybridtestgrids.hh is included as documentation, but is actually used by grid tests, also in external modules (e.g. foamgrid).
Could it be moved below the dune/grid/* hierarchy and also get installed as a regular header? Otherwise grid checks using it will not work with installed versions of dune-grid. Also
#include "../../../../doc/grids/gridfactory/hybridtestgrids.hh"
just doesn't look right.
Ansgar
https://gitlab.dune-project.org/flyspray/FS/-/issues/1495FS#1495 reading element data is buggy using dune-alugrid2014-09-24T19:28:25ZFlyspray ImporterFS#1495 reading element data is buggy using dune-alugrid
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Nagaiah (nagaiah.chamakuri@gmail.com) |
| Reported at | Sep 24, 2014 19:28 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | ...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Nagaiah (nagaiah.chamakuri@gmail.com) |
| Reported at | Sep 24, 2014 19:28 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Hi,
Last week I updated my all dune modules and downloaded git version of dune-alugrid.
I found that reading the element data from dgf file is buggy using ALUGRID_SIMPLEX type.
This happens when all dune modules (including dune-alugrid)
are compiled with --enable-parallel flag.
without enable-parallel flag(sequential compilation) this works fine.
reading vertex data works fine in both cases.
No issues using UG grid, this works in sequential and parallel version.
Please find attached the dgf file and
for the test case I used the example file from
dune-grid/dune/grid/io/file/dgfparser/test/main.cc
(using GRIDTYPE=ALUGRID_SIMPLEX and GRIDDIM=3)
Here you have to copy the main.cc file in to your user module and
compile using with dune-grid and dune-alugrid.
The resulting vtu file (after loading in paraview) shows that the
element data is distorted. Please find the attached two figures
what it should look like and should not.
seq.png : it should look like this
par.png : odd solution after reading element data with ALUGrid
tested with latest git version of all dune code modules and dune-alugrid.
Compiler is : gcc-4.7.2
# Attachments
* ![seq](/uploads/9da49baafb7e12697a901dc4ece8c254/seq.png)
* ![par](/uploads/46cd97eac57d67836d99f838bc8872e1/par.png)
* [test.dgf](/uploads/efb338c07addd5b0d389770a7290fcf6/test.dgf)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1444FS#1444 public/protected types in GridView2014-03-24T18:48:33ZTobias MalkmusFS#1444 public/protected types in GridView
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Mar 24, 2014 18:48 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecif...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Mar 24, 2014 18:48 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
I'm a little bit puzzled about the public/protected types in the gridview interface.
While type Implementation is protected, maybee should be public in EXPERTIMENTAL_GRID_EXTENSION mode, while type GridViewImp is public.
Both have the same type, so its just a different name ?!?!
https://gitlab.dune-project.org/flyspray/FS/-/issues/1416FS#1416 Unexpected behaviour with setAccumulate2015-11-20T10:42:07ZFlyspray ImporterFS#1416 Unexpected behaviour with setAccumulate# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Olaf Ippisch (olaf.ippisch@iwr.uni-heidelberg.de) |
| Reported at | Jan 15, 2014 12:04 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| ...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Olaf Ippisch (olaf.ippisch@iwr.uni-heidelberg.de) |
| Reported at | Jan 15, 2014 12:04 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
The accumulation mode used by the parallel AMG can be specified with the function setAccumulate. It has two varieties. One has a on/off characteristic and a bool argument, the second selects one of different modes and expects an enum value of type AccumulationMode. There are two things which can be surprising to the user:
- with setAccumulate(bool) the accumulation mode is always set to successiveAccu if the argument is true, even if parmetis is not installed. This results in later warnings and also overwrites the correct setting of the constructor to atOnceAccu. There are two possibilities to cure this. Either to always use at once accumulation or at least to always use it if parmetis is not installed. As this is closer to the current behaviour I implemented the second.
- if a stupid user (like me) wants to use the non-bool version and uses an int as argument (of course no standard-adhering C++ programmer would do that) the bool version is called (as int converts to bool). As the two overloaded version do different things (one activates or deactivates accumulation and the other selects a certain mode) it might be possible to rename one of them.
I add a patch, which addresses both problems.
# Attachments
* [patch](/uploads/e0b52722f574dfec896de1488df41b9a/patch)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1389FS#1389 Multicomponent vtk data should be written as scalar2013-11-14T13:34:27ZCarsten Gräsergraeser@math.fau.deFS#1389 Multicomponent vtk data should be written as scalar
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Nov 14, 2013 13:34 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating Syst...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Nov 14, 2013 13:34 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Multicomponent point data for paraview is written as 'vector' data with the desired number of components. In case numberOfComponents!=3 loading such data in paraview results in permanent warnings. According to the following paraview bug-report this can be avoided by using the 'scalar' type with the desired number of components instead:
http://paraview.org/Bug/bug_relationship_graph.php?bug_id=12024&graph=relation
If 'vectors' is replaced by 'scalars' in the .vtu file paraview does indeed not complain any more. As this report is not commented and I could not find appropriate documentation it's unclear if this is a paraview bug or if we misuse the 'vector' type.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1374FS#1374 Raviart-Thomas elements on simplices lack orientation in interface2013-10-08T07:12:14ZChristoph GrüningerFS#1374 Raviart-Thomas elements on simplices lack orientation in interface
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 8, 2013 07:12 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operat...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Oct 8, 2013 07:12 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
The generic Raviart-Thomas elements on simplices lack orientation (called set number s in the documentation) in the interface. This is needed to detected twisted elements. According to Andreas Dedner this data are internally known but not accessible in the interface. Maybe the way twists will be handled, as discussed in Aachen, will help to clarify the interface.
Unless this is done, I revert the deprecation of raviartthomas02d.hh and raviartthomas12d.hh.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1343FS#1343 dunecontrol should limit its dependecy check when --[only|module]=<mo...2015-11-16T17:02:16ZMarkus BlattFS#1343 dunecontrol should limit its dependecy check when --[only|module]=<mod> to dependecies of mod# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Aug 27, 2013 18:37 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Aug 27, 2013 18:37 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Currently dunecontrol checks whether all the module dependencies of all dune.module files found can be fullfilled.
This seems to be overeager to me and should be limited to the files of interest if --module or --only option is given.
Just noticed this again, because dune-pdelab has a new dependency (typetree) that I have not yet on my disc. Command `dunecontrol --module=dune-istl all` complains:
```
./dune-common/bin/dunecontrol --opts=../opts/shared.opts --module=dune-istl all
--- going to build dune-common dune-istl ---
--- calling all for dune-common ---
--- calling vcsetup for dune-common ---
--> Updating Git pre-commit hook with newer version
--- calling autogen for dune-common ---
ERROR: could not find module dune-typetree,
module is also unknown to pkg-config.
Maybe you need to adjust PKG_CONFIG_PATH!
dune-typetree is required by dune-pdelab
--- Failed to build dune-common ---
Terminating dunecontrol due to previous errors!
```
https://gitlab.dune-project.org/flyspray/FS/-/issues/1333FS#1333 ISTL GMRES parallel performance bug2013-08-20T19:31:31ZTobias MalkmusFS#1333 ISTL GMRES parallel performance bug
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Aug 20, 2013 19:31 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Unspecif...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Aug 20, 2013 19:31 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
In parallel, the ISTL GMRES implementation calls in each iteration step_sp.dot( ... ) for each Krylov-basisvector, which is at most "number of Restarts"-times.
Usually, a global summation over each process is called in each _sp.dot( ... ) evaluation.
This makes at most "number of Restarts" + 3 numbers of global communication per iteration.
In my personal code the parallel performance breaks down for more than 2 processes.
At the moment i don't have an example for the performance break down.
I will try to provide one tomorrow.
Best Tobias
https://gitlab.dune-project.org/flyspray/FS/-/issues/1325FS#1325 hmv function missing from matrix interface2015-12-14T15:20:34ZMarkus BlattFS#1325 hmv function missing from matrix interface# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Aug 11, 2013 15:27 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Aug 11, 2013 15:27 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
While looking at the matrix interface, I noticed that there seems to be one fuction missing for consistency:
`void mhv(const Vector&, Vector&)`.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1319FS#1319 Update documentation of virtual refinement2015-11-19T11:29:07ZChristoph GrüningerFS#1319 Update documentation of virtual refinement# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jul 9, 2013 05:35 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
|...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jul 9, 2013 05:35 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
dune-geometry's documentation is outdated. It misses some past changes. An example is that the class `StaticRefinement` replaced the class `Refinement`.
This is a replacement task to the remaining stuff of FS#1102.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1296FS#1296 No range checking for rows in addindex() of bcrsmatrix.hh2015-11-20T17:12:06ZFlyspray ImporterFS#1296 No range checking for rows in addindex() of bcrsmatrix.hh# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tilak Raj Singh (tilak72@gmail.com) |
| Reported at | May 2, 2013 12:20 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Linux |
# Desc...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tilak Raj Singh (tilak72@gmail.com) |
| Reported at | May 2, 2013 12:20 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Linux |
# Description
Range checking is only done for column index and not row index in addindex() of bcrsmatrix.hh
So if trying to add a index for row not in matrix we get a segmentation fault. It would be nice to report this
I propose the following patch
# Attachments
* [bcrsmatrix.patch](/uploads/f3d9eafd6a5d03b346dd0bb6fe053e2c/bcrsmatrix.patch)