Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2021-03-24T21:32:34Zhttps://gitlab.dune-project.org/core/dune-common/-/issues/34Local DUNE_CONTROL_PATH doesn't prevent CMAKE_MODULE_PATH being populated wit...2021-03-24T21:32:34ZLukas BögerLocal DUNE_CONTROL_PATH doesn't prevent CMAKE_MODULE_PATH being populated with globally installed entriesWhen compiling dune modules in a local directory parallel to globally installed modules, the CMAKE_MODULE_PATH can be configured such that global cmake modules have precedence over local ones, even though DUNE_CONTROL_PATH is exclusivel...When compiling dune modules in a local directory parallel to globally installed modules, the CMAKE_MODULE_PATH can be configured such that global cmake modules have precedence over local ones, even though DUNE_CONTROL_PATH is exclusively set to local paths and the --only option passes nothing but local modules. This can lead to issues during the configuration for different local/global module versions.
Example: all core modules 2.4.1 and dune-alugrid 2.4.0 installed in /usr. Additionaly a local directory with all core-modules, dune-typetree and dune-pdelab from the current master branch. The following command
```bash
DUNE_CONTROL_PATH=$(find `pwd` -name dune.module | tr '\n' ':') ./dune-common/bin/dunecontrol --only=dune-common,dune-localfunctions,dune-pdelab,dune-geometry,dune-typetree,dune-istl,dune-grid configure
```
fails with the output
```
Call Stack (most recent call first):
cmake/modules/DunePdelabMacros.cmake:2 (include)
[pwd]/dune-common/cmake/modules/DuneMacros.cmake:570 (include)
[pwd]/dune-common/cmake/modules/DuneMacros.cmake:714
(dune_process_dependency_macros)
CMakeLists.txt:23 (dune_project)
CMake Error at /usr/share/dune/cmake/modules/Headercheck.cmake:11
(dune_common_script_dir):
Unknown CMake command "dune_common_script_dir".
Call Stack (most recent call first):
[pwd]/dune-common/cmake/modules/DuneMacros.cmake:738
(setup_headercheck)
CMakeLists.txt:23 (dune_project)
```
where obviously /usr/share/dune/cmake/modules/Headercheck.cmake has been loaded instead of the local ./dune-common/cmake/modules/Headercheck.cmake though no global directories are involved.
This mechanism can apparently also appear with global, non-DUNE components involved in the compilation, like the std library.2017-11-01https://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-common/-/issues/362Assert and debug levels for error checking2024-02-22T15:36:08ZSimon PraetoriusAssert and debug levels for error checking### Summary
In several dune core modules, error checking is enabled differently.
- In dune-common `boundschecking.hh` a macro `DUNE_ASSERT_BOUNDS` is enabled, if the variable `DUNE_CHECK_BOUNDS` is set.
- In `densematrix.hh` and `diagon...### Summary
In several dune core modules, error checking is enabled differently.
- In dune-common `boundschecking.hh` a macro `DUNE_ASSERT_BOUNDS` is enabled, if the variable `DUNE_CHECK_BOUNDS` is set.
- In `densematrix.hh` and `diagonalmatrix.hh` additionally, the macro `DUNE_FMatrix_WITH_CHECKING` is checked and if set, some additional conditions are tested.
- Also in dune-common but also in dune-istl, the macro `DUNE_ISTL_WITH_CHECKING` is available for enabling extra checks in parallel code and in istl containers
- Then we have the classical `assert` macro as well as the extra macro `DUNE_ASSERT_AND_RETURN`
- In `debugallocator.hh` we have another macro: `ALLOCATION_ASSERT`
- And `stdthread.hh` defines `DUNE_ASSERT_CALL_ONCE`
- The file `reservedvector.hh` additionally introduces the macro `CHECKSIZE` that is activated by `CHECK_RESERVEDVECTOR`
- In some files, explicitly `NDEBUG` is used for deactivating extra checks
This situation is not very satisfactory. Probably, I have not listed all available macros and variables to do some error checking. We need a better way!
#### Another related issue:
- The `DUNE_THROW` macro cannot be used in `constexpr` contexts. This is, because the `Dune::Exception` classes are no literal types and one cannot even construct them with a string message directly.
### How do others solve this issue?
- *wxWidgets* introduce a `wxDEBUG_LEVEL` variable (default value 1) and macros `wxASSERT` and `wxASSER_LEVEL_2` to distinguish cheap and expensive debug checks
- *Microsoft* has `ASSERT` (checks if `_DEBUG` is set), `VERIFY` (always checked), and `ASSERTE` (check with message representing the checked expression)
- *deal.ii* has `Assert`, `AssertThrow` and `AssertNothrow` macros that are enabled if `DEBUG` is set.
- *LiveV* introduces macros `ASSERT(X,A)` (deactived with `-DNODEBUG`), `ASSERT_PRE(X,A)`, `ASSERT_POST(X,A)`, `ASSERT_INV(X,A)` (activated with `-DTEST_[PRE|POST|INV]`
- *CppCoreGuidelines* introduce `Expects()` and `Ensures` macros for pre- and post-conditions. In the GSL, these are implemented using the `[[likely]]` keyword
### Proposal
- I suggest to only have a single type of macro for all checks: `DUNE_ASSERT`
- I like the design of wxWidgets to have a dedicated name for expensive asserts, `DUNE_ASSERT_LEVEL_2`. Whether it is activated or not, can be controlled by the variable `DUNE_DEBUG_LEVEL` (name of that macro is up to discussion)
- I like the design of LiveV with a message argument by default, but maybe this can be made optional.
- Additionally, one might consider to distinguish pre-/post-conditions and invariants, and may introduce also assumptions, e.g. `DUNE_ASSUME` that are always checked but might not leads to direct termination. These are infos to the compiler and the user and termination with error-messages must be enabled explicitly.
- The `DUNE_THROW` macro and exceptions should be made `constexpr`-friendly
An alternative with a flexible set of arguments to the assert macro it described in https://www.foonathan.net/2016/09/assertions/
### Related issues/merge-requests
- !1346 (Add the macro DUNE_ASSUME)
- #110 (`DUNE_THROW` fails when used within `constexpr` function)https://gitlab.dune-project.org/core/dune-geometry/-/issues/36Recent "cleanup" breaks code in dune-fem.2024-01-23T12:20:23ZRobert KRecent "cleanup" breaks code in dune-fem.A recent "cleanup" merge !235 breaks code in dune-fem (removal of header include in a MR that says doxygen fixes).
Apparently, a deprecated header is used and there never was any warning that this should not be done anymore. This is ex...A recent "cleanup" merge !235 breaks code in dune-fem (removal of header include in a MR that says doxygen fixes).
Apparently, a deprecated header is used and there never was any warning that this should not be done anymore. This is exactly these cases where the merging person has to have more overview on the code and in general some common sense.https://gitlab.dune-project.org/core/dune-common/-/issues/361Installation of pkg-config / cmake files depend on libdune<module>2024-02-25T22:23:21ZChristoph GrüningerInstallation of pkg-config / cmake files depend on libdune<module>If a Dune module provides a library (like common, geometry, grid), pkg-config and CMake files are installed below the library path (e.g. `lib64`). If a module provides no library (like localfunctions, typetree), the same files go below a...If a Dune module provides a library (like common, geometry, grid), pkg-config and CMake files are installed below the library path (e.g. `lib64`). If a module provides no library (like localfunctions, typetree), the same files go below a different lirary path (e.g. `lib`).
Caused by this part of our code:
https://gitlab.dune-project.org/core/dune-common/-/blob/master/cmake/modules/DuneProject.cmake#L246-L255
Is this really our intention? Why not always using one of the two variables `CMAKE_INSTALL_LIBDIR` or `DUNE_INSTALL_NONOBJECTLIBDIR`?DUNE 2.10.0https://gitlab.dune-project.org/core/ci-config/-/issues/4Update CodeChecker to use Debian 122024-01-12T14:13:05ZSantiago Ospina De Los Ríossospinar@gmail.comUpdate CodeChecker to use Debian 12When using Debian 12 as a base image for the CodeChecker, it will include `clang-tidy` 14 which already includes the clang version of `include-what-you-use`.When using Debian 12 as a base image for the CodeChecker, it will include `clang-tidy` 14 which already includes the clang version of `include-what-you-use`.Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-common/-/issues/360dunecontrol does not manage installed modules correctly2024-01-10T12:04:29ZSimon Praetoriusdunecontrol does not manage installed modules correctly### Summary
While most of the time people are using dune modules in the build-environment purely, there are some situations where this is not the best idea, e.g. when provided in a package management system or in a HPC cluster (e.g. wit...### Summary
While most of the time people are using dune modules in the build-environment purely, there are some situations where this is not the best idea, e.g. when provided in a package management system or in a HPC cluster (e.g. with easybuild). The problem is, that `dunecontrol` fails to decide whether a module is an installed module or is in the build-environment in some cases:
- The pkg-config file shipped with the module is incorrect, e.g., a missing dependency or a typo (even if we do not use pkg-config for anything in dune)
- The module is installed in a path not directly next to the installation of dunecontrol. Then the `PKG_CONFIG_PATH` variable is filled incorrectly and again pkg-config does not find the module.
The underlying problem is, that the decision whether a modules is classified as "installed" or not, is just by checking whether pkg-config can find it. We want to either remove the pkg-config support in the future, or clean it up (!910). Maybe we can find a different criterion whether a module is installed or not, e.g., by installing a file in a specific place, or by adding this information into the `dune.module` file.https://gitlab.dune-project.org/core/dune-common/-/issues/359Deprecate parts of alignedallocator.hh and debugalign.hh that are covered by ...2023-12-21T16:11:21ZChristoph GrüningerDeprecate parts of alignedallocator.hh and debugalign.hh that are covered by C++17From reading the documentation, C++17 should provide replacements for `alignedallocator.hh` and `debugalign.hh`. `std::align` and `std::alligned_alloc` sound like suitable replacements.
We need to clarify, if we need parts of the two he...From reading the documentation, C++17 should provide replacements for `alignedallocator.hh` and `debugalign.hh`. `std::align` and `std::alligned_alloc` sound like suitable replacements.
We need to clarify, if we need parts of the two headers, deprecate the no longer necessary part for Dune 2.10 and remove them after the release.DUNE 2.10.0https://gitlab.dune-project.org/core/dune-common/-/issues/358dune-common installs Python packages and fails2023-12-07T10:46:22ZYuri Vicdune-common installs Python packages and fails```make install``` prints this and then succeeds:
```
Installing python package
Installing wheel for python package at /usr/ports/math/dune-common/work/.build/python/. into /usr/local/share/dune/wheelhouse...
CMake Warning at /usr/ports/...```make install``` prints this and then succeeds:
```
Installing python package
Installing wheel for python package at /usr/ports/math/dune-common/work/.build/python/. into /usr/local/share/dune/wheelhouse...
CMake Warning at /usr/ports/math/dune-common/work/dune-common-d5f5ceec68cc0dc542f175857c9bf14aa98f2c11/cmake/modules/DuneExecuteProcess.cmake:76 (message):
wheel installation failed - ignored
Run
command:/usr/ports/math/dune-common/work/.build/dune-env/bin/python;-m;pip;wheel;-w;/usr/local/share/dune/wheelhouse;/usr/ports/math/dune-common/work/.build/python/.
Return code: 2
Output:
ERROR: Exception:
Traceback (most recent call last):
File "/usr/ports/math/dune-common/work/.build/dune-env/lib/python3.9/site-packages/pip/_internal/cli/base_command.py", line 180, in exc_logging_wrapper
status = run_func(*args)
File "/usr/ports/math/dune-common/work/.build/dune-env/lib/python3.9/site-packages/pip/_internal/cli/req_command.py", line 245, in wrapper
return func(self, options, args)
File "/usr/ports/math/dune-common/work/.build/dune-env/lib/python3.9/site-packages/pip/_internal/commands/wheel.py", line 110, in run
ensure_dir(options.wheel_dir)
File "/usr/ports/math/dune-common/work/.build/dune-env/lib/python3.9/site-packages/pip/_internal/utils/misc.py", line 109, in ensure_dir
os.makedirs(path)
File "/usr/local/lib/python3.9/os.py", line 215, in makedirs
makedirs(head, exist_ok=exist_ok)
File "/usr/local/lib/python3.9/os.py", line 225, in makedirs
mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/usr/local/share/dune'
Call Stack (most recent call first):
python/cmake_install.cmake:48 (dune_execute_process)
cmake_install.cmake:113 (include)
```
It's fundamentally wrong for a C++ package to also install Python packages, because there are multiple concurrently installed Python versions, each of which needs python package to be installed individually.
If dune-common needs to install Python packages - it should create a separate project for this, for example ```dune-common-python```, that should build and install Python packages.
Version: 2.9.0https://gitlab.dune-project.org/core/dune-common/-/issues/357Follow-up from "[bugfix] Include config.h in lrutest.cc"2023-12-06T13:15:29ZSantiago Ospina De Los Ríossospinar@gmail.comFollow-up from "[bugfix] Include config.h in lrutest.cc"The following discussion from !1317 should be addressed:
- [ ] @carsten.graeser started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1317#note_132374): (+1 comment)
> I think one should understa...The following discussion from !1317 should be addressed:
- [ ] @carsten.graeser started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1317#note_132374): (+1 comment)
> I think one should understand what's the problem here and why this was not found by the CI.
>
> Maybe related: !1262, !1310.https://gitlab.dune-project.org/core/dune-common/-/issues/355How are flags generated and passed to compile scripts in dune-py?2023-11-23T20:50:18ZSimon PraetoriusHow are flags generated and passed to compile scripts in dune-py?# Summary
I am investigate a pipeline failure
https://gitlab.dune-project.org/core/dune-common/-/jobs/531775
that shows a strange preprocessor error:
```
/builds/core/dune-common/build-cmake/dune-env/.cache/dune-py/config.h:44:34: err...# Summary
I am investigate a pipeline failure
https://gitlab.dune-project.org/core/dune-common/-/jobs/531775
that shows a strange preprocessor error:
```
/builds/core/dune-common/build-cmake/dune-env/.cache/dune-py/config.h:44:34: error: expected value in expression
#if defined(HAVE_MPI) && HAVE_MPI
```
Actually, this would be valid code and it compiles on all compilers I have found. So, why does this happen? The reason seems to be that during the generation of the compile command/flags in dune-py the flag `HAVE_MPI=` is set without a value. I am trying the MR !1310 where mpi flags are not set via `ENABLE_MPI=1` but directly as `HAVE_MPI=1`. Thus, if no mpi is enabled, no variable is defined. This is not a problem anywhere else. So, the question is where and how this `HAVE_MPI` flag is collected and put into a list of compile-flags? And why is it set to an empty value?https://gitlab.dune-project.org/core/dune-geometry/-/issues/34Follow-up from "Default constructible geometries"2023-11-06T12:09:10ZSantiago Ospina De Los Ríossospinar@gmail.comFollow-up from "Default constructible geometries"The following discussion from !224 should be addressed:
- [ ] @santiago.ospina started a [discussion](https://gitlab.dune-project.org/core/dune-geometry/-/merge_requests/224#note_130752): (+4 comments)
> > [...] In the `test-multi...The following discussion from !224 should be addressed:
- [ ] @santiago.ospina started a [discussion](https://gitlab.dune-project.org/core/dune-geometry/-/merge_requests/224#note_130752): (+4 comments)
> > [...] In the `test-multilineargeometry` this storage is defined as a `std::reference_wrapper` that is not default constructible and so it not the whole multilinear geometry class. [...]
>
> This sounds like simple "view". I would write this as a raw pointer where `nullptr` means that is unassigned.https://gitlab.dune-project.org/core/dune-common/-/issues/354Compiler warning pollution from dependencies2023-11-06T12:57:49ZAlexander MüllerCompiler warning pollution from dependenciesI tried for my dune module to really go hard on fix warnings from clang.
The output is polluted by giving warnings on all other included modules/header from e.g. `dune-functions,yasp_grid,dune-geometry,...`.
Now I read about the fact th...I tried for my dune module to really go hard on fix warnings from clang.
The output is polluted by giving warnings on all other included modules/header from e.g. `dune-functions,yasp_grid,dune-geometry,...`.
Now I read about the fact that the compilers may not produce warning for system headers.
https://cmake.org/cmake/help/latest/command/target_include_directories.html
>If SYSTEM is specified, the compiler will be told the directories are meant as system include directories on some platforms. This may have effects such as suppressing warnings or skipping the contained headers in dependency calculations (see compiler documentation). Additionally, system include directories are searched after normal include directories regardless of the order specified.
Therefore, in https://gitlab.dune-project.org/core/dune-common/-/blob/1437ba8a2840120ef48d563f798134cbb66db70c/cmake/modules/DuneEnableAllPackages.cmake#L301,
there could be an option to include these as SYSTEM header or even as default?
I'm not sure if this will break.
Maybe there is another mechanism less intrusive I'm unaware of.
Nevertheless, this is a show stopper for me to enable warning, since currently the warning pollution of dependencies is too big.
Any thoughts on this @simon.praetorius @santiago.ospina ? Thanks!https://gitlab.dune-project.org/core/dune-istl/-/issues/113Solver factory cannot be instantiated with dynamic blocks2023-10-17T16:49:52ZSantiago Ospina De Los Ríossospinar@gmail.comSolver factory cannot be instantiated with dynamic blocksThe solver factory fails to be instantiated with dynamic blocks like `BCRSMatrix<BCRSMatrix<...>>`. This seems to me that is because that there is not an agreent on [what a matrix is](https://gitlab.dune-project.org/core/dune-common/-/is...The solver factory fails to be instantiated with dynamic blocks like `BCRSMatrix<BCRSMatrix<...>>`. This seems to me that is because that there is not an agreent on [what a matrix is](https://gitlab.dune-project.org/core/dune-common/-/issues/253#note_128057)... The preconditioners assume that the assembled operators are a matrix and its blocks are either numbers or matrices with the `DenseMatrix<...>` interface, thus, all of the preconditioners with the exception of `Richardson` will fail to be instantiated for `depth==1`.https://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 ;-)