[Dune] DGFParser interface

Christian Engwer christi at uni-hd.de
Mon Jul 24 15:56:34 CEST 2006


Hi,

today I discussed with Robert what we have to do before the release of
1.0.

We agreed that every major feature in dune 1.0 should be stable and
easy to use. We think the dgfparser is a tool that make using dune a
lot easier, especially for newbies. Therefor the interface should be
as simple as possible. We were discussing two alternatives, how we
could improve the usability.

We considered the GridPtr class a hack to avoid pointers and to avoid
the need of a uniq constructor for all grids.

Option one would be to define a uniq constructor in the interface and
make this a requirement for all grids.

This uniq constructor might look like this:

DuneGridFormatParser p("filename");
Grid<...> g(p, mpi_comm);
g.lbegin();
...

The second option is to subclass the gridclass and do the
specialization in this subclass grid:

template<class Grid>
class MacroGrid<Grid> : public Grid, private DuneGridFormatParser
{
public:	
  MacroGrid(const std::string &fname, MPI_Comm comm);
}

We should also consider adding a second constructor 
  MacroGrid(const std::string &fname)
which instatiates sequentiell grids. If your grid uses MPI it could
just use MPI_COMM_WORLD and test for a size of 1.

The usage might the look like

MacroGrid< Grid<...> > g("filename", mpi_comm);
g.lbegin();
...

Even when using the derived class MacroGrid we could pass the Parser
as a constructor parameter:
  MacroGrid(const DuneGridFormatParser &parser, MPI_Comm comm);

What is your opinion regarding these different proposals? Are there
other ideas?

CU Christian




More information about the Dune mailing list