[Dune-devel] [GSoC]Updates and problems

[Xinyun]

Hi,

Markus, thanks for your comments. Following your suggestions, I made a 
vector of BSplineGirdEntity as a member in the BSplineLeafGridView class 
and sovled the problem. Finally the code is able to compile and is 
available online now. With the iterator, entity and girdView class, a 
range-based for as below is possible.

IGA::BSplineGrid<dim,dimworld> grid(knotSpans, controlNet, order); auto 
gridView = grid.leafGridView(); for (auto const &element:gridView) { 
auto geometry = element.geometry(); //blabla }

I'm not sure if this is what you expect from the iterator. Please check 
if I need to add or modify anything to keep consistent with DUNE grid 
interface. I'm now trying to make a BSplineGridLeafIndexSet class. I 
tried to imitate the OneDGridLeafIndexSet class and here are my 
elementary thoughts:

template<class GridImp>
class BSplineGridLeafIndexSet :
public IndexSet<GridImp,BSplineGridLeafIndexSet<GridImp> >

contains an index function which returns the index of a 
BSplineGridLeafEntity.

Is it OK? And should I also implement an Intersection class? Would be 
helpful if you can provide me some detailed steps.

Cheers,
Xinyun



On 07/15/2016 01:47 PM, Markus Blatt wrote:
> Hi,
>
> On Thu, Jul 14, 2016 at 10:07:18AM +0200, Oliver Sander wrote:
>> Hi Xinyun,
>> [please keep the discussions on the list.]
>>
>> I think your BSplineLeafIterator class needs to hold a (shared) pointer so the entity it points to,
>> in addition to the directIndex.  Then what 'dereference' returns is
>> not a temporary anymore.
> I do not agree with this fix as it might cause dangling
> references. I am sure that at some point this pointer will be reset
> (e.g. by operator++ being called). In this case we might have a reference to
> a non-existent object or the value pointed to might be different. Both
> are really hard to detect/debug. Just imagine this:
>
> Iter iter = bla.begin();
> auto& ref = *iter; // everything ok.
> ++iter; // Most probably resets the shared_ptr or overwrites the value
>          // pointed to.
>
> Either we have a really hard to debug dangling reference or it does
> not point to the spline that the user expects (second spline instead
> of first).
>
> May I ask why the BSplineGridEntity is created on demand?
>
> If it is for a really good cause, then the iterator should not return a
> reference, but a proxy object that contains a shared_ptr to it. But
> the reason must be really, really, really good. std::vector<bool> does
> this but it is really frowned upon.
>
> Otherwise the question should read:
>
> Why can't we create a container of BSplineGridEntities and thus get
> rid of the problem?
>
> Markus
>
>> On 14.07.2016 00:28, Xinyun wrote:
>>> Hey Oliver,
>>>
>>> In the past few days I tried to make the BSplineLeafIterator work
>>> using the Barton-Nackman trick. You can check here
>>> <http://gsoc2016xinyun.blogspot.de/2016/07/make-b-spline-grid-iterators-work.html>
>>> for more details about what I intended to do. But I encountered a
>>> specific programming problem which even hindered me to compile the
>>> code. I have spent some time to play around but still couldn't
>>> make it through. So I think it's better to ask for your help. As
>>> the code still contains errors, I didn't upload it to gitlab.
> But that might make commenting on code a bit easier.
>
> Markus
>

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