On Sun, Nov 20, 2011 at 10:20:25PM +0000, Garth N. Wells wrote: > On 20 November 2011 22:00, Anders Logg <l...@simula.no> wrote: > > On Sun, Nov 20, 2011 at 09:57:13PM +0000, Garth N. Wells wrote: > >> On 20 November 2011 21:02, Anders Logg <l...@simula.no> wrote: > >> > On Sun, Nov 20, 2011 at 08:40:02PM +0000, Garth N. Wells wrote: > >> >> On 20 November 2011 20:32, Anders Logg <l...@simula.no> 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@lists.launchpad.net > >> >> > Unsubscribe : https://launchpad.net/~dolfin > >> >> > More help : https://help.launchpad.net/ListHelp > >> >> > > >> >> > >> >> > >> >> > >> > > > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
