The Unify system was originally proposed to unify or mate together the PVM and new MPI APIs. The intention was to enable users to take current PVM applications and slowly migrate toward complete MPI applications, without having to make the complete conceptual jump from one system to the other.
The project, which was a masters degree project, never reached full maturity in that many MPI features (such as virtual topologies, profiling, attribute caching, and intercommunicators) were not implemented. Although all the MPI intracommunicator point-to-point and collective operations were included, Unify failed to exploit PVM's dynamic spawning capability (hence no need for intercommunicators) and forced the user to spawn a fixed number of master-slave SPMD processes from the command line. More specifically, the start-up sequence consisted of a process that checked to see whether it was a master by the existence of a parent process and then spawned N-1 copies of itself. If a parent existed, the process was assumed to be a slave and would block on a receive, awaiting a TID list so that it could build its MPI_COMM_WORLD, MPI_COMM_SIZE and MPI_COMM_RANK values. Thus, a Unify application could not be started by any other PVM process (including the console). Moreover, it could not use PVM spawn to start other MPI applications, since their MPI_Init calls would wait for never-arriving start-up messages.
Unify did address the difficulty of mapping identifiers between the PVM and MPI domains,
where each system used a different scheme; PVM using a 32-bit integer and MPI using a handle to
an opaque internal structure together with a rank inside that structure. Unify provided only
two new additional calls: one from MPI to PVM tid, and vice versa
(without restrictions, since
all the tasks were running within both the PVM and the MPI environments).