Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2018-01-14T04:25:16Zhttps://gitlab.dune-project.org/core/dune-geometry/-/issues/16Multiplicative construction of simplex quadrature rules is suboptimal2018-01-14T04:25:16ZOliver Sanderoliver.sander@tu-dresden.deMultiplicative construction of simplex quadrature rules is suboptimalThere is code in `dune/geometry/quadraturerules/tensoproductquadrature.hh` that constructs quadrature rules for simplices by conically multiplying given 1d rules. However, this is suboptimal. Rules with higher order / less points can b...There is code in `dune/geometry/quadraturerules/tensoproductquadrature.hh` that constructs quadrature rules for simplices by conically multiplying given 1d rules. However, this is suboptimal. Rules with higher order / less points can be constructed by using particular 1d Gauss-Jacobi rules. More information is given in the code itself. Quote:
* [snip] the 1D quadrature must be at least \f$\dim B\f$ orders higher
* than the quadrature for \f$B\f$.
*
* Question: If the polynomials are created via Duffy Transformation, do we
* really need a higher quadrature order?
*
* Answer (from OS): Not really. The official way is to use a Gauss-Jacobi
* rule with \f$ \alpha = \dim B, \beta = 0 \f$ for the 1D rule.
* That takes care of the term \f$ (1-z)^{\dim B} \f$ without needing
* additional orders. See for example A.H. Stroud, "Approximate Calculation
* of Multiple Integrals", Chapters 2.4 and 2.5 for details.
* If you want to use plain Gauss-Legendre you do need the additional orders.https://gitlab.dune-project.org/core/dune-localfunctions/-/issues/16Cleanup LagrangeSimplexLocalCoefficients2019-08-27T07:31:10ZCarsten Gräsergraeser@math.fau.deCleanup LagrangeSimplexLocalCoefficientsThe implementation of `LagrangeSimplexLocalCoefficients` is very cluttered and inconsistent:
* [ ] Construction from permutation needlessly throws for dim=1.
* [ ] Text of thrown exceptions is misleading or incorrect.
* [ ] For dim>3 co...The implementation of `LagrangeSimplexLocalCoefficients` is very cluttered and inconsistent:
* [ ] Construction from permutation needlessly throws for dim=1.
* [ ] Text of thrown exceptions is misleading or incorrect.
* [ ] For dim>3 compile time failure should be preferred.
* [ ] Code duplication for dim=2: Constructor from permutation uses ´generateLocalKeys()` while default constructor is implemented separately.
* [ ] `LocalKey` generation for dim=1,dim=2,dim=3 are spread over multiple methods, dim=2 and dim=3 are implemented very differently.
* [ ] `LocalKey` generation code is completely undocumented. While dim=2 is easy to understand, this is not true for dim=3.
* [ ] `generateLocalKeys()` needlessly takes a its `std::array` argument by value.
* [ ] Ordering/position of Lagrange points is not documented.
* [ ] `LocalKey` ordering of surface DOFs is not documented.
* [ ] Semantics of permutation interface is not documented property:
* [ ] Is `vertexMap` a forward or backward permutation?
* [ ] How do the obtained finite elements differ?
* [ ] Which invariants (per-subentity `LocalKey` ordering) are guaranteed?
* [ ] This should also be documented in the `LocalSimplexFiniteElement`
Some of these are easy to fix. However, most need a deeper look into the code, maybe some refactoring of the 3d code, and careful testing.https://gitlab.dune-project.org/core/dune-istl/-/issues/5SPQR uses methods only introduced in Suitesparse 4.3.02017-05-21T00:30:58ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deSPQR uses methods only introduced in Suitesparse 4.3.0So I researched my issue from !8 by diving into the suitesparse code:
Those methods here:
```
/home/dominic/dune/dune-istl/dune/istl/spqr.hh: In member function ‘virtual void Dune::SPQR<Dune::BCRSMatrix<Dune::FieldMatrix<K, n, p>, T...So I researched my issue from !8 by diving into the suitesparse code:
Those methods here:
```
/home/dominic/dune/dune-istl/dune/istl/spqr.hh: In member function ‘virtual void Dune::SPQR<Dune::BCRSMatrix<Dune::FieldMatrix<K, n, p>, TA> >::apply(Dune::SPQR<Dune::BCRSMatrix<Dune::FieldMatrix<K, n, p>, TA> >::domain_type&, Dune::SPQR<Dune::BCRSMatrix<Dune::FieldMatrix<K, n, p>, TA> >::range_type&, Dune::InverseOperatorResult&)’:
/home/dominic/dune/dune-istl/dune/istl/spqr.hh:154:42: error: ‘cholmod_common’ has no member named ‘SPQR_flopcount’
std::cout<<"Flops Taken: "<<cc_->SPQR_flopcount<<std::endl;
^
/home/dominic/dune/dune-istl/dune/istl/spqr.hh:155:44: error: ‘cholmod_common’ has no member named ‘SPQR_analyze_time’
std::cout<<"Analysis Time: "<<cc_->SPQR_analyze_time<<" s"<<std::endl;
^
/home/dominic/dune/dune-istl/dune/istl/spqr.hh:156:45: error: ‘cholmod_common’ has no member named ‘SPQR_factorize_time’
std::cout<<"Factorize Time: "<<cc_->SPQR_factorize_time<<" s"<<std::endl;
^
/home/dominic/dune/dune-istl/dune/istl/spqr.hh:157:45: error: ‘cholmod_common’ has no member named ‘SPQR_solve_time’
std::cout<<"Backsolve Time: "<<cc_->SPQR_solve_time<<" s"<<std::endl;
```
were introduced in SuiteSparse 4.3.0. However, debian stable provides 4.2.1. So, I guess we should:
* remove it
* replace it
* guard it.
Pick your favorite!https://gitlab.dune-project.org/core/dune-grid/-/issues/32Some tests suddenly very slow (factor 10)2017-04-07T14:32:03ZAnsgar Burchardtansgar.burchardt@tu-dresden.deSome tests suddenly very slow (factor 10)Some tests in `dune-grid` are suddenly quite a bit slower and `tensorgridfactorytest` even exceeds its timeout.
As an example, from https://gitlab.dune-project.org/core/dune-grid/builds/2255:
```
25/36 Test #25: test-yaspgrid .............Some tests in `dune-grid` are suddenly quite a bit slower and `tensorgridfactorytest` even exceeds its timeout.
As an example, from https://gitlab.dune-project.org/core/dune-grid/builds/2255:
```
25/36 Test #25: test-yaspgrid ................................ Passed 267.93 sec
35/36 Test #35: tensorgridfactorytest ........................***Timeout 300.00 sec
```
versus a week ago from https://gitlab.dune-project.org/core/dune-grid/builds/1995:
```
25/36 Test #25: test-yaspgrid ................................ Passed 36.89 sec
35/36 Test #35: tensorgridfactorytest ........................ Passed 41.79 sec
```
These aren't the only tests that are affected.https://gitlab.dune-project.org/core/dune-common/-/issues/50genericTransformTuple does not work on const tuples2017-05-25T21:04:49ZFelix GrubergenericTransformTuple does not work on const tuples`genericTransformTuple` from tupleutility.hh fails to compile if it is given a constant tuple, even if we use a functor with const argument that would theoretically allow to be applied to a const tuple.
Here’s a small example to show wh...`genericTransformTuple` from tupleutility.hh fails to compile if it is given a constant tuple, even if we use a functor with const argument that would theoretically allow to be applied to a const tuple.
Here’s a small example to show what’s happening:
```
#include <tuple>
#include <dune/common/tupleutility.hh>
struct Reciprocal
{
template<class>
struct TypeEvaluator
{
typedef double Type;
};
template<class T>
typename TypeEvaluator<T>::Type operator()(const T& val) const {
return 1./val;
};
};
int main() {
const std::tuple<int, double> t1(1, 2.);
auto t2 = Dune::genericTransformTuple(t1, Reciprocal());
}
```
This code fails to compile with a missing overload in `genericTransformTupleBackend`.
I’ll publish a merge request soon that adds a testcase and the missing overload for `genericTransformTupleBackend`.DUNE 2.5.0https://gitlab.dune-project.org/core/dune-geometry/-/issues/17GeometryType cannot be used as a template parameter2019-12-19T22:12:23ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deGeometryType cannot be used as a template parameterBack when I cleaned up the `GeometryType`, the consensus seemed that we really don't need the `BasicType` anymore. While cleaning up PDELab for 2.6, we've stumbled across `BasicType` in a few places and got rid of it in most of them, but...Back when I cleaned up the `GeometryType`, the consensus seemed that we really don't need the `BasicType` anymore. While cleaning up PDELab for 2.6, we've stumbled across `BasicType` in a few places and got rid of it in most of them, but we have found one problematic case (see also pdelab/dune-pdelab#102):
In PDELab, we have a unified interface for picking the correct `LocalFiniteElement` from `dune-localfunctions` depending on the `GridView`:
```c++
using FEM = RaviartThomasLocalFiniteElementMap<GV,DomainField,RangeField,rt_order>;
```
That class inspects the `GridView` and picks the correct implementation from `dune-localfunctions`, e.g. `Dune::RT0Cube2DLocalFiniteElement<D,R>`. This inspection fails for grids that do not export compile-time information about their unique cell `GeometryType` - mostly UG as it supports mixed grids. Right now, the user can work around this problem by explicitly specifying the `BasicType`:
```c++
using FEM = RaviartThomasLocalFiniteElementMap<GV,DomainField,RangeField,rt_order,Dune::GeometryType::simplex>;
```
That workaround now triggers lots of deprecation warnings.
We basically want the user to be able to say **in a template parameter**: Pick an implementation that works for tetrahedral or hexahedral elements. The easy solution
```c++
RaviartThomasLocalFiniteElementMap<...,Dune::GeometryTypes::simplex(GV::dimension)>
```
does not work because you can only have certain built-in types as template parameters.
I see three (two-and-a-half) possible solutions:
1. Revert the deprecation of `BasicType` and postpone a real solution: the cheap way out. Maybe not a bad idea considering where we are in the release process of 2.6. **Short term I would really like this and re-deprecate after 2.6 is out.**
2. Use the `topologyId` (accessible via `GeometryType::id()`) instead of the `Basictype`. That works, but you still need two template parameters to encode a `GeometryType` in the general case (dimension and `topologyId`). Moreover, explaining to users why they have to write
```c++
Dune::GeometryTypes::simplex(dim).id() // note the trailing .id()
```
won't be easy...
3. Settle on `GlobalGeometryTypeIndex` as the "canonical" encoding of `GeometryType` in a single template parameter and provide implicit and `constexpr`-capable roundtripping between a `GeometryType` and its index:
```c++
template<GeometryTypeIndex gt_index>
struct FEM
{
static constexpr GeometryType gt(gt_index);
};
int test()
{
constexpr auto gt = GeometryTypes::triangle;
FEM fem<gt>();
constexpr auto gt2 = fem.gt;
static_assert(gt == gt2, "this should work");
}
````
This can be easily implemented by adding a `enum class GeometryTypeIndex` and the necessary implicit conversion operators. This should not create unwanted implicit conversions, as `enum class` does not implicitly cast into its underlying type.
I am in favor of 1. and 3. Even though we are really late in the release, 3. seems rather low-risk as it is just a straight interface addition. @all: Thoughts?DUNE 2.7.0Steffen Müthingsteffen.muething@iwr.uni-heidelberg.deSteffen Müthingsteffen.muething@iwr.uni-heidelberg.dehttps://gitlab.dune-project.org/core/dune-localfunctions/-/issues/17Error during build: No rule to make target2023-08-30T14:03:56ZYuri VicError during build: No rule to make target```
gmake[6]: Entering directory '/usr/ports/math/dune-localfunctions/work/.build'
cd /usr/ports/math/dune-localfunctions/work/.build && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /usr/ports/math/dune-localfunctions/work/dune...```
gmake[6]: Entering directory '/usr/ports/math/dune-localfunctions/work/.build'
cd /usr/ports/math/dune-localfunctions/work/.build && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /usr/ports/math/dune-localfunctions/work/dune-localfunctions-4def7a7c627172d660854411d322818115a20765-4def7a7c627172d660854411d322818115a20765 /usr/ports/math/dune-localfunctions/work/dune-localfunctions-4def7a7c627172d660854411d322818115a20765-4def7a7c627172d660854411d322818115a20765/doc /usr/ports/math/dune-localfunctions/work/.build /usr/ports/math/dune-localfunctions/work/.build/doc /usr/ports/math/dune-localfunctions/work/.build/doc/CMakeFiles/install_dune-localfunctions-manual.pdf.dir/DependInfo.cmake --color=
Dependee "/usr/ports/math/dune-localfunctions/work/.build/doc/CMakeFiles/install_dune-localfunctions-manual.pdf.dir/DependInfo.cmake" is newer than depender "/usr/ports/math/dune-localfunctions/work/.build/doc/CMakeFiles/install_dune-localfunctions-manual.pdf.dir/depend.internal".
Dependee "/usr/ports/math/dune-localfunctions/work/.build/doc/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/usr/ports/math/dune-localfunctions/work/.build/doc/CMakeFiles/install_dune-localfunctions-manual.pdf.dir/depend.internal".
Scanning dependencies of target install_dune-localfunctions-manual.pdf
gmake[6]: Leaving directory '/usr/ports/math/dune-localfunctions/work/.build'
/usr/local/bin/gmake -f doc/CMakeFiles/install_dune-localfunctions-manual.pdf.dir/build.make doc/CMakeFiles/install_dune-localfunctions-manual.pdf.dir/build
gmake[6]: Entering directory '/usr/ports/math/dune-localfunctions/work/.build'
gmake[6]: *** No rule to make target '/usr/ports/math/dune-localfunctions/work/dune-localfunctions-4def7a7c627172d660854411d322818115a20765-4def7a7c627172d660854411d322818115a20765/doc/dune-localfunctions-manual_safepdf', needed by 'doc/CMakeFiles/install_dune-localfunctions-manual.pdf'. Stop.
gmake[6]: Leaving directory '/usr/ports/math/dune-localfunctions/work/.build'
gmake[5]: *** [CMakeFiles/Makefile2:2384: doc/CMakeFiles/install_dune-localfunctions-manual.pdf.dir/all] Error 2
gmake[5]: Leaving directory '/usr/ports/math/dune-localfunctions/work/.build'
gmake[4]: *** [CMakeFiles/Makefile2:2391: doc/CMakeFiles/install_dune-localfunctions-manual.pdf.dir/rule] Error 2
gmake[4]: Leaving directory '/usr/ports/math/dune-localfunctions/work/.build'
gmake[3]: *** [Makefile:772: install_dune-localfunctions-manual.pdf] Error 2
```
But in the end the build succeeds.https://gitlab.dune-project.org/core/dune-istl/-/issues/4Drop support for SuperLU 3.x2017-05-21T00:30:58ZChristoph GrüningerDrop support for SuperLU 3.xSuperLU 4.0 was released in 2009, SuperLU 3.0 in 2004. Since Jessie even Debian provides a newer packaged version of SuperLU then 3.0 (they provide 4.3).
I suggest to remove the support for older versions, as every version has changes...SuperLU 4.0 was released in 2009, SuperLU 3.0 in 2004. Since Jessie even Debian provides a newer packaged version of SuperLU then 3.0 (they provide 4.3).
I suggest to remove the support for older versions, as every version has changes and we try to detect them all in our CMake check. This would simplify the code and make it hopefully a little bit easier to add super for SuperLU 5.0 later on.
Please check your SuperLU version and the one you can get from your distribution. This is now the time to trigger / create an updated SuperLU package for your distribution.DUNE 3.0.0Christoph GrüningerChristoph Grüningerhttps://gitlab.dune-project.org/core/dune-grid/-/issues/30test-ug does not build with clang, due to Hybrid::ifElse weirdness2017-04-07T14:32:04ZOliver Sanderoliver.sander@tu-dresden.detest-ug does not build with clang, due to Hybrid::ifElse weirdnesstest-ug builds fine with gcc. However, if fails to build with both clang-3.6 and clang-3.8.
Here's how far I got: in uggridindexsets.hh:75 there is a code block
Hybrid::ifElse(Std::bool_constant<cc==0>(), [&](auto id)
...test-ug builds fine with gcc. However, if fails to build with both clang-3.6 and clang-3.8.
Here's how far I got: in uggridindexsets.hh:75 there is a code block
Hybrid::ifElse(Std::bool_constant<cc==0>(), [&](auto id)
{
[...]
result = UG_NS<dim>::levelIndex(UG_NS<dim>::GetEdge(UG_NS<dim>::Corner(grid_->getRealImplementation(e).getTarget(), // ***
UGGridRenumberer<dim>::verticesDUNEtoUG(a,e.type())),
UG_NS<dim>::Corner(grid_->getRealImplementation(e).getTarget(),
UGGridRenumberer<dim>::verticesDUNEtoUG(b,e.type()))));
}
});
The cc==0 condition is static, therefore this code should really only be instantiated when cc==0. However, clang barfs at the line *** when the case cc==1 is tested. I attach the error message below.
@carsten.graeser , as you wrote the Hybrid::ifElse, could you please have a look? Thanks!
In file included from /home/sander/dune/dune-grid/dune/grid/test/test-ug.cc:14:
In file included from /home/sander/dune/dune-grid/dune/grid/uggrid.hh:125:
/home/sander/dune/dune-grid/dune/grid/uggrid/uggridindexsets.hh:86:84: error: cannot initialize a parameter of
type 'const UG_NS<2>::Element *' (aka 'const UG::D2::element *') with an rvalue of type 'typename
UG_NS<2>::Entity<codim>::T *' (aka 'UG::D2::edge *')
...grid_->getRealImplementation(e).getTarget(),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sander/dune/dune-grid/dune/grid/common/indexidset.hh:178:31: note: in instantiation of function template
specialization 'Dune::UGGridLevelIndexSet<const Dune::UGGrid<2> >::subIndex<1>' requested here
return asImp().template subIndex< cc >( e, i, codim );
The error by itself is okay when cc==1, that is why a static if is used.DUNE 2.5.0https://gitlab.dune-project.org/core/dune-common/-/issues/49Hybrid::forLoop does not work with class derived from std::tuple2017-05-25T21:04:49ZMarco AgneseHybrid::forLoop does not work with class derived from std::tupleThe `Hybrid::forLoop` does not work with classes derived from `std::tuple`. So for example
```
#include <iostream>
#include <tuple>
#include <utility>
template<typename... Args>
struct Foo:public std::tuple<Args...>
{
Foo(Args&&... a...The `Hybrid::forLoop` does not work with classes derived from `std::tuple`. So for example
```
#include <iostream>
#include <tuple>
#include <utility>
template<typename... Args>
struct Foo:public std::tuple<Args...>
{
Foo(Args&&... args):
std::tuple<Args...>(std::forward<Args>(args)...)
{}
};
int main()
{
typedef Foo<int,int> Tuple; // DOES NOT WORK
//typedef std::tuple<int,int> Tuple; // WORKS
Tuple foo(1,2);
Dune::Hybrid::forEach(foo,[&](auto&& ti){std::cout<<ti<<std::endl;});
return 0;
}
```
does not work because the ADL choose the wrong `size` specialization (the one with priority 0).
@carsten.graeserhttps://gitlab.dune-project.org/core/dune-geometry/-/issues/18Maxima scripts do not produce exakt quadrature coefficients2021-06-26T19:20:52ZSimon PraetoriusMaxima scripts do not produce exakt quadrature coefficientsWhile working on the redesign of the quadraturerules I found out that the automatically generated 1d rules are not as exact as assumed, i.e. although the points and weights are printed with 100 digits the actual precision is only about 1...While working on the redesign of the quadraturerules I found out that the automatically generated 1d rules are not as exact as assumed, i.e. although the points and weights are printed with 100 digits the actual precision is only about 16-17 digits. This might be fine for `double` precision calculations, but when changing the ctype to `long double` or `Float128` or even `GMP` it is not applicable.
I'm not an expert in Maxima, so I don't see the error in the script. It seems that the actual calculation is performed in double precision only and just the output is in high precision. @christi I think, you have uploaded the maxima scripts. Any ideas?
The error can be seen by simply summing up the weights. It should be 1 but the difference is about `1.e-16` for rules with order >= 8 at least.
To be mode precise: the quadrature weights are of low precision.https://gitlab.dune-project.org/core/dune-localfunctions/-/issues/18Installs an empty directory 'comm' into /usr/local/share/doc/dune-localfunctions2023-08-30T14:24:56ZYuri VicInstalls an empty directory 'comm' into /usr/local/share/doc/dune-localfunctionshttps://gitlab.dune-project.org/core/dune-istl/-/issues/3[cmake] ISTL uses FindSuiteSparse.cmake2017-05-21T00:30:58ZChristian Engwer[cmake] ISTL uses FindSuiteSparse.cmakethe FindSuiteSparse.cmake is part of dune-common, but it is used in istl and not common. As common provides the check, I think it should also run the check. Then istl can use use the results. If the tests should be run by istl, I'd expec...the FindSuiteSparse.cmake is part of dune-common, but it is used in istl and not common. As common provides the check, I think it should also run the check. Then istl can use use the results. If the tests should be run by istl, I'd expect that the tests are part of istl.
The thing that is particularly strange is that cmake/modules/DuneIstlMacros.cmake explicitly includes AddSuiteSparseFlags, which is not part of istl.https://gitlab.dune-project.org/core/dune-grid/-/issues/25UGGrid does not implement subIndex method for entities other than elements2018-01-15T15:13:10ZOliver Sanderoliver.sander@tu-dresden.deUGGrid does not implement subIndex method for entities other than elementsThis makes the tightened tests from !87 (and its improved version !89) fail.This makes the tightened tests from !87 (and its improved version !89) fail.DUNE 2.5.0Oliver Sanderoliver.sander@tu-dresden.deOliver Sanderoliver.sander@tu-dresden.dehttps://gitlab.dune-project.org/core/dune-common/-/issues/48duneproject should not accept modules names which include numbers2017-05-25T21:04:49ZFelix Schindlerduneproject should not accept modules names which include numbersI was able to create a new DUNE module which contained trailing numbers (e.g., `dune-foo1`), using `duneproject`. Such names, however, seem not to be supported by DUNE (i.e., dependend modules cannot find the module, since the trailing n...I was able to create a new DUNE module which contained trailing numbers (e.g., `dune-foo1`), using `duneproject`. Such names, however, seem not to be supported by DUNE (i.e., dependend modules cannot find the module, since the trailing numbers are stripped from the module name). Hence I would expect `duneproject` to reject such module names in the first place.DUNE 2.5.0https://gitlab.dune-project.org/core/dune-geometry/-/issues/19test-cornerstoragerefwrap segfaults on AMD CPUs in job "debian:10 gcc-8-noas...2018-12-17T17:03:17ZJö Fahlkejorrit@jorrit.detest-cornerstoragerefwrap segfaults on AMD CPUs in job "debian:10 gcc-8-noassert-17" since gcc-8.2.0See https://gitlab.dune-project.org/core/dune-geometry/-/jobs/55554 and the discussion in !107See https://gitlab.dune-project.org/core/dune-geometry/-/jobs/55554 and the discussion in !107https://gitlab.dune-project.org/core/dune-localfunctions/-/issues/19Compilation error with Scalar=Float1282023-03-08T09:19:36ZDimitry PavlovCompilation error with Scalar=Float128Hello,
I get the following error using DuMux with DUNE with Scalar=Float128 setting:
```
/home/dpavlov/DUMUX/dune-localfunctions/dune/localfunctions/lagrange/lagrangesimplex.hh: In instantiation of ‘void Dune::Impl::LagrangeSimplexLoca...Hello,
I get the following error using DuMux with DUNE with Scalar=Float128 setting:
```
/home/dpavlov/DUMUX/dune-localfunctions/dune/localfunctions/lagrange/lagrangesimplex.hh: In instantiation of ‘void Dune::Impl::LagrangeSimplexLocalBasis<D, R, dim, k>::evaluateJacobian(const typename Dune::Impl::LagrangeSimplexLocalBasis<D, R, dim, k>::Traits::DomainType&, std::vector<typename Dune::LocalBasisTraits<D, dim, Dune::FieldVector<CoordType, coorddim>, R, 1, Dune::FieldVector<Scalar, 1>, Dune::FieldMatrix<R, 1, dim> >::JacobianType>&) const [with D = double; R = Dune::Impl::Float128; unsigned int dim = 2; unsigned int k = 1; typename Dune::Impl::LagrangeSimplexLocalBasis<D, R, dim, k>::Traits::DomainType = Dune::FieldVector<double, 2>; typename Dune::LocalBasisTraits<D, dim, Dune::FieldVector<CoordType, coorddim>, R, 1, Dune::FieldVector<Scalar, 1>, Dune::FieldMatrix<R, 1, dim> >::JacobianType = Dune::FieldMatrix<Dune::Impl::Float128, 1, 2>]’:
/home/dpavlov/DUMUX/dune-localfunctions/dune/localfunctions/common/virtualwrappers.hh:113:7: required from ‘void Dune::LocalBasisVirtualImp<T, Imp>::evaluateJacobian(const typename Dune::LocalBasisVirtualImp<T, Imp>::Traits::DomainType&, std::vector<typename T::JacobianType>&) const [with T = Dune::LocalBasisTraits<double, 2, Dune::FieldVector<double, 2>, Dune::Impl::Float128, 1, Dune::FieldVector<Dune::Impl::Float128, 1>, Dune::FieldMatrix<Dune::Impl::Float128, 1, 2> >; Imp = Dune::Impl::LagrangeSimplexLocalBasis<double, Dune::Impl::Float128, 2, 1>; typename Dune::LocalBasisVirtualImp<T, Imp>::Traits::DomainType = Dune::FieldVector<double, 2>; typename T::JacobianType = Dune::FieldMatrix<Dune::Impl::Float128, 1, 2>]’
/home/dpavlov/DUMUX/eor-1p/app/main.cc:172:1: required from here
/home/dpavlov/DUMUX/dune-localfunctions/dune/localfunctions/lagrange/lagrangesimplex.hh:331:38: error: operands to ?: have different types ‘Dune::Impl::Float128’ and ‘double’
prod *= (j==l) ? R(k) / (i[p]-l) : (kx[p]-l) / (i[p]-l);
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/dpavlov/DUMUX/dune-localfunctions/dune/localfunctions/lagrange/lagrangesimplex.hh:331:38: note: and each type can be converted to the other
```
Changing the problematic line to
`prod *= (j==l) ? R(k) / (i[p]-l) : (R)(kx[p]-l) / (i[p]-l);`
helps, but I am not sure whether this is the correct fix.DUNE 2.9.0https://gitlab.dune-project.org/core/dune-istl/-/issues/1add reference to KAMG2017-05-21T00:30:59ZChristian Engweradd reference to KAMGThe documentation of KAMG should include a reference explaining what it is detail.
Is this an implementation following the paper [[Notay and
Vassilevski, 2007]](http://onlinelibrary.wiley.com/doi/10.1002/nla.542/abstract)?The documentation of KAMG should include a reference explaining what it is detail.
Is this an implementation following the paper [[Notay and
Vassilevski, 2007]](http://onlinelibrary.wiley.com/doi/10.1002/nla.542/abstract)?https://gitlab.dune-project.org/core/dune-grid/-/issues/24Remove method index<cc> and subIndex<cc> from IndexSet2018-01-15T15:13:10ZMartin NolteRemove method index<cc> and subIndex<cc> from IndexSetThe index set currently provides the index and subIndex methods twice:
template< class Entity >
Index index ( const Entity &e ) const
template< int codim >
Index index ( const typename Grid::template Codim< codim >::Entity &e ) const
...The index set currently provides the index and subIndex methods twice:
template< class Entity >
Index index ( const Entity &e ) const
template< int codim >
Index index ( const typename Grid::template Codim< codim >::Entity &e ) const
Of course, both methods do the same thing. The second version simply checks the type of entity. We have better checks for this now, e.g.:
template< class Entity, std::enable_if_t< std::is_same< Entity, typename Grid::template Codim< Entity::codimension >::Entity >::value, int > = 0>
Index index ( const Entity &e ) const
I think dropping the second form (maybe in favor of the third) would clarify the interface for the user.https://gitlab.dune-project.org/core/dune-common/-/issues/47Almost everyhing is convertible into a `DenseMatrix`2017-05-25T21:04:49ZTobias MalkmusAlmost everyhing is convertible into a `DenseMatrix`I figured out that `std::is_convertible< ..., DenseMatrix< ... > >::value` is true for huge range of types.
See also the attached test: [fmatrix.cc](/uploads/03d7c889d4c5391dc4c3a2e8ab181b91/fmatrix.cc)I figured out that `std::is_convertible< ..., DenseMatrix< ... > >::value` is true for huge range of types.
See also the attached test: [fmatrix.cc](/uploads/03d7c889d4c5391dc4c3a2e8ab181b91/fmatrix.cc)