Feature/arbitrary virtual refinement

This merge adds more flexibility to the VirtualRefinement class. The old version of VirtualRefinement could only produce

2^n

sub elements per axis. For example, refined triangle with

n=2

:

|\
| `\
|   `\
|-----`\
|`\   | `\
|  `\ |   `\
|----`\-----`\
|`\   |`\   | `\
|  `\ |  `\ |   `\
|----`\----`\-----`\
|`\   |`\   |`\   | `\
|  `\ |  `\ |  `\ |   `\
|----`\----`\----`\-----`\

Now it is possible to have an arbitrary number of sub elements per axis. For example, a refined triangle with

3

sub triangles per axis is possible:

|\
| `\
|   `\
|     `\
|-------`\
|`\     | `\
|  `\   |   `\
|    `\ |     `\
|------`\-------`\
|`\     |`\     | `\
|  `\   |  `\   |   `\
|    `\ |    `\ |     `\
|------`\------`\-------`\

To use the number of sub elements in a call of a VirtualRefinement function an RefinementIntervals object must be passed, instead of just one int. For example, to call nVertices use

nVertices(Dune::refinementIntervals(n)).

To use the old functionality, call the same function with Dune::refinementLevels(int), which creates an RefinementIntervals object with

2^n

intervals.

Calling the VirtualRefinement functions with one int yields the same result as before, but will additionally give a deprecation warning.

The changes above are now also implemented for the StaticRefinement interface.

Intended merge date: 2017-08-28 (@joe).

Closes: !56 (merged).

added 1 commit

• e3f109e3 - [virtual refinement] Removes an unnecessary variable

Compare with previous version

added 3 commits

• f4599397 - [virtual refinement] Reverts renaming of hyper cube namespace
• 03770ddc - [virtual refinement] Consistent capitalization
• 26ba0070 - [virtual refinement] Replaces std::pow call and removes typo

Compare with previous version

OK, so now I've worked in all your suggestions.

added 1 commit

• 46f8503f - [virtual refinement] Uses more appropriate naming scheme

Compare with previous version

You are right with the names, they are a bit weird. I've changed it to the name you suggested.

There is also StaticRefinement in refinement/base.cc. It should not be too hard to extend it to support the tags, too.

Note: currently StaticRefinement derives from some refinement implementation, and just exports all the methods. Any methods you see declared in StaticRefinement are for documentation puposes only (e.g. inside #ifdef DOXYGEN). You can add tag support by actually implementing these methods inside StaticRefinement for real and just forwarding the calls to the base class (the implementation), converting from level to nIntervals as appropriate. This avoids the need to have backward compatibility methods in each implementation class.

Using tag classes instead of tag values is particularly convenient for StaticRefinement, because it completely avoids the need for dynamic dispatch. In VirtualRefinement you do have dynamic dispatch through the virtual method table anyway.

added 1 commit

• 37c4f178 - [virtual refinement] Uses static overloads instead of dynamic dispatch

Compare with previous version

added 1 commit

• dcca08f4 - [virtual refinement] Adds tag information to the test output

Compare with previous version

mentioned in merge request dune-grid!193 (merged)

added 1 commit

• 7eb1685f - [virtual refinement] Adds strongly typed refinement tags and deprecation warnings

Compare with previous version

changed the description