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

Oliver Sander oliver.sander at tu-dresden.de
Mon Sep 14 22:23:36 CEST 2015


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.

>
> 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'.

However, I am not against vector backends in general.  I just don't want
them forced onto users of "simple" bases.


> 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.


> 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
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dune-functions mailing list
> dune-functions at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-functions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20150914/f049d49d/attachment.htm>


More information about the dune-functions mailing list