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, it seems like "don't let everything go out of scope, just create a MeshFunction or call MeshTools::bounding_box()" would be the simplest workaround. > 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. > 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 assistance. Really, what we need is to properly parallelize MeshFunction, but I'm not sure what the right API is to do that with MPI. If processor A wants to evaluate the function on a point in processor B's elements, processor B (which probably has a whole list of evaluations it needs itself) is going to need to be notified somehow to interrupt what it's doing and help A. --- Roy ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
