Jed points out a flaw in the simple minded naming scheme we have. Lisandro points out the lack of generality of Jed's fix. To insure unique names and consistent names across ranks for a parallel object we could use the following scheme: classname_MPI-comm-id_counter where MPI-comm-id is obtained somehow from the communicator (and then set as an attribute) and counter is a another attribute of that communicator that is cranked up each time it is obtained. For a given communicator after setting the MPI-comm-id no communication is needed for each new name it hands out (and the debug version of PETSc would do a communication to check that everyone's counter is the same as a sanity check). I do not know a way to generate unique MPI-comm-id's. Any thoughts? Some feature of MPI I don't know? Barry On Nov 16, 2009, at 9:48 AM, Lisandro Dalcin wrote:

On Mon, Nov 16, 2009 at 10:49 AM, Jed Brown <[email protected]> wrote:

...

Since it is not collective, the names can get out of sync, even with "reasonable" usage. Consider a case where rank 0 views a serial Vec (say with the Matlab viewer), and then a parallel Vec (e.g. to HDF5). The result would either be deadlock (with collective IO) or a file where Vec_0 contains all but rank 0's part, and Vec_1 contains only rank 0's part (and an HDF5 error once another vector is viewed because the Vec_1 dataspace cannot be created if it already exists).

Is it reasonable to make PetscObjectName (and necessary dependents) collective where it performs this?

MPI_Allreduce(MPI_IN_PLACE,&counter,1,MPI_INT,MPI_MAX,obj->comm);

And what about VecView() of serial objects on two different processes? What about parallel Vec's on subcommunicators of COMM_WORLD?

-- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594