GridPtr can also read gmsh files and then handle the load balance of user data.

This MR adds the ability of reading gmsh files to the GridPtr class. This needs testing by some gmsh users.

@andreas.dedner @tkoch @bernd.flemisch

I think this is the most practical approach to the unification for reading a grid with different parsers. Please take a look and let me know what you think.

I get an error when trying make build_tests:

dune-grid/dune/grid/io/file/gmshreader.hh:613:13: error: no matching function for call to ‘Dune::GridFactory<Dune::YaspGrid<3> >::insertBoundarySegment(std::vector&, std::shared_ptr<Dune::BoundarySegment<3> >)’ factory.insertBoundarySegment(vertices,

I guess this could be seen as a mistake in the GridFactory implementation of YaspGrid or we need some SFINAE to avoid compiling in the GMestReader in cases like yaspgrid

Since the name GridPtr seems to be of considerable annoyance to some, I suggest to rename the class (or add a using and deprecate). What would be a better name? I came up with DuneGridReader but the problem is that it doesn't behave like a Reader so perhaps not the best name. Any suggestions?

I guess that is why there are specializations for each grid in DGF ;-) We can use the singleGeometry capability for this since the gmsh only reads simplices anyway.

The other option is of course to add the gmsh format to the simplexgenerator section or something like it.

That is not correct gnshreadet reads hybrid grids definitely including cube elements.

But is the problem not simply a bug in the grid factory implementation that yaspgrid used? Shouldn't the method just be there and throw?

I guess that is correct. Then one could catch that throw inside GridPtr.

I don't see how this is an extensible solution. What if I wanna add a vtk reader now?

this is useful though as it shows what problems come up. I guess this can be wrapped in a virtual interface and then everyone can add user implementations.

If you want to add a vtk writer then you'll need to add a few lines for capturing that case, naturally. Of course it's possible to define an abstract interface for that, but my opinions is that it's not necessary. On the other hand, nobody is forced to use a specific format and reader. GridPtr is just a convenience implementation for dealing with the load balancing of the parameters etc. All of that needs to be reimplemented in the general interface concept that you are envisioning. I thinks it's simpler to just fill GridPtr from a given reader/grid factory. And for that, you may want to define an interface.

The other option is of course to add the gmsh format to the simplexgenerator section or something like it.

No it is not, because gmsh support many different mesh types.

added 2 commits

• 15d08281 - [bugfix][GridFactory] corrected forwarding of default implementation of…
• 19a3b661 - [feature][GridPtr] GridPtr can also read gmsh files and then handle

Compare with previous version

@christi: Don't understand. The simplexgenerator can use gmsh to create a simplex mesh. But anyway, another block for reading gmsh can be added, or like now the GmshReader is used to read the grid, whatever element types it may have.

@andreas.dedner: Should compile now. It was a bug in the default gridfactory implementation.

Christian's point is that gnshreadet can handle more general grids then simplex grids

I understood that. Anyway, here is a suggestion how to generalize the reading of a grid. Just one possibility.

Disclaimer: Not an interface!.

marked as a Work In Progress

added 3 commits

• 57efe288 - [bugfix][OnedGridFactory] use default implementation for insertionIndex
• 9aacab75 - [cleanup][gridcheck] remove warnings caused by unused variables in
• 0a8c7b07 - [feature][GridPtr] GridPtr can also read gmsh files and then handle

Compare with previous version

added 3 commits

• 0a8c7b07...7e9a6828 - 2 commits from branch master
• 3cedf86d - [feature][GridPtr] GridPtr can also read gmsh files and then handle

Compare with previous version

Is it possible to clarify the relation of this MR to !90 and #23?

I would say it's a bit alternative to !90, because the interface is hidden inside GridPtr. At the end of the say one wants something that translates a filename or input stream into a grid and some data. GridPtr does exactly that, and with this PR you can pass either gmsh or dgf files. Adding the other readers is more or less straight forward. As @tkoch pointed out, it is however not extendible in the way that someone derives a class and overloads a method. You would have to add an if statement with the file format/reader specifications. That kind of if statement has to be done somewhere, either in a main routine of, for example, in the GridPtr. That's just a matter of taste. And, as pointed out earlier, when adding a couple of lines to the GridPtr, the load balancing of the user data comes for free.