[dune-functions] [Dune-functions-commit] [Commit] dune-functions - c7b3989: Resize must now be done manually before interpolate()

[Carsten Gräser]

Hi,

Am 14.09.2015 um 22:23 schrieb Oliver Sander:
> 
> Hi Carsten,
>> there are two parts to this question:
>>
>> a)Should we expect the user to resize manually?
>> we could simply call this in the interpolate method. But the result of
>> calling this will be rather complicated to describe for a nested vector,
>> especially because we only write into a subset of components in general
>> and it's hard to give proper defaults. For me it's much cleaner to say,
>> that the user has to resize on its own.
>>
>> For this simple example you could also simply do
>>
>>   dirichletNodes.resize(feBasis.size());
>>
>> Making it easier to the eye. But this expects knowledge
>> about the implementation details of the basis and interpolate.
> I'd prefer if the 'interpolate' method would set the correct sizes at least
> for the simple cases.  Having to resize manually clutters up the user code.
> Also, I find it difficult to explain to newbies why the implementation of a
> simple standard basis does not know/must not use the number of basis
> functions.
calling resize just for 'simple' bases is in my opinion
not an option, because we have to define and explain to
users the difference between 'simple' and 'non-simple'
bases and why they behave differently. But you're right,
this clutters user code. I'll add the resize call to
interpolate for all cases.

>> b)Should we expose the backend stuff?
>> The basis itself does only provide indices and does not tell,
>> how to map them to a specific container implementation. But
>> each time you want to interpolate, or construct a grid function
>> from coefficients and basis, you need to pass mutiindices and
>> size information to the containers nested operator[] and resize().
> Yes, but if you start with this in dune-functions we'll have another
> sizeable chunk of dune-pdelab functionality in there soon.  We may
> decide to go that way, but I recall that at least originally the claim was
> 'no vector backends in dune-functions'.
But without backends, a basis is just an ordered set of functions.
Then we must also drop things like interpolate or *BasisGridFunction
because they require to link vectors with bases.

> However, I am not against vector backends in general.  I just don't want
> them forced onto users of "simple" bases.
I'd also not add a bunch of backends, just the trivial one that bridges
the gap from the multi-index (1,2,3) to [1][2][3].

>> Even for the simple p1 example you cannot pass the multi-index
>> directly but have to explain the appended [0]. This is exactly
>> what the backend encapsulates.
> ... which is kind-of ugly, as a matter of fact.  I keep thinking that maybe
> we should replace array<size_t,1> by size_t whenever that appears as
> a multi-index.
But this would mean to teach users things that will not work
in general. Even worse you cannot write code that works in both,
the simple and not so simple cases. If you really think it's so ugly
we may consider to derive from array and add a cast to size_t
in the simple case. However I'd prefer to hide the complicated
multiindex stuff in a simple wrapper (that's the backend) that
can also be explained easily.

Best,
Carsten

>> Maybe a cleaner solution would be, to provide some kind of vector
>> adaptor providing operator()(MultiIndex) and a hierachic resize.
>> Then we would write
>>
>>   SomeVector v;
>>   auto&& v_coeff = basisCoefficients(v, basis);
>>   v_coeff.resize();
>>   interpolate(v_coeff, treePath, f);
>>
>> This would also allow to exchange the now hard wired backend
>> more easily.
> Possibly.
> 
> Best,
> Oliver
> 
>> Best,
>> Carsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20150914/a0b5911c/attachment.sig>