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/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/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/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/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/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/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/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/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/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/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)