dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Jun 26, 2008 at 05:28:42PM +0100, Garth N. Wells wrote:
> 
> 
> Martin Sandve Alnæs wrote:
> > 2008/6/26 Garth N. Wells <gnw20@xxxxxxxxx>:
> >> Martin Sandve Alnæs wrote:
> >>> If we can use references somewhere we use pointers, we should change
> >>> that. All factory functions will of course return pointers, and they
> >>> clearly give away ownership to the caller. Where else do we need to
> >>> use pointers?
> >> DiscreteFunction is an example where we use a number of pointers because a
> >> DiscreteFunction may or may not own the data. Without having a bunch of
> >> constructors, I don't know how to tell DiscreteFunction what it does and
> >> doesn't own.
> >>
> >> Pointers are also used quite a bit in DofMap and DofMapSet. These of course
> >> will be overhauled in the near future.
> > 
> > Ok. Also, we should allow FooVector and FooMatrix to be a "view" of an
> > object they don't own, or take over ownership. This may be important
> > if somebody tries to use dolfin as a component on the side and not the
> > main application framework, e.g. if they have an existing PETSc Mat or
> > Epetra_FEVector to use. Both are possible with shared_ptr, possibly
> > with custom deleters in special cases.
> >
> 
> I'll play around with this for the NewtonSolver to experiment as it's 
> pretty unobtrusive. At the moment NewtonSolver owns the Jacobian matrix, 
> but I'd like to set it up such that the NewtonSolver can create and own 
> the matrix (which will be the case 95% of the time), or a user can 
> supply the matrix which NewtonSolver may or may not then own. A reason
> a user might want to supply a matrix is to specify a special matrix type 
> (say a PETSc UMFPACK matrix).
> 
> Garth

I think we should try to design the classes in such a way that we
never need to use smart pointers. It should be obvious whether or not
the data is owned by an object. That's not the case right now so we
need to try harder.

For example, the following line in XMLFile.cpp is outright disturbing:

  ff.local_vector = x;

:-)

It should not be the responsibility of XMLFile to set a private
variable in Function to let Function know it owns the data (even
if it's a friend).

The correct way to read in *data for a Function* should be to

1. Assert that we get a discrete function or make the function
discrete.

2. Extract the data from the Function (which are owned by the
Function).

3. Read values into those data.

Something like this:

  void XMLFile::operator>>(Function& f)
  {
    // Step 1
    dolfin_assert(f.type() == Function::discrete);

    // Step 2
    Mesh& mesh = f.mesh();
    GenericVector& x = f.vector();

    // Step 3
    file >> mesh;
    file >> x;
  }

The first step could be replaced by something like

  f.init(Function::discrete);

which could be a call to create an empty discrete Function.

-- 
Anders

Attachment: signature.asc
Description: Digital signature