dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Nov 20, 2011 at 09:57:13PM +0000, Garth N. Wells wrote:
> On 20 November 2011 21:02, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Sun, Nov 20, 2011 at 08:40:02PM +0000, Garth N. Wells wrote:
> >> On 20 November 2011 20:32, Anders Logg <logg@xxxxxxxxx> wrote:
> >> > The unit test currently failing on the Mac buildbot (timing out) is
> >> > failing on my machine (Ubuntu 11.10) with a PETSc error claiming that
> >> > the vector in question is not ghosted.
> >> >
> >> > I've tracked it down to the plotting from the C++ eigenvalue demo, and
> >> > the call to gather() from within interpolate_vertex_values.
> >> >
> >> > The problem is that the Function to be plotted is created from a
> >> > solution vector x from the eigenvalue problem like so:
> >> >
> >> >  Function u(V, x);
> >> >
> >> > Since x does not come from a Function to begin with, it was not
> >> > initialized with ghost values, so then later when
> >> > u.interpolated_vertex_values is called, the call to gather() fails.
> >> >
> >> > Should there be a test for whether ghost values exist in either
> >> > PETScVector or Function (_have_ghost_values)?
> >> >
> >>
> >> Take a look here on how to test:
> >>
> >>     http://lists.mcs.anl.gov/pipermail/petsc-dev/2011-November/006286.html
> >
> > ok, so VecIsGhosted is in petsc-dev.
>
> If you follow the thread, there is a solution for PETSc 3.2.

Yes I noticed. We could copy-paste that if we need it now.

> > It would be good to use that in
> > the future but then we need the same for Epetra.
> >
>
> Epetra doesn't support ghosting - it's been added to our wrappers, so
> it's easy to detect.

ok.

> > But it still doesn't solve the problem with the constructor
> >
> >  Function u(V, x);
> >
> > Does it make sense in parallel when x may not have the correct
> > ghosted values so calls to interpolate_vertex_values (and likely other
> > functions) may fail?
> >
>
> It will be problematic when getting values from u, e.g. when used as a
> coefficient. A better approach is
>
>   Function u(V);
>   *u.vector() = x; // Not sure the syntax is right

Should there be a test in that constructor that the input vector has
the correct layout, in particular that it has all dofs it needs?

--
Anders


> Garth
>
> >
> >
> >> Garth
> >>
> >> > On top of this, the call to plot() does not work in parallel from C++
> >> > anyway so it's easy to make the bug disappear (by moving the check in
> >> > the plot function earlier to before the call to
> >> > interpolate_vertex_values), but it exposes a problem with the
> >> > constructor
> >> >
> >> >  Function u(V, x);
> >> >
> >> > which may not make sense if x does not have the proper layout.
> >> >
> >> >
> >> > _______________________________________________
> >> > Mailing list: https://launchpad.net/~dolfin
> >> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >> > Unsubscribe : https://launchpad.net/~dolfin
> >> > More help   : https://help.launchpad.net/ListHelp
> >> >
> >>
> >>
> >>
> >