Successful set up of I-TASSER Suit on Virtual machine - Tips and Troubleshooting

I have included a list of details regarding my implementation of the I-TASSER suit package (v2.1) as well as troubleshooting steps taken regarding common errors to result in a successful, smooth running machine. In addition I provide information about the environment and hardware used to run the package and approximate times for each simulation based on the environment and number of amino acids. I hope this proves useful to some.

Note that FORTRAN STOP is a normal exit and is not an error if printed.
-Added printf “2.2 Run PSSpred” to runI-TASSER.pl (missing 2.2 run confirmation correction)

-removed # from line 12 of runI-TASSER.pl (2.4.1 homology removal loop fix)

-rename seq file to seq.fasta (specified seq file determined by -datadir, NOT filename)

-replaced solve 32 bit (included) with solve.pdf 64-bit (recompiled) (infinite run solve issue)

-updated Ubuntu with following commands in terminal to correct infinite run solve threading issue:
sudo apt-get update
sudo apt-get install ia32-libs
sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0 lib32asound2

-manually unpackaged wgt.tar.bz2 into tmp directory (in system files under usrname and I-TASSER) and I-TASSER/data directory

-installed new JRE (openjdk7) from https://apps.ubuntu.com/cat/applications/openjdk-7-jre/ (missing/incomplete JAVA component correction)

-located java using 'whereis java' command (should have installed to /usr/bin) (JAVA_HOME setting incorrect error correction)

-used -java_home /usr/ argument in command line to point to correct java path. Default java_home path points to usr/java/latest and program uses $java_home/bin/java to find and execute java. Redefining java_home changes incorrect path (/usr/java/latest/bin/java) to correct path (/usr/bin/java). Java is essential to running wMUSTER, wPPA, wsPPA (JAVA_HOME setting incorrect error correction)

-downloaded newer stride DB from I-TASSER suit website and replaced old stride DB. DB seemed be missing over 300 stride.7state files needed for wMUSTER to run correctly. Cause of absence is unknown. (missing 7state file correction)

-used 'sudo nautilus' to move bzip2 and associated system files to /usr/bin/. used for simulations (simulation bzip2 missing error correction)

NOTE: With 70 aa's simulated (serial) in I-TASSER, each simulation run takes approximately 1 hour 35 minutes to complete. Progress of the run can be monitored by checking in the tmp directory for the current simulation run file (containing 44 files). Right clicking and viewing the properties of this file periodically will allow viewing the change in the file size. For 70 aa's each simulation concluded after the file size reached approximately 8.1 MB. This was built and run on a virtual machine running Ubuntu 64bit as the guest OS and windows 7 64bit as the host. The host possessed a single i7 processor, 8 GB of DDR3, and a 1 TB hard drive (200GB dynamically allocated to VM). Hyper threading was enabled in the BIOS. I allocated 6 GB of RAM to the guest machine while it was running and allowed the virtual box to allocate 3 CPU's to the guest machine. Note that using more CPU's than are physically present will make the system very sensitive to other input and should not be done if the user wishes to work on the host OS while running the simulation. After each simulation is complete there should be an output file labeled with the sim that was completed (i.e. out1A, out2A, out3A, etc.) in the datadir. Ensure that these files are complete and have the correct length of AA. In these files you can also locate the start and stop time of each simulation, giving you an estimate on the run time under your current settings.

Upon successfully making restraints and starting the simulations (step 4.1) 14 Simulation files should be created and located in the datadir. The names/types of trajectories generated are decided in runI-TASSER.pl lines 1304-1312. If the target is identified as easy then A=4 and M=10, else A=6 and M=8. The names for my 70 AA run are as follows:
seq.fastasim_1A seq.fastasim_1M
seq.fastasim_2A seq.fastasim_2M
seq.fastasim_3A seq.fastasim_3M
seq.fastasim_4A seq.fastasim_4M
seq.fastasim_5A seq.fastasim_5M
seq.fastasim_6A seq.fastasim_6M
seq.fastasim_7M
seq.fastasim_8M

rep*.tra*.bz2 files will be generated at the conclusion of each respective simulation. If these files are not present an error involving bzip2 or premature deletion of the IT* (ITseqfasta) file located in the tmp directory is likely. Older versions of the I-TASSER suit (1.0 and 2.0) used a command in the zysubmod file that attempted to copy all rep$x.tra files ($x ranging from 1 to 16) to the datadir. This commonly resulted in '/bin/cp : cannot stat rep$x.tra: No such file or directory' errors due to the absence of some rep*.tra*.bz2 files not being generated from the earlier easy/non-easy target decision. While these errors were printed the modeling should still have resulted in a complete run.
Node (node_seq.fastasim_1A) and in*.dd (in1A.dd) files with similar names will be generated in the datadir as the simulations run and should only show at the beginning of the respective simulation.