ERROR: Option matching -s not found in command line top-level context

[Anonymous]

The commandline is:
$/home/xxx/Rosetta3.1/rosetta_source/bin/docking_protocol.cygwingccrelease @flags -database /home/xxx/Rosetta3.1/rosetta_database/

The content of flags is:
-s /input/1brs.pdb (I also tried various formats and locations of directories for 1brs.pdb, none of them worked)
-dock_pert 3 8
-spin
-fake_native
#-dock_mcm
-mute core.util.prof ## dont show timing info
-out:overwrite
-out:file:fullatom
-out:file:o 1brs
-mute core.io.database

Before getting this error message in running rosetta, I had many troubles in the installation.
Luckily, these troubles were solved by following the discussion between Marsia and smlewis.
(see: problem compiling rosetta3.1 in windows vista 32 bit using cygwin 1.7.5-1)

[Anonymous]

-s is kind of holy, so it’s surprising to see it is giving you an error.

I have a sneaking suspicion that it is some sort of character formatting error – like the CR/LF issue that often plagues raw text files moved from *nix systems to windows.

The first thing I would try is re-ordering the flags in your file; it may be that something is broken somewhere such that no flags are read in properly.

The next thing I would try is running with no other flags but -help; check that -s does appear in that (very long) list as it should.

Also try -in:file:s instead (that is its full name).

[Anonymous]

It looks to me like the issue is the path:
-s /input/1brs.pdb

Is input in the root directory? Should it read -s input/1brs.pdb? I only ask to double check this because Occam’s razor is how I live my life.

[Anonymous]

Thanks for the suggestion.

I moved -s down by one row. The flags is:
-dock_pert 3 8
-s /input/1brs.pdb

Now I got:
$ /home/xxx/yyy/Rosetta3.1/rosetta_source/bin/docking_protocol.cygwingccrelease @flags -database /home/xxx/yyy/Rosetta3.1/rosetta_database/

ERROR: Option matching -dock_pert not found in command line top-level context

I also run:
$ /home/xxx/yyy/Rosetta3.1/rosetta_source/bin/docking_protocol.cygwingccrelease -help

the output is:

Usage:
/home/xxx/yyy/Rosetta3.1/rosetta_source/bin/docking_protocol.cygwingccrelease [options]
Options: [Specify on command line or in @file]
…….

It seems flag can’t be recognized by docking_protocol.cygwingccrelease, am I right?

[Anonymous]

Yesterday I tried to put options in command line, the results is:

$ /home/xxx/yyy/Rosetta3.1/rosetta_source/bin/docking_protocol.cygwingccrelease -s 1brs.pdb -database /home/xxx/yyy/Rosetta3.1/rosetta_database/
ERROR: Option matching -s not found in command line top-level context

1brs.pdb is in the current directory; it is also in ./input/.

[Anonymous]

Have you tried -help (to see if A. it runs, and B. it finds in:file:s as a valid option)?

Have you tried -in:file:s yet?

[Anonymous]

I have run the command line with -help, the result is attached below.
What do you mean in:file:s?
It seems not in the list of options.

attachment:
===========================================================================================
$ /home/xxx/yyy/Rosetta3.1/rosetta_source/bin/docking_protocol.cygwingccrelease -help

Usage:
/home/xxx/yyy/Rosetta3.1/rosetta_source/bin/docking_protocol.cygwingccrelease [options]

Options: [Specify on command line or in @file]
in | | B| Input option group
in: | | |
termini | false | B| Put full N and C termini on input structures
new_icoor | false | B| New set of idealized coordinates for full atom, 05-2009
ignore_unrecognized_res | false | B| Do not abort if unknown residues are found in PDB file; instead, ignore them.
remember_unrecognized_res | false | B| Ignore unrecognized residues, but remember them in PDBInfo.
detect_disulf | false | B| Forcably enable or disable disulfide detection. When unspecified, rosetta
conservatively detects disulfides in
full atom input based on SG distance,
but will not form centroid disulfides.
Setting `-detect_disulf true` will
force aggressive disulfide detection
in centroid poses based on CB
distance. Setting `-detect_disulf
false` disables all detection, even in
full atom poses. Note that disabling
disulfides causes severe clashes for
native disulfides.
fix_disulf | | F| Specify disulfide connectivity via a file. Disulfides are specified as two
whitespace-seperated residue indicies
per line. This option replaces the old
‘-run:fix_disulf’ option.
use_stupid_foldtree_format | false | B| use the fold-tree format that existed for one week after revision 21447
==========================================================================================================================

[Anonymous]

The full name of “s” is “in:file:s”. Normally the namespacing (in and file) do not need to be specified, because s is a unique option name. You have out:file:fullatom in your original post; in:file:s is the analogous expansion to its full name. So, using -in:file:s in place of -s may produce different results (not for any good reason, but it’s worth a shot).

The fact that -help works indicates that the compiled code is not hopelessly broken, since it was able to detect -help.

[Anonymous]

The results is a little depressing:

$ /home/xxx/yyy/Rosetta3.1/rosetta_source/bin/docking_protocol.cygwingccrelease -in:file:s 1brs.pdb
ERROR: Option matching -in:file:s not found in command line top-level context

Shall I re-compile the code?

[Anonymous]

I got the same result for fixbb as follows:

$ /home/xxx/yyy/Rosetta3.1/rosetta_source/bin/fixbb.cygwingccrelease -in:file:s 1brs.pdb

ERROR: Option matching -in:file:s not found in command line top-level context

I will try 3.2 and see what will happen.

Thanks so much for your help.

[Anonymous]

There seems to be a zlib problem with 3.2 version as follows:

$ ./scons.py bin mode=release
scons: Reading SConscript files …
svn: ‘.’ is not a working copy
scons: done reading SConscript files.
scons: Building targets …

g++ -o build/src/release/cygwin/1.7/32/x86/gcc/utility.dll -lz -Xlinker –enable-auto-import -Xlinker –export-all-symbols -shared build/src/release/cygwin/1.7/32/x86/gcc/utility/basic_sys_util.os build/src/release/cygwin/1.7/32/x86/gcc/utility/string_util.os build/src/release/cygwin/1.7/32/x86/gcc/utility/heap.os build/src/release/cygwin/1.7/32/x86/gcc/utility/integer_mapping.os build/src/release/cygwin/1.7/32/x86/gcc/utility/mpi_util.os build/src/release/cygwin/1.7/32/x86/gcc/utility/exit.os build/src/release/cygwin/1.7/32/x86/gcc/utility/LexicographicalIterator.os build/src/release/cygwin/1.7/32/x86/gcc/utility/sql_database/sqlite3_interface.os build/src/release/cygwin/1.7/32/x86/gcc/utility/sql_database/sqlite3_connection_manager.os build/src/release/cygwin/1.7/32/x86/gcc/utility/Tag/Tag.os build/src/release/cygwin/1.7/32/x86/gcc/utility/io/icstream.os build/src/release/cygwin/1.7/32/x86/gcc/utility/io/izstream.os build/src/release/cygwin/1.7/32/x86/gcc/utility/io/ocstream.os build/src/release/cygwin/1.7/32/x86/gcc/utility/io/ozstream.os build/src/release/cygwin/1.7/32/x86/gcc/utility/file/file_sys_util.os build/src/release/cygwin/1.7/32/x86/gcc/utility/file/FileName.os build/src/release/cygwin/1.7/32/x86/gcc/utility/file/gzip_util.os build/src/release/cygwin/1.7/32/x86/gcc/utility/file/PathName.os build/src/release/cygwin/1.7/32/x86/gcc/utility/excn/Exceptions.os build/src/release/cygwin/1.7/32/x86/gcc/utility/pointer/ReferenceCount.os build/src/release/cygwin/1.7/32/x86/gcc/utility/pointer/ReferenceCountMI_.os build/src/release/cygwin/1.7/32/x86/gcc/utility/options/OptionCollection.os build/src/release/cygwin/1.7/32/x86/gcc/utility/options/mpi_stderr.os build/src/release/cygwin/1.7/32/x86/gcc/utility/boinc/boinc_util.os build/src/release/cygwin/1.7/32/x86/gcc/utility/options/keys/OptionKeys.os -Llib -Lexternal/lib -Lbuild/src/release/cygwin/1.7/32/x86/gcc -Lsrc -Lbuild/src/release/cygwin/1.7/32/x86/gcc/lib/cygwin -Lsrc/lib/cygwin -L/usr/local/lib -L/usr/lib -lObjexxFCL -lz

build/src/release/cygwin/1.7/32/x86/gcc/utility/string_util.os:string_util.cc:(.text$_ZN11zlib_stream21basic_unzip_streambufIcSt11char_traitsIcESaIcEhSaIhEE9underflowEv[zlib_stream::basic_unzip_streambuf, std::allocator, unsigned char, std::allocator >::underflow()]+0x7f): undefined reference to `_inflate’
build/src/release/cygwin/1.7/32/x86/gcc/utility/string_util.os:string_util.cc:(.text$_ZN11zlib_stream21basic_unzip_streambufIcSt11char_traitsIcESaIcEhSaIhEE9underflowEv[zlib_stream::basic_unzip_streambuf, std::allocator, unsigned char, std::allocator >::underflow()]+0xb2): undefined reference to `_crc32′
……………………………
collect2: ld returned 1 exit status
scons: *** [build/src/release/cygwin/1.7/32/x86/gcc/utility.dll] Error 1
scons: building terminated because of errors.

[Anonymous]

You are correct that you are having problems with zlib. Unfortunately I have no idea what they are, specifically. Nobody in my lab (nor I) have ever gotten the cygwin build to work.

Undefined reverence is a linker error, not a compiling error. This implies that the problem is a mismatch between what Rosetta expects to see in zlib, and what your copy of zlib actually contains. I don’t know how to fix that.

[Anonymous]

I have no experience with compiling Rosetta on Windows with or without cygwin, but I found a previous discussion on the forums which mentions the issue may be a spurious zlib at {rosetta_source}/external/lib/z.lib. Try removing the Rosetta-provided zlib, confirming that you have the appropriate zlib installed with your cygwin installation, and then redoing the building and installation.

[Anonymous]

I agree that /input is likely to be problematic, but it shouldn’t lead to a crash at options time – it should cause a crash at try-to-read-the-PDB time.

[Anonymous]

Does it recognize the -help flag? (Does it recognize ANY flags?) What if you put them on command line instead of in the options file?

Did you type the options file yourself, or is it from the demo? Perhaps generating a “clean” version will help if there is some strange character encoding going on.

[Anonymous]

I would recompile (and update to 3.2 while you’re at it). I don’t have a clue what’s going wrong but I think it must be pretty serious.

You can also try a different executeable (say, fixbb) to see if it also rejects the “s” option. All executeables can see all options, it’s just that most of them ignore others’ options, so if you run fixbb with the docking options it should not crash in this fashion. (Of course, docking shouldn’t crash in this fashion either).

[Author]

Posts