- This topic has 2 replies, 2 voices, and was last updated 8 years, 2 months ago by Anonymous.
September 19, 2015 at 7:08 pm #2291Anonymous
1) I am running the protocol for comparative modeling, and run the program it tells not find some flags. The question is, is this common? It will really interfere too much in my final result?
2) what the function of this sequence, after calling the program? (@flags >& test.log &)
ERROR: Option matching -silent_decoytime not found in command line top-level context
caught exception ERROR: Option matching -silent_decoytime not found in command line top-level context
September 19, 2015 at 7:31 pm #11218Anonymous
1) The -silent_decoytime option was removed from Rosetta about a year ago. – What it was supposed to do was to “Add time since last silent structure was written to score line”, but it actually wasn’t doing anything – there wasn’t any place in the code which actually looked at the value of the option.
So it should be safe to just remove that option from the commandline or the options file.
2) The “@flags >& test.log &” bit is actually doing three different things:
- “@flags” – The “@” symbol is a Rosetta-specific directive that says to treat what comes after it as the name of the options (flags) file. That is, Rosetta will open the file named “flags”, read the contents, and then treat things like the contents were options on the commandline. This way you can set up all the relevant options for a run in a file, and don’t have to re-type them for every command.
- “>& test.log” – This is a directive to the shell (Rosetta actually never sees this bit) that you want to direct both the standard output and standard error streams to the file “test.log”. That is, instead of printing things to the screen, save the output to the specified file. (See http://www.tldp.org/LDP/abs/html/io-redirection.html or http://tomecat.com/jeffy/tttt/cshredir.html for more.)
- “&” – This is a directive to the shell (Rosetta never sees this bit either) to run the command in the background instead of the foreground. That is, instead of waiting for the command to finish before starting the next command, immediately go on to the next command (or return control to the prompt), letting the command run in the background. (See http://www.thegeekstuff.com/2010/05/unix-background-job/ for more.)
September 21, 2015 at 6:10 pm #11228Anonymous
Thank you very much RMORETTI.
- You must be logged in to reply to this topic.