← Back to team overview

dolfin team mailing list archive

Re: Vector conclusions

 

On Tue, Apr 15, 2008 at 08:29:43PM +0200, Martin Sandve Alnæs wrote:
> 2008/4/15, Dag Lindbo <dag@xxxxxxxxxx>:
> > Thanks Martin! It is much clearer now. My main concern here is as a "user",
> > since a release is forthcoming. I only wish to clarify things here for the
> > benefit of (myself and) other users. Comments below.
> >
> >  Martin Sandve Alnæs wrote:
> >
> > > 2008/4/15, Dag Lindbo <dag@xxxxxxxxxx>:
> > >
> > > > Hello!
> > > >
> > > >  A lot has happened on the Vector/Function/<backend>Vector interface the
> > > >  last weeks. For clarity, I would like to have a little "summing up"
> > > >  thread. That is, I  think it would be beneficial to explicitly show how
> > > >  the new interface is intended to be used. Sounds good? Here are some
> > > >  situations, to which I propose solutions. Please correct if these are
> > > >  not in line with the intended interface, or if there are better ones.
> > > >
> > > >  How to:
> > > >  *) Get reference to Vector from a (discrete) Function u
> > > >  Vector& v = dynamic_cast<Vector&>(u.vector());
> > > >
> > >
> > > Why would you want that?
> > > All dolfin library code will now use GenericVector references.
> > > This way it will also work with f.ex. uBlasVector objects directly.
> > >
> >
> >  I understand that Generic* is used for all internal DOLFIN code.
> >
> >  It is still not clear how "application code", i.e. an actual solver for a
> > user, is supposed to do this. Is GenericVector from now on part of the
> > public interface of DOLFIN? (sorry if I'm repeating this question)
> 
> 
> Actually, I think you've pointed out a user interface problem here.
> We can in general go from Vector to backend-type, but not the other way around.
> 
> You _can_ do this:
>     Vector& v = dynamic_cast<Vector&>(u.vector());
> _if_ your code has been using Vector consistently.
> It will throw a std::bad_cast exception otherwise.
> 
> But that will limit that part of your code to built-in dolfin backends, which
> is one of the things we're trying to avoid by using GenericVector& everywhere.
> 
> On the other hand, if you use
>     GenericVector& v = u.vector();
> this does, as you say, make GenericVector enter user code alongside Vector,
> which was something Anders didn't want to begin with (if I remember correctly?).
> 
> From Python, this is not an issue.

I suggest doing something like this:

  Vector x;
  Function u(mesh, x, form);

Then use x.

Or if you get a Function, use u.vector() directly, like

  solve(A, u.vector(), b);

It's only if you want to pick out the vector first and then use it
that you need to write GenericVector (and I can't see a way to avoid
writing that).

-- 
Anders


References