dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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.

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     : dolfin@xxxxxxxxxxxxxxxxxxx
>> >> > Unsubscribe : https://launchpad.net/~dolfin
>> >> > More help   : https://help.launchpad.net/ListHelp
>> >> >
>> >>
>> >>
>> >>
>> >
>