On Tue, 31 Aug 2010, Derek Gaston wrote:

> So... up until now I've only ever needed one "ghosted" vector... for
> the solution vector.  And, just as we do in petsc_nonlinear_solver.C
> I've just been bastardizing System::update() and
> current_local_solution to "ghostize" a vector.
>
> But now that won't work because I need two such vectors
> simultaneously.  What is the current state of the ghosted vector
> situation?  What is the right way to take a Vec from a Petsc
> callback and form a ghosted PetscVector out of it that I can pass to
> my own (assembly like) routines?

In theory, assuming your Vec v is already ghosted, all you need is:
PetscVector<Number> wrapper(v);
and then use wrapper.  The constructor PetscVector::PetscVector(Vec v)
checks to see whether v is ghosted, serial, or parallel (and how big v
is) and updates our metadata cache accordingly.  We do assume that v
has already been initialized and isn't in mid-assembly, which should
be true in your callback function.

But that's in theory.  In practice:

1. We also call this->_vec = v; this works in current PETSc since a
Vec is really just a pointer to the real structure, but I'm not sure
if it's official standard behavior that won't break someday.

2. How well tested is this code path?  You might be the second or even
first guinea pig.
---
Roy

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to