*************** * TOOLBOX MPI * *************** OCT bindings for LAM 7.1 calls (MPI 1.2 - MPI 2.0) Works under Octave 2.1.60 Linux (tested with Kernel 2.4.20, RedHat 8.0) ___________________________________________________________________ | Javier Fernández Baldomero 2004 | | Mancia Anguita 2004 | | Depto. de Arquitectura y Tecnología de Computadores | | Facultad de Ciencias, Universidad de Granada | | Avda. Fuentenueva S/N | | 18071-GRANADA SPAIN | |_________________________________________________________________| You can copy and use MPITB in the same terms of LAM/MPI (see http://www.lam-mpi.org/community/license.php) replacing names where sensible (MPITB instead of LAM, etc) *** REMEMBER TO UPDATE THIS *** LEARN GNU LICENSING AND SUCH *** These lines will certainly change when I learn what's the usual licensing scheme for an Octave package/toolbox. I'll adhere to anything as long as both LAM and Octave rules are not broken. If that's not possible, I'll remove these lines and warn instead that using MPITB is illegal since it brokes either LAM or Octave rules. *** REMEMBER TO UPDATE THIS *** LEARN GNU LICENSING AND SUCH *** *********** * INSTALL * *********** The preferred setup is a local copy of LAM & MPITB, since - usually not many users in a cluster will use MPITB (usually just one), and - MPITB requires a dynamically linked LAM, which is not usual (the RedHat-provided LAM rpm package comes only with static libmpi.a) BTW, your octave must support DLDs, since the whole MPITB consist of DLD (.oct) files. -------------------- - Choose ubication - -------------------- e.g.: octave subdir in joe's local directory cd /home/joe/octave ------------------------ - Decompress and untar - ------------------------ cp /mpitb.tgz . tar zxvf mpitb.tgz rm mpitb.tgz Now there is a ~joe/octave/mpitb subdirectory. -------------------------------- - Configuring Octave's startup - -------------------------------- MPITB comes with a .octaverc file (linked to startups/octaverc_MPI.m) e.g.: user joe wants to run octave from ~/octave (not from ~/octave/mpitb) and he already had a .octaverc file (complex example) cd ~joe/octave ln -s mpitb/startups/octaverc_MPI.m . then add these lines to joe's original .octaverc % MPI Toolbox startup M-file, if it exists. if exist('octaverc_MPI.m','file') octaverc_MPI end then try it out. It's ok when you can read those help lines about MPI octave ... Set SSI rpi to tcp with the command: putenv('LAM_MPI_SSI_rpi','tcp'), MPI_Init Help on MPI: help mpi octave:1> e.g.: user joe does neither mind changing to mpitb to run octave, nor needs to preserve any previous .octaverc startup (easiest example) Again, it's ok when you can read those help lines about MPI cd ~joe/octave/mpitb ls -la .octaverc # make sure the link is there octave ... Set SSI rpi to tcp with the command: putenv('LAM_MPI_SSI_rpi','tcp'), MPI_Init Help on MPI: help mpi octave:1> ----------------------------------- - Configuring users' shell script - optional ----------------------------------- MPITB can use an MPITB_HOME environment variable. If it is not defined but the user has installed MPITB under ~/octave/mpitb, MPITB uses that location (please see octaverc_MPI.m) as MPITB_HOME. If you chose a different location, or want to set MPITB_HOME anyways, you can edit your shell-run-command to include the definition: e.g.: for bash: I added to my ~/.bashrc export LAMVER=7.1.1 export LAMHOME=~/lam-$LAMVER export PATH=$LAMHOME/bin:$PATH export LD_LIBRARY_PATH=$LAMHOME/lib:$LD_LIBRARY_PATH export LAMBHOST=$LAMHOME/bhost.def export LAMAPPLDIR=~ export OCTVER=2.1.60 export OCTAVE=~/octave-$OCTVER export PATH=$OCTAVE/bin:$PATH export OCT_DOX=$OCTAVE/include/html/index.html export OCT_SRC=~/ftp/octave/octave-$OCTVER/src export MPITB_HOME=~/octave/mpitb alias octave='octave -q' eg.: for tcsh the syntax is different ... setenv MPITB_HOME ~/octave/mpitb ... These examples are meant for a "local" LAM 7.1.1 install, a "local" octave install, and a "local" MPITB install under ~/octave. Your mileage will vary. --------------- - Recompiling - optional --------------- The Makefile is in $MPITB_HOME/src. You simply cd there and type "make". It recompiles the .cc files there to .oct files in $MPITB_HOME/DLD. This is in no way a "high tech" Makefile. I'm afraid it heavily depends on variables such as $OCTAVE, $OCTVER and $LAMHOME being defined. It worked, so I didn't feel like studying more make manual. If you can't stand looking at it and need to make a better version, and if additionally you wouldn't mind sharing it with me, I would of course properly acknowledge it when I included it in the web page. Makefile.env changes with each new LAM/Octave version. Double-check it before recompiling to make sure the mentioned switches/subdirs are OK. BTW, the Makefile.Debian.env file included in the src subdir was contributed by Michael Creel (as acknowledged in the MPITB web page) -------------------------------------- - LAM default hostfile (boot schema) - -------------------------------------- You need a bhost file to easily boot a LAM. From the above defined LAMBHOST, lamboot will read the host file $LAMHOME/bhost.def, where hosts names could be added or deleted. You could also change this value of LAMBHOST in .bashrc/.tcshrc Edit that $LAMBHOST file so that it describes your Local Area Multicomputer (man bhost). Then type "lamboot", and if you don't get error messages, there you go. If you get errors, you must solve them before using MPITB under Octave. Read the LAM FAQ since most probably somebody has already had exactly the same problem as you, and the answer is already there. LAM must be already booted when you use MPI_Init from inside Octave. (ok, other Octave users might want to system("lamboot"), agreed :-) Typically you want your cluster headed node (where you start Octave) last in the list, and all other cluster nodes before your headed node in bhost.def. That way, spawned octave processes will go to the other cluster nodes, not to the headed node where you are already running an octave process. The user could have several bhost files in different subdirs, probably belonging to different projects. To switch project, the user changes LAMBHOST before using lamboot (possibly editing .bashrc/.tcshrc until switching to another project). If you are planning to use the $MPITB/utils subdir, you also might want to edit the LAM_Init.m file so that the HOSTS variable describes your cluster. Or perhaps get used to define global HOSTS before invoking LAM_Init. Octave_Spawn, NumCmds_Init and NumCmds_Send are also interesting utilities. ------------------------------- - What now? The TUTORIAL file - ------------------------------- Once you have a running Octave with a lambooted LAM, you may want to open an xterm/editor from where to copy/paste lines from the tutorial file to the octave window. It is the fastest way to learn MPI. You won't regret reproducing the whole tutorial, or at least the sections that use the MPI routines you are interested in. The tutorial includes a particularly interesting section on ssh forwarding, on which a shell-script called "lamprep" is introduced. You might want to study that section, to be able to send xterms back from the headless nodes - through the headed node - back to your remote PC. The "lamprep" script (as well as another obsolete "proxy" script) are included in the "stdlones" subdir. The demo applications "Speedup", "PingPong" and "Spawn" all assume you are able to send xterms back. They won't work if xterms get blocked. They will get stuck in the MPI_Comm_spawn call waiting for the blocked xterms to appear. ----------------------------- - What then? The Pi example - ----------------------------- The Pi subdir actually contains two different examples: - PingPong.m: bandwidth vs. msgsize graphs - Ping.m: source peer - Pong.m: destination peer - Speedup.m: speedup vs. #computers graphs - Mast.m: master code - Work.m: slave code (worker) - AllThem: all graphs at once You can run "AllThem" to see the graphs generated in my cluster, before removing the data files *.mat and try to reproduce them in your cluster. You might start with Ping.m, trying to make it work in your cluster. Please, do notice the DEBUG flag on the very first line of Ping.m/Mast.m If you get tired of seeing so many xterms, you can reset it to 0. It is originally left set so that users know whether the spawn commands are working or not. The most common cause of failure is an unappropriate DISPLAY (read the TUTORIAL section on DISPLAY/ssh). Ping.m uses the LAM_Init.m utility, so again you might want to either edit LAM_Init to modify the built-in HOSTS, or edit Ping.m to define a new HOSTS which describes your cluster. If you get Ping to work, please proceed to PingPong.m, which cares even of lambooting LAM for you. First you should edit the very first line, where the nodes are named, to correctly reflect your cluster environment. If you can manage to get it working as well, please make me know (:-) and do the same with the Mast/Work/Speedup family, which compute Pi (hence the name of the subdir) with an increasing number of hosts. If you also manage to make it work, you probably want to run AllThem and obtain the whole set of graphs in a snap. -------------- - What then? - -------------- If you want me to add some application of yours to the MPITB web page, or mention a paper or publication in a congress which uses MPITB, or link to some document you prepared for your research fellows/students dealing on MPITB, drop me an e-mail. I'd certainly like to see the "MPITB papers" list growing :-) ************************************* * Thanks for your interest in MPITB * ************************************* Granada, SPAIN, 29/Oct/2004