Disk Space User Guide

1. Running a job which requires a lot of CPU, RAM and scratch disk. You must select the correct server and queue combination, and follow the rules explained in the man page on qtpqueues(l).

2. A project consisting of running many jobs. This type of project requires all aspects of 1. for each job, but in addition requires some data management. If the important data extracted from each job is small in size, it can be kept on your home disk, together with the text of the thesis or paper. If the data file from each job to be processed further is large, you must put it on short-term scratch, if all the work can be done in 14 days, or move it to long-term scratch. Careful planning in the beginning saves enormous amounts of time later.

3. Software building project. This usually takes a short time. Unpack a tar file, run make, debug and install. If debugging takes a long time, you really are in the next case.

4. Software engineering project. Most people at QTP do some software development. The model for such development that has been used succesfully at QTP for years by some of the more advanced subgroups is based on techniques developed by computer scientists, practiced in the industry and perfected and adapted for Computational Chemistry and Material Science by people at QTP and other places.

The model is that there is a well thought-out structure defined for each subgroup in QTP. All software lives in an account, like ~sbtprogs, for example, not associated with any individual gradaute student or post-doc or faculty, since these people move and change roles, but the group's software needs to be functional at all times. One or more individuals have primary responsibility for this directory tree.

The sharing of files by a group, with certain subgroups having write access and others having read-only access, can be arranged satisfactorily by creating special UNIX groups, in addition to the one containing all members of the research subgroup associated with each QTP faculty.

The group's software account contains the master source code, under CVS control. CVS stands for Concurrent Version System. It is software that keeps track of changes made to software. Especially for large pieces of software like ZINDO, ACES II and ENDyne, such automated source code control is essential. The CVS software consists of one command, cvs(1), with numerous options. It is very simple to use. It automatically keeps track of who makes what changes to what piece of software for which reason.

The group directory also has a checked out version of the source of all its software under deveolpment. That version is the one from which the active production executables are built.

There is also a lib and bin subdirectory with symbolic links pointing to camp directories containing the SPARC and POWER architecture specific libraries and executables. These executables and libraries are large files and should not be stored on a /home disk, but on a /camp disk. The camp-directories are owned by the group account. Symbolic links can be used to make the whole tree look simple (as if it were all on a single disk).

Each subgroup member who must do some development, should check out, with cvs(1), the piece of interest into a personal home-directory or camp-directory if the portion is too large. The member then works on the piece and uses a makefile to compile the source code of the piece and link it to the group library to load subroutines that are not modified. The test executable should be stored in a personal camp-directory, not in the group directory, so as not to jeopardize production by other group members while the new piece is being debugged.

Only after careful testing against an established set of test cases stored in the group directory and only when all test cases give the correct results, can the member update the group source code repository with CVS. The members changes should be checked by the person responsible for the group code before this checkin operation, which is very simple with cvs(1).

Below we specify in detail how each kind of disk should be used. If these practices and procedures are followed, with variations, of course, whole QTP system and all its 150 GByte of disks will be used smoothly, effectively and productively. This cooperation will benefit the entire QTP community and everyone in it.

Files that are read only once at startup can be place anywhere it is convenient. Large files that must be read, should be placed on /home/crunch_1 or on dedicated directories assigned by the computer director on /scr/crunch_2 or 3 or 4.

Files that are being written intensively, such as integral files in electronic structure caclulations, should be written to local scratch disks /scr_1.

Molecular dynamics and Monte Carlo codes do write large files, but not with the intensity that integral files or files with Coupled Cluster intermediates, Such files can be written to remote disks such as /scr/crunch_2 or /scr/crunch_3.

Never write to local workstation disks such as /scr/sred18_1 directly, but write to local scratch first and copy the result at the end of your job with