dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Sep 19, 2006 at 05:15:19PM +0200, Johan Jansson wrote:
> On Tue, Sep 19, 2006 at 03:50:21PM +0200, Anders Logg wrote:
> > On Tue, Sep 19, 2006 at 12:43:00PM +0200, Johan Jansson wrote:
> > It looks a little strange:
> > 
> > void Function::interpolate(Function& ftarget)
> > {
> >   // Delegate function call
> >   f->interpolate(ftarget);
> > }
> > 
> > Here ftarget is the target for the interpolation, so ftarget = P(*this).
> > 
> > But then in DiscreteFunction::interpolate()
> > 
> > void DiscreteFunction::interpolate(Function& fsource)
> > {                                             ~~~~~~
> >   Vector& x = vector();
> >               ~~~~~~~~~
> >   ...
> >       x(nodes[i]) = coefficients[i];
> >       ~~~~~~~~~~~~~
> > }
> > 
> > So it seems that ftarget is actually the source.
> > 
> 
> This is fixed now, I changed my mind mid-way.

ok.

> > > I want to add projection too, but that probably has to go via
> > > PyDOLFIN.
> > 
> > It seems that this will only work when the old interpolate() function
> > works, and that one only works when interpolating onto a restriction
> > of the global space. It won't work between different types of
> > functions defined by different elements or on different meshes.
> 
> You're right. I guess global interpolation is not defined between
> general finite elements. So projection is a better way to go, probably
> also for the case of different meshes.

Yep.

> > Another thing: do you need to do the interpolation from initial values
> > explicitly? I made a fix previously so you can define say u0 as a
> > user function, but then you can do
> > 
> >   u0 = u1;
> > 
> > and u0 becomes a discrete function. Then the interpolation is not needed.
> > 
> 
> I don't think this mechanism is sufficient. In general I want to evaluate:
> 
> dot(u) = f(u)
> 
> where u could be composed of several subfunctions. Currently the
> administration of the layout of the subfunctions is done manually, but
> this can likely be solved with the subelement/subfunction interface in
> the future. Currently I need to assume u is a DiscreteFunction, and it
> will be hard to write f(u) if I have to take into account that u can
> suddenly change from being a UserFunction to a DiscreteFunction.
> 
>   Johan

Do you really need to know what type of function it is? The purpose of
the Function class is that the type should be ignored.

/Anders