dune-grid issueshttps://gitlab.dune-project.org/core/dune-grid/-/issues2017-12-30T00:27:52Zhttps://gitlab.dune-project.org/core/dune-grid/-/issues/12checkpartition.hh: failures do not cause test to fail2017-12-30T00:27:52ZAnsgar Burchardtansgar.burchardt@tu-dresden.decheckpartition.hh: failures do not cause test to failThe checks in dune/grid/test/checkpartition.hh only write to `std::cerr` when they fail.
Test programs making use of checkpartition.hh thus don't fail, see https://gitlab.dune-project.org/core/dune-grid/merge_requests/54#note_16818The checks in dune/grid/test/checkpartition.hh only write to `std::cerr` when they fail.
Test programs making use of checkpartition.hh thus don't fail, see https://gitlab.dune-project.org/core/dune-grid/merge_requests/54#note_16818DUNE 3.0.0https://gitlab.dune-project.org/core/dune-grid/-/issues/9test-loadbalancing does not work in parallel2018-03-09T09:20:10ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.detest-loadbalancing does not work in parallelWhile testing for the 2.4.1 release, I tried to run test-loadbalancing in parallel (2 or 4 processes). As it turns out, that fails on both my system (OS X 10.11, GCC 5.3, MPICH 3.2, ParMETIS 4.0.3) and Ubuntu 14.04 (GCC 4.8.4, OpenMPI 1....While testing for the 2.4.1 release, I tried to run test-loadbalancing in parallel (2 or 4 processes). As it turns out, that fails on both my system (OS X 10.11, GCC 5.3, MPICH 3.2, ParMETIS 4.0.3) and Ubuntu 14.04 (GCC 4.8.4, OpenMPI 1.6.5, ParMETIS 3.1). I have no idea whether it is just the test or the partitioner (the test uses UG, and I haven't really looked at what it does. AFAIK there are problems when trying to do multiple loadbalances on a UG grid).
I really have no idea what's wrong there, but it seems kind of pointless to have a load balancing test that only works in sequential mode...
Anyway, here are the outputs:
## OS X 10.11
```
[smuething@Steffens-MBP test]$ mpirun -np 2 ./test-loadbalancing
Using 2 Processes.
Step 0 on 0 ...
Refining level 0 on 0 ...
Step 0 on 1 ...
Refining level 0 on 1 ...
Refining level 1 on 1 ...
Refining level 1 on 0 ...
Coarsening level 0 on 0 ...
Coarsening level 0 on 1 ...
Coarsening level 1 on 1 ...
Coarsening level 1 on 0 ...
Step 1 on 0 ...
Refining level 0 on 0 ...
Step 1 on 1 ...
Refining level 0 on 1 ...
0: ERROR, copying changed the object type!
0: was: Edge, becomes: Node
0: ERROR, copying changed the object type!
0: was: IVertex, becomes: Edge
0: ERROR, copying changed the object type!
0: was: Node, becomes: Edge
0: ERROR, copying changed the object type!
0: was: Edge, becomes: IVertex
0: ERROR, copying changed the object type!
0: was: Edge, becomes: Node
0: ERROR, copying changed the object type!
0: was: IVertex, becomes: Edge
0: ERROR, copying changed the object type!
0: was: Node, becomes: IVertex
1: ERROR, copying changed the object type!
1: was: Edge, becomes: IVertex
1: ERROR, copying changed the object type!
1: was: Edge, becomes: Node
1: ERROR, copying changed the object type!
1: was: IVertex, becomes: Edge
1: ERROR, copying changed the object type!
1: was: Node, becomes: Edge
1: ERROR, copying changed the object type!
1: was: Edge, becomes: IVertex
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= PID 93513 RUNNING AT Steffens-MBP.fritz.box
= EXIT CODE: 11
= CLEANING UP REMAINING PROCESSES
= YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================
YOUR APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault: 11 (signal 11)
This typically refers to a problem with your application.
Please see the FAQ page for debugging suggestions
[smuething@Steffens-MBP test]$
```
## Ubuntu 14.04
```
smuething@ubuntu1404:~/dune/build/default/dune-grid/dune/grid/test$ mpirun -np 2 ./test-loadbalancing
Using 2 Processes.
Step 0 on 0 ...
Refining level 0 on 0 ...
Step 0 on 1 ...
Refining level 0 on 1 ...
Refining level 1 on 0 ...
Refining level 1 on 1 ...
Coarsening level 0 on 1 ...
Coarsening level 0 on 0 ...
Coarsening level 1 on 1 ...
Coarsening level 1 on 0 ...
test-loadbalancing: refine.cc:5842: int AdaptLocalGrid(UG::D2::GRID*, UG::INT*): Assertion `0' failed.
[ubuntu1404:06391] *** Process received signal ***
[ubuntu1404:06391] Signal: Aborted (6)
[ubuntu1404:06391] Signal code: (-6)
test-loadbalancing: refine.cc:5842: int AdaptLocalGrid(UG::D2::GRID*, UG::INT*): Assertion `0' failed.
[ubuntu1404:06392] *** Process received signal ***
[ubuntu1404:06392] Signal: Aborted (6)
[ubuntu1404:06392] Signal code: (-6)
[ubuntu1404:06392] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7efc4ffc5340]
[ubuntu1404:06391] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f06bcc1e340]
[ubuntu1404:06391] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7f06bc87fcc9]
[ubuntu1404:06391] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f06bc8830d8]
[ubuntu1404:06391] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x2fb86) [0x7f06bc878b86]
[ubuntu1404:06391] [ 4] /lib/x86_64-linux-gnu/libc.so.6(+0x2fc32) [0x7f06bc878c32]
[ubuntu1404:06391] [ 5] /home/smuething/dune/external/ug-parallel/lib/libugS2-3.12.1.so(+0x779eb) [0x7f06bea979eb]
[ubuntu1404:06391] [ 6] /home/smuething/dune/external/ug-parallel/lib/libugS2-3.12.1.so(_ZN2UG2D214AdaptMultiGridEPNS0_9multigridEiii+0xaf5) [0x7f06bea98605]
[ubuntu1404:06391] [ 7] ./test-loadbalancing(_ZN4Dune6UGGridILi2EE5adaptEv+0xc8) [0x5ad81e]
[ubuntu1404:06391] [ 8] ./test-loadbalancing(main+0xb1f) [0x551d47]
[ubuntu1404:06391] [ 9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f06bc86aec5]
[ubuntu1404:06391] [10] ./test-loadbalancing() [0x5507f9]
[ubuntu1404:06391] *** End of error message ***
[ubuntu1404:06392] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7efc4fc26cc9]
[ubuntu1404:06392] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7efc4fc2a0d8]
[ubuntu1404:06392] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x2fb86) [0x7efc4fc1fb86]
[ubuntu1404:06392] [ 4] /lib/x86_64-linux-gnu/libc.so.6(+0x2fc32) [0x7efc4fc1fc32]
[ubuntu1404:06392] [ 5] /home/smuething/dune/external/ug-parallel/lib/libugS2-3.12.1.so(+0x779eb) [0x7efc51e3e9eb]
[ubuntu1404:06392] [ 6] /home/smuething/dune/external/ug-parallel/lib/libugS2-3.12.1.so(_ZN2UG2D214AdaptMultiGridEPNS0_9multigridEiii+0xaf5) [0x7efc51e3f605]
[ubuntu1404:06392] [ 7] ./test-loadbalancing(_ZN4Dune6UGGridILi2EE5adaptEv+0xc8) [0x5ad81e]
[ubuntu1404:06392] [ 8] ./test-loadbalancing(main+0xb1f) [0x551d47]
[ubuntu1404:06392] [ 9] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7efc4fc11ec5]
[ubuntu1404:06392] [10] ./test-loadbalancing() [0x5507f9]
[ubuntu1404:06392] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 1 with PID 6392 on node ubuntu1404 exited on signal 6 (Aborted).
--------------------------------------------------------------------------
smuething@ubuntu1404:~/dune/build/default/dune-grid/dune/grid/test$
```DUNE 3.0.0https://gitlab.dune-project.org/core/dune-grid/-/issues/185Make geometry properties/capabilities static2024-03-22T14:41:05ZSimon PraetoriusMake geometry properties/capabilities staticThe Geometry interface defines a method `affine()` that can be used to make some optimization decisions, since for example the jacobians and integration elements are constant in the geometry. However, this property is only available as a...The Geometry interface defines a method `affine()` that can be used to make some optimization decisions, since for example the jacobians and integration elements are constant in the geometry. However, this property is only available as a runtime property, although in several cases it could be provided as a compile-time property. For example, AlbertaGrid has simplex elements only and all `AlbertaGeometry` type have a constant `bool affine() { return true; }` implemented.
Why would it be useful to have this property also as a static property? First, the optimizations mentioned before can be done at compiletime and we could even write class specializations for these cases. Second, some geometry transformations like chaining of geometries would benefit from that knowledge, e.g. a chaining of two affine geometries is also affine and the Jacobian can be computed just once as a product of two Jacobians.
In the design of the `std::mdspan` data structure (and also `std::mdarray`), there are some properties provided as static and dynamic properties, e.g. `is_unique` and `is_always_unique`. I would propose to do something similar also for the geometry interface:
```c++
struct Geometry
{
bool affine() const; // a runtime check whether the geometry is affine
static constexpr bool alwaysAffine(); // a compiletime check whether the geometries is guaranteed to always be affine
};
```
The property `alwaysAffine` implied `affine` (but not vice versa).
An example for a geometry that is not always affine, but sometimes, is the `MultiLinearGeometry`. Examples for always affine geometries are the `AffineGeometry` and the `AxisAlignedCubeGeometry` and some grid-specific geometries.
Other useful properties could also be `multilinear` and `axisaligned`. This is not proposed here, but might be a future extension.
### Alternative Designs
- We could add `Capabilities` for dune geometries, e.g. `Capabilities::IsAffine<Geometry>::v`
- We could provide a utility free function `constexpr bool isAffine(Geometry)` that checks whether the method `geometry.affine()` is static constexpr and if so calls this method, otherwise defaults to `false`.
- Maybe a combination of both.https://gitlab.dune-project.org/core/dune-grid/-/issues/184XML read errors with subsamplingVTKCheck (libvtk9) on Debian/sid and Ubuntu 2...2024-03-21T17:10:33ZMarkus BlattXML read errors with subsamplingVTKCheck (libvtk9) on Debian/sid and Ubuntu 23.10I am trying to fix some other bugs in Debian, but right now compiling dune-grid 2.9.0 fails (maybe due to libvtk9.1?)
Is this familiar to someone, maybe even fixed in newer versions?
```
subsamplingVTKCheck dim=2
subsamplingVTKCheck di...I am trying to fix some other bugs in Debian, but right now compiling dune-grid 2.9.0 fails (maybe due to libvtk9.1?)
Is this familiar to someone, maybe even fixed in newer versions?
```
subsamplingVTKCheck dim=2
subsamplingVTKCheck dim=3
2024-03-08 21:09:21.261 ( 0.113s) [ 2F99E040] vtkXMLParser.cxx:375 ERR| vtkXMLDataParser (0x153f020): Error parsing XML in stream at line 23, column 0, byte index 1092: not well-formed (invalid token)
2024-03-08 21:09:21.261 ( 0.113s) [ 2F99E040] vtkXMLReader.cxx:521 ERR| vtkXMLUnstructuredGridReader (0x153eac0): Error parsing input file. ReadXMLInformation aborting.
2024-03-08 21:09:21.261 ( 0.113s) [ 2F99E040] vtkExecutive.cxx:752 ERR| vtkCompositeDataPipeline (0x153aff0): Algorithm vtkXMLUnstructuredGridReader(0x153eac0) returned failure for request: vtkInformation (0x1541030)
Debug: Off
Modified Time: 8910
Reference Count: 1
Registered Events: (none)
Request: REQUEST_INFORMATION
ALGORITHM_AFTER_FORWARD: 1
FORWARD_DIRECTION: 0
2024-03-08 21:09:21.262 ( 0.114s) [ 2F99E040] vtkXMLParser.cxx:375 ERR| vtkXMLDataParser (0x153f020): Error parsing XML in stream at line 23, column 0, byte index 1089: not well-formed (invalid token)
2024-03-08 21:09:21.262 ( 0.114s) [ 2F99E040] vtkXMLReader.cxx:521 ERR| vtkXMLUnstructuredGridReader (0x153eac0): Error parsing input file. ReadXMLInformation aborting.
2024-03-08 21:09:21.262 ( 0.114s) [ 2F99E040] vtkExecutive.cxx:752 ERR| vtkCompositeDataPipeline (0x1542f50): Algorithm vtkXMLUnstructuredGridReader(0x153eac0) returned failure for request: vtkInformation (0x1541d60)
Debug: Off
Modified Time: 9448
Reference Count: 1
Registered Events: (none)
Request: REQUEST_INFORMATION
ALGORITHM_AFTER_FORWARD: 1
```
I did not spend any time yet...
Bug report in Debian with more output: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064762https://gitlab.dune-project.org/core/dune-grid/-/issues/181GridFactory should export element permutation2023-10-02T15:41:54ZSimon PraetoriusGridFactory should export element permutation### Summary
When creating a grid using a grid factory, the element numbering put into the factory is not necessarily the numbering ending up in the created grid, e.g. `ALUGrid` performs some renumbering - I think to guarantee that the gr...### Summary
When creating a grid using a grid factory, the element numbering put into the factory is not necessarily the numbering ending up in the created grid, e.g. `ALUGrid` performs some renumbering - I think to guarantee that the grid can always be refined by bisection afterwards. This renumbering is not directly exported but is required for some applications, e.g., when we also have stored a finite element basis associated to the local vertices, or a geometry mapping. While we have the `insertionIndex` of elements and vertices we can compute the element permutation afterwards, but one always has to think about this again how to do it without comparing coordinates.
1. Is there an easy way to extract this permutation that I am simply not aware of?
2. Would this be a useful interface extension of the `GridFactory` or better a utility next to it?https://gitlab.dune-project.org/core/dune-grid/-/issues/180FS#1714 Generalize intersection concept for network grids2023-09-29T11:06:15ZOliver Sanderoliver.sander@tu-dresden.deFS#1714 Generalize intersection concept for network grids
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 4, 2015 10:50 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Operating Sys...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Oliver Sander (oliver.sander@tu-dresden.de) |
| Reported at | Sep 4, 2015 10:50 |
| Type | Feature Request |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
Together with Timo Koch and Natalie Schröder (and a few others), I have recently put some work into FoamGrid, a grid manager for 1d and 2d network grids.
Check it out at users.dune-project.org/projects/dune-foamgrid
As it turns out, the intersection concept in dune-grid is not quite general enough for network grids. Therefore, I request certain generalizations to the dune grid interface to improve working with network grids. On the way, these changes also solve a few issues we have had with dune-grid-glue.
The requested changes are not very invasive, but they are a bit subtle. To ease the discussion, and to make sure we are all talking about the same thing, I have tried to write a semi-formal change request document. This document, which I will attach here, gives the reasons why I want to change the interface, and the requested changes in as much detail as possible (to me). Additionally, it describes one alternative approach to the same problem, which I am not proposing, but which was part of the discussion for a while.
It is quite a long document for a small change. It is open for discussion in all regards. Once we settle on something, the document shall make sure that we all remember the details of what we agreed upon.
# Attachments
* [dicr-multiple-intersections.pdf](/uploads/55d15dbc9bdbc85e11ee12e4b6ab656f/dicr-multiple-intersections.pdf)
https://gitlab.dune-project.org/core/dune-grid/-/issues/179FS#1709 Add test for subentity orientation2023-09-29T11:05:40ZCarsten Gräsergraeser@math.fau.deFS#1709 Add test for subentity orientation# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Aug 19, 2015 13:58 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating S...# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Aug 19, 2015 13:58 |
| Type | Bug Report |
| Version | Git (pre2.4) [cmake] |
| Operating System | Unspecified / All |
# Description
On the developer meeting 2013 we decided that subentities should always have a unique orientation which is in general not consistent with the orientation provided by the reference element embedding.
Checkindexset.hh must be extended to test for this consistency guarantee.
https://gitlab.dune-project.org/core/dune-grid/-/issues/178FS#1550 Make Geometry default constructible2023-09-29T13:53:35ZMartin NolteFS#1550 Make Geometry default constructible
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jan 9, 2015 10:54 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspeci...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Martin Nolte (nolte@mathematik.uni-freiburg.de) |
| Reported at | Jan 9, 2015 10:54 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
Geometries are now copy constructible and copy assignable objects. However, in some situations it, like storing geometries in a vector indexed by the index set, a default constructor would be extremely convenient.
As a geometry can always model the identity, there seems no design principle speaking against such default constructibility. Only the return value of "type()" needs to be implementation-defined.
Since nobody will use a default constructed geometry, I would even propose to specify undefined behavior for all methods. This way, implementations simply storing a pointer internally remain trivial.
Are there any reasons not to add this default constructor to the interface?Simon PraetoriusSimon Praetoriushttps://gitlab.dune-project.org/core/dune-grid/-/issues/177FS#1615 Geometry interface not elaborate enough for hessian computation2023-11-04T08:33:47ZChristian EngwerFS#1615 Geometry interface not elaborate enough for hessian computation
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Apr 14, 2015 09:13 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System |...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Apr 14, 2015 09:13 |
| Type | Feature Request |
| Version | 2.3 |
| Operating System | Unspecified / All |
# Description
If I want to compute the hessian of a discrete function I have to map from local to global coordinates. In this case I need in addition to the jacobianInverseTranspose the same for second derivatives.
This issues is in the first place a reminder for the interface problem ;-)https://gitlab.dune-project.org/core/dune-grid/-/issues/176FS#1285 semantic of maxLevel2023-09-29T10:58:29ZAndreas DednerFS#1285 semantic of maxLevel
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Apr 23, 2013 21:05 |
| Type | FAQ |
| Version | 2.2 |
| Operating System | Unspecified / All |
# D...
# Metadata
| Property | Value |
| -------- | ----- |
| Reported by | Andreas Dedner (A.S.Dedner@warwick.ac.uk) |
| Reported at | Apr 23, 2013 21:05 |
| Type | FAQ |
| Version | 2.2 |
| Operating System | Unspecified / All |
# Description
In a parallel run is the semantics of maxLevel
1) the maxLevel for the local partition?
2) the maxLevel of the grid over all processors?
ALU takes the second view at the moment but I think the first makes more sense and I would like to change ALU's behaviour (no way to make backward compatible...)Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-grid/-/issues/175LoadBalance of GeometryGrid is deactivated2023-10-02T14:32:14ZSimon PraetoriusLoadBalance of GeometryGrid is deactivatedWhen using a `GeometryGrid` wrapper in parallel, it is surprising that the `loadBalance(...)` functions are actually commented out. The effect is that the `GridDefaultImplementation` is used, which means: no load balancing at all. This m...When using a `GeometryGrid` wrapper in parallel, it is surprising that the `loadBalance(...)` functions are actually commented out. The effect is that the `GridDefaultImplementation` is used, which means: no load balancing at all. This means, `GeometryGrid` cannot be used with most grid managers that require a `loadBalance()` call after setup (except if you call that function on the host grid directly).
The corresponding code, see https://gitlab.dune-project.org/core/dune-grid/-/blob/master/dune/grid/geometrygrid/grid.hh?ref_type=heads#L437 simply has an `#if 0` without proper documentation why, since about 13y. So, no-one used `GeometryGrid` in parallel since then?
In my opinion, the behavior is a bug. The proper behavior would be at least an error message if that function does not work with the `GeometryGrid` wrapper. One aspect could probably be difficult: If a `DiscreteCoordFunction` is used that is based on discrete data, then this data also needs to be communicated in the load-balancing step. But, I think, this could be implemented.https://gitlab.dune-project.org/core/dune-grid/-/issues/174Feature request: include UGGrid in dune.grid python bindings2023-09-26T14:15:01ZChristian EngwerFeature request: include UGGrid in dune.grid python bindingsCurrently UGGrid is not bundled in the `dune-grid` python bindings. As UGGrid is an optional dependency of `dune-grid`, it is not (easily) possible to offer different python packages. I suggest to include UGGrid in the default `dune-grid...Currently UGGrid is not bundled in the `dune-grid` python bindings. As UGGrid is an optional dependency of `dune-grid`, it is not (easily) possible to offer different python packages. I suggest to include UGGrid in the default `dune-grid` packages.https://gitlab.dune-project.org/core/dune-grid/-/issues/170DGF documentation is rendered with missing information2023-09-22T16:00:19ZSantiago Ospina De Los Ríossospinar@gmail.comDGF documentation is rendered with missing informationThe documentation of the DGF parser in the [source code](https://gitlab.dune-project.org/core/dune-grid/-/blob/master/dune/grid/io/file/dgfparser/dgfparser.hh#L78) and the documentation rendered in the [Doxygen documentation](https://dun...The documentation of the DGF parser in the [source code](https://gitlab.dune-project.org/core/dune-grid/-/blob/master/dune/grid/io/file/dgfparser/dgfparser.hh#L78) and the documentation rendered in the [Doxygen documentation](https://dune-project.org/doxygen/2.9.0/group__DuneGridFormatParser.html#details) doesn't seem to match to me. In particular, the _usage_ section is completely skipped while the _format_ section is rendered as the _usage_ section. Maybe this is done on purpose?Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-grid/-/issues/168VTKWriter with tensor data does not compile2023-06-04T10:02:59ZCarsten Gräsergraeser@math.fau.deVTKWriter with tensor data does not compileUsing `VTKWriter::addVertexData(gridFUnction, FieldInfo("name", FieldInfo::Type::tensor, dim))` leads to a compilation error.
While there is code in the `VTKWriter` to dynamically throw an exception, because tensor data is not supported,...Using `VTKWriter::addVertexData(gridFUnction, FieldInfo("name", FieldInfo::Type::tensor, dim))` leads to a compilation error.
While there is code in the `VTKWriter` to dynamically throw an exception, because tensor data is not supported, this is not triggered here, because the code fails to compile. We should make it transparent to the user what is actually failing by
* documenting that tensor data is not supported,
* ideally catching this case with a static assertion.https://gitlab.dune-project.org/core/dune-grid/-/issues/166All grid factories should support custom communicators2023-02-09T20:40:48ZChristian EngwerAll grid factories should support custom communicatorsCurrently the support of custom communicators for parallel grid construction is very inconsistent.
- `GmshReader` doesn't support custom communicators at all
- `DGFGridFactory` supports this for some meshes, so that the interface is i...Currently the support of custom communicators for parallel grid construction is very inconsistent.
- `GmshReader` doesn't support custom communicators at all
- `DGFGridFactory` supports this for some meshes, so that the interface is inconsistent
- `StructuredGridFactory` also doesn't allow any custom communicator
Surely we will have to think about how to pass the custom communicator to the grid, but imho it would be very helpful to support a common interface.https://gitlab.dune-project.org/core/dune-grid/-/issues/165PythonBindings: YaspGrid Constructor does not allow to change Communicator2023-02-28T12:03:02ZAlexander SchellPythonBindings: YaspGrid Constructor does not allow to change CommunicatorWhen setting up a YaspGrid in Python it is not possible to change the Communicator.
[_grids.py](/uploads/b49f12e90f5a3f171a0f9f54ce460a76/_grids.py)
@christiWhen setting up a YaspGrid in Python it is not possible to change the Communicator.
[_grids.py](/uploads/b49f12e90f5a3f171a0f9f54ce460a76/_grids.py)
@christihttps://gitlab.dune-project.org/core/dune-grid/-/issues/164Compilation warnings about redefined ALBERTA_DIM2023-01-08T08:59:22ZMarkus BlattCompilation warnings about redefined ALBERTA_DIMThis might actually be due to upstream Alberta package but wasn't an issue before moving to imported targets.
It seems like each imported (via pkg-config) Alberta library sets it's own ALBERTA_DIM to the dimension of the Alberta library...This might actually be due to upstream Alberta package but wasn't an issue before moving to imported targets.
It seems like each imported (via pkg-config) Alberta library sets it's own ALBERTA_DIM to the dimension of the Alberta library. As all of those are automatically linked to CMake target for libdune-grid, these definitios are passed to the compiler as e.g `-DALBERTA_DIM=1 -DALBERTA_DIM=2 -DALBERTA_DIM=3` and provoke compiler warnings:
```
<command-line>: warning: "ALBERTA_DIM" redefined
<command-line>: note: this is the location of the previous definition
```
It seems like before moving to imported target we used the maximum (world?-)dimension for ALBERTA_DIM.https://gitlab.dune-project.org/core/dune-grid/-/issues/163Concept checks convertible_to vs same_as2023-01-10T11:18:15ZSimon PraetoriusConcept checks convertible_to vs same_asShould we always allow `std::convertible_to` for the return types of grid functions, or is it sometimes better to be a bit more restrictive and test to `std::same_as`. Specifically, I thought about iterator concept checks, e.g. in `GridV...Should we always allow `std::convertible_to` for the return types of grid functions, or is it sometimes better to be a bit more restrictive and test to `std::same_as`. Specifically, I thought about iterator concept checks, e.g. in `GridViewCodim` concept
```c++
template<class GV, int codim>
concept GridViewCodim = [...] &&
EntityIterator<typename GV::template Codim<codim>::Iterator> &&
requires(const GV gv)
{
{ gv.template begin<codim>() } -> std::convertible_to<typename GV::template Codim<codim>::Iterator>;
{ gv.template end<codim>() } -> std::convertible_to<typename GV::template Codim<codim>::Iterator>;
};
```
I think, the `begin()` and `end()` function should return exactly the iterator we have defined in the type aliases, i.e.,
```c++
{ gv.template begin<codim>() } -> std::same_as<typename GV::template Codim<codim>::Iterator>;
{ gv.template end<codim>() } -> std::same_as<typename GV::template Codim<codim>::Iterator>;
```
For some boolean methods, like `EntitySeed::isValid()` we could also require that the return type is exactly `bool` and not just `convertible_to<bool>`. Or is this too restrictive?https://gitlab.dune-project.org/core/dune-grid/-/issues/162Capabilities should implement value constant2022-11-04T12:27:24ZSimon PraetoriusCapabilities should implement value constantThe grid capabilities are something like boolean integral constants indicating whether a grid supports some feature. Unfortunately, these traits classes are implemented in a way incompatible with standard library traits, i.e., a constant...The grid capabilities are something like boolean integral constants indicating whether a grid supports some feature. Unfortunately, these traits classes are implemented in a way incompatible with standard library traits, i.e., a constant with the uncommon name `v` is provided instead of the more common name `value`.
This might be just an small issue and one might get used to it, but me and others are so often fallen into this trap of using `value` instead of `v` that I came to this proposal and suggest to rename this into `value`.
However, this is nothing that can be changed easily. The reason is that nearly all grids provide specializations for these capability classes. Is there a way to deprecate the old `::v` constant and provide the new `::value` in addition? Is there a smooth transition?
Maybe one could add a value constant aliases that provides a transition switch to old `::v` constants. Example:
```c++
// a utility to extract the value from the capability
template<class Capability>
constexpr auto getCapabilityValue(Dune::PriorityTag<2>) -> decltype(Capability::value)
{
return Capability::value;
}
template<class Capability>
[[deprecated]]
constexpr auto getCapabilityValue(Dune::PriorityTag<1>) -> decltype(Capability::v)
{
return Capability::v;
}
// the capability class
template<class Grid>
struct isCartesian
{
static constexpr bool value = false;
[[deprecated]] static constexpr bool v = value;
};
// the value alias for the capability
template<class Grid>
inline constexpr bool isCartesian_v = getCapabilityValue<isCartesian<Grid>>(Dune::PriorityTag<3>{});
```
With this, new code could directly go for `isCartesian_v` and get deprecation warnings for grids that are not yet changed to `::value`. This would allow us to slowly change to the constant `::value` while old grids are still supported. Other code that uses `::v` will still work and get for some grids a deprecation warning, but not for all grids. If you would use the constant `::value` directly, not-updated grids would simply fail to compile.
If this is something we would agree on, then I would start updating all grids I have access to by providing the second constant `::value` in addition to `::v`.https://gitlab.dune-project.org/core/dune-grid/-/issues/160pyproject.toml2022-10-19T13:52:57ZRobert Kpyproject.tomlhttps://gitlab.dune-project.org/core/dune-grid/-/blob/master/pyproject.toml#L5
I guess this is outdated since a long time ago. Seems to work still. What is the idea here?
@andreas.dedner, @samuel.burbulla: Please take a look.https://gitlab.dune-project.org/core/dune-grid/-/blob/master/pyproject.toml#L5
I guess this is outdated since a long time ago. Seems to work still. What is the idea here?
@andreas.dedner, @samuel.burbulla: Please take a look.