Unify lagrange cube implementations

added 1 commit

• 75da6412 - Add an explicit empty user-defined default constructor

Compare with previous version

CI failures are apparently caused by virtual memory exhaustion. Sigh...

Lack of virtual memory should be a runner configuration issue; I've retried the build a few times to get some other CI runner to build it (now building on hd-2c-8g-1h instead of dune-ci@sky.uni-muenster.de). If that succeeds, we should ask to increase whatever limit on the Münster CI Runner.

There aren't any limits memory-wise, unless @marcel.koch introduced some. There are 384GiB main memory and no swap. According to last, I was the only one logged in on that machine today, and I wasn't doing anything memory-related. Maybe the recent Ubuntu 18.04 upgrade introduced something? Otherwise it's probably the compiler tripping over itself.

It's probably the compiler; it failed with an internal compiler error on the other runner.

added 7 commits

• 75da6412...fd823dbe - 4 commits from branch master
• db3765bf - New class LagrangeCubeLocalFiniteElement
• 303cb78f - LagrangeCubeLFE: Implement the general-order case
• b3d6ac91 - Add an explicit empty user-defined default constructor

Compare with previous version

So what do I do to get my MR merged?

Going by the assumption that this is a compiler bug, I'd try to build a reproducer, figure out what exactly triggers it (applying the changes one-by-one in a minimal way, or, failing that, reducing the reproducer with the help of C-Reduce). Understanding what exactly triggers it should then make it possible to figure out a way to work around it.

added 11 commits

• b3d6ac91...b90a3cee - 8 commits from branch master
• 5a2c2cca - New class LagrangeCubeLocalFiniteElement
• e3e0b7a3 - LagrangeCubeLFE: Implement the general-order case
• ddee8040 - Add an explicit empty user-defined default constructor

Compare with previous version

added 5 commits

• ddee8040...ad9af0d4 - 2 commits from branch master
• a238f676 - New class LagrangeCubeLocalFiniteElement
• 732f3721 - LagrangeCubeLFE: Implement the general-order case
• 2103a8eb - Add an explicit empty user-defined default constructor

Compare with previous version

added 1 commit

• 2cc4dbb7 - Partially bring back Q1LocalFiniteElement for older compilers

Compare with previous version

added 1 commit

• 976e0576 - Partially bring back Q1LocalFiniteElement for older compilers

Compare with previous version

The problem seems to be the class Impl::LagrangeCubeLocalCoefficients, but as that class doesn't really do any dirty tricks at all I didn't look any further. I added a patch that brings back the original Q1LocalCoefficients if the compiler is gcc-6 or earlier. That makes the CI system pass. Are there objections to merging the code like that?

merged

mentioned in commit 140fd947

Though I like this change very much, I was a bit surprised that entire classes have been removed without any deprecation warning or changelog entry.

Of course the replacement is quite easy, but I would have liked to know for example that the order of the template parameters of the local coefficients has been reversed (the QkLocalCoefficients class was not marked as an implementation detail before!).

Yes, I took a deliberate risk there. :-) For me, QkLocalCoefficients and friends are implementation details, and the only reason they are not marked as such is because nothing was marked as implementation detail back in the days when we wrote them.

But I understand if people disagree on this point, and if you need some of these classes we can bring them back.

No, you can leave it as it is. The former fragmentation of the different Q^k classes seemed rather artificial anyway. I'm accepting the risk of having to change template parameters once in a while ;-)