Member Site › Forums › Rosetta 3 › Rosetta 3 – Applications › matdes_design: ERROR]EXCN_utility_exit has been thrown from: src/core/io/silent/SilentFileData.cc line: 302
- This topic has 5 replies, 2 voices, and was last updated 10 years, 5 months ago by
Anonymous.
-
AuthorPosts
-
-
March 22, 2014 at 12:51 am #1854
Anonymous
Hi all,
I’m trying to do a test run of matdes_design with the following flags:
-database /local/databases/minirosetta/ -s 3N79_edit.pdb -symmetry_definition O3.sym -ex1 -ex2 -holes::dalphaball ../../../DAlphaBall_new/src/DAlphaBall.icc -matdes::pdbID 3n79 -matdes::prefix O3_ -matdes::num_subs_building_block 3 -matdes::num_subs_total 24 -matdes::radial_disp -20 -matdes::angle 6 -ignore_unrecognized_res True -matdes::design::grid_size_angle 2 -matdes::design::grid_size_radius 2 -matdes::design::grid_nsamp_angle 5 -matdes::design::grid_nsamp_radius 11
However, I run into the following error:
ERROR: Value of inactive option accessed: -out:file:oSo I added -out:file:o O3_3n79 to the flags and tried running the application again, this time I got the following errors:
[ERROR] EXCN_utility_exit has been thrown from: src/core/io/silent/SilentFileData.cc line: 302
ERROR: Could not make O3_3n79/default.outI’m not sure if I fixed the first error at all…. And I don’t know how to fix the new errors. Please help!
Thanks a lot!
-
March 22, 2014 at 5:59 pm #9917
Anonymous
The matdes_design application is apparently a bit idiosyncratic in expecting that an output directory (relative to the running directory) be given to the -out:file:o flag.
This directory needs to exist prior to running the protocol — in general, Rosetta will not create a directory if it does not already exist.
-
April 10, 2014 at 1:29 am #9959
Anonymous
Hi rmoretti,
I ran into another problem… My matdes_design stops prematurely because of this error:
[ERROR] EXCN_utility_exit has been thrown from: src/core/scoring/packing/compute_holes_score.cc line: 111
ERROR: incorrect DAlphaBall output! see debug_holes_DalphaBall_command.logAnd debug_holes-DalphaBall_command.log says this only:
ERROR: expecting ‘END’I attached the debug_holes_DalphaBall_command.daball file.
Thanks in advance!
-
March 25, 2014 at 7:36 pm #9922
Anonymous
Thanks for the reply rmoretti. I was able to get the application running. However, I came across another problem: the output of the program is a list of .pdb.gz files and a default.out file containing the scores of each pdb file, for example:
SCORE: -196.777 -1294.357 215.002 652.426 2.852 -95.115 12.199 -89.413 -100.761 -14.105 -7.385 0.000 -12.531 45.020 440.259 -21.601 70.733 -1466.275 -1.387 -5.750 0.703 0.812 32.000 3.223 15.844 307.984 0.442 O3_3n79_-20.8_5_9360.pdb.gz
SCORE: -204.633 -1292.692 215.326 655.373 2.780 -98.326 12.191 -89.413 -100.761 -19.223 -9.967 0.000 -13.329 45.020 436.051 -22.827 75.164 -1337.244 -1.401 -5.498 0.654 0.744 35.000 2.997 15.886 198.466 0.568 O3_3n79_-20.7_5_5906.pdb.gz
SCORE: -198.015 -1293.574 215.131 653.898 2.787 -97.017 12.207 -89.413 -100.761 -18.169 -8.460 0.000 -13.547 45.020 441.351 -22.932 75.463 -1183.248 -1.326 -5.595 0.665 0.773 35.000 3.108 16.029 179.221 0.638 O3_3n79_-20.7_5_0965.pdb.gz
SCORE: -190.922 -1282.570 214.733 645.013 2.778 -93.995 12.202 -89.413 -100.761 -15.883 -6.248 0.000 -13.408 45.020 435.405 -23.262 79.466 -1062.815 -1.222 -5.317 0.653 0.569 34.000 2.979 15.912 140.251 0.435 O3_3n79_-20.6_5_1622.pdb.gzThere are 27 scores assigned for each pdb file, I’m wondering what score (score, fa_rep, fa_sol etc) each column corresponds to?
Thanks.
-
March 25, 2014 at 11:10 pm #9923
Anonymous
The program should print a header to the file. One reason it may not is if the file exists already, in which case it assumes the header is already there.
The headers should be consistent between different runs with the same parameters, so if you re-run it, you only have to wait until the first structure is output, at which time the new file (to the name given by -out::file::silent) should contain the appropriate header.
-
April 10, 2014 at 4:50 pm #9962
Anonymous
Hi rmoretti,
After posting the previous question, I did some troubleshooting. And it seems that the problem is my input protein is too big (300 aa). I cut this input to 150 aa, then the application ran smoothly. I also tried a few other input files under 150 aa, all of them ran without errors. Is there a way to get around this and allow me to use DalphaBall with bigger proteins?
Thanks
-
-
AuthorPosts
- You must be logged in to reply to this topic.