next up previous contents index
Next: File types Up: Miscellaneous rules and features Previous: Controlling breakpoints and the   Contents   Index

Subsections


File naming

There are several filename generating mechanisms that facilitate file handling. Not all of them apply to all file types.

Environment variables

There can be UNIX shell environment variables in any input or output filename. The environment variables have to be in the format ${VARNAME} or $(VARNAME). Also, two predefined macros are available for string variables:

Output directory prefix

For all output filenames, except for those that start with '/', the full output filename is obtained by prefixing the filename with output_directory.


Coordinate files and derivative data

When accessing an atom file, a specified filename is tried first. If this is unsuccessful, MODELLER automatically expands the original filename by adding extensions '.Z', '.gz', or '.bz2'. This allows it to detect atom files compressed with the UNIX compress, gzip, or bzip2 commands. If the compressed file exists, MODELLER automatically uncompresses it, reads it, and puts it back into the original state after the reading is finished (note that the gzip and bzip2 programs must be installed on your system in order for this to work). If the specified file is still not found, the extensions '.atm', '.pdb', '.ent', and '.crd' are tried in this order, with and without the compressed extensions, then also with the 'pdb' prefix. This search for the atom file is repeated through all the directories in io_data.atom_files_directory (directories are separated by ':'), unless the input atom filename starts with '/', in which case io_data.atom_files_directory is neglected. Finally, if still unsuccessful and the file specified by the environment variable $PDBENT exists, the coordinate filename (e.g., the 4 character PDB code) is matched to the list of the full PDB filenames in $PDBENT (compressed and uncompressed). For example, $PDBENT file may be:

/disk2/pdb/pdb.pdb.bnl.gov/all_entries/uncompressed_files/pdb1ema.ent
/disk2/pdb/pdb.pdb.bnl.gov/all_entries/uncompressed_files/pdb1hbp.ent
/disk2/pdb/pdb.pdb.bnl.gov/all_entries/uncompressed_files/pdb1gpy.ent
/disk2/pdb/pdb.pdb.bnl.gov/all_entries/uncompressed_files/pdb6gpb.ent
/disk2/pdb/pdb.pdb.bnl.gov/all_entries/uncompressed_files/pdb1fia.ent
etc.

Any derivative data that MODELLER may need, including residue solvent accessibilities, hydrogen bonding information, dihedral angles, residue neighbors, etc., are calculated on demand from the atomic coordinates. The most time consuming operation is calculating solvent accessibility, but even this calculation takes less than 1 sec for a 200 residue protein on a Pentium III workstation.

MODELLER stores the filenames of coordinate sets in the alignment arrays. These arrays are used by alignment.compare_structures(), model.restraints.make(), alignment.malign3d(), alignment.align2d(), and several other commands. If these filenames do not change when the structures are needed for the second time, the coordinate files are not re-read because they should already be in memory. This creates a problem only when the contents of a structure file changes since it was last read during the current job.


next up previous contents index
Next: File types Up: Miscellaneous rules and features Previous: Controlling breakpoints and the   Contents   Index
Ben Webb 2006-02-28