Standalone vs. Zhang Server Discrepancies: Useless use of /d modifier in transliteration operator

Hi all,

I have been running the I-TASSER standalone package on my Desktop with runstyle gnuparallel multithreading on a 64-bit Linux OS. Recently, I repeated one of the jobs I submitted to the server itself and noticed structural and GO differences between the results. I have had some occasional errors that I looked up on these message boards and which were deemed as unimportant for structure accuracy. However, I was wondering if this has something to do with not updating the ITLIB (itasser library). See the script below. This is after running COACH (step 7) the first time and second time. What do we use as the PDB list when updating? Does the list in the GO folder suffice? Or do we need to make another one and put it in the PDB folder (I used download_lib.pl). Additionally, sometimes I noticed the threading was getting killed so I edited the program to use only four cores instead of the 8 that I have available. What is the issue here?

1st time:

7 run COACH to predict function: Ligand-binding site,EC number,GO terms...
/home/rrahman/I-TASSER5.1/I-TASSERmod/runCOACH.pl -pkgdir /home/rrahman/I-TASSER5.1 -libdir /home/rrahman/ITLIB -runstyle gnuparallel -protname DDB_G0271656 -model model1.pdb -datadir /home/rrahman/I-TASSER5.1/DDB_G0271656 -homoflag real -idcut 1 -LBS true -EC true -GO true
Useless use of /d modifier in transliteration operator at /tmp/root/JSD_qury/parse_blast.pl line 314.
Use of uninitialized value in printf at /home/rrahman/I-TASSER5.1/DDB_G0271656/model1/cofactor/CF_DDB_G0271656_model1.pl line 1337.
Use of uninitialized value in printf at /home/rrahman/I-TASSER5.1/DDB_G0271656/model1/cofactor/CF_DDB_G0271656_model1.pl line 1337.
Useless use of /d modifier in transliteration operator at ./parse_blast.pl line 314.
4075.22user 1190.73system 44:11.46elapsed 198%CPU (0avgtext+0avgdata 3513468maxresident)k
32990304inputs+808888outputs (284major+84600560minor)pagefaults 0swaps

2nd time:
run /home/rrahman/I-TASSER5.1/DDB_G0271220/model1/coach/CH_DDB_G0271220_model1.pl...
0.15user 0.05system 0:00.21elapsed 94%CPU (0avgtext+0avgdata 15780maxresident)k
144inputs+8outputs (10major+16892minor)pagefaults 0swaps
cp: cannot stat '/home/rrahman/I-TASSER5.1/DDB_G0271220/model1/cofactor/BSITE_model1/lig_*.pdb': No such file or directory
cp: cannot stat '/home/rrahman/I-TASSER5.1/DDB_G0271220/model1/tmsite/tms_*.pdb': No such file or directory
cat: tms_6k61M_BS02_CLA.pdb: No such file or directory
cat: lig_1f59A_BS02_III.pdb: No such file or directory
cat: lig_2bptA_BS02_III.pdb: No such file or directory
cat: tms_4ev6E_BS03_MG.pdb: No such file or directory
cat: tms_5zx5B_BS06_Y01.pdb: No such file or directory
cat: tms_2exxB_BS01_NAP.pdb: No such file or directory
cat: tms_3e6sE_BS04_FE.pdb: No such file or directory
cat: tms_5jreD_BS03_ADE.pdb: No such file or directory
cat: lig_1u6g0_P201_III.pdb: No such file or directory
cat: lig_1i7x0_P101_III.pdb: No such file or directory

I will note here that the initial job had a C-score of -4.35, so perhaps the low level of confidence affected the stark differences. My job had a final C-score of -3.90. Additionally, the first job was completed on May 12, whereas my job was just finished. Please let me know how to update my library, and whether these errors are making a difference (also if threading gets killed but ITASSER finishes, is the result to be trusted? I have assumed no).
Thank you!