dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #09656
Re: [HG DOLFIN] Don't initialize vector in DiscreteFunction if already initialized.
On Mon, Sep 15, 2008 at 12:24:39PM +0100, Garth N. Wells wrote:
>
>
> Kent Andre wrote:
> > On ma., 2008-09-15 at 11:48 +0100, Garth N. Wells wrote:
> >> Kent Andre wrote:
> >>> On ma., 2008-09-15 at 11:19 +0100, Garth N. Wells wrote:
> >>>> DOLFIN wrote:
> >>>>> One or more new changesets pushed to the primary dolfin repository.
> >>>>> A short summary of the last three changesets is included below.
> >>>>>
> >>>>> changeset: 4751:df802d1b2b349e91a51b70f799ba6d0d3b825376
> >>>>> tag: tip
> >>>>> user: Anders Logg <logg@xxxxxxxxx>
> >>>>> date: Sat Sep 13 08:55:34 2008 +0200
> >>>>> files: dolfin/function/DiscreteFunction.cpp
> >>>>> description:
> >>>>> Don't initialize vector in DiscreteFunction if already initialized.
> >>>>>
> >>>> Vector::init() only resizes the vector if necessary, but it also zeroes
> >>>> the vector. Looks to me like it is desirable to zero the vector?
> >>>>
> >>>> Garth
> >>>>
> >>> The reason for this, I think, is initialization as such:
> >>>
> >>> solve(A, x, b, cg, amg)
> >>> u = Function(element, mesh, x)
> >>> plot(u)
> >>>
> >> The problem is that I could also create the function, and then use it
> >> with a vector that hasn't been initialised properly.
> >
> > But then you would not use this constructor?
> >
> >> The most robust approach, which I've been working towards, is that a
> >> DiscreteFunction always owns it's vector and can't be initialised with a
> >> Vector. The above code would be
> >>
> >> u = Function(element, mesh)
> >> solve(A, u.vec(), b, cg, amg)
> >> plot(u)
> >>
> >> Garth
> >>
> >
> > It is fine by me if DiscreteFunction owns the vector, then the entries
> > of x has to be copied.
> >
>
> I've set it up now such that if a Function is created using the simple
> constructor interface (no smart pointers), it always owns the vector and
> a reference to the vector is returned by Function::vector(). This vector
> is initialised to zero.
>
> It's possible to create a Function and associate it with a particular
> vector by using the interface with smart pointers, in which case the
> vector is not initialised to zero.
>
> Garth
I think it would be natural to say that x.init(N) does not zero a
vector. It should only check that if the size is wrong, it will adjust
the size and set all entries to zero. But if the size is correct, it
shouldn't zero the vector. We have x.zero() for that.
I haven't looked at all backends, but the PETSc backend at least zeros
the vector in init(). Should we try to fix this for all backends?
--
Anders
Attachment:
signature.asc
Description: Digital signature
References