File DDIMPLEM.VAX not updated in 1999 JMMS GB 04 Dec. 1996 |------------------------------ DIRDIF-96 -----------------------------| | Instructions for implementing DIRDIF on a VAX/VMS + Alpha/OpenVMS | | WARNING: NOT UPDATED IN 1999: compair with ddimplem.unix ........!!!!! | ---------------------------------------------------------------------| | This procedure has been tested on a Alpha ... computer under OpenVMS | | For authors, e-mail addresses, etcetera: see file DDEXEC.VAX | | ---------------------------------------------------------------------| In the DIRDIF.PRIMER and in output listings, capitals are used for all file-names. However all file-names are appended ( by the VMS system ) by '.DAT' . For instance, the name of the ATOMS file is: 'ATOMS.DAT' . Note: There is no difference in file names for different compounds: the execution of DIRDIF must be in the proper directory of the compound! IMPLEMENTATION. Proceed as follows. Note: '===>' means: 'enter the instruction:' , '! ...' are comments 1. Create the directory DDROOT and subdirectory DDFTP and make [.DDROOT.DDFTP] the default (working-) directory. ===> CREATE/DIR [.MONOS] ! this is the DIRDIF root directory ===> SET DEF [.DDROOT] ! ===> CREATE/DIR [.DDFTP] ! directory to store the ftp - files ===> SET DEF [.DDFTP] ! 2. Get all the files belonging to the DIRDIF program system using ftp: WARNING: next address is valis up to the end of December 1996: Ask for new ftp instructions for 1997 via: ptb@sci.kun.nl ===> ftp VM.UCI.KUN.NL === out of date ===================== You have now downloaded about 30 files into [.DDROOT.DDFTP]. 3. List the files, and look at DIRDIF.NEWS : ===> DIR ! just to see ... ===> TYPE DIRDIF.NEWS ! what is new since last version ... Some explanation: ... Some of the files you just received are for information only. Note: in the following implementation we assume that all essential files are present. If not, things go wrong and you have to inspect DIRDIF.IMPLEM section 2 to find out which files are missing. +++++++++++ this part in the IMPLEM file is not updated, +++++++++++ so some files are different now (1996). 4. Get and run DDMAKE.VAX, which is a command file to be used for implementation of the DIRDIF system on the VAX/VMS : ===> SET DEF [-] ! Return to [.DDROOT] ===> SHOW DEF ! Answer: ....[.DDROOT] ===> COPY [.DDFTP]DDMAKE.VAX []DDMAKE.COM ===> @DDMAKE ! Execute the DDMAKE file Main results: - Data files (CRYSIN.DAT and FREF.DAT) for the test structure compound MONOS are stored in subdirectory [.DDROOT.MONOS]. - The DIRDIF system files needed during execution (i.e. DDHELP, ORBASE and ORUSER) are copied to [.DDROOT]. - The FORTRAN source files are copied to [.DDROOT], but they are removed after compilation. - The executable program files *.EXE are stored in [.DDROOT] . - The file DDEXEC.VAX has been copied to [.DDROOT]DIRDIF.COM . The latter is the command file for the execution of DIRDIF. - All files in [.DDROOT.DDFTP] remain as back-up files; some files (information only) were not used at all. Note: if something went wrong, or after an update of one or more files, you run DDMAKE again. 5. In DIRDIF.COM we must define the path to the executable program files in [.DDROOT] . The following line has to be adapted: DDROOTPATH :== dua0:[xxx.DDROOT] To find out how to adapt: dua0:[xxx. give 'SHOW DEF'; this will prompt the exact information ( because [.DDROOT] is the (present) default directory ). ===> SHOW DEF ===> EDIT DIRDIF.COM change one line: DDROOTPATH :== dua0:[xxx.DDROOT] We also need to define the path to a user's private copy of the file ORUSER. Please, read the comments given here about defining: ORUSERPATH :== dua0:[yyy] ..... See below (5A.). ===> EXIT 5A. In DIRDIF.COM the path to the file DIRDIF.ORUSER, ORUSERPATH, is defaulted to be identical to the path: DDROOTPATH . This is fine if you are a sole user. If not, we prefer to define the path to a user's private copy of the file DIRDIF.ORUSER. Therefor the user should enter a definition in his login file, saying something like: ORUSERPATH :== dua0:[yyy] How to adapt: 'dua0:[yyy]' is depending on your choice where to put the user's private copy of DIRDIF.ORUSER . See below: 8. 6. Start testing the help function of DIRDIF by calling DIRDIF from working directory [.DDROOT]: ===> SET DEF [DDROOT] ===> @DIRDIF H 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 .... =========== later: look in DIRDIF.IMPLEM (which is to be improved!) =========== now: please, let us know immediately (by e-mail) ...... 7. Next test run of DIRDIF is done on the data of compound MONOS. The tests are described in detail in the PRIMER, Section 4. In this 'preliminary' test stage we use the MONOS data in [.DDROOT.MONOS], later we have to allow access from any (user) directory with structural data, see 8. Make [.DDROOT.MONOS] the working directory and execute program CRYSDA as a program of the DIRDIF system: ===> SET DEF [.DDROOT.MONOS] ===> @[-]DIRDIF MONOS CRYSDA Program CRYSDA reads the CRYSIN file (CRYSIN.DAT) and prepares the CRYSDA file (CRYSDA.DAT). 8. We have to make DIRDIF accessable from any (user's) directory with structural data by defining the location of DIRDIF.COM in the user's LOGIN file. We also need to define the path to a user's private copy of DIRDIF.ORUSER by defining ORUSERPATH. ===> EDIT (user's) LOGIN insert: DIRDIF :== @dua0:[xxx.DDROOT]DIRDIF.COM replace 'dua0:[xxx' by the same value of 'dua0:[xxx' as was done in DIRDIF.COM, see 5. insert: ORUSERPATH :== dua0:[yyy] where 'dua0:[yyy]' depends on where to put the user's private copy of DIRDIF.ORUSER, see 5A. ===> EXIT Note : If you have an older DIRDIF.COM file, remove it, or use a temporary name for the new one while testing. For instance: if you rename DIRDIF.COM (new version) to DDNEW.COM you can execute the tests by substituting 'DDNEW' for 'DIRDIF'. (Do not forget to rename also this file name in the LOGIN file definition to DIRDIF accordingly, see 8.) 9. To get the assignment activated: ===> @login 10 Some more test runs. Change to the directory with the structural data of compound MONOS ; run the help function once more; also run program PATTY: ===> SET DEF [.DDROOT.MONOS] ! directory with MONOS test data ===> DIRDIF H ! (or DDNEW) ===> DIRDIF MONOS PATTY ! (or DDNEW) Program PATTY solves the structure of MONOS. 11 To complete the testing procedure, follow the exercises given in the printed material DIRDIF.PRIMER, section 4. It is stongly advised to test the performance of ORIENT. 12 After the MONOS test runs have been completed, decide what to do in the future with the files created by DIRDIF: a. Normally, LIS1 (= LIS1.DAT, older version: = IPR2.DAT) is to be inspected, may be printed? or copied to keep record of what went on ? b. Output atom files (ATOMS.DAT, XYZN.DAT, SCH.DAT, SPF.DAT) have been created to be tranferred to your graphics program and to your least-squares refinement program: other conversions =if any= should be automated! See 14. For a first plot, you may skip the possible 'Q'atoms (low peaks). c. The output files normally have to be kept for further DIRDIF runs. Nevertheless, if CRYSDA has been removed, the next DIRDIF run on the same compound automatically generates this file again. d. If for whatever reason DIRDIF crashes, then remove all files (maybe unfamiliar to you) that this run has created and were not erased automatically because of the crash ! 13. In order to make DIRDIF available for a group of users the system manager ('owner') has to take some action: [.DDROOT] with the files DIRDIF.COM, DDHELP, ORBASE, ORUSER, the PROGRAM.EXE files and directory [.MONOS] have to be copied (moved) to public (read only) directories (check the value of 'DDROOTPATH' in DIRDIF.COM and in the LOGIN files, see 5. and 8.). Special care should be taken with DDHELP, ORBASE and ORUSER which must be available for listing by all group members/users. Therefor check their protections set in DDMAKE. Mind that these assignments only take effect after the user's log in. 14. The user is now ready to use the DIRDIF system. When you start working on a structure of your own it is essential to store the data files in one unique directory dedicated to this structure only, and to make it your default directory before starting to execute DIRDIF. Cherish your private ORUSER as a self made reservoir of structural models and structural fragments. 15 Notes At present the ATOMS output file is converted to '*'.DAT: 'ATOMS' is the original DIRDIF output ATOMS file, 'XYZN' is the SHELXL 'INS' file (just rename it to 'INS') 'SPF' is the input file for PLUTON (graphics, A.Spek) 'SCH' is the input file for SCHAKAL (graphics, ??) ------------------ end of DDIMPLEM VAX --------------------------------