[Dune-devel] YaspGrid becomes a tensor product grid

[Martin Nolte]

Hi Oli,

apart from possible regression in Dominic's branch, I think we should 
(briefly?) discuss this on the developer meeting before taking any action.

Best,

Martin

On 09/12/2013 12:41 PM, Oliver Sander wrote:
> Hi Dominic,
> I just had another look at your code, and cleaned up the patches a little
> bit.  I was about to push the result, when I noticed a line of code that
> you out-commented, saying
>
> //TODO laesst sich auskommentieren so lange non-periodic
>
> Does that mean that your patch introduces a regression?  Can I still use
> periodic grids with your patches as they are now?
>
> 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
>>
>
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany