dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Nov 20, 2011 at 10:20:25PM +0000, Garth N. Wells wrote:
> On 20 November 2011 22:00, Anders Logg <logg@xxxxxxxxx> wrote:
> > 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?
> >
>
> Simpler would be to remove the
>
>    Function u(V, x);
>
> constructor.

Yes. Is it much used? As far as I can see, it's only used in the
eigenvalue demo. I'll make a separate post on that.


--
Anders


> Garth
>
>
> >
> >
> >> 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
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >