On Mon, 12 Jan 2009, Roy Stogner wrote:
> On Mon, 12 Jan 2009, Tim Kroeger wrote:
>> At the end of my application, I want to evaluate the computed solution
>> at a number of points (which cannot be assumed to be grid nodes).
>> Since I only want to write the values to a file, it suffices to do
>> this on one processor.
>> My idea was:
>> 1. Localize.
>> 2. On all processors except #0, let everything go out of scope.
> Any reason why? If you're not needing the memory for anything else,
Well, I thought that creating the MeshFunction would require a lot of
memory, so it would be nice to let the other processors reduce their
memory requirements. (Some of the processors are located on the same
node, i.e. are using the same memory pool.)
> it seems like "don't let everything go out of scope, just create a
> MeshFunction or call MeshTools::bounding_box()" would be the simplest
That's what I'm doing now, and it works, but I thought there would be
a nicer solution.
>> 3. On processor #0, make a MeshFunction and evaluate as required.
> If you build a MeshFunction but only intend to use it on proc 0,
> there's no need for the only expensive step of serializing the
> solution vector to the rest of those processors; I doubt you'd even
> have to allocate a zeroed serial vector on them.
Well, the point is that there is no NumericVector::localize_to_one
(NumericVector&, unsigned int). See also my posting of December 17,
>> However, this fails to work because there is a call to
>> parallel_only() in the initialization of MeshFunction (that is, in
>> tree.C, line 45, MeshTools::bounding_box() is called, which itself
>> calls parallel_only()).
> Right - in the case of a ParallelMesh, for instance, it's not even
> possible to compute a bounding box without every processor's
That's true, of course.
Dr. Tim Kroeger
tim.kroeger@... Phone +49-421-218-7710
tim.kroeger@... Fax +49-421-218-4236
Fraunhofer MEVIS, Institute for Medical Image Computing
Universitaetsallee 29, 28359 Bremen, Germany