[Dune-devel] [GSoC] Status update

[Xinyun]

Hello Oliver,

Thanks for your detailed and clear decomposition. Sorry I didn't reply 
in time because I just moved into a new flat and didn't have Internet 
last week.
I have mainly followed your steps and uploaded them to Gitlab. Please 
check if I did it correctly.

Now should I create the entity class and complete the leafIterator 
class? Below are my elementary thoughts.
1.For the BSpline entitry class
template<int codim, typename GridImp>
class BSplineGridEntiry

contains a BSplinePatch object pointer and an index indicative of the 
knot span where it locates. Also, a geometry function should be provided 
to access the BSpline geometry the entity binds to.

2. The BSpline leaf itertator class
template<int codim, typename GridImp>
class BSplineGridLeafIterator

should contain an gridView object and an index. The operator* method, an 
operator != method, and an operator++ should be implemented.

Please kindly correct my ideas. If you agree on them, I will start 
implementing them.

Best regards,
Xinyun


On 06/29/2016 06:44 AM, Oliver Sander wrote:
> Hi Xinyun,
>
> too bad you didn't write earlier.  You seem to have gone off slightly in a bad direction.
>
> This just goes to show that it would be really great if we had a text that describes
> how to write grids!
>
> Namely, you do not have to use the DefaultGridView class, and you do not have to implement
> all the GridTraits at once.  Here is my proposal for how to proceed in small steps:
>
> 1) Write a class
>
> template <int dim, int dimworld>
> class BSplineGrid;
>
> with a constructor that accepts all information needed to setup a B-spline patch.
>
> 2)  Write a class
>
> template <int dim, int dimworld>  // more parameters, if needed
> class BSplineLeafGridView;
>
> with a constructor that accepts all information needed to setup a B-spline patch.
>
> 3) The BSplineGrid class gets a data member 'BSplineLeafGridView leafGridView_'.
>
> Make the following snippet compile
>
> BSplineGrid<2,3> grid;
> auto gridView = grid.leafGridView();  // returns the BSplineLeafGridView by value
>
> 4) Write an empty class
>
> template <int codim, int GridImp>  // more parameters, if needed
> class BSplineGridLeafIterator;
>
> 5) Make the BSplineLeafGridView export the type of the iterator:
>
> The following typedef should return the type of the new iterator
>
> template <int codim>
> using NewIterator = BSplineLeafGridView::Codim<codim>::Iterator;
>
>
> These should all be reasonably easy to do.  I need to go now, but I can add more steps
> later today.  If you want we can have another phone call, but that would practically
> have to be tomorrow between 14:00 and 16:00.  After that I am unavailable until next
> wednesday.  Or maybe one of the other mentors can step in.
>
> Cheers,
> Oliver
>
>
>
> On 27.06.2016 16:55, Xinyun wrote:
>> Hi Oliver,
>>
>> Sorry I did not report my latest progress to you as I really feel stuck somehow.
>>
>> Last week, I spend quite some time to read and understand the source code of onedgird and vtkwriter as well. I found for most girds they use the defaultGridView which takes the gird type as a template parameter. It means that we don't need to manually implement a specific girdView but we need to implement all the grid traits. It seems that vtkwriter requires all or most gird traits specifications.  So I decided to set the vtkwriter as a long term goal in the very end.
>>
>> Then I tried to decompose the long term goal into realistic small ones. Having every trait implemented is not realistic for me in a short time so I picked out three important traits in a priority order: gridentity, gridLeafIterator, gridIndexSet. It doesn't mean the others are not needed, for example, girdintersectioniterator.
>>
>> Aftereards, I attempted to imitate the entity implementation of onegrid. But I found the OneDGridEntity is inherited from the EntityDefaultImplementation and wraps the OneDEntityImp object. Another class
>> OneDGridEntityPointer then wraps a OneDGridEntity object and is the base class for the gridLeafIterator. These relations may be very clear to experienced dune develops but it really took me a while to figure them out. Then I have doubts on how to define a B-Spline entity. In isogemetric analysis, the knot span is considered as the element in finite element analysis. So should I take each knot as a vertex(0-dimension entity) and every possible knot cube(with multiplications) as an element(1-dimension entity)? Or do I just need the element since the vertex doesn't make a lot of sense?
>>
>> Please correct me if I made any mistake or I'm going to a total wrong direction. I feel very sorry that I am moving slowly. Now I am still working on the BSplinePatchEntityImp, BSplinePatchEntity and BSplinePatchEntityPointer. I hope very much that I can finish and show you this week.
>>
>> Best regards,
>> Xinyun
>>
>> On 06/26/2016 10:04 PM, Oliver Sander wrote:
>>> Hi Xinyun,
>>>
>>> how are you?  I am writing to enquire about the current status of your GSoC project.
>>> The last time we talked in person we agreed that the next milestone should be a
>>> spline surface that can be written to a file by the standard VTKWriter class.
>>> You have shown good results so far, but in your git repo I see no movement at all
>>> towards the VTK milestone.  Does that all happen on your local machine?  Then please
>>> share the current status with me, to keep me informed.  Or are you stuck with some
>>> questions?  In that case, I am here to help.
>>>
>>> Cheers,
>>> Oliver
>>>
>>>
>>>
>>> _______________________________________________
>>> Dune-devel mailing list
>>> Dune-devel at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20160705/3025069c/attachment.htm>