dune-tnnmg issueshttps://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/issues2023-03-27T14:18:49Zhttps://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/issues/5Removal of dune-common/dune/function.hh makes TNNMG unusable2023-03-27T14:18:49ZPatrick Jaappatrick.jaap@tu-dresden.deRemoval of dune-common/dune/function.hh makes TNNMG unusableIn https://gitlab.dune-project.org/core/dune-common/-/commit/cc5bb9fda147168ef83d88c1813bc43a1dc1277c
the deprecated file with the interfaces `Dune::Function` and `Dune::VirtualFunction` is now deleted.
`dune-tnnmg` still depends on thi...In https://gitlab.dune-project.org/core/dune-common/-/commit/cc5bb9fda147168ef83d88c1813bc43a1dc1277c
the deprecated file with the interfaces `Dune::Function` and `Dune::VirtualFunction` is now deleted.
`dune-tnnmg` still depends on this file in the definition of the functional classes.
I am opening an issue since I am not sure how severe the problem is.
A workaround would be to transfer the old interface from the `dune-common` module to `dune-tnnmg`, since we only need a few members and methods.https://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/issues/4[new_tnnmg] Tests do not compile with g++-4.9.2., g++-5.2and g++-5.3.12020-09-08T14:44:54Zlh1887[new_tnnmg] Tests do not compile with g++-4.9.2., g++-5.2and g++-5.3.1I noticed that the tests for the `new_tnnmg` branch do not compile with the mentioned compilers.
For g++ 4.9.2 (the one from the "old" Debian Jessie), this is probably the same issue as in #3 but this time for in `normfunctional.hh'. I ...I noticed that the tests for the `new_tnnmg` branch do not compile with the mentioned compilers.
For g++ 4.9.2 (the one from the "old" Debian Jessie), this is probably the same issue as in #3 but this time for in `normfunctional.hh'. I personally do not use this compiler anymore but it might be worth mentioning.
For g++ 5.2 and 5.3.1 (this is the one included with the current Ubuntu LTS, so not just a niche version), I get an error in the nonlinearperformancetest, see attached file [tnnmg_gcc_5_2_error.txt](/uploads/eaee5be8b6fda407b8a5c175c3adaad1/tnnmg_gcc_5_2_error.txt).
This can be "fixed" by removing the
`#include <dune/tnnmg/iterationsteps/nonlineargsstep.hh>`
line in `dune/tnnmg/functionals/quadraticfunctional.hh`. I don't see where the functional uses anything from the `nonlineargsstep.hh` header, but I might be mistaken. Also, I am not sure what really causes the problem here, as g++ 6.3 and clang seem to be happy according to the CI.https://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/issues/3Meta: gcc 4.x support2018-08-30T09:13:51ZpippingMeta: gcc 4.x support*I'm moving this here from #2 because that issue is and should remain closed and we were getting pretty off-topic. This could also be a wiki page. This is not really an issue but rather a documentation of the status-quo.*
GCC 4.9.x is...*I'm moving this here from #2 because that issue is and should remain closed and we were getting pretty off-topic. This could also be a wiki page. This is not really an issue but rather a documentation of the status-quo.*
GCC 4.9.x is not able to compile relevant branches of quite a few modules now. 4.9.2 is the latest version that current Debian stable comes with. This should come as no surprise because we don't have a build bot with gcc 4.9.x.
- [x] With 4.9.2 [but not 4.9.3](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766), you will get
```
.../dune/tnnmg/functionals/quadraticfunctional.hh:76:49: error: non-static data member declared ‘auto’
friend auto derivative(const AffineOperator& f)
^
```
and more such errors when compiling e.g. the nonlineargstest on **the feature/new-tnnmg branch of dune-tnnmg**. *Update*: This should be fixed with 9a2da3b0b9393198046e40836085a0f92f957235.
- [x] With 4.9.2 and 4.9.3 you'll get
```
.../dune/solvers/common/algorithm.hh:195:3: error: body of constexpr function ‘constexpr auto Dune::Solvers::Hybrid::Imp::integralRange(const Begin&, const End&, const Dune::PriorityTag<0ul>&) [with Begin = std::integral_constant<long unsigned int, 0ul>; End = long unsigned int]’ not a return-statement
}
^
```
when compiling e.g. the nonlineargstest on **the feature/new-tnnmg branch of dune-tnnmg**. This appears to be a C++14 feature ("Relaxing requirements on constexpr functions ") missing [from all versions of gcc 4.x](https://gcc.gnu.org/projects/cxx-status.html#cxx14). *Update*: This has been addressed, I believe, even though I do not know in which commit.
- [x] With 4.9.2 and 4.9.3 you'll get the error
```
.../dune/typetree/nodeinterface.hh:109:27: error: template declaration of ‘constexpr const size_t Dune::TypeTree::staticDegree’
constexpr std::size_t staticDegree = StaticDegree<Node>::value;
^
```
when compiling e.g. the stokes-taylorhood example or the gridviewfunctionspacebasistest from the **master branch of dune-functions**. *Update*: This goes away if one uses the **feature/no-variable-templates branch of dune-typetree**.https://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/issues/2[new_tnnmg] Iterations in nonlineargsperformancetest_iterates never converge ...2018-08-30T09:13:51Zpipping[new_tnnmg] Iterations in nonlineargsperformancetest_iterates never converge with NonlinearGSStep.I'm not 100% sure what this test does. In particular, in two different settings, it goes through three phases:
1. Solve with new `NonlinearGSStep`
2. Solve with new `NonlinearGSStep` (timed)
3. Solve with old `TruncatedBlockGSStep` ...I'm not 100% sure what this test does. In particular, in two different settings, it goes through three phases:
1. Solve with new `NonlinearGSStep`
2. Solve with new `NonlinearGSStep` (timed)
3. Solve with old `TruncatedBlockGSStep` (timed)
I don't quite understand the purpose of the first step. Either way, each step is composed of 10 calls to a loopsolver (which in turn does 100 iterations). The 10 calls are just to get a higher sampling number, I take it, so the numerical results are always the same and we can focus on just one of them.
So if I take the final output line by the loop solver in each case (not ten times), I get this:
```
7: maxTotalConvRate: 2, 100 iterations performed
7: maxTotalConvRate: 2, 100 iterations performed
7: maxTotalConvRate: 0, 2 iterations performed
7: maxTotalConvRate: 2.99221, 100 iterations performed
7: maxTotalConvRate: 2.99221, 100 iterations performed
7: maxTotalConvRate: 0.987341, 100 iterations performed
```
The `TruncatedBlockGSStep` converges with a maximum convergence rate of `0` or `0.987341`. The `NonlinearGSStep` has a `maxTotalConvRate >> 1` in both cases. Indeed, the size of the corrections blows up and this is not just the maximum convergence rate, it is the convergence rate in each step. Yet, the test declares success and passes.
It seems to me that the test is broken somehow (or rather, the direct-iterate-solving-logic of the `NonlinearGSStep`).
For comparison, the numbers from the `nonlineargsperformancetest_corrections` test:
```
6: maxTotalConvRate: 0, 2 iterations performed
6: maxTotalConvRate: 0, 2 iterations performed
6: maxTotalConvRate: 0, 2 iterations performed
6: maxTotalConvRate: 0.987341, 100 iterations performed
6: maxTotalConvRate: 0.987341, 100 iterations performed
6: maxTotalConvRate: 0.987341, 100 iterations performed
```graesergraeserhttps://git.imp.fu-berlin.de/agnumpde/dune-tnnmg/-/issues/1`binaryEqual` appears to be needed after all2018-08-30T09:13:51Zpipping`binaryEqual` appears to be needed after all**Update**: I see now why we indeed need this function. Let me go through my thought process anyway.
The issue mentioned in bisection.hh regarding unpredictable rounding from 80 to 64 bits is worrisome. It's also mentioned here:
...**Update**: I see now why we indeed need this function. Let me go through my thought process anyway.
The issue mentioned in bisection.hh regarding unpredictable rounding from 80 to 64 bits is worrisome. It's also mentioned here:
https://gcc.gnu.org/wiki/x87note
However, from my understanding (and please correct me if I'm wrong), this only happens if instructions for x87 FPUs are generated, and in particular not if SSE is enabled. With SSE, rounding is reasonable and predictable.
So now there are two questions:
1. when do we generate code for x87
2. can we really trigger an issue such as this when we do?
Question no. 1 appears to depend considerably on the compiler. It's actually hard to do this with clang. I need to use the command line
```
clang++ -m32 -mno-sse
```
The flat `-mfpmath=387` cannot be used on its own and something like `-m32 -mtune=generic` did not suffice: SSE was still used.
With gcc, this is quite different. As soon as gcc is in 32bit mode, it will use x87 FP arithmetic. To keep it from doing so, we need to use
```
g++ -m32 -msse2 -mfpmath=sse
```
The former flag is implied by `march` for architectures that support sse2. But the latter is not.
To test the implications of this issue, I wrote two test programs. The first one bisects the interval `[-M_PI_2, M_PI_2]` in search of `0`, i.e. the zero of `std::sin`:
```c++
#include <cassert>
#include <iostream>
#include <random>
int main() {
size_t const num_samples = 100;
std::default_random_engine generator;
std::uniform_real_distribution<double> left_distribution(-M_PI_2, 0);
std::uniform_real_distribution<double> right_distribution(0, M_PI_2);
size_t conv_counter = 0;
for (size_t i = 0; i < num_samples; ++i) {
double left = left_distribution(generator);
double right = right_distribution(generator);
// we need approximately 1000 steps to go down to 1e-300
for (size_t j = 0; j < 1500; ++j) {
double const middle = 0.5 * left + 0.5 * right;
if (middle == left or middle == right) {
assert(std::abs(middle) < 1e-14);
conv_counter++;
break;
}
double const mvalue = std::sin(middle);
if (mvalue > 0)
right = middle;
else
left = middle;
// std::cout << "[" << left << ", " << right << "]" << std::endl;
}
}
std::cout << conv_counter << std::endl;
return conv_counter == num_samples ? 0 : 1;
}
```
The second program checks if the the midpoint between two consecutive floating point numbers really needs to be equal to at least one of them.
```c++
#include <cmath>
#include <iostream>
int
main()
{
double x = 1.0;
double y = std::nextafter(x, 2.0);
double middle = (x+y)/2.0;
//std::cout << middle << std::endl;
if (x == middle or y == middle)
std::cout << "Behaving as expected" << std::endl;
else
std::cout << "Help, where are we?" << std::endl;
}
```
As I've mentioned before: To see proper behaviour, you can use something like
```
clang++ -std=c++11 -m32 foo.cc
```
or
```
g++ -std=c++11 -m32 -msse2 -mfpmath=sse foo.cc
```
For the opposite, we need
```
clang++ -std=c++11 -m32 -mno-sse foo.cc
```
or
```
g++ -std=c++11 -m32 -O1 foo.cc
```
(note the need for optimisation, at least `-O1`).graesergraeser