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/1599FS#1599 move special purpose streams from dune/grid/io/vtk/streams.hh to dune...2017-08-26T20:11:55ZChristian EngwerFS#1599 move special purpose streams from dune/grid/io/vtk/streams.hh to dune-common# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Mar 16, 2015 08:27 |
| 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 08:27 |
| Type | Bug Report |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
We have two special purpose streams, one writing data as base64 and one writing data as binary data (`s << 10;` really writes the binary representation and not the ascii representation). As these might be attractive for more data writers, perhaps even in other modules, I suggest to move them (along with b64.hh) to dune-common. I suggest a subdirectory dune/common/io/.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1597FS#1597 check generated vtk files in all unit tests2017-08-26T20:11:55ZJö Fahlkejorrit@jorrit.deFS#1597 check generated vtk files in all unit tests
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Mar 13, 2015 21:11 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unsp...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Mar 13, 2015 21:11 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
In FS#1539 I introduced a way to check whether files generated by the dune vtkwriter can be read by vtk. This is currently used in vtktest, it is probably a good idea to use it in other tests too, e.g. subsamplingvtktest.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1591FS#1591 Unique Intersections.2017-08-26T20:11:55ZRobert KFS#1591 Unique Intersections.# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Mar 10, 2015 15:25 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Mar 10, 2015 15:25 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Robert K (robertk@posteo.org) |
| Last edited at | Jun 4, 2015 12:21 |
# Description
For some numerical discretizations (e.g. Raviart-Thomas, Hybrid-DG, Mimetic FD) it is necessary to attach unknowns to intersections. There is a lack of support for this feature in the DUNE grid interface. Currently, intersections don't provide an id and one cannot get the orientation from the interface class. Of course one can hack around this problem for various grids, but extending the interface to fully support this seems necessary. Also, communication between intersections is not possible which prohibits non-conforming grids without ghost/overlap elements.
On behalf of some of the core developers I would like to propose the following interface extensions to the DUNE grid interface. The following methods should be added:
`Intersection`:
```c++
// return true if intersection is the representative one
bool representative () const;
// flip intersection, i.e. return Intersection object representing the flipped version
Intersection flip () const;
```
`LocalIdSet`:
```c++
// return id of representative intersection, i.e. only one id for the two appearances of an
// intersection
IdType id( const Intersection& intersection ) const;
```
The `IndexSet` and `PersistentContainer` have to add a similar method.
`DataHandle`:
```c++
bool containsIntersection(); // true if intersection communication is wanted
// fixedsize( Intersection )
bool fixedsizeIntersection();
void gather( buffer, Intersection );
void scatter( buffer, Intersection );
```
For the communication there also occurs the problem that the intersection orientation is flipped between sending and receiving intersection.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1583FS#1583 Additional user grid.geometry() methods from CurvilinearGeometry2016-10-06T11:48:29ZFlyspray ImporterFS#1583 Additional user grid.geometry() methods from CurvilinearGeometry# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Aleksejs Fomins (aleksejs.fomins@lspr.ch) |
| Reported at | Mar 5, 2015 12:00 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspec...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Aleksejs Fomins (aleksejs.fomins@lspr.ch) |
| Reported at | Mar 5, 2015 12:00 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
In this post I will discuss some of the new functionality available in `CurvilinearGeometry`. The question is to find the best way to provide the user with this functionality through dune-grid interface. This post will be quite big, I foresee to split it into smaller requests at a later stage
## Priority 1
methods to obtain basic information about curvilinear entity
* `InterpolationOrder()` - Gets polynomial order of this entity
* `vertex(int i)` - Gets i-th interpolatory vertex coordinate (like `corner(int i)` which provides corners of the geometry)
* `vertices()` - Gets number of interpolatory vertices (like `corners()` which provides the number of corners)
* `isInside(local, global)` - already mentioned in request FS#1578
## Priority 2
When investigating the available quadrature rules, we did not find a suitable way to integrate polynomials of high order over triangles and tetrahedra
To go around this problem, we implemented a class which allows to analytically represent polynomials, and analytically integrate them over the reference elements. That way an integral of a polynomial function over a curvilinear entity can be done analytically for arbitrary order as long as the system has enough resources. This approach has 2 downsides and 1 additional upside
1. (Currently) it only works if the integrand is polynomial. Further investigation is necessary if some other basis is used as integrand
2. It does not work when `mydim < cdim`. When integrating a scalar function over, e.g., a surface in 3D, the Jacobian determinant is a square root of a polynomial, so in this case numerical approach is necessary.
3. It is, however, possible, to find surface integrals (dot and cross-product with normal) analytically.
so the available methods are
* `ctype integrateAnalyticalScalar(const LocalPolynomial & P)` - integrates a polynpmial over the entity when mydim==cdim
* `ctype integrateAnalyticalDot(const PolynomialVector & PVec)` - integrates (PVec.normal) over the surface, when mydim==cdim-1
* `GlobalCoordinate integrateAnalyticalTimes(const PolynomialVector & PVec)` - integrates (PVec x normal) over the surface, when mydim==cdim-1
Since we are interested to be able to integrate polynomial scalars over all codimensions 3D, we provide an internal iterative scheme to do so over triangles and edges.
Our scheme can integrate arbitrary functor f()(x) over the curvilinear triangle or edge (aka integrating f(x)sqrt(det(J(x))) over reference edge/triangle). It works by recursively refining the entity, integrating a 2nd and 4th order interpolating order polynomial over each leaf, and taking the difference of the two as the running error estimate. We have tested it and it is quite precise, but rather slow for high orders. Any contributions welcome
So the numerical methods are
* `volume()` - standard dune.geometry method requires numerical integration in case mydim < cdim, which is done internally
* `integrateNumerical(Functor f)` - iterative scheme to integrate arbitrary functor over simplex of dimension 1 or 2
* `integrateNumerical` needs to be extended to manage dim=3 arbitrary integrals, it is not available at the moment, since I was not sure if it is worth putting extra effort into the method since it is not the best algorithm there is anyway
## Priority 3 - auxiliary polynomial functions
There are some auxiliary functions that may or may not be interesting to the user
* `PolynomialVector interpolatoryVectorAnalytical()` - Analytical representation of the curvilinear local->global map using a vector of polynomials of dimension cdim
* `LocalPolynomial JacobianDeterminantAnalytical()` - Analytical representation of Jacobian determinant when mydim=cdim
* `PolynomialVector NormalIntegrationElementAnalytical()` - vec{dS} in 2D
* `LocalPolynomial IntegrationElementSquaredAnalytical()` - det(J^T J)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1580FS#1580 DGF grid creator for new Yasp grid modes2015-03-10T05:40:37ZChristoph GrüningerFS#1580 DGF grid creator for new Yasp grid modes
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Mar 4, 2015 14:42 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Opera...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Mar 4, 2015 14:42 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
| Last edited by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Last edited at | Mar 10, 2015 05:40 |
# Description
As Yasp grid gained two new modes, non-trivial origin and tensor grid, the DGF grid creator still does not support them.
For the non-trivial origin it is enough to adapt the DGF grid creator. I already crated a feature branch called
feature/dgf-yasp
Please comment. I'll merge it after a week or so.
For the tensor grid, I suggest to introduce a new block marked with the keyword "Tensor". It is followed by dimworld lines. Each line represents a tensor, i.e. contains the sorted coordinates for this dimension.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1578FS#1578 Deprecate paradigm of finding point inside element through local->glo...2015-11-17T14:54:24ZFlyspray ImporterFS#1578 Deprecate paradigm of finding point inside element through local->global map# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Aleksejs Fomins (aleksejs.fomins@lspr.ch) |
| Reported at | Mar 3, 2015 11:29 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspec...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Aleksejs Fomins (aleksejs.fomins@lspr.ch) |
| Reported at | Mar 3, 2015 11:29 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
## Problem:
For curvilinear grids global->local mapping is undefined for points outside element.
Currently, the paradigm to check if a point is inside the element is to perform global->local map and see if resulting point is inside the element.
This approach works only for linear grids.
## Proposed solution:
`grid::geometry` gains a method `bool isInside(const GlobalCoordinate & global, LocalCoordinate & local)`, returns true and a meaningful local coordinate if the point is inside, and simply false with no further implications if the point is outside.
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/1558FS#1558 Headercheck in cmake2015-11-17T14:58:53ZTobias MalkmusFS#1558 Headercheck in cmake# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Jan 30, 2015 11:48 |
| Type | Feature Request |
| Version | 2.3 |
| Operating Syste...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Tobias Malkmus (tomalk@mathematik.uni-freiburg.de) |
| Reported at | Jan 30, 2015 11:48 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
Hi all
In the last days I switched from autotools to cmake.
One feature which I used very often in the past is the headercheck `make headercheck HEADER=...` to test first versions of my code.
AFAIK the current headercheck is not able to mimic this, please correct me if I'm wrong.
I wrote a small cmake script which mimics this autotool's properties, see the attached patch.
With this script you can check your headers, whether they compile or not, in 3 different ways:
1. type `make headercheck` in the build directory to check all headers within the module.
2. use cmake to invoke the headercheck.cmake script in the source directory via:
`cmake -D HEADER=file.hh -P build-dir/headercheck.cmake` ( for a single file )
or `cmake -P build-dir/headercheck.cmake` ( for all headerfiles, the same as `make headercheck` )
3. on UNIX systems a convenience bash script `build-dir/headercheck.sh` is created which encapsulates the call to cmake.
It can be called from the source directory in both ways: checking for a single header (`./headercheck.sh file.hh`) or all in one if no argument is given.
During the headercheck a temporary source file including the header 'hctest.cc' is generated within the build directory.
# Attachments
* [0001-cmake-add-cmake-headercheck-script.patch](/uploads/cc255362c856b6ea2ce181a11c4cd491/0001-cmake-add-cmake-headercheck-script.patch)
https://gitlab.dune-project.org/flyspray/FS/-/issues/1556FS#1556 ReferenceElements: Seperate cache from factory2015-11-17T15:10:51ZJö Fahlkejorrit@jorrit.deFS#1556 ReferenceElements: Seperate cache from factory# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Jan 21, 2015 15:41 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All ...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Jan 21, 2015 15:41 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
The current approach of coupling the cache and the factory of reference elements is problematic. There is only one implementation of the cache, but for certain applications other implementations may be more suitable. E.g. it might be more quitable to use one cache per thread instead of a global cache. There is now way to clear the cache to free up memory. Once one reference element is requested, all reference elements of the same dimension are generated, which can result in quite high memory usage for higher dimension -- Martin Nolte reports [~2GB for dim=10](https://gitlab.dune-project.org/flyspray/FS/issues/1544#note_10632).
There are some opinions in FS#1544, starting at https://gitlab.dune-project.org/flyspray/FS/issues/1544#note_10627. There is a similar report for QuadratureRules in FS#1555.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1555FS#1555 QuadratureRules: Separate cache from factory2015-11-17T15:10:15ZJö Fahlkejorrit@jorrit.deFS#1555 QuadratureRules: Separate cache from factory# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Jan 21, 2015 15:31 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All ...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Jan 21, 2015 15:31 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
| Last edited by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Last edited at | Mar 5, 2015 19:08 |
# Description
The current approach of coupling the cache and the factory of quadrature rules is problematic. There is only one implementation of the cache, but for certain applications other implementations may be more suitable. E.g. it might be more quitable to use one cache per thread instead of a global cache. Similarly, there is currently no way to request a quadrature rule without using the cache -- which makes implementing other caches impossible. Also there is now way to clear the cache to free up memory.
There are some opinions in FS#1544, starting at https://gitlab.dune-project.org/flyspray/FS/issues/1544#note_10627. There is a similar report for ReferenceElements in FS#1556.
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)