WIP: Implementation of a grid reader interface

I have implemented a proposal for the grid-reader interface (see issue #23) , using a CRTP abstract base class implementation, i.e. concrete file readers have to implement at least (2) of

template <class... Args> // (1)
static std::unique_ptr<Grid> readImp(const std::string &filename, Args&&... args);

template <class... Args> // (2)
static void readFactoryImp(GridFactory<Grid> &factory, const std::string &filename, Args&&... args);

The static method (1) redirects to (2) in its default implementation by creating a GridFactory internally. The additional arguments are here just for illustrational purposes. They are forwarded to the concrete implementation.

Several readers are adopted to this interface, i.e. gmshreader, starcdreader, amirameshreader, dgfparser (a new reader classes is added), albertareader. The amirareader could not yet be tested, due to lack of a the amira-code.

A small test is added that currently just calls the two read methods for the grid implementations UGGrid and AlbertaGrid for dim=dimworld=3. Therefore it was necessary to provide mesh-files that can be read by all the tested readers, i.e. simplicial-meshes in dimension 3.

mentioned in issue #23

Added 1 commit:

• ead70423 - test of grid-readers corrected, i.e. created grids are deleted after creation

Added 1 commit:

• 5b40b739 - Implementation of accessor pattern in gridreader interface to allow to hide the …

Discussion in the Dune dev meeting 2018:

• readImp should have a second form accepting an input stream
• return parameters for element/boundary data should be unified
• Maybe use an object instead of static methods, maybe this object should behave more like a grid factory

1. Some readers, like AlbertaReader, do not and can not have an overload for iostreams. This is, because it calls a C library for the actual read. So, then I need to add a default implementation that throws an error if the concrete reader has no implementation for streams?

2. I like the idea of having a unified interface for reading some more data from the files, since many file formats store these values. I will have a look and try to extend the proposal. MAybe I have to discuss this with someone having more experience with these data fields

3. Using an object instead of a static implementation can probably be done easily. I was just thinking, I see rarely any data that should be stored in the object, so that it is not necessary to really have an instance of the class. But maybe this changes when some data readers are added (?). Maybe one could add some flags to decide what to read or about verbosity in a constructor.

Timo Koch and I brought this up at the dev meeting and would be happy to help. Concerning the data, we think that the parameters interface of the GridPtr should be general and good enough to cover everything needed.

For DGF and Gmsh data, we already have stuff in Dumux that we could outsource.

mentioned in merge request !312 (merged)

mentioned in issue #133