[Dune] [Dune-Commit] dune-grid r7063 - in trunk/dune/grid: albertagrid alugrid/2d alugrid/3d common onedgrid uggrid

[Oliver Sander]

Hi Jö!

> Hmm, possibly.  I saw this as a backward compatible addition rather than a
> change but probably the latter is meant to contain the former.  Shall we vote
> on that now or shall I move the stuff to a branch and we vote on it later?
>    
I think backward compatible additions are interface changes.
> Here are the exact additions, later addition depend on earlier ones:
>
> 1) I propose the give the GridFactory an additional constructor signature of
>     the form
>
>       GridFactory(const ParameterTree&);
>
>     This constructor is meant for passing options from a (user written)
>     parameter file to the grid creation process.  An empty ParameterTree here
>     is equivalent to calling the default constructor.  Parameters unknown to
>     the particular grid manager are ignored.
>    
This is closely related to FS 699.  Maybe we should settle that one first.
> 2) Use 1) to support passing UG's heapSize parameter as a "heap_size"
>     ParameterTree option to the GridFactory.
>    
There has been the alternative proposal to use static methods of the
grid instead of constructor arguments to pass this kind of parameters.
I am not sure which one I like better.

> 3) On the StructuredGridFactory add the signatures
>
>       static shared_ptr<GridType>
>       createSimplexGrid(const FieldVector<ctype,dimworld>&  lowerLeft,
>                         const FieldVector<ctype,dimworld>&  upperRight,
>                         const array<unsigned int,dim>&  elements,
>                         const ParameterTree&params);
>       static shared_ptr<GridType>
>       createCubeGrid(const FieldVector<ctype,dimworld>&  lowerLeft,
>                         const FieldVector<ctype,dimworld>&  upperRight,
>                         const array<unsigned int,dim>&  elements,
>                         const ParameterTree&params);
>
>     The additional ParameterTree parameter is simply passed to the underlying
>     GridFactory and not otherwise acted upon by the StructuredGridFactory
>     itself.
>    
This is the reason why static methods may be better:  with constructor
arguments you have to tunnel the parameters to a lot of places.
> 4) On the StructuredGridFactory add the signatures
>
>       static shared_ptr<GridType>
>       createSimplexGrid(const ParameterTree&params);
>       static shared_ptr<GridType>
>       createCubeGrid(const ParameterTree&params);
>
>     These extract the properties of the Grid to create from the ParameterTree
>     and then call the functions introduced in 3).  The following options are
>     recognized:
>
>       bbox.lower ->  lowerLeft  (default: vector of 0)
>       bbox.upper ->  upperRight (default: vector of 1)
>       elements   ->  elements   (default: array of 1)
>    
This methods doesn't appear very helpful to me.  If I understand it 
correctly
a call to this method would replace a call like
    createSimplexGrid(params.get<array<int,dim> >("bbox.lower"),
                                    params.get<array<int,dim> 
 >("bbox.upper"),
                                    params.get<array<int,dim> 
 >("elements"));

which I find simple enough.  With your new method I may as well start
replacing the arguments of each and every method with a ParameterTree.
> 5) On the StructuredGridFactory add the following ParameterTree option to the
>     to the functions introduced in 4)
>
>       global_refines ->  number of globalRefines() to do after the grid has been
>                         created according to the other options.
>                         (default: 0)
>    
This violates the UNIX philosophy (i.e. beware of the eierlegende 
Wollmilchsau):
The StructuredGridFactory should only construct structured grids.  
Refinement
is a separate business and should be done elsewhere.

Executive summary: there are good reasons for your changes, but at least
for me there are good reason against them, too.  So I think we should 
discuss
them.

Best,
Oliver
> Bye,
> Jö.
>
>    


-- 
************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75348           *
* Institut für Mathematik      ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************