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