Abrelax – Dunbrack02.lib.bin missing

This topic has 3 replies, 2 voices, and was last updated 13 years, 3 months ago by Anonymous.

Viewing 1 reply thread

Author

Posts
- September 18, 2011 at 1:30 pm #1033
  Anonymous
  Hi,
  
  I’ve installed Rosetta 3.3 (yes, downloaded after 9/6/11) and started some abinitio runs with the second method described in Wang et al. 2011 (PLoS ONE). After a few minutes Rosetta stops with the following warning:
  
  “Warning: Unable to locate database file Dunbrack02.lib.bin”
  
  I’ve checked the database directory, the file is not present. I have also checked Rosetta 3.2.1; the old version contains the files Dunbrack02.lib.bin and Dunbrack08.lib.bin, which are both missing in Rosetta 3.3.
  
  Doing standard abinitio runs without the special options for treating disordered regions also results in the same warning from Rosetta 3.3 as described above.
  
  Here is the SGE script I am using:
  
  #!csh
  #$ -S /bin/csh
  #$ -wd /state/partition1/test/
  #$ -j y
  #$ -t 1-50000
  ${rosetta3} -in:file:fasta t000_.fasta -in:file:frag3 aat000_03_05.200_v1_3
  -in:file:frag9 aat000_09_05.200_v1_3 -in:path:database ${rosetta3DB}
  -abinitio:relax -abinitio::increase_cycles 10
  -abinitio::rg_reweight 0.5 -abinitio::rsd_wt_helix 0.5
  -abinitio::rsd_wt_loop 0.5 -disable_co_filter true
  -replonly_residues 29 30 31 32 33 34 35 36 54 55 56 57 58 59 60 61 62 63
  -correct -residues:patch_selectors replonly
  -nstruct 2 -score::weights score13_env_hb
  -user_tag j000$SGE_TASK_ID
  -run::seed_offset $SGE_TASK_ID -out::file::silent default_$SGE_TASK_ID.out
  -out::file::scorefile score_$SGE_TASK_ID.fsc
  
  Am I the only Rosetta 3.3 user experiencing these problems with missing database files?
  
  Thanks for your help.
  
  Oliver
- September 18, 2011 at 1:37 pm #6057
  Anonymous
  This file is supposed to be missing; don’t worry about it. The text-file Dunbrack libraries are large and take many (30) seconds to read in. Upon first use, Rosetta serializes the data structure containing the Dunbrack libraries and writes it to disk as Dunbrack0*.lib.bin. Next time you use Rosetta, it re-uses the binary version instead, which reads in in tenths of seconds or less. After one use of Rosetta (that did packing), the file will exist, and the warning will go away.
  
  The next lines after that warning should have been explicitly about creating the binary file and saving it to Dunbrack02.lib.bin. If that’s not so, or if you still don’t have the file after a run, then check that the Rosetta executable has write permissions to the database directory.
- September 18, 2011 at 4:06 pm #6058
  Anonymous
  Thanks for the hint!
  
  I’ve just finished some more testing. Rosetta 3.3 is a fresh installation, so the abinitio disorder scripts were the first jobs to use this new version.
  It turned out that including the following lines in the script somehow prevented Rosetta from creating the Dunbrack02.lib.bin:
  -replonly_residues 29 30 31 32 33 34 35 36 54 55 56 57 58 59 60 61 62 63 -correct -residues:patch_selectors replonly
  When I leave out the above mentioned lines, Dunbrack02.lib.bin is created.
  
  So, for the future I will remember to run a single job with a new installation of Rosetta first. Because submitting several thousand jobs to the SGE queue could end up in quite a mess, when several jobs want to create the Dunbrack libraries in parallel.
  
  Thanks a lot!
- September 18, 2011 at 4:48 pm #6059
  Anonymous
  Andrew wrote the binary-file system to be able to handle many processes trying to create the file simultaneously. Nevertheless, you are correct that it’s better to run a single short job first, for safety’s sake. The easiest thing is to run the fixed backbone design integration tests (cd test/integration; integration.py fixbb).
Author

Posts

Viewing 1 reply thread

You must be logged in to reply to this topic.