Newsgroups: comp.parallel.pvm
From: adilger@enel.ucalgary.ca (Andreas Dilger)
Subject: Groups, PVM, and the console
Organization: ECE Department, U. of Calgary, Calgary, Alberta, Canada
Date: 24 May 1995 23:43:58 GMT
Message-ID: <3q0gbu$1f0a@ds2.acs.ucalgary.ca>

Hello all in PVM world.  I am working with PVM a lot recently, and I have
noticed that it is inconvenient to handle various configurations of compute
pools and such with the pvm console, as well as from within a program.

An example of what I mean is:  I have several sub-nets of systems, each of
which has its own file system and network, and I want to start a controller
on one machine in each sub-net, and then have the rest of the machines be
compute slaves.  I am currently using the sp= flag to assign unique
net IDs in the lower digits of the speed, and then checking these digits
in my executable, but this is a kuldge.

Another example would be if you have started pvm with a list of hosts (from a
config file), and you want to add or delete a whole group of them at once.
You could then use "add <group>" or "delete <group>".  It should also be
possible to have a console command like
"group <group name> <machine> [machine ...]" to add the machines to the group.

My idea is to add another config file option like gr=<string> [string]
(ie group = ) which would allow one to check from within an executable how the
PVM machine should be configured, without re-compiling the executable, and
without having to keep track of a separate configuration file.  Note that this
doesn't really have anything to do with the pvm group functions, but could be
used to help assign groups in cases where it matters which machine is which.
It would ideally also be possible to assign multiple group names to a single
machine.

Does anyone have something like this implemented, or does anyone actually think
this would be useful?  I haven't really looked into how much work it would be
to add this to the existing pvm, but I would imaging it would involve modifying
add and delete, as well as adding the group (and probably ungroup commands),
as well as having pvm_conf return the additional group information.

How does this approach contrast with using a tasker process?  I am leary of
doing so, since at any time, I don't know which machines are in the PVM
machine, so the tasker would have to be quite smart to handle the various
configurations.

Cheers, Andreas.
-- 
Andreas Dilger    University of Calgary   \ "If a man ate a pound of pasta and
(403) 220-8792    Micronet Research Group  \  a pound of antipasto, would they
Dept of Electrical & Computer Engineering   \    cancel out, leaving him still
<http://www-mddsp.enel.ucalgary.ca/People/adilger/>        hungry?" -- Dogbert

