Comment 8 for bug 594954

On Tue, 2010-06-29 at 12:13 +0200, Anders Logg wrote:
> On Tue, Jun 29, 2010 at 11:50:38AM +0200, Mehdi wrote:
> > Is there any specific reason why we have this type of problems in
> > resizing uBLAS vectors not other type of vectors?
>
> Yes, because of a bug in the uBLAS resize function (it does not
> initialize data).
>
> > Note that resizing a vector becomes important in the adaptive methods.
> > Since when a function updates, we need to resize its underlying vector.
> > If we clear a vector, then we lose all data that we had there.
>
> There's no point in keeping the old dofs as part of the vector since
> the number of the mesh (and the old dofs) may change. What is needed
> for adaptive methods is to interpolate the old solution to the new
> mesh (which is already implemented in DOLFIN).

This is not the case in XFEM where we have a fixed mesh but the number
of degrees of freedom is changing. Although this is not a big challenge,
since we can define some local variables to transfer data from the old
vector to new one.

Mehdi
>
> --
> Anders
>
>
> > Mehdi
> >
> > On Mon, 2010-06-28 at 15:01 +0000, Anders Logg wrote:
> > > The problem was that x = Vector(b.size()) created a vector which
> > > sometimes contained strange numbers. This has been changed now (in
> > > uBLASVector::resize()) so that the vector is always zero. Took me a
> > > while to work through all the 29 different axpy_prod that call each
> > > other in operation.hpp in uBLAS...
> > >
> > > Should be fixed now.
> > >
> > > ** Changed in: dolfin
> > > Status: Confirmed => Fix Committed
> > >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to : <email address hidden>
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help : https://help.launchpad.net/ListHelp