Make GeometryType constexpr

This merge request makes all eligible constructors and members of GeometryType constexpr. I only skipped those functions for which it doesn't make sense (I/O) or is not possible for all supported compilers. The merge request also adds new static factory functions that do the same as the make...() methods, but return a new GeometryType instead, which is much more useful in constexpr context.

The main reason for wanting a GeometryType that works in constexpr context is some code in PDELab that returns the number of DOFs per GeometryType. Being able to call that code constexpr would make it possible to automatically deduce correct ISTL block sizes. Currently, we rely on the user to correctly set the block size, which leads to ugly, silent run time errors that are really hard to debug.

added 4 commits

• fbd37337 - [GeometryType] Make GeometryType mostly constexpr
• 97bcc761 - [tests] Add a new test for constexpr GeometryType
• 4a9a419c - [GeometryType] Add constexpr static factory functions for GeometryTypes
• 01025658 - [tests] Test GeometryType factory functions

Compare with previous version

What is a 'singular'?

The documentation in the file says that 'none' means "Generic element in any nonnegative dimension". Isn't that something else?

I don't know, I just copied blindly from makeNone(dim)...

But please don't confuse this with "extended"! :-)

changed this line in version 4 of the diff

added 1 commit

• 1bc5179d - [tests] Test GeometryType factory functions

Compare with previous version

Nice. In other words I can use the return value of id() at compile time? Does this allow to get rid of the recursive construction in lines (roughly) 25 -- 250 ?

Yes, that works now. As to that construction, I don't know if those topologies were used in other contexts... @martin.nolte ?

Can we keep to our coding style and make these functions start lower-case?

As I explained below, they seemed so constructor-like, just with different names. But I'm not overly attached to that detail, and I'll try and give @martin.nolte's idea of using constexpr variables in a namespace a spin.

changed this line in version 4 of the diff

@oliver.sander: These are the original construction structures. I have been thinking about getting rid of Point, Prism, Pyramid for quite some time, but it does not seem to be that easy. They are used in more places than I expected, especially in dune-localfunctions and dune-fem.

Therefore, I'll try to answer the other way round: What you definitely want is the methods like isPrism as they allow switching over the construction type from the (topologyId, dim) pair. Without these, the entire generic construction degenerates into bit-manipulation formalae that nobody wants to read or maintain.

As a start, however, we should replace the structs like PyramidTopology, which only return the topologyId in a compile-time static manner. As they are implementation details, we can remove them without deprecation. I think this should go into a separate merge request, though.

As for the actual MR: I do not see the advantage of Dune::vertex over Dune::GeometryType::vertex. I somehow do not like burning names like Dune::vertex or Dune::simplex (which is unfortunately used by dune-alugrid, too).

Moreover, why is a free-standing function better than a variable like Dune::Partitions::border? I imagine something along the lines of Dune::GeometryTypes::vertex or Dune::GeometryTypes::simplex(3), where the first is a variable while the second is a constexpr function, of course. This way, you can abbreviate your code by using namespace Dune::GeometryTypes without burning these names in the Dune namespace.

Hmm, it looks like my explanation wasn't entirely clear: I didn't put any new names into global namespaces, I just added static constexpr members that let you write Dune::GeometryType::Vertex(). As @joe remarked, he doesn't like the uppercase. To me, they seemed a little like constructors with fancy names, that's why I capitalized them. But I actually like the idea of providing constants in a namespace. :-)

@smuething: Oops, sorry. Seems like I messed up understanding the diff.

Oh, I remember the problem with global variables: Simplex(dim), Cube(dim) and None(dim). When providing the objects as constexpr variables, that parameter would need to be become a template parameter, which I didn't like.

Yes, but simplex, cube and none could become constexpr functions, e.g., GeometryType none(unsinged int dim).

OK, that would solve the problem.

One more thing: I we revise the "constructors" we should remove (deprecate) the old makeVertex-like methods.

That's a good idea (I would have suggested the same), but should probably go in a separate MR.

Yes, it should.

added 2 commits

• 68a1f424 - [GeometryType] Add namespace GeometryTypes with constexpr variables and factory functions
• f4755cb0 - [tests] Test objects in namespace GeometryTypes

Compare with previous version

OK, I replaced the factory functions inside GeometryType with variables and free functions in namespace Dune::GeometryType. The tests won't pass for now as this depends on dune-common!304 (merged).

I meant namespace Dune::GeometryTypes, of course.

added 1 commit

• 1af9f005 - [doxygen] Add missing group directive for vertex variable

Compare with previous version