FS issueshttps://gitlab.dune-project.org/flyspray/FS/-/issues2013-11-21T14:40:13Zhttps://gitlab.dune-project.org/flyspray/FS/-/issues/1218FS#1218 Add flexible Krylov solvers2013-11-21T14:40:13ZMarkus BlattFS#1218 Add flexible Krylov solvers
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Dec 12, 2012 11:31 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System |...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Dec 12, 2012 11:31 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Markus Blatt (markus@dr-blatt.de) |
| Last edited at | Nov 21, 2013 14:40 |
# Description
The Krylov solvers currently availble in ISTL assume that preconditioners do not change between iterations. But often this is the case (e.g. using AMG with a non-direct solver the number of iterations of the coarse solver might change and therefore the whole AMG changes.)
To allow for changing preconditioners we should add flexible versions to ISTL
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/1175FS#1175 insertionIndex methods are not tested2012-09-01T15:26:38ZOliver Sanderoliver.sander@tu-dresden.deFS#1175 insertionIndex methods are not tested
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 1, 2012 15:26 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Unspecified / Al...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 1, 2012 15:26 |
| Type | Bug Report |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
We require the GridFactory class implementations to provide insertionIndex methods. Apparently there is no test for them. Hence grid implementations may fail to implement these methods without anyone noticing.
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/1130FS#1130 Write Dune-specific assert which ignores -DNDEBUG2013-11-20T07:31:41ZChristoph GrüningerFS#1130 Write Dune-specific assert which ignores -DNDEBUG
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jun 15, 2012 09:59 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| ...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Grüninger (gruenich@iws.uni-stuttgart.de) |
| Reported at | Jun 15, 2012 09:59 |
| Type | Feature Request |
| 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
Citing from Jö's message [1]:
That means we want to run many of the tests once with -DNDEBUG
and once with -UNDEBUG. In both cases we want to always enable those misused
asserts in the testing code. We could do that in the following way:
- introduce a macro unittest_assert() which is always enabled and use that in
the relevant testing code. Or use "if(!...) abort();" or similar.
- when compiling with -DENABLE_DEBUG forcibly undefine NDEBUG in the test
programs
- when compiling with -DDISABLE_DEBUG forcibly define NDEBUG in the test
programs
- otherwise, leave NDEBUG untouched.
We can put that stuff in a header. But we should use seperate headers for
unittest_assert() and the NDEBUG-fiddling, since the latter needs a very
specific position in the list of includes.
Are all corner-cases covered by this scheme?
[1] http://lists.dune-project.org/pipermail/dune/2012-June/011537.html
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/1105FS#1105 Point-to-point communication wrapper for MPI missing.2012-06-07T09:39:48ZRobert KFS#1105 Point-to-point communication wrapper for MPI missing.
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | May 14, 2012 15:21 |
| Type | Feature Request |
| Version | 2.0 |
| Operating System | Unspecified / All |
| La...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | May 14, 2012 15:21 |
| Type | Feature Request |
| Version | 2.0 |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Jun 7, 2012 09:39 |
# Description
Currently, in dune-common we only have collective communication, but no point-to-point communication such send and receive (i.e. MPI_Isend, MPI_Irecv) is available.
The communication classes should be improved providing such features.
Together with that we need a proper stream class (e.g. like the ALUGrid ObjectStream currently used as message buffer in gather and scatter of the DataHandle) allowing to read/write simple objects to/from the data stream which then can be exchanged as MPI_BYTE stream.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1025FS#1025 Add virtual bseclass for different vtkwriters2012-01-20T12:41:30ZChristian EngwerFS#1025 Add virtual bseclass for different vtkwriters
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Jan 20, 2012 12:41 |
| Type | Feature Request |
| Version | 2.1 |
| Operating System |...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Jan 20, 2012 12:41 |
| Type | Feature Request |
| Version | 2.1 |
| Operating System | Unspecified / All |
# Description
We provide different vtkwriters with a common coarse grained interface. It would be very convenient to have a common baseclass, so that I could write code, which only knows, that it uses some kind of VTKWriter (obviously we have to keep the template parameters), but it doesn't matter if it is a normal one, subsamplingvtkwriter, or something completely different.
https://gitlab.dune-project.org/flyspray/FS/-/issues/1015FS#1015 Matrix<T> operator*(Matrix<T>,Matrix<T>) docu inaccurate2015-11-19T11:50:22ZFlyspray ImporterFS#1015 Matrix<T> operator*(Matrix<T>,Matrix<T>) docu inaccurate# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Uli Sack (usack@math.fu-berlin.de) |
| Reported at | Jan 9, 2012 11:08 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating S...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Uli Sack (usack@math.fu-berlin.de) |
| Reported at | Jan 9, 2012 11:08 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
For a quick and dirty test I wanted to use
Matrix<T> operator*(Matrix<T>,Matrix<T>)
but had to realize that it won't work for any T with block_size other than one due to the row_type of Matrix and the operator* in block_vector_unmanaged.
In general this came as a surprise, as I would expect a method for a block matrix to be able handle block matrices of arbitrary block sizes.
Therefore my question is, is there any reasonable way to use that method? Why is it there at all? Up to now I thought that ISTL-philosophy was "do not provide methods that are very costly (here:copying around matrices) or [cannot be | are not] implemented generically". Should it not be removed maybe?
In any case I think that this shortcoming should be documented, now documentation says "Generic matrix multiplication." I don't have to argue that 'generic' doesn't quite hit the mark. Anyway, there is a patch attached that slightly enhances documentation in that respect.
# Attachments
* [matrix.patch](/uploads/0566aeb5cedb3cfb92e4f123d373935e/matrix.patch)
https://gitlab.dune-project.org/flyspray/FS/-/issues/975FS#975 outerNormal for outside entity2012-07-10T18:45:28ZAndreas DednerFS#975 outerNormal for outside entity
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Nov 8, 2011 22:43 |
| Type | Feature Request |
| Version | 2.0 |
| Operating System | Unspecified /...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Nov 8, 2011 22:43 |
| Type | Feature Request |
| 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:45 |
# Description
For surface grids one in general does not have matching outerNormals, e.g.,
N_{T'} != -N_T
where T and T' are neighboring elements.
On an intersection one now needs to find the corresponding intersection on outside to obtain n_{T'} through iteration over all intersection and some matching. That is quite difficult and expensive especially if the normals are not constant.
Suggestions (with increasing complexity for everyone):
A: add outerNormalInOutside(x) to intersection
B: implement some sort of reverseIntersection
method on the Intersection class which provides the matching intersection from the outside entity.
C: Have method to obtain normal on the entity:
outerNormal(i,x) (x in codim=1 or codim<0> coordinates).
One could then use something like:
inter.outside()->outerNormal(inter.numberInOutside, inter.geometryInOutisde.global(x))
D: have the intersection provide an insideIntersection() and outsideIntersection() method returning a class with methods like geometry() (the same as geometryInInside/Outside) and so on. Code like (*iter).geometryInInsde(x) would then have to be changed to (*iter).insideIntersection().geometry(x). The Intersection class would then have the bool methods (neighbor/boundary...) and the geometry method while all other methods would be moved to the class returned by insideIntersection() and outsideIntersection()
Because I think D would be too intrusive and not worth it, I favor A or B.
But perhaps somebody has a better suggestion?
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/943FS#943 scan and allgather missing in MPICollectiveCommunication2011-08-01T11:59:10ZRobert KFS#943 scan and allgather missing in MPICollectiveCommunication
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Aug 1, 2011 11:59 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unsp...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Aug 1, 2011 11:59 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
The interface for ClollectiveCommunications misses improtant methods like scan (MPI_Scan) or allgather (MPI_Allgather).
Furthermore, there are no methods for sending and receiving data, (MPI_Send, MPI_Recv, ...).
https://gitlab.dune-project.org/flyspray/FS/-/issues/942FS#942 Nonconforming information on Intersections not sufficient. 2012-06-07T09:39:13ZRobert KFS#942 Nonconforming information on Intersections not sufficient.
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Jul 21, 2011 15:21 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Uns...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Robert K (robertk@posteo.org) |
| Reported at | Jul 21, 2011 15:21 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Jun 7, 2012 09:39 |
# Description
The method conforming on intersections does not deliver enough information. One would also like to know whether the inside or the outside entity has a non-conforming face. Currently this cannot or only in an expensive way be determined.
I suggest to add a new method nonConforming that returns the level of non-conformity, conforming = 0,
insideConforming > 0
outsideConforming < 0
By using nonConforming () == 0 one can implement the old method conforming().
https://gitlab.dune-project.org/flyspray/FS/-/issues/935FS#935 Enabling gmshreader to read more than one tag. 2012-02-15T18:02:55ZFlyspray ImporterFS#935 Enabling gmshreader to read more than one tag.
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jayesh Badwaik (jayesh.badwaik90@gmail.com) |
| Reported at | Jun 18, 2011 09:07 |
| Type | Feature Request |
| Version | 2.0 |
| Operating System | Unspecifie...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jayesh Badwaik (jayesh.badwaik90@gmail.com) |
| Reported at | Jun 18, 2011 09:07 |
| Type | Feature Request |
| Version | 2.0 |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Feb 15, 2012 18:02 |
# Description
According to the discussions in the forum, I think it would be easy to add a functionality to gmshreader which will enable it to read more than one tag from the file. Examining the file, I've found that the file already reads three tags but it ouputs just one. By changing the pass2Handle() function to handle the three values and then changing the arguments appropriately of the function wherever it is called should do the job.
This is what I've gathered. However, for that we would have to add extra std::vector objects for all the three tags and this will make the gmshreader argument list too long (total of ten arguments). For now, we can make it work that way, otherwise we'll have to change the way the tags are output from the GmshReader.
https://gitlab.dune-project.org/flyspray/FS/-/issues/909FS#909 Method 'infinity_norm' does not actually compute the infinity norm2015-11-19T11:50:42ZOliver Sanderoliver.sander@tu-dresden.deFS#909 Method 'infinity_norm' does not actually compute the infinity norm# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Apr 26, 2011 21:01 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operat...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Apr 26, 2011 21:01 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
I would expect a method called 'infinity_norm' of a matrix to compute the infinity norm: the maximum of the absolute values of all entries. However at least the implementations in DenseMatrix, BCRSMatrix, and Matrix compute something else, namely the maximum over the 1-norms of the matrix rows. This is a flagrant violation of the principle of least surprise.
The fix is easy, however apparently the behavior is intentional. At least it is mentioned in the documentation. Why would I need such a strange norm? And isn't there a better name for it?
https://gitlab.dune-project.org/flyspray/FS/-/issues/900FS#900 Can't use GeometryGrid with the PoolAllocator2020-02-13T10:48:04ZOliver Sanderoliver.sander@tu-dresden.deFS#900 Can't use GeometryGrid with the PoolAllocator
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Mar 30, 2011 13:55 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating Sys...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Mar 30, 2011 13:55 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Last edited at | Apr 10, 2012 05:56 |
# Description
The GeometryGrid takes an stl-conforming allocator as its third template parameter. The PoolAllocator class from dune-common is (AFAIK) standard conforming. Hence I should be able to use the two together. However when I try I get loads of compiler errors. Just uncomment the line
//test<GeometryGridWithPoolAllocator>(gridfile);
from test-geogrid.cc to see it for yourself. The complete error log is also attached for your convenience.
# Attachments
* [test-geogrid-poolallocator.log](/uploads/f91be3e53bf879d044d74a92e9047b18/test-geogrid-poolallocator.log)
https://gitlab.dune-project.org/flyspray/FS/-/issues/898FS#898 Easy access to detailed description of grid implementations2015-11-16T17:13:38ZChristoph GersbacherFS#898 Easy access to detailed description of grid implementations# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Gersbacher (gersbach@mathematik.uni-freiburg.de) |
| Reported at | Mar 30, 2011 09:20 |
| Type | Feature Request |
| Version | Git (pre2.4) [au...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christoph Gersbacher (gersbach@mathematik.uni-freiburg.de) |
| Reported at | Mar 30, 2011 09:20 |
| Type | Feature Request |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Detailed descriptions of the grid implementations should be accessible directly through the "modules" page of the doxygen documentation. Currently, this is only the case for GeometryGrid. The documentation is already there, on the class documentation.
https://gitlab.dune-project.org/flyspray/FS/-/issues/892FS#892 FieldVector-FieldVector operations must statically check the size!2016-02-02T10:01:36ZMarkus BlattFS#892 FieldVector-FieldVector operations must statically check the size!# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Mar 3, 2011 19:55 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System ...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Markus Blatt (markus@dr-blatt.de) |
| Reported at | Mar 3, 2011 19:55 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Markus Blatt (markus@dr-blatt.de) |
| Last edited at | Mar 4, 2011 09:54 |
# Description
There a quite a few methods in FieldVector with a FieldVector as the only argument, that only make sense if both vectors have the same size.
Unfortunately, most of them are forwarded to the base class DenseVector which only has a dynamic assertion which checks the size.
This is far from ideal and I would propose a `static_assert` in FieldVector itself!
I have already fixed this for the copy constructor.
Some of the methods that should still be changed are:
```
operator=
operator+=
operator-=
```
...
https://gitlab.dune-project.org/flyspray/FS/-/issues/870FS#870 volume() is not precise for non-affine geometries2019-01-29T22:43:51ZJö Fahlkejorrit@jorrit.deFS#870 volume() is not precise for non-affine geometries
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Feb 4, 2011 19:51 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecifie...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Jö Fahlke (jorrit@jorrit.de) |
| Reported at | Feb 4, 2011 19:51 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
# Description
Am Fri, 4. Feb 2011, 17:27:38 +0100 schrieb joe@dune-project.org:
> Modified:
> trunk/dune/grid/genericgeometry/test/testbasicgeometry.cc
> Log:
> [testbasicgeometry.cc] Extend to test all GeometryTypes up and includeing
> dim=3, in affine and non-affine versions.
The test now checks the volume of the basicgeometry-objects (as far as I have
been able to calculate a reference value for the volume, i.e. feel free to
supply values for the 3D non-affine geometries). The volume check currently
fails for non-affine quadrilaterals in a 3D space, yielding
Volume: 1.22474, but 1.28079 was expected!
I am not 100% sure that I calculated the area correctly though; if someone
else wants to have a go, the corners of the quadrilateral are (x,y,z):
(0,0,0), (1,0,0), (0,1,0), (1,1,1)