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

[Jö Fahlke]

Am Wed,  3. Nov 2010, 15:12:53 +0100 schrieb Oliver Sander:
> >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.

It is related, but it is not the same: FS 699 concernd parameters of the grid,
this however concerns the grid creation process.  Consider for instance the
heapSize-parameter of UG: does it even make sense to change it once the grid
has been created?  By that time you already have run out of memory.

Note also that this is meant for the GridFactory, not for the Grid itself:
The factory provides a unified interface for the construction of certain
(unstructured) grid, which the grids themselves don't do.  It is currently
impossible to pass something like the heap_size parameter without
special-casing your program for UG (and with the StructuredGridFactory it is
impossible even then).

Wait a minute... "static methods"?  You want to set grid creation parameters
globally before constructing the grid?  Or do you want to introduce a kind of
gridmanager-specific GridParameter object, and the static methods set
parameters in that object, and this object is then later passed to the
constructor of the grid?

> >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.

The main reason for the additional ParameterTree parameter here was so I could
implemented 4) in terms of 3) without having to greatly rewrite the original
methods.  Still It may be useful on it's own.

The problem with the StructuredGridFactory is that all the grid creation
methods are static -- it acts more like a "namespace template" than an actual
class template.  Otherwise you could provide the ParameterTree to the
constructor of the StructuredGridFactory or set it later using a member
function.

> >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.

Except that your code does not handle default values, and it is difficult to
make it so because array has no suitable constructors.  Also, letting the
StructuredGridFactory do the interpretation of the ParameterTree means that
the parameter names are standardized.

>                              With your new method I may as well start
> replacing the arguments of each and every method with a ParameterTree.

The new method was not meant to replace the old one, it was rather meant as an
alternative to avoid often-repeated code.

> >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.

Well I was trying to create a 512x512 UG grid, and UG ran out of ID space or
something similar.  As a solution I was told to create a coarser grid and use
globalRefine() to obtain a gridView of the desired resolution.

So I believed it would make sense here because I wanted to create a certain
*GridView* while you are probably thinking of creating coarse grids for *grid
hierarchies*.

5) as a whole is a kludge anyway: even if you are just interested in a certain
GridView, you will end up with different results for different grid managers
because of different refinement strategies (i.e. Alberta vs. ALUGrid/UG).
A better way to achive a particular gridview would probably be to do something
like "refine until largest edge is smaller than x".

Summing up 5): I'm not too happy about it, do see now that it is off-topic for
the StructuredGridFactory and am probably going to vote against it myself.

Jö.

-- 
It is my conviction that killing under the cloak of war is nothing but
an act of murder.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20101103/caf2c1da/attachment.sig>