Core Modules issueshttps://gitlab.dune-project.org/groups/core/-/issues2017-11-10T16:27:24Zhttps://gitlab.dune-project.org/core/dune-common/-/issues/82Make building shared libraries the default2017-11-10T16:27:24ZMartin NolteMake building shared libraries the defaultCurrently, DUNE will build statically linked libraries by default. Unfortunately, new users to dune-corepy tend to overlook our request to compile with `-DBUILD_SHARED_LIBS=TRUE`. I think it would help new users, if the default were to b...Currently, DUNE will build statically linked libraries by default. Unfortunately, new users to dune-corepy tend to overlook our request to compile with `-DBUILD_SHARED_LIBS=TRUE`. I think it would help new users, if the default were to build shared libraries.
As far as I remember, the default was chosen because loading shared libraries tends to be terribly slow on supercomputers. But users of supercomputers are more advanced and should be willing to read a section or two on tuning DUNE for these machines. I think we cannot expect the same patience from new DUNE users.DUNE 2.6.0Martin NolteMartin Nolte2017-11-10https://gitlab.dune-project.org/core/dune-common/-/issues/81Python packages in the virtualenv ('build-cmake/dune-env') don't get updated2018-01-15T15:13:11ZLukas RiedelPython packages in the virtualenv ('build-cmake/dune-env') don't get updatedI use the `dune_python_install_package` function together with the necessary CMake flags to install the Python modules of my projects into the virtualenv at configure time. However, re-configuring does not update the packages in the virt...I use the `dune_python_install_package` function together with the necessary CMake flags to install the Python modules of my projects into the virtualenv at configure time. However, re-configuring does not update the packages in the virtualenv. After making changes to files within a package that has already been installed into the virtualenv, I have to remove the dune-common build directory completely and re-configure all projects with Python packages to incorporate said changes. Is there a way to circumvent that? As far as I'm aware, `dune-python` used to overwrite packages in the virtualenv every time CMake was run.DUNE 2.6.0Martin NolteMartin Nolte2017-11-17https://gitlab.dune-project.org/core/dune-grid/-/issues/67VTK tests take a long time in CI2017-08-30T12:23:53ZSteffen Müthingsteffen.muething@iwr.uni-heidelberg.deVTK tests take a long time in CII just noticed that the VTK tests take a long time in the CI system (more than 10 minutes in total for each target). Is there something we can do about that (smaller grids or maybe build those tests with optimization)? Running those test...I just noticed that the VTK tests take a long time in the CI system (more than 10 minutes in total for each target). Is there something we can do about that (smaller grids or maybe build those tests with optimization)? Running those tests takes more than third of the overall time required for compiling + running...DUNE 2.6.0https://gitlab.dune-project.org/core/dune-common/-/issues/80dune_python_install_package: avoid error when pip is not installed, but nothi...2017-12-11T15:59:48ZAnsgar Burchardtansgar.burchardt@tu-dresden.dedune_python_install_package: avoid error when pip is not installed, but nothing to install`dune_python_install_package` currently checks that `pip` was found at the beginning of the function and errors out when it was not found. However, when `DUNE_PYTHON_INSTALL_LOCATION` is `none` and `DUNE_PYTHON_VIRTUALENV_SETUP` is fals...`dune_python_install_package` currently checks that `pip` was found at the beginning of the function and errors out when it was not found. However, when `DUNE_PYTHON_INSTALL_LOCATION` is `none` and `DUNE_PYTHON_VIRTUALENV_SETUP` is false, `pip` would never be called.
It would be nice if `dune_python_install_package` would not return an error in this case.DUNE 2.6.0Andreas DednerAndreas Dednerhttps://gitlab.dune-project.org/core/dune-grid/-/issues/65free function `referenceElement(Geometry)`2017-08-30T12:23:53ZAnsgar Burchardtansgar.burchardt@tu-dresden.defree function `referenceElement(Geometry)`[Some time ago][1] we wanted to add a free function to make accessing the reference element easier.
PDELab already has something like this (pdelab/dune-pdelab!116).
The meeting notes say @martin.nolte wanted to look at this.
[1]: htt...[Some time ago][1] we wanted to add a free function to make accessing the reference element easier.
PDELab already has something like this (pdelab/dune-pdelab!116).
The meeting notes say @martin.nolte wanted to look at this.
[1]: https://www.dune-project.org/community/meetings/2015-09-devmeeting/protocol/#sec-7-1-2DUNE 2.6.0https://gitlab.dune-project.org/core/dune-istl/-/issues/34Memory corruption when calling BCRSMatrix::setSize with three arguments2017-12-23T07:10:58ZOliver Sanderoliver.sander@tu-dresden.deMemory corruption when calling BCRSMatrix::setSize with three argumentsSomething fishy goes on when calling BCRSMatrix::setSize with three arguments (the third is the number of nonzeros). To reproduce, simply run matrixtest under valgrind:
~/dune/dune-istl/build-cmake/dune/istl/test(master)> valgrind ...Something fishy goes on when calling BCRSMatrix::setSize with three arguments (the third is the number of nonzeros). To reproduce, simply run matrixtest under valgrind:
~/dune/dune-istl/build-cmake/dune/istl/test(master)> valgrind ./matrixtest
==4936== Memcheck, a memory error detector
==4936== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4936== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==4936== Command: ./matrixtest
==4936==
==4936== Conditional jump or move depends on uninitialised value(s)
==4936== at 0x16D7DD: Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >::equals(Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> > const&) const (basearray.hh:611)
==4936== by 0x15CA46: std::enable_if<std::is_convertible<Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> > >::value, bool>::type Dune::operator==<Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::FieldMatrix<double, 2, 2>, Dune::FieldMatrix<double, 2, 2>&, long, Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::FieldMatrix<double, 2, 2>, Dune::FieldMatrix<double, 2, 2>&>(Dune::BidirectionalIteratorFacade<Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::FieldMatrix<double, 2, 2>, Dune::FieldMatrix<double, 2, 2>&, long> const&, Dune::BidirectionalIteratorFacade<Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::FieldMatrix<double, 2, 2>, Dune::FieldMatrix<double, 2, 2>&, long> const&) (iteratorfacades.hh:381)
==4936== by 0x1557A3: Dune::EnableIfInterOperable<Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, bool>::type Dune::operator!=<Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::FieldMatrix<double, 2, 2>, Dune::FieldMatrix<double, 2, 2>&, long, Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::FieldMatrix<double, 2, 2>, Dune::FieldMatrix<double, 2, 2>&>(Dune::BidirectionalIteratorFacade<Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::FieldMatrix<double, 2, 2>, Dune::FieldMatrix<double, 2, 2>&, long> const&, Dune::BidirectionalIteratorFacade<Dune::Imp::compressed_base_array_unmanaged<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::RealIterator<Dune::FieldMatrix<double, 2, 2> >, Dune::FieldMatrix<double, 2, 2>, Dune::FieldMatrix<double, 2, 2>&, long> const&) (iteratorfacades.hh:419)
==4936== by 0x155338: Dune::BCRSMatrix<Dune::FieldMatrix<double, 2, 2>, std::allocator<Dune::FieldMatrix<double, 2, 2> > >::endindices() (bcrsmatrix.hh:1233)
==4936== by 0x151697: main (matrixtest.cc:391)
==4936==
==4936==
==4936== HEAP SUMMARY:
==4936== in use at exit: 8 bytes in 1 blocks
==4936== total heap usage: 196 allocs, 195 frees, 265,272 bytes allocated
==4936==
==4936== LEAK SUMMARY:
==4936== definitely lost: 0 bytes in 0 blocks
==4936== indirectly lost: 0 bytes in 0 blocks
==4936== possibly lost: 0 bytes in 0 blocks
==4936== still reachable: 8 bytes in 1 blocks
==4936== suppressed: 0 bytes in 0 blocks
==4936== Rerun with --leak-check=full to see details of leaked memory
==4936==
==4936== For counts of detected and suppressed errors, rerun with: -v
==4936== Use --track-origins=yes to see where uninitialised values come from
==4936== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 0 from 0)DUNE 2.6.0Christian EngwerChristian Engwer2017-11-10https://gitlab.dune-project.org/core/dune-grid/-/issues/63UGGrid should not query size of the message from the data handle on the recei...2018-08-10T09:22:18ZMarkus BlattUGGrid should not query size of the message from the data handle on the receiving side (when loadbalancing)According to a discussion on the mailing list there situations where this is not possible. Yet when scattering UGGrid asks the data handle for the size of the data sent for each element. Later on this size is passed to the scatter method...According to a discussion on the mailing list there situations where this is not possible. Yet when scattering UGGrid asks the data handle for the size of the data sent for each element. Later on this size is passed to the scatter method.
The call occurs in [dune/grid/uggrid/uglbgatherscatter.hh#L99](/core/dune-grid/blob/ff651f7cebb6a9a68306e816d3c17472fcbb09d8/dune/grid/uggrid/uglbgatherscatter.hh#L99). This only happens for the communication with the datahandle when loadbalancing. All other communication seems to use [dune/grid/uggrid/ugmessagebuffer.hh#L83-L107](/core/dune-grid/blob/ff651f7cebb6a9a68306e816d3c17472fcbb09d8/dune/grid/uggrid/ugmessagebuffer.hh#L83-L107) which does the right thing.DUNE 2.6.0https://gitlab.dune-project.org/core/dune-common/-/issues/75wrong use of FIND_PACKAGE_HANDLE_STANDARD_ARGS in dune_python_find_package2017-11-10T16:50:31ZMartin Noltewrong use of FIND_PACKAGE_HANDLE_STANDARD_ARGS in dune_python_find_packageI just tried to add the following line to the checks of dune-fempy:
```
dune_python_find_package(PACKAGE "ufl" REQUIRED VERSION "2016.2")
```
The test itself does succeed, but I get the following error message:
```
CMake Error at /usr/sh...I just tried to add the following line to the checks of dune-fempy:
```
dune_python_find_package(PACKAGE "ufl" REQUIRED VERSION "2016.2")
```
The test itself does succeed, but I get the following error message:
```
CMake Error at /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:219 (message):
No REQUIRED_VARS specified for FIND_PACKAGE_HANDLE_STANDARD_ARGS()
Call Stack (most recent call first):
/home/nolte/numerics/master/dune-common/cmake/modules/DunePythonFindPackage.cmake:111 (find_package_handle_standard_args)
cmake/modules/DuneFempyMacros.cmake:2 (dune_python_find_package)
/home/nolte/numerics/master/dune-common/cmake/modules/DuneMacros.cmake:579 (include)
/home/nolte/numerics/master/dune-common/cmake/modules/DuneMacros.cmake:732 (dune_process_dependency_macros)
CMakeLists.txt:14 (dune_project)
```
The system in question is Debian Stretch, i.e., CMake 3.7.DUNE 2.6.02017-11-10https://gitlab.dune-project.org/core/dune-common/-/issues/73[2.5] Failure to compile hybridutilities.hh2017-08-04T11:28:09ZElias Pipping[2.5] Failure to compile hybridutilities.hhWhile I'm usually on Linux, I've tried to compile the core modules and a few others on a Mac to see if it'd work. In each case, I went with the 2.5 release branch.
When compiling dune/grid/io/file/dgfparser/dgfparser.cc, I hit the follo...While I'm usually on Linux, I've tried to compile the core modules and a few others on a Mac to see if it'd work. In each case, I went with the 2.5 release branch.
When compiling dune/grid/io/file/dgfparser/dgfparser.cc, I hit the following error:
```
/Users/pipping/dune-sources/dune-common/dune/common/hybridutilities.hh:110:12: error:
type 'Dune::Std::integer_sequence<unsigned long, 0, 1, 2>' does not provide a
subscript operator
return c[i];
^ ~
```
The issue appears to be the following: `elementAt` has a few specialisations and a fallback. I end up getting the fallback, namely
```c++
template<class Container, class Index>
constexpr decltype(auto) elementAt(Container&& c, Index&& i, PriorityTag<0>)
{
return c[i];
}
```
here, which doesn't work (and can't be expected to because there is no `integer_sequence::operator[]`). Instead, this should be chosen:
```c++
template<class T, T... t, class Index>
constexpr decltype(auto) elementAt(std::integer_sequence<T, t...> c, Index&&, PriorityTa
g<1>)
{
return std::get<std::decay_t<Index>::value>(std::make_tuple(std::integral_constant<T,
t>()...));
}
```
Why is it not? The compiler (Apple LLVM version 8.1.0 (clang-802.0.42)) is invoked with `-std=c++14` for me so that `Dune::Std` should just be `using std::integer_sequence`. Either way, a template specialisation for one apparently does not count as a template specialisation for the other.
My impression is that as long as we're providing `Dune::Std::integer_sequence`, we should not be using `std::integer_sequence` directly anywhere because (1) when we do, it entirely defeats the purpose of providing a fallback and (2) apparently it can lead to issues such as this one.
Indeed, if I replace each occurrence of `std::integer_sequence` with `Dune::Std::integer_sequence` in hybridutilities.hh, I can compile dune-grid (to me, this seems to be the right fix for the issue, too). I have not checked if this affects the master branch, too, since I'm more interested in 2.5; even if it didn't, I believe this should be fixed.DUNE 2.5.1Carsten Gräsergraeser@math.fau.deCarsten Gräsergraeser@math.fau.dehttps://gitlab.dune-project.org/core/dune-istl/-/issues/28Suprising behaviour of BCRSMatrix.nonzeroes()2017-12-23T07:10:58ZJanick GerstenbergerSuprising behaviour of BCRSMatrix.nonzeroes()`BCRSMatrix.nonzeroes()` can be 0 even when the matrix has entries (e.g. when read with `loadMatrixMarket()`) and changes its value when copied.
Both are highly surprising and I would consider the first one a defect. Attached is a simpl...`BCRSMatrix.nonzeroes()` can be 0 even when the matrix has entries (e.g. when read with `loadMatrixMarket()`) and changes its value when copied.
Both are highly surprising and I would consider the first one a defect. Attached is a simple example.
[nonzeroes.cc](/uploads/0430b3b94de2177a8f0016577186957a/nonzeroes.cc)
[test.mm](/uploads/de25f3779afd3b9505e18a60c6ee9244/test.mm)DUNE 2.6.02017-11-10https://gitlab.dune-project.org/core/dune-common/-/issues/70DUNE_VERSION_NEWER is misleading.2017-10-31T11:21:56ZRobert KDUNE_VERSION_NEWER is misleading.The DUNE_VERSION_NEWER macro name is misleading since it implements actually >= instead of > as the name suggests.
I proposed to rename the macro DUNE_VERSION_NEWER to
1) DUNE_VERSION_GEQ
2) DUNE_VERSION_GREATER_EQUAL
3) DUN...The DUNE_VERSION_NEWER macro name is misleading since it implements actually >= instead of > as the name suggests.
I proposed to rename the macro DUNE_VERSION_NEWER to
1) DUNE_VERSION_GEQ
2) DUNE_VERSION_GREATER_EQUAL
3) DUNE_VERSION_AT_LEAST
The old macro should be deprecated but kept for at least one or two versions for convenience and if the change is made it should be backported at least to DUNE 2.5 if not 2.4 for the better.DUNE 2.6.0https://gitlab.dune-project.org/core/dune-grid/-/issues/59EntityIterator::codimension missing2018-08-10T09:22:18ZTobias MalkmusEntityIterator::codimension missingDue to the recent removal of entitypointer.hh and the corresponding class `EntitPointer` the enum `codimension` is missing in the `EntityIterator` interfaceclass.
I'm not sure if this is a feature or a bug.
I think this issue is r...Due to the recent removal of entitypointer.hh and the corresponding class `EntitPointer` the enum `codimension` is missing in the `EntityIterator` interfaceclass.
I'm not sure if this is a feature or a bug.
I think this issue is related to #58DUNE 2.6.0https://gitlab.dune-project.org/core/dune-istl/-/issues/26Add a generic factory for solver setup using configuration from a ParameterTree2020-01-19T16:59:41ZChristian EngwerAdd a generic factory for solver setup using configuration from a ParameterTree**This is a followup on !5 and !1.**
The idea is to allow creating solvers / preconditioners from ParameterTrees.
A solver (including preconditioner) should be configurable via an ini file, similar to (we might want to change the seman...**This is a followup on !5 and !1.**
The idea is to allow creating solvers / preconditioners from ParameterTrees.
A solver (including preconditioner) should be configurable via an ini file, similar to (we might want to change the semantics slightly in some places...):
```
[solver]
precond = SeqSSOR
solver = CGSolver
[SeqSSOR]
iterations = 1
relaxation = 1.8
[CGSolver]
reduction=1e-9
maxit = 5000
verbose = 3
```
**Necessary steps:**
* [x] make interface classes really dynamic (see !84)
* [x] add constructors taking a `ParameterTree` (see !315)
* [x] use these new constructors in a solver factory (see !312)
* [x] rewrite the factories to use the `ParameterizedFactory` in `dune-common` (see !312)
* [x] review and cleanup the `ParameterTree` *"interface"*
* [x] remove static AMG configurations (coarse solver, smoother, etc) (explicit dispatch in !312)
* [x] switch `Hierarchy<T>` to use `std::shared_ptr` or `std::unique_ptr` for internal memory management instead of manual `new`/`delete`)(see !274 and !333)
1. introduce a value semantics wrapper class for the polymorphic interface classes
1. add concepts for simple precompilation for a range of field types, e.g. vectorized data.
1. review the concepts of how to instantiate and pre-compile the factoriesDUNE 2.7.0Christian EngwerChristian Engwerhttps://gitlab.dune-project.org/core/dune-common/-/issues/63DUNE 2.4.2 maintenance release2018-12-23T09:43:36ZChristoph GrüningerDUNE 2.4.2 maintenance releaseI am preparing a Dune 2.4.2 maintenance release. I am aiming for somewhere towards end of March or April.
Please back-port any commits soon!I am preparing a Dune 2.4.2 maintenance release. I am aiming for somewhere towards end of March or April.
Please back-port any commits soon!DUNE 2.4.2Christoph GrüningerChristoph Grüningerhttps://gitlab.dune-project.org/core/dune-common/-/issues/62`serial` wrapper to run block sequentially on all ranks (for debugging)2018-12-23T09:43:36ZAnsgar Burchardtansgar.burchardt@tu-dresden.de`serial` wrapper to run block sequentially on all ranks (for debugging)I still often use "printf"-debugging. With parallel processes and multi-line output this however gets ugly fairly quick and serializing the output would help.
For this I implemented a `serial` function which executes a function sequentia...I still often use "printf"-debugging. With parallel processes and multi-line output this however gets ugly fairly quick and serializing the output would help.
For this I implemented a `serial` function which executes a function sequentially on all ranks:
```c++
serial([&](int rank, int size) {
std::cout << "I'm rank " << rank << " out of " << size << std::endl;
});
```
which will always output
```
I'm rank 0 out of 4.
I'm rank 1 out of 4.
I'm rank 2 out of 4.
I'm rank 3 out of 4.
```
I find this useful, but obviously one would never want this to be used in production code. So I'm not sure if it is a good idea to add such a function to DUNE? (It might end up used somewhere and really slow things down.)
There are some other ways to split output (e.g. OpenMPI mpirun's `--output-filename` option), but I find them less convenient.DUNE 2.6.0https://gitlab.dune-project.org/core/dune-grid/-/issues/55UGGrid creation with boundary segments segfaults2017-05-22T11:02:26ZMartin WeiserUGGrid creation with boundary segments segfaultsIn some situations, UG grid segfaults during grid creation when boundary segments have been specified. A simple test code that reads a grid created by triangle is attached (together with the grid files triggering the segfault, the outpu...In some situations, UG grid segfaults during grid creation when boundary segments have been specified. A simple test code that reads a grid created by triangle is attached (together with the grid files triggering the segfault, the output, and a brief stack trace).
[ugboundarysegmentstest.cpp](/uploads/661c16533556ceb8c99ce293aeb5b1ec/ugboundarysegmentstest.cpp)[output.txt](/uploads/e7e4782b9a23ea650d05cfeaa6dbf522/output.txt)[ugboundarysegmentstest.1.node](/uploads/3bf0487680add052d45737640e7d4100/ugboundarysegmentstest.1.node)[ugboundarysegmentstest.1.ele](/uploads/404c9fbf74d747a0cbc637a30b33273d/ugboundarysegmentstest.1.ele)[ugboundarysegmentstest.1.edge](/uploads/9b0764471c0c5f679f889406a8bb1388/ugboundarysegmentstest.1.edge)DUNE 2.6.0Ansgar Burchardtansgar.burchardt@tu-dresden.deAnsgar Burchardtansgar.burchardt@tu-dresden.dehttps://gitlab.dune-project.org/core/dune-grid/-/issues/54gmshtest-uggrid: fails since !145 was merged2017-04-07T14:32:03ZAnsgar Burchardtansgar.burchardt@tu-dresden.degmshtest-uggrid: fails since !145 was mergedThe gmshtest-uggrid test fails with a segmentation fault since !145 was merged. Reverting the merge makes the test pass again.The gmshtest-uggrid test fails with a segmentation fault since !145 was merged. Reverting the merge makes the test pass again.DUNE 2.6.0Ansgar Burchardtansgar.burchardt@tu-dresden.deAnsgar Burchardtansgar.burchardt@tu-dresden.dehttps://gitlab.dune-project.org/core/dune-localfunctions/-/issues/5Remove diffOrder from LocalBasisTraits2017-12-03T03:06:23ZCarsten Gräsergraeser@math.fau.deRemove diffOrder from LocalBasisTraitsOne reason to adopt the new interface of `partial()` in favour `evaluate()` was that the number of implemented partial derivatives should not be encoded in the interface type. However we still do so via the `diffOrder` template parameter...One reason to adopt the new interface of `partial()` in favour `evaluate()` was that the number of implemented partial derivatives should not be encoded in the interface type. However we still do so via the `diffOrder` template parameter and enum. I propose to remove both.
Since `diffOrder` originally denoted the number of partial derivatives implemented by `evaluate()` we could instantly remove the enum. it because it's meaningless now. However, for transition, we could also implement the following variants:
* keep the template parameter and drop the enum
* keep the template parameter but ignore it and always export the enum `diffOrder=0`DUNE 2.6.0https://gitlab.dune-project.org/core/dune-grid/-/issues/53UGGrid: Wrong geometry for nonconforming intersections2017-04-07T14:32:03ZLasse Hinrichsen-Bischofflh1887@mi.fu-berlin.deUGGrid: Wrong geometry for nonconforming intersectionsIf I refine a cube UG grid locally in an nonconforming way (i.e. `ClosureType::NONE`), I observed that after some refinements the intersection geometry doesn't seem to work properly in all cases. More specifically, it seems to be larger ...If I refine a cube UG grid locally in an nonconforming way (i.e. `ClosureType::NONE`), I observed that after some refinements the intersection geometry doesn't seem to work properly in all cases. More specifically, it seems to be larger than the smaller of two edges in some cases, which in my understanding should not happen. In contrast, e.g. ALUGrid doesn't show this behaviour.
I can not tell if the problem is in the wrapper or in UGGrid itself.
I'll attach a test case that triggers the problem.[dune-uggrid-bug.cc](/uploads/3f686eae26404ca2fb783728f2c68cc7/dune-uggrid-bug.cc)DUNE 2.6.0Ansgar Burchardtansgar.burchardt@tu-dresden.deAnsgar Burchardtansgar.burchardt@tu-dresden.dehttps://gitlab.dune-project.org/core/dune-grid/-/issues/52Add non default copy constructor and assignment operator for GeoGrid::GridView2017-12-11T15:55:22ZJakob SchneckAdd non default copy constructor and assignment operator for GeoGrid::GridViewCurrently the class `GeoGrid::GridView` has no explicit implementation of copy constructor and copy assignment operator and therefore default versions are used. But these are not always sufficient, since the stored index set is essential...Currently the class `GeoGrid::GridView` has no explicit implementation of copy constructor and copy assignment operator and therefore default versions are used. But these are not always sufficient, since the stored index set is essentially a pointer to the host index set. For example creating an object of type `GeometryGrid<GeometryGrid<...>, ...>` and using the copy constructor or copy assignment operator of the corresponding grid view can lead to a segmentation fault. (In this example the index set of the new created / reassigned grid view will point to the host grid view of the old (copied) grid view which possibly no longer exists.) Providing explicit implementations of the copy constructor and copy assignment operator as shown in the following snippet should fix this problem:
```c++
GridView( const This &other )
: grid_( other.grid_ ),
hostGridView_( other.hostGridView_ ),
// indexSet_ contains a pointer to host index set, so copying this can be dangerous in case we create GeometryGrid<GeometryGrid<...>, ...>
indexSet_()
{}
This & operator=( const This &other) {
grid_ = other.grid_;
hostGridView_ = other.hostGridView_;
// indexSet_ contains a pointer to host index set, so assigning it from other.indexSet_ can be dangerous in case we create GeometryGrid<GeometryGrid<...>, ...>
indexSet_ = IndexSet{};
}
```DUNE 2.6.0Martin NolteMartin Nolte2017-11-10