Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2024-03-22T14:41:05Zhttps://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/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-common/-/issues/352DUNE ENV 2.02024-02-22T15:19:29ZRobert KDUNE ENV 2.0The desire is to build DUNE without automatic virtual env creation and pip install.
Related to
- !222.
- !960
- !1104The desire is to build DUNE without automatic virtual env creation and pip install.
Related to
- !222.
- !960
- !1104https://gitlab.dune-project.org/core/dune-localfunctions/-/issues/22Thread safety.2023-09-19T15:05:29ZRobert KThread safety.It seems that the evaluation of shape functions is not thread safe. Is this something that can be fixed easily?It seems that the evaluation of shape functions is not thread safe. Is this something that can be fixed easily?Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/core/dune-common/-/issues/350Vc code not compiling2023-12-21T16:12:35ZChristoph GrüningerVc code not compilingThe expensive tests were not run for !1275, so I decided to install Vc and test locally. To my surprise I cannot compile dune-common's Vc/SIMD tests, as they fail with ambiguous overloads. This happens for master and both GCC 13 and Clan...The expensive tests were not run for !1275, so I decided to install Vc and test locally. To my surprise I cannot compile dune-common's Vc/SIMD tests, as they fail with ambiguous overloads. This happens for master and both GCC 13 and Clang 16. (Vc 1.4.3, most recent).
Is anybody using Vc? Is it me or my new compilers? What happyenden to the runners of the expensive tests?
I have to yet tried the 2.9 branch, maybe we have to fix this prior to the upcoming patch release 2.9.1.DUNE 2.10.0