[Dune-devel] YaspGrid becomes a tensor product grid

[Oliver Sander]

Hi Dominic,
great to hear you are working on this.  I had a quick look at your code,
and here are a few thoughts.

- even with SPGrid around I still think that YaspGrid remains important,
   because I need an extra module for SPGrid, while YaspGrid is right
   there.  This doesn't mean that YaspGrid shouldn't be touched, though.
- Your tree contains cleanup together with actual new code.  Can you
   send the cleanup as separate patches?  I would commit such patches
   immediately.
- The base class of YaspGrid is only there for historic reasons.
   Hence the constructor documentation should not mention "is forwarded
   to the base class"
- In fact, major kudos to the person who merges YaspGrid and its base
   class.
- Some YaspGrid constructors take FieldVector<bool> arguments.  Those
   exist only for backward compatibility.  If you write new constructors
   those should take std::bitset instead.
- Will you try how much slower the code is now?  Since the new coordinate
   vectors are only accessed when geometries are created I would expect
   that the slowdown is minimal.  This would actually be a good use case
   for the new benchmarking system.  If your code is slower: have you
   considered adding a static switch that changes between the old
   and the new behavior?
- Please use array<int> instead of FieldVector<int>.  FieldVector implements
   elements of a vector space, but you can't have a vector space based
   on int.

Best,
Oliver

Am 30.08.2013 15:51, schrieb Dominic Kempf:
> Dear Dune Community,
> I have spent the last weeks working on YaspGrid to make it a tensorproduct grid.
> For those of you who dont know: A tensorproduct grid is a structured
> axiparallel cube grid characterized by a coordinate vector for every
> coordinate direction. In 2D two vectors x = {x_0,...,x_s(0)} and  y =
> {y_0,...,y_s(1)} are given. The resulting grid is made of the
> following vertices: { (x_i,y_j) | i=0..s(0), j=0..s(1)}. Such grids
> are of great interest for quite a lot of people here in the Heidelberg
> DUNE community. Workarounds based on UG and GeometryGrid have been
> used that created gigantic overhead. After the release of SPGrid, Yasp
> is no longer urgently needed and was thus recoded into a
> tensorproductgrid.
> Some remarks:
> - In the backend (i.e. in the header /yaspgrid/grids.hh) the grids are
> entirely characterized by their coordinate vectors.
> - The code is completely backwards compatible. For all old
> constructors, coordinate vectors are generated. Due to the relatively
> low memory needs (in comparison to a DOF vector), this was chosen over
> a specialization of the backend code for the equidistant case. Should
> extensive performance testing show, that this is a problem, this will
> be implemented.
> - The data structure to be used to give coordinates to the constructor
> of YaspGrid is Dune::array<std::vector<ctype>, dim>. Helper classes to
> generate such vectors with sequences such as geometric series are to
> follow, but not part of this first release.
> - As a side effect, YaspGrid is no longer tied to having a trivial origin!
> - While digging through the backend code, I realized a lot of
> redundant code or code that is actually never used. Such things have
> not been tackled yet.
>
> Unfortunately implementation is not yet done completely. The following
> features are NOT yet fully implemented:
> - periodic grids
> - the refinement option choosing to keep the overlap in cell size,
> instead of physical size.
>
> I invite everybody to take a look at my work and test it. You find the
> feature branch on my github account:
> https://github.com/dokempf/dune-grid/tree/feature/tensorproductgrid
>
> I will not be available to work on this until around mid of november,
> but until then, I would like to collect your feedback and wishes to
> make the new YaspGrid first choice for problems that require a
> tensorproduct grid.
>
> Best regards,
> Dominic Kempf
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel
>