- This topic has 3 replies, 2 voices, and was last updated 9 years ago by Anonymous.
December 1, 2014 at 4:08 pm #2092Anonymous
I’ve just installed the last rosetta bundle (20014.35) and have experienced some problems with the “-j” option of the fragment_picker. The error message is as follows:
md is: /home3/cluster/apps/fred/rosetta_2014.35.57232/tools/fragment_tools/psipred/bin/psipass2 /home3/cluster/apps/fred/rosetta_2014.35.57232/tools/fragment_tools/psipred/data/weights_p2.dat 1 1.0 1.0 psipred_ss2 psipred_ss > psipred_horiz
psipred file ok.
Command: /home3/cluster/apps/fred/rosetta_2014.35.57232/tools/fragment_tools/../../main/source/bin/fragment_picker.default.linuxgccrelease @query_picker_cmd_size3.txt -j 8
ERROR: Option matching -j not found in command line top-level context
Finished running command: /hom e3/cluster/apps/fred/rosetta_2014.35.57232/tools/fragment_tools/../../main/source/bin/fragment_picker.default.linuxgccrelease @query_picker_cmd_size3.txt -j 8
Output: caught exception ERROR: Option matching -j not found in command line top-level context
Exactly like in the previous install, the fragment_picker binary is linked as follows:
/lrwxrwxrwx 1 ferreirafm ferreirafm 93 Nov 28 14:51 home3/cluster/apps/fred/rosetta_2014.35.57232/tools/fragment_tools/../../main/source/bin/fragment_picker.default.linuxgccrelease -> ../build/src/release/linux/2.6/64/x86/gcc/4.4/default/fragment_picker.default.linuxgccrelease
Has anybody experienced something similar?
December 1, 2014 at 4:32 pm #10660Anonymous
Sorry, this was a bug that was introduced in some weekly releases. (See https://www.rosettacommons.org/node/3886.) Go into main/source/src/basic/options/options_rosetta.py and at around line 455, remove the “#” from before the line that goes “Option( ‘j’, ‘Integer’, desc=’Number of threads to use’),”
Note that you need to compile Rosetta in multithreading mode in order for that flag to be of any use to the fragment picker. As you have it now, as a single-threaded application, Rosetta will just ignore that option.
December 1, 2014 at 5:24 pm #10661Anonymous
By multithreading you mean extra=mpi?
It would be fine if get fragment_picker single-thread running. Should I have to recompile single and/or mpi rosetta again? In other words, those patch is a compilation option or do I have to simple rerun the fragment_picker without recompile? This sounds stupid but I don’t want to mess my fresh rosetta install.
December 4, 2014 at 3:01 am #10674Anonymous
No, by multithreading I meant “extras=boost_thread”. MPI also uses multiple processors, but the difference is that with threading the multiple processors all share the same memory, whereas with MPI they’re separate programs which communicate with each other. With MPI, an external launcher program controls how many processors to use, whereas with threading that’s handled internally by Rosetta (hence the need for the -j option).
If all you want is to run the fragment_picker single-threaded and single-processor, you shouldn’t need to recompile – just simply omit the -j option from your commandline, as a single threaded, single processor job doesn’t use that option anyway.
- You must be logged in to reply to this topic.