When I run a Desmond simulation, it can take a long time to copy the trajectory back to the working directory, and sometimes it fails. Why is this?

If you generate a trajectory with a large number of frames, copying of the trajectory from the temporary location on the execution host to the launch directory can be very slow, or fail altogether. This happens because the trajectory contains a large number of small files (each containing 25 frames, by default) in a single directory. When a directory has more than a few thousand files, file systems such as ext2 and ext3 (the common file systems on Linux) become very slow. More modern filesystems like zfs can handle the large numbers of files much better. As a consequence of the slowness, Job Control can fail to transfer all the files, and it may treat the job as failed and clean up the remaining files.

There are several possible workarounds.

• Limit the number of frames in the trajectory. Regardless of whether the copying is successful, any file operations on the trajectory (including viewing it) will be slow if there are too many frames.
• Run the job with -LOCAL so that the job files are written to the launch directory rather than a temporary directory. This can only be done if the launch directory is mounted on the execution host. While this workaround can eliminate the Job Control failure, it does not address the issue of the number of files.
• Increase the number of frames per file. You can do this by adding or changing the following line in the config (.cfg) file in the section for the trajectory plugin, which is usually in the mdsim section.
  
  frames_per_file = n
  
  where n is the number of frames to write to each file. You should choose n so that the total number of files is small enough for the file system to handle. If you are running the job with the desmond command, you can add the option -cfg mdsim.trajectory.frames_per_file=n to the command. Minimizing the number of files also speeds up trajectory display in Maestro.

Back to Search Results