File ddimplem.unix Update 27 Sep. 1999 (GKB Feb 97) |----------------------------------------------------------------------| | | Instructions for implementing DIRDIF-99 on several unix-type computers | | | DEC (alpha) and DEC 5000 (ultrix) machines | | HP9000 / 735 unix | | IBM Risc 6000 (aix) | | Silicon Graphics Indigo and Iris (irix (unix)) | | SUN onder SunOS 4.1.2 (unix) | | SUN-SOLARIS 2.4 | | Linux (unix for PC) | | | |----------------------------------------------------------------------| | |--------------------------------------------------------------------| | | DIRDIF-99 | | | | | | Crystal Structure Determination by Patterson Methods and | | | Direct Methods applied to Difference Structure Factors | | | | | | Paul T. Beurskens, Gezina Beurskens, Rene de Gelder, | | | S. Garcia-Granda, R.O. Gould, Randy Israel, and Jan M.M. Smits | | | | | | Crystallography Laboratory, University of Nijmegen, | | | Toernooiveld 1, 6525 ED Nijmegen, The Netherlands | | | | | |--------------------------------------------------------------------| | |--------------------------------------------------------------------| | | | | | In case of problems please contact one of the following persons: | | | Paul T. Beurskens, E-mail: ptb@sci.kun.nl | | | Jan M.M. Smits, E-mail: smits@sci.kun.nl | | | Rene de Gelder, E-mail: rdg@sci.kun.nl | | |--------------------------------------------------------------------| | |--------------------------------------------------------------------| ===========> COMPUTER DEPENDENCY for unix type computers <============== Substitute XXX (see below) to define your computer: XXX for computer: dec for DEC Alpha (ultrix) and DEC 5000 (ultrix) hp3 for HP9000 (unix ...) rs6 for IBM Risc 6000 (aix) sg for Silicin Graphics Indigo and irix (unix ...) sun for SunOS 4.1.2 (unix) and Sun Polaris 2.4 (unix) sol for Sun Solaris 2.4 (unix) linux for PC linux (unix) ======================================================================= Note about filenames The filename dictates the contents and the format of the file. Filenames are presented by capitals in all FORTRAN programs, documents, output listings, and file-identifiers. Local implementation may change the filenames ! In the present (unix) implementation the capitals are converted into lower case and the name is concatenated to the compound code (ccode). The filename conversion is done by the programs (NIJX1 subroutines). For instance the name of the CRYSIN file for the test structure MONOS is 'monos.crysin' . For DIRDIF files definitions see the PRIMER (file DIRDIF.PRIMER, or for unix: dirdif.primer) . IMPLEMENTATION. Mind the use of lower case and CAPITALS ! Note: if you have followed the instructions given in README.FTP, and already have downloaded the system, skip points 1 and 2. 1. Define "ddroot" . Decide where the DIRDIF system is to be stored: in which directory? That directory is referred to as the DIRDIF-root directory: "ddroot". Any name will do, but we will use "ddroot" in the the following text. The present implementation procedure can also be used for updates because existing individual files from an earlier download will be overwritten. However, old *.zip files should be removed ! Note: if you have an old dirdif script file, remove it, or rename it, or use a temporary name for the new dirdif script file while testing the new system, but reread point 7 for the path definition ! Proceed as follows. Note: '===>' means: 'enter the instruction:' , '# ...' are comments ===> mkdir ddroot # which is the DIRDIF -root directory ===> cd ddroot ===> mkdir ddftp # to store the new release of DIRDIF ===> cd ddftp You are now in the subdirectory ddftp of your ddroot directory. Individual files from an older download will be overwritten, but old *.zip files should be deleted. 2. Get all DIRDIF files (FORTRAN, system, info, test data files) by ftp. Proceed as follows: ===> ftp ftp.sci.kun.nl # to connect to our computer ===> anonymous # after 'USER:' or after 'name:' password?===> enter your own e-mail address ===> cd pub/dirdif # to change to the dirdif environment ===> ls # just to see its subdirectories ===> prompt # to toggle prompting to 'off' ===> bin # set binary to download binary files ===> get README.FTP # get file with ftp instructions: # if in doubt: read it, and try again ! ===> cd unix # change to directory dirdif/unix ===> mget * # get all files ===> quit # to end this ftp session. You have now downloaded all DIRDIF files into ddroot/ddftp. [ These include zip files; [ if you can not unzip: ask for a tar+gziop file. ] 3. List the files, and look at the file dirdif.news : ===> ls # just to see what you got ... ===> more dirdif.news # what is new since last version ... # (sorry: not updated per July 1999) ===> q # quit (just a few lines will do) . Some of the files you just received are for information only. The files dirdif.handout and dirdif.primer are the same as the first two chapters from the DIRDIF USER's GUIDE . We assume now that you have these two files at hand (as printed material) while testing. Look at these documents ( handout and primer ), so you know where to find explanations about many things. Note: in the following implementation we assume that all essential files are present. If not, things go wrong! Then: let us know now! 4. Implementation [ the present working directory is xxxx/ddroot/ddftp ] The file ddmake.XXX is a script file to be used for implementation of the DIRDIF system on a specific unix-type machine. For most computers we used the highest optimization with the compilation of the FORTRAN programs, but for some computers it appears that the highest optimization can not be used! (For details, see the compilation commands in the appropriate ddmake.XXX files.) ===> cp ddmake.XXX ddmake # choose substitute for XXX: # dec, hp3, rs6, sg, sun, pol, linux ===> chmod ugo+rx ddmake # to make this file executable ===> ddmake # to execute the ddmake script # (which includes executing ddmake2 and -3) Note 1: some files are double: do allow the system to overwrite ! Note 2: ignore all compiler warnings ! Modern compilers overdo ! But e-mail me in case of severe errors, please ! Results. - New directories are created, and - some files are copied from ddroot/ddftp to other directories and some of them are renamed: - Test data files for compound MONOS are stored in directory: ddroot/monos These files are for testing only. - The DIRDIF system files needed during execution (i.e. ddhelp, orbase and oruser) are copied to the dirdif directory ddroot. - The executable program files are stored in the directory ddroot, with program names given in CAPITALS. - All files in directory ddroot/ddftp remain as back-up files; some files (info only) were not used at all. (The zip files were unzipped, and therafter the *.zip files were removed.) - The file ddexec.unix (script file for the execution of DIRDIF) has been copied (and renamed) to ddroot/bin/dirdif . - At the end of the ddmake procedure the pwd still is ddroot/ddftp . Note: if something went wrong, or after an update of one or more files, you can always run ftp and/or ddmake again. 5. Edit the script file 'dirdif' for the execution of DIRDIF. ===> cd ../bin # that is: the pwd is ddroot/bin ===> vi dirdif # or use your prefered local editor First, we must check the top line of the file to define the shell ( Bourne shell or Korn shell ) which is used in the dirdif script. (Initially, this script is defined as as a Bourne shell, but some DEC (?) systems requir the Korn shell definition.) So: ======> accept or adapt the first line: #!/............. Next, we must implement the path to the files in ddroot and to a possible private copy of the file oruser, as described in the comment lines of the file, i.e. ======> adapt: DDROOTPATH=........ ======> adapt: ORUSERPATH=........ for instance, for the situation in Nijmegen: DDROOTPATH=/nsr/ptb/ddroot NAME=`whoami` ORUSERPATH=/nsr/$NAME ======> wq # write and quit, end of editing 6. Start testing by calling dirdif from present directory ddroot/bin : ===> ./dirdif h # to start up testing The DIRDIF system is called into execution without using structural data. The DIRDIF calling parameter 'h' invokes a simple help session. Try some of the possibilities. If something goes wrong .... let us know immediately (by e-mail) ...! Now assume that all goes well. 7. Define path We must make the script 'dirdif' accessable from any other directory. We have tried out and used three different options to achieve this: 7A. The file ddroot/bin/dirdif can be copied to any directory which is already accessable by an existing 'set path' or PATH= command in your start-up procedure. ===> cp ???/ddroot/bin/dirdif [target directory] where the path ??? is similar to the DDROOTPATH defined in the script file ddroot/bin/dirdif (see 5.). ===> rehash # to get this entry in the path reactivated. 7B. Of course the path to the ddroot/bin directory can be added to the 'set path' or PATH= command in your start-up procedure. It is similar to the DDROOTPATH defined in the script file ddroot/bin/dirdif : i.e. for the Bourne-shell : ===> edit the file .profile for instance: PATH=:.......:/users/local/ddroot/bin:..... for Nijmegen: PATH=:.......:/nsr/ptb/ddroot/bin:.... and/or for the C-shell : ===> edit the file .login for instance: set path=(..... /users/local/ddroot/bin .... ) for Nijmegen: set path=(..... /nsr/ptb/ddroot/bin .... ) To get this path activated: ===> logout and login again. 7C. The path to ddroot/bin/dirdif can also be defined by an alias, which is also activated in your start-up procedure. For instance, for the C-shell, in Nijmegen, we have inserted in the file .cshrc =========> alias dirdif '/nsr/ptb/ddroot/bin/dirdif' where the pass definition is the same as given for DDROOTPATH . ===> logout and login again. # to get this alias activated. 8. Test runs on MONOS Test the performance of DIRDIF with the MONOS test data as is described in the primer ! See section 4 of the primer for details. The MONOS data are stored in the directory ddroot/monos . So we now change from the present directory to ddroot/monos , and execute DIRDIF : ===> cd xxxx/ddroot/monos # xxxx : as appropriate ===> dirdif h # to test 'h' as above # enter 'q' to quit ===> dirdif monos patty # for an automatic dirdif run ===> dirdif monos obase # to generate a molecular model # for proper replies, see primer. ===> dirdif monos orient # for an automatic dirdif run Herewith we solve the structure of MONOS two times. All tests are essential. Check the results as described in the primer ! 9. After the MONOS test runs have been completed, decide what to do in the future with the resulting files: a. Normally, LIS1 (= ccode.lis1) is to be inspected: may be printed(?) or copied(?) to keep records of what went on. b. Output atom files (ATOMS, XYZN, SPF) could be tranferred to your graphics program and/or to your least-squares refinement program. Conversion to your local programs =if any= should be automated! - At present the ATOMS output file is converted to ccode.'*' : 'atoms' is the original DIRDIF output ATOMS file, 'xyzn' is the SHELXL 'INS' file (just rename this file to 'ins') 'spf' is the input file for PLUTON (graphics, A.Spek) 'sch' is the input file for SCHAKAL (graphics, ??) c. All output files normally have to be kept for further DIRDIF runs. Old files never must be removed (except maybe, at severe crashes). 10. FOR THE SYSTEM MANAGER In order to make DIRDIF available for a group of users, the ddroot directory with all files, including directories ddroot/bin and ddroot/monos (but NOT ddroot/ddftp) should be copied (moved) to public (read only) directories. Note: About twenty test structures are available via ftp; if you wish to try and experiment with those, proceede as follows. Make a directory for storage of all data, and make it your working directory, for instance - mkdir xxxx\xxxx\ccall - cd xxxx\xxxx\ccall and get the appropriate files as in point 2 but - change to directory: pub/dirdif/ccall - enter: prompt ; bin ; mget * ; quit Then follow instructions given in file README.CC . ========================================================================