A DECUS distribution for VMS (both VAX and AXP) contains only the DECW, VWS and UWS drivers, and the sources are in compressed archives (with LHARC).
A DECUS distribution for UNIX (both Ultrix and OSF/1) contains only the OWS drivers, and the sources as an uncompressed tar tape.
Requirements: VMS
The VMS libraries contain code compiled using the new FORTRAN V6.0 compiler. This compiler is only supported on VMS versions 5.4 and above. To use MDPP linked using the libraries on this tape you must have the new Math RunTime library that ships with the V6.0 compiler installed (not the compiler itself: you may not have a license for it). To use the MDPP on lower versions of VMS will require full re-compilation of all sources.
Requirements: OSF/1
OSF/1 uses shared libraries and these must be available for the pre-linked program to work. In particular, the compiled code support library, libota.so, must be available as well as the FORTRAN shared library libUfor.so. These libraries are available on the OSF/1 installation CD-ROM and should be loaded from it in the event that there are problems starting the program. Obviously, to re-compile or re-link the program, a FORTRAN compiler must be available (with it's license).
The first task: Unloading the tapes
Tapes for VMS can be unloaded on a VAX/VMS system running version 6.x or 5.x: it cannot be unloaded on a version 3.x system: use on a 4.x system is uncertain.
Tapes for UNIX should be unloaded using the tar utility, with the command 'tar -x'. Issue this command from within the directory where you want to root the MDPP directory tree. There have been some problem on Alphas getting the tape drive name correct: alternative commands would look like 'tar -xf /dev/rmt1h'.
Continuing the Installation
The second task is gaining access to the on-line documentation. To do this, start the BOOKREADER application and `Switch Library' from within the `File' pull-down menu. Go to the MPP:[ON-LINE] directory and select the LIBRARY.DECW_BOOKSHELF file and open it. Open the `Installation' on-line book and follow the instructions therein.
Reminder on Customization
The Alpha/VMS and Ultrix stuff is bulky: delete it if you don't want it. Use TAILOR.COM to eliminate pieces you do not need (for VMS), or remove the directories that are not needed with 'rm -R ogen' (UNIX).
Summary: Get started by first installing the software (either VMS, section 2, or UNIX, section 4): this will usually, but not necessarily, involve someone with system manager's privileges. Second, read section 5, "Getting started with MDPP" for tips on running for the first time.
Step-by-Step Installation (VAX)
"REN DISK:[000000]MDPP.DIR DISK:[000000]MDPPOLD.DIR"
where "DISK:" is the name of your disk volume. You may need help from the System Manager to do this. This old directory can be deleted when the new version of MDP is running (remember to save the old [MDPP.LOCAL] area if you have made your own local changes to MDP).
If the directory [MDPP] does not exist, BACKUP will create it for you if the job you run has sufficient priviliges. NOTE: the <base> directory will be MDPP if you get your distribution from NYU: it will be something else (e.g. VAX535.MPT) if your distribution comes from another source, such as DECUS. Use the BACKUP/LIST command to look at the begining of the tape to see what you actually have. You may wish to include an `/EXCLUDE=(<files>)' switch to ensure that unneeded files do not get copied: examples might be /EXCLUDE=*_AXP.* to avoid getting the Alpha AXP files on a VAX where they could not be used.
mv mdpp-unix mdpp-unix-old
You may need root privs to do this. This old directory can be deleted when the new version of MDP is running (remember to save any customized files if you have made your own local changes to MDP).
tar will create a new directory tree with 'mdpp-unix' at the top level, in the directory where the command was run. MDPP is quite large. Therefore do not create it in a partition with limited space (as /usr often is).
Users who wish to use large arrays may experience difficulties due to having the wrong limits set for common login parameters. For some of the processing the default limits will be inadequate, which will cause MDPP to crash. We have PGFLQUOTA=100000, BYTLM=64000, FILLM=100, BIOLM=150, DIOLM=150, ASTLM=250, TQELM=10 and ENQLM=2000 for our heaviest user (using AXP, on a VAX smaller values may suffice). A large value for PGFLQUOTA is needed to re-link MDPP be cause of its humongous size. Also, the values of the working set sizes may need adjustment to avoid excessive page faulting. We are currently using WSQUO=4000, WSDEF=2000 and WSEXTENT=16384. Very large values for WSxxx parameters are dangerous since they may lock the system: do not exceed the value in the system parameter WSMAX. Discuss the matter with the System Manager who will need to re-set these for you using the AUTHORIZE utility in the event you have a problem. Obviously, the system parameters need to be adequate to allow these values. On the `good' side, the current releases of OpenVMS come with defaults that appear to be adequate.
You may also need to customize the MDPP.COM file for your site. This file defines SYMBOLS and LOGICALS for various devices to allow printing of pictures, etc. The file MDPP.COM should contain sufficient information to permit the correct changes to be made. Remember to set the PL0: definition correctly if you want to use ReGIS plotting.
The linked version of MDPP in this distribution was built under V5.5-3 of VMS with Motif V1.2 installed. This means that it will not run if you have a lower version of Motif. Best may be to upgrade Motif.
Including your own commands. You may also need to customize MDPP for your own site to include special routines you need for image output, and also to add new commands.
In the VMS version, to install your own routines, simply install your own local [.LOCAL] directory with its own versions of these routines compiled and loaded into the library file. Then edit the file MDPP.COM and alter the assignment statement which defines "LOCAL_LIB:" to point to the file which you have used to put the new routines into (if different from the one provided). Note that you need to protect yourself and put this out of the way so that this new local area is neither deleted or renamed when you get a new distribution of MDPP. MDPP will rebuild with your routines in place when "MDPPBLD.COM" is executed.
In the UNIX version, to install your own routines simply edit and load the new or modified routines into the library (mdpp.ls or mdppo.ls). Remember to KEEP a copy of the unmodified libraries safely somewhere before messing with them. Re-link using the command provided.
If you need to add a new command you will need to follow a more complicated procedure. This is outlined in the file "[MDPP.DOC]NEW_CMD.DOC" which you should read before attempting to add your own command. Note that this procedure is automated to a degree for VMS, but not for UNIX as yet. Sorry...
The user give MDPP access to this file by defining the logical MDP_USRDFL to point to the file which provides the appropriate default definitions. If he does not have special requirements then he can omit this definition, and MDP will use the MDP_SYSDFL definition to get system-wide definitions.
The MDPP mode switch allows the user to switch between keyboard (0), display screen oriented (1) and terminal screen MENU driven (2) input modes.
In keyboard mode all commands come from the keyboard, display screen options are available, but are not selected automatically, the user must enter the appropriate command to activate screen input.
In display screen oriented mode the input is from the keyboard but the screen options of each command are selected automatically, if there are any. This option has not been fully implemented, and should not be used.
In menu driven mode MDPP is driven entirely from user-defined menu screens. These menus are user programmable, as are their functions, via the PROCEDURE driver. If you wish to use MODE=2 (MENU) you should be aware that you have to write your own menu file and the procedures called by it. If the user wants to use MODE=2, then he must also define the logical MDP_MENU, which must point to his menu file. There is no system-wide default for MDP_MENU, since menus are expected to be user-specific. The user may also wish to write his own MENU help files. The logical MDP_MENU_HELP, for which there is no system-wide default, needs to be defined in order that such help be available. The user's individual definitions should be placed in his LOGIN.COM file, after the call to MDPP.COM.
X-Server Font Problems
The MDPP attempts to get fonts for the display of cursor locations, etc., using a wild-card font request. Some servers (the box driving the screen that you look at) respond with a choice of font that is unappealing or just plain wrong (like: shows odd symbols rather than nice characters). If this happens to you, there are two ways to fix it. System wide: If you can identify a particular font that looks good on all the servers you need to run MDPP on, then you can define it in MDPP.COM with a statement like:
$ DEF MDP_DECW_FONT -
$_ "-MISC-FIXED-MEDIUM-R-NORMAL--*************C-80-ISO8859-1"
This line is already in the MDPP.COM file. Just un-comment it and edit it, if ncessary, to point to the font you require. For each user individually: If you cannot get consensus on a good font that everyone can use, then each user can define the MDP_DECW_FONT logical in their own LOGIN.COM file, AFTER MDPP.COM has been executed.
The Utilities
MDPP.COM (VMS) contains a call to the file UTILITIES.COM that sets up several useful utility programs. Check this file to see if these overlap with routines you are already using. If they do, you may wish to edit this file and update the information in it. The utilities are not a part of MDPP and are not supported as a part of it. However, we do try to ensure that they are kept current and will update any that we can find in a straight-forward manner. Let us know if any utilities are busted and we'll try to help.
HELP
The manual for the system is the same for both the VMS and Ultrix versions of the system. There is now an extensive set of `HELP' files located in the directory [MDPP.DOC] which is pointed to by the logical name MDPDOC:. These files can be printed out and constitute the manual for the system. MDPP accesses the HELP files using its own internal reading system to provide on-line help. Obtain on-line help by typing "HELP <command_name>" (e.g. "HELP VF") from within MDPP in command mode, or a "?" at any prompt for input. Note that a system level HELP entry can be obtained by loading the file MDPP.HLP into the system help library file using the command "LIBR/HELP SYS$HELP:HELPLIB MDPP".
On-line HELP via BOOKREADER is also available: you are using it now!
Note also that the plotting program subroutine library its own help library which can be accessed using the appropriate system HELP command.
Using the anonymous/FTP Distribution
The FTP distribution is not guaranteed to be any of: up-to-date, usable,
complete, bug-free. Generally it will be updated on an ad-hoc basis when
appropriate. The message is: I really want people to get MDPP
from DECUS.
That said. Here it is for what it is worth. Good luck.
Suggested Retrieval Order
CMP (or LZDCM_AXP, depending whether you have an Alpha or not), available in the previous directory. If you have a DECwindows system and the executable in this saveset works, then you are nearly done.
MDPP-LIBRARIES.BCK_Z
MDPP-LIBRARIES_AXP.BCK_Z
b) A driver for the display screen. There are two choices for VAXes, only one for the Alpha.
DECW-DRIVER.BCK_Z
DECW-DRIVER_AXP.BCK_Z
VWS-DRIVER.BCK_Z
The documentation is available in two forms: the text docs which provide on-line docs whilst MDPP is running, and the BOOKREADER documents. The BOOKREADER docs are fairly well organized and provide a structured intro (well, maybe) to the MDPP and may be much better to use. The text docs have the same information, but are not organized for straightforward access. The BOOKREADER docs contain a workable Installation Guide.
LINE-DOCS.BCK_Z --- The text documentation
ON-LINE-DOCS.BCK_Z --- The BOOKREADER docs.
These are the libraries [lib.rgb] (color tables), [lib.menu] (some canned menus we have used here) and [lib.proc] (some procedures we have used).
SUPPORT-LIBRARIES.BCK_Z
The examples: You should take DONNA (a cute image to test the display, etc.) You may want to pass on the full example saveset which show MDPP in action in some problem areas.
DONNA.BMD_Z
EXAMPLE.BCK_Z
Are not here!! If you want the sources you will have to get them from the DECUS distribution.
As stuff gets fixed I will try to keep up-to-date linked versions of MDPP on line here as MDPP.EXE_Z and MDPP_AXP.EXE_Z. If these are usable for you, then you can just grab the linked .EXE, FTP it, uncompress it, and you are all set. PLEASE don't FTP the libraries every time: they are huge and only relatively tiny bits will have changed.
**IMPORTANT** The instructions for setting up MDPP assume that the full distribution is available. If you want to try to get it running with only the BASE distribution, you may have to customize the file MDPP.COM to remove some lines that point to missing bits of MDPP. If you need to do this, please mail the result to me and I will build it in. This idea of a BASE distribution is a bit new. It will take time to get it fully function.
MDPP
|
+--- GENERAL The VMS program executables.
|
+--- LIB The Libraries and some .COM files
| |---- RGB The color
tables
| |---- MENU Some examples of user menus
| +---- PROC
Some examples of procedures
|
+--- DRIVERS The Driver libraries
| |---- DECW The DECwindows
driver
| |---- VWS The VWS driver
| |---- UWS The Ultrix
DECwindows driver
| |---- OWS The OSF/1 DECwindows driver
|
+---- LEXIDATA The Lexidata driver
|
+--- UGEN The Ultrix programs and libraries
+--- OGEN The OSF/1 programs and libraries
+--- DOC The text docs
+--- ON-LINE The BOOKREADER docs
+---
DDIF The BOOKREADER docs (DECwrite)
|
+--- EXAMPLES Some examples.
|---- HELICES
| +------
STRAIGHTEN
|---- MOVIE
|---- PLANE_LAYER_FILTERING
+----
PLANE_LAYER_RECONSTRUCTION
<smith@mcrcr.med.nyu.edu>
Differences between VMS and UNIX
Note that the behavior of MDP under Ultrix is essentially identical to that
under VMS. The interrupt control characters behave in the same way, except
that they follow the UNIX model, not the VMS model. In particular under
Ultrix, <Cntl-\> means `Cancel' and <Cntl-C> means `Quit', and
<Cntl-D> means <EOF> (equivalent to Cntl-C,Y and Z,
respectively).
Obviously there will be small differences between the VMS and Ultrix versions. Mostly, these are listed in the docs. Please look at the docs for RD, SV and IO for the file processing differences.
Getting Started with MDPP
Once you have installed the MDPP you need to figure out how to use it. The
MDPP can be started on the VAX by typing `MDPT', if the approproiate task has
been installed. The program will begin by printing a series of messages to you
which you answer as follows:
.IS OUTPUT FOR A CRT (1=NO): x
.ENTER NAME OF OUTPUT FILE (A20):out/O/I/S
.ENTER NAME OF INPUT FILE (A20): inp
If the output device is not a CRT then enter `1'; otherwise enter a <cr>. The output file name is entered in response to the next prompt; the default is `SYS$OUTPUT:'. Output processing is controlled by the switches `/O', `/I' and `/S'. Using the `/I[NPUT_LOG]' switch causes an input log to be generated containing all commands and data entered to MDP. This logfile, called `INPUT.LOG', should be able to be re-submitted to MDP to re-create the current session. Note that it is only useful to use this switch if you are logging a terminal session. The `/O[UTPUT_LOG]' switch controls whether an output log, called `OUTPUT.LOG', is to be generated. There is no point in requesting an output log if a general output file is being created. If a general output file is request then the `/S[POOL]' switch controls the spooling of this output file. If the file is to be spooled then append `/S' to the file name (e.g. `MYFILE.OUT/S'). If just `/S' is entered then a default filename is assigned (MDPPSPL.DMP) and the output is spooled at the end of the run and the file deleted. The input file is to be entered; the default is `SYS$INPUT:'. If an input file name is entered input will come from that file. The default extension is `.INP'. If an input file is entered then MDPP will ask if MACRO processing is to be done (see the write-up for the MACRO and LOOP processors). The prompt is:-
.ENTER `1' FOR MACRO PROCESSING: m
Entering `1' will cause the MACRO processor to be invoked and an ex panded input file will be generated.
.FILES OPENED SUCCESSFULLY
indicates that processing, if requested, is complete and all further input will be from the designated input file. For the beginer, this will be the terminal.
This tedious input can be simplified considerably and the input all placed on a single line in a comma-separated list, as follows:-
$MDPT x,out,inp,sw (for VMS)
mcgcr0-14> mdp x,out,inp,sw (for Ultrix)
As before, `x' is either "1" for the `dumb terminal' mode or blank for the SMG screen managed output., and `sw' is either "1" to activate the MACRO processor (only if you have an input file please) or blank to skip MACRO processing.
The program will now clear the screen and be ready to start work. The actual response will depend on the manner that it has been started.
The `:>' or `Command:> 'prompts indicate that the program is ready to receive input from the terminal and the user, by now in a frenzy of excitment, will comply.
Commands are read in the FORTRAN format (A2,2I2). Spaces are therefore significant. The 2I2 allows two numbers to be read in which provide extra information for the commands: the user is advised to respect the formating as failure to do so will lead to disaster.
In some of the simpler subroutines errors are not explicitly indicated by an error message but the expected output is suppressed (very rare in this version of MDPP). All commands should terminate with a confirmatory message: if this message is missing and the console simply types the prompt asking for the next command, something has probably gone wrong. It's up to the bright intelligent user to spot his silly mistake.
Data involved in processing steps is read from a permanent disk file into a disk or a core buffer area depending on its size, the availability of core in the program and the nature of the processing to be done. Once the data are in the program buffer (the so-called current file) the user can perform operations on these data using the MDPP's commands. At the end of each step (command) in the analysis the data is left stored in the buffer. When the user is finished, the modified data can be written back out to disk. Output is very flexible: the user can write out data after each and every step, after a small series of steps, at the end of the entire chain of processing operations, or not at all. (Note that this is different from some other packages which return the data to disk after each step. Some other packages retain the original data used at each step: MDPP does not, unless the data has been saved by the user explicitly). In the MDPP data read from a disk file is transformed by each command and then returned to the buffer, ready for the next step.
(Generally speaking it is not necessary for the user to pay particular attention to the particular type of buffer being used in a calculation. There are exceptions however when the arrays being used are `stacks' of pictures or data, and when data arrays are in core. This is sometimes important because some of the routines will work only on data held in core: usually however, these are output processes or those designed for use on processed data.)
To reiterate, analysis of the data is performed by a series of subroutines which are called in the order required by the user, the main program acting as a `shunting yard' passing the data between each of the subroutines which actually do the work. The order in which the subroutines are called is controlled by the user who generates a so-called `command list'. The command list consists of a series of two-letter commands, which specify the operation (subroutine) the user wishes to utilize, followed by a series of data lines, should these be needed.
The computational work done by each subroutine is called a job-step. Each job-step is, up to a point, independent of those steps preceding it and those which follow. The programs have been written to permit a reasonable amount of flexibility in organizing the analysis but the user should bear in mind that the order is not really variable if sensible results are to be obtained.
The core buffer available for data storage is 2,101,256 words in the present system which supports a 1,4482 or a 1283 array of Reals, a 2,0482 or a 1603 array of Integer*2s and just under a 2,9002 or a 2043 array of Bytes. This can be changed by altering two lines in the MDPP_MEMORY_MANAGER program, recompiling it and then relinking the new version into the old load module. A larger core area can greatly improve the speed of the programs provided that all the data can be held entirely in core. The current space is sufficient for nearly every project you are likely to use it for. We advise you not to meddle with the core buffer size without working with the program first.
Output from `DV' is directed to the terminal, or to a display device. On this tape the command causes a file to be output to the device designated by the line `Display type' in the file `MDPP.DFL' (see below for a description of this file). At NYU we set this to `1' which designates a video display device. If you have a video display you must have (or write) a driver for it which interfaces MDPP with the device. We provide drivers for the LEX-90, METHEUS, GOULD IP8500, GOULD IP9000, UWS, VWS, DECWindows and the AED displays.
'DV 3' puts up a very crude picture on the screen of any terminal. `DV' also uses ReGIS to plot images on the screen of a VT125 or VT240 series terminal; `DV 1' is quite quick; `DV 2' is slow, but the quality is surprisingly good (these two programs were provided by Dr. Michael Rademacher in Albany, NY).
Many programs (but not all) which require the cursor position to be marked inside the image window allow you to double-click inside the window (or hit <Cntl-E>, VAX only). This causes a sub-window to be created with an enlargement of the area within it. This is to allow the user to position the cursor to within a sample point in the image: this is generally impossible to do on the main display since the MDP images of large areas are displayed at a resolution too low to permit cursor positioning at the single pixel level. This sub-window automatically extinguishes itself if a mouse key is clicked, or the cursor is moved outside the displayed area. A subwindow is not displayed if the magnification of the original image is already sufficient to allow single-pixel positioning.
Defaults (or: What am I going to do NOW!!?)
The MDPP is a complex program. The documentation is idiosyncratic and there are going to be many times when figuring out what to do will be well-nigh impossible. As an aid to the confused (and to make life easier for the cognoscenti) MDPP tries to have acceptable defaults available for all the inputs requested by the various commands. The correct thing to do when faced with a confusing situation, is to just hit <cr> and see what MDPP thinks the right answers are. Now obviously this is not going to work all the time. So if you are confused and you have not saved the last step, back off from the command by hitting <cntl-Z> (VMS) or <cntl-D> (UNIX) to exit to the command prompt, save the file, and then restart the command. Now you can play: if you get the input arguments wrong just re-read the file and try again. If the file is saved from the previous step, there is really nothing that can get seriously screwed up..
Using the Examples
The outline here for the usage of the MDPP is undoubtedly less adequate for a
user that needs to get started than it might be. Unfortunately, there is no
good way to communicate the 20-odd years that have gone into program
development and the thinking (and sometimes the lack of it) that has influenced
the growth of this package.
For the most part, MDPP deals best with the problems it was designed to tackle, EM images and structural biology. Some of the tools here are unique and have never been successfully reproduced on other integrated packages (the helix stuff is an example, shadowed particle processing is another). We are very happy with the 2-D filtering tools as well and the 3-D reconstructions from tilted views of 2-D crystals.
However, if you are looking for a package to do general image processing of color images, or morphing, etc. MDPP is not the tool for you. There are a few tools, but sophisticated stuff isn't there, and never will be, probably. If you want to slice and dice 3-D images at high speed, you need a SGI and something like AVS as your IP package, not MDPP. My guess is that the tools for analyzing radiological data are probably all there, but we do not have the experience or expertise to recommend MDPP in this application.
Getting started is tough. But the only way to come to grips with the programs is to use them. Play around! Read in one of the example files (e.g. DONNA.BMD, or MANDRIL.BMD), get maximums and minimums (MM), generate noise images (GN), display them on the workstation (DV), slice their values (SL), add noise to DONNA (SU), smooth the result (SO), compute a total image power (TP), renormalize (NR), draw some contours (PL), warp the image (WA), etc, etc... Look thought the "Menu of commands" and try some things you like the look of (maybe they will work [our fault], maybe not [your fault] :-). But don't get scared off and if you have a major problem, feel free to call or E-mail for help.
Finally, when you have built up a bit of confidence, look at the examples in the area MPP:[EXAMPLES]. This are contains complete sets of data and command lists to allow you to see the MDPP in action for several of the major problem areas where the MDPP works well. Don't screw up the files in that area! Rather, copy them over to your own space and play with them. Change the command lists, use the commands interactively, fiddle. Report the bugs if you find any! Don't accept stuff you do not understand, and don't accept anomalies in the processing (that is how we have found some key errors).
Finally, good luck! We have fun making MDPP (for the most part that is) and think it is a really great product. Your use of it can make it better. Keep in touch!
List of Files with this Distribution
You will obtain a complete working version of the MDPP, allocated in several
directories. On the DECUS VMS distribution, the sources are stored in LHARC
compressed archives: LHARC is located in the [GENERAL] directory and is
`activated' when you execute the MDPP.COM setup file (see below). In the UNIX
distribution files are uncompressed.
- [MDPP] - All the sub-directories, and the AA_README.1ST file.
- [MDPP.GENERAL] - The MDPP.EXE built task, the command files to rebuild MDPP, and the utility tasks. Also included is the main program, MAIN.FOR which the user may wish to alter. Additionally, a copy of KERMIT.EXE has been included. Please do not delete this since it may be valuable if file transfers are needed to patch your system. The executables for the Alpha are also here, as <file>_AXP.EXE.
- [MDPP.LIB] - The library file containing all the MDPP and utility subroutines (MDPP.OLB) and the current MDPP macro library files SYSLIB.MCW, and a file which can be used as a model for a user's own macro library in his own area (USERLIB.MCW). The Libraries for other system facilities (PLOTTING, etc.) are also there. Note that (nearly) all source is written in FORTRAN. You also get a copy of the file `MDPP.DFL', the default file, which you may need to copy into your own working area. Libraries for ALpha are also found here.
- [MDPP.LIB.RGB] - Color tables for the display (which you can modify) Most of these files were the gift of Dr. Joachim Frank.
- [MDPP.LIB.PRC] - The procedure library. You can modify these and/or add to them as you see fit.
- [MDPP.LIB.MENU] - The menu library. You can modify these and/or add to them as you see fit.
- [MDPP.DOC] - Documentation files for the program package.
- [MDPP.DDIF] - DECwrite source files for the documentation.
- [MDPP.ON-LINE] - The BOOKREADER files for the documentation.
- [MDPP.IMAGE] - A dummy area set up as for a user. It contains a model for a LOGIN.COM file, which other users of the system will need to copy or adapt, and also a test image DONNA.BMD which can used for testing purposes for MDPP.
- [MDPP.LOCAL] - Used for files modified to accommodate the local system. This area contains the library file LOCAL.OLB which is empty (intentionally). <not distributed in the DECUS distribution>
- [MDPP.SOURCES.JP] - Contains the correspondence analysis program from Dr. J.-P. Bretaudier. This is not a part of MDPP code,
and is not supported by NYUMC. We will refer bug info. to JP, however. NOTE! that this is a separate, Copyrighted package which we redistribute with permission. Redistribution is permitted PROVIDED the copyright statements in the code remain in place <compressed for DECUS>
- [MDPP.SOURCES.SOURCE] - Contains the VAX-specific MDPP source code <compressed for DECUS>
- [MDPP.SOURCES.USOU] - Contains the Ultrix-specific MDPP source code <compressed for DECUS>
- [MDPP.SOURCES.UVMS] - Contains the common UNIX/VAX MDPP source code (most of the code falls into this category) <compressed for DECUS>
- [MDPP.SOURCES.DISPLAY] - Contains the display driver routines: you can alter these if you need to do so. They should be device independent, despite the `LEX_' prefix on most of them <compressed for DECUS>
- [MDPP.SOURCES.WINDOW] - Contains the SMG$ library routines. This is a package written by Hayes Dansky at NYUMC. The package was never completed, and is still being modified to better accommodate MDP. You are free to use the WINDOW routines, but they may be altered without warning on future re-issues of the software <compressed for DECUS>
- [MDPP.SOURCES.MFTU] - (not distributed) The MFTU package for data preparation for mailing <compressed for DECUS>
- [MDPP.SOURCES.UTILITIES] - This directory contains sources and compressed distributions of other useful program. Notably, NIH-IMAGE for the Macintosh. These need to be extracted from their archives before they can be worked-with (either ZOO or LHARC). <compressed for DECUS>
- [MDPP.DRIVERS...] - These directories contain the device drivers for the different display devices for which we currently have code. Note that we do not have Metheus or AED displays and so cannot verify that the drivers written by others and distributed here do actually work. <compressed for DECUS. Contains only DECwindows, UWS and VWS code)
- [MDPP.DRIVERS.FACIT] - Contains programs for displaying images the FACIT printer.
- [MDPP.EXAMPLES] - Contains examples of processing of different types of data. All files needed to work through the examples should be provided here. Complain if it is broken. The examples from the 1992 PSC course are nolonger included due to their large size.
- [MDPP.UGEN] - Contains the Ultrix libraries and executable (mdpp.x).
- [MDPP.OGEN] - Contains the OSF/1 libraries and executable (mdpp.xo).
The History of the MDPP
The MDPP was written by P.R. Smith on the F. Hoffmann-LaRoche IBM 360 &
370 computers in Basel, Switzerland, beginning in 1972. Additional program was
written by Drs. U. Aebi and A.C. Steven. MDPP was ported in
1978 onto the PDP 11/70 at NIH by Drs. Benes Trus and A.C. Steven. The NIH
system (re-named PIC) was given to U. Aebi at Johns Hopkins in 1980 who passed
it back to P.R. Smith at NYU at the end of 1981, with improvements incorporated
by Dr. Loren Buhle in the Aebi lab, where it was merged with the then current
IBM version of the MDPP to create a PDP11/RSX11M version of the MDPP. Since
the transport of PIC to JHU, the MDPP and PIC systems have diverged, and are
now distinct packages with a common root in the old MDPP/IBM from Basel. The
first version of MDPP/VAX was generated by Loren Buhle at JHU based on
MDPP/RSX, and was brought to NYU in 1985 for debugging and reorganization. The
port to Ultrix was also started by Loren Buhle, and was finished by Ross Smith
(in 1991). Rachel Oberai at DEC supplied a DECstation 3100 to use as a
conversion platform. The OpenVMS/AXP port was performed in NY in March, 1993,
also after the loan of a computer from DEC. The NYU Medical Center GCRC
provided the use of the Alpha-OSF/1 platform for the port to that operating
system.
Many other individuals have contributed code incorporated into the MDPP, including (in no particular order) David Agard, J-P Bretaudier, Joachim Frank, Terry Frey, Michael Radermacher, Owen Saxton, Michael Unser, Lyn ten Eyke, Tony Crowther, Linda Amos, Robert Solomon, Billy DeLeon, Terry Peters, Peter Maas, Suzy Gottesman, Roland Buerki, Tim Baker, Richard Henderson, Mike Schmid and Andreas Engel. Marin van Heel and Michael Schatz helped with the movie program and provided hints to aid our X-programming. Tom Clarke did most of the work getting the on-line documentation started. A stripped-down Cray version of the system was developed at PSC in 1990 with the hard work and skill of Doug Balog and Jim Joyce, student programmers, and Alex Ropelewski and David Deerfield on the PSC staff.
This version of the MDPP has been extensively rewritten since publication of a short report on the system in 1978 (P.R. Smith, Ultramicroscopy, 3:153), including a completely new user interface. One major strength of MDPP is that it has been constructed to make use of compute-servers for the analysis of large computational tasks. The MDPP running on a small workstation (under VMS or Ultrix) will decide whether the computational task assigned by the operator can be done locally, or whether a remote compute-server could provide better service. MDPP then selects the appropriate compute-server, either the VAX 6000 front end or the PSC Cray Y/MP, and automatically sends the job to the server. The operator either remains on-line to watch the progress of the job (in the case of the VAX 6000 as server which employs an active DECnet link), or is free to do other tasks until notified of the completion of the remote job and the availability of the computed data (as with the Cray). The description of this is published in CABIOS, Vol 7, pp. 501-507,1991.
The Mandatory Disclaimer
Users of this software package, which includes MDPP and the utilities, accept
full responsibility for its possession and use. Users understand that this is an unsupported package provided at no charge consisting of experimental
software intended for research purposes only. The package is provided as-is
without any warranty of any kind expressed or implied as to its fitness to
perform any function or meet any specification. No warranty is made that the
contents of this package or the use of this package will not infringe on any
patent, copyright, trade secret or trade mark of any third person. None of the
contributing authors, nor the institutions where they currently work or have
worked in the past, nor DIGITAL EQUIPMENT CORPORATION (DEC), nor DECUS accept
any liability for the contents of the package, the use of this package or any
fragment of it, or the consequences of using the package or any of the utility
programs. A user of this package accepts full legal liability for the
possession of the package, its components and any and all use thereof. A user
accepts all costs of legal defense for any and all legal actions which may
arise from use of the package. A request for a distribution tape of the
package, or its use, is understood to be construed that user undertakes to
defend the authors and their institutions, at the users own cost, in any legal
actions which may arise from the possession or use of the package by that user.
Use of this package in conjunction with medical patient care is not
recommended. Use of this package in a clinical environment is the sole
responsibility of the Chief of Service of the relevant clinical department who
must establish on his own authority that the package is free from errors which
could affect any aspect of patient care. It is recommended that patient
"informed consent" be obtained from all individuals whose clinical data is to
be analyzed with this package, appraising them of these conditions of use. The
package is believed to be free from extraneous code which would constitute a
`Virus', `Worm', `Trojan Horse' or similar code which would damage a computer
or its files: however, no specific checks have been made for such extraneous
code and no guarantees can be made that such code has not been inserted,
unknown to the authors. Therefore, the authors and their institutions accept no
responsibility for damage to data or equipment, loss of use of any system,
disruption of programmers time or any other disaster or difficulty arising from
the use of MDPP or any of the utility programs.
Availablility, Copyright & Support
It is, therefore, a condition of use of the MDPP that the support for its development as scientific research tool be acknowledged in all publications describing the work. An example of a suitable phrase is: "The development of the MDPP package was supported in part by the NSF through grant BIR-9410750" but modifications of this may fit better in some cases. For the purposes of defending my grant I would be very grateful if people were to E-mail me with the citations of papers that describe the science done with the help of the MDPP.
I understand, of course, that everyone tries to minimize the clutter in the `Acknowledgments' bit in the paper. It has been made quite clear to me by the NSF, however, that in these tough times, NSF, NIH and indeed all US Federal agencies supporting science need to justify their activities by showing a product. The best product is translational science, that is, science that starts in a lab, and turns into a deliverable like a cure for the common cold, a new software package to replace Lotus 1-2-3reg., or whatever. Failing this, lists of papers documenting that the Agency investment produced something that others cared about, is an acceptable alternative. Showing use of tools supported by development funds is therefore essential to preserve these programs. Please help!