You are here

run Rosetta under windows prompt

4 posts / 0 new
Last post
run Rosetta under windows prompt

I am building rosettaligand for boinc. Compiling linux versions are straightfoward and easy. But when on windows, life is like in the hell. I hacked a few things to get static rosettaligand version built under cygwin on windows7 32bit, and it run smoothly under cygwin emulator. However, when I tried to run rosettaligand from windows commandline prompt, it said "ERROR: Unique best command line context option match not found for -path. Possible matches include: in:path out:path". I changed the line terminator and remove all path seperator in flags file, but the error persisted. What could be the cause of the error?

Post Situation: 
Fri, 2013-12-20 21:16

From the error message, it looks more like you're just using the wrong flag, rather than having Windows issues.

What do your flags file (you can attach it to the forums as a text file) and commandline look like? Are you using the full "-in:path" and "-out:path", or are you just using "-path"?

You're right that doing things with Rosetta on Windows is a pain - that's why we don't support using Rosetta on Windows. The only reason a Rosetta developer would try to get Rosetta working on Windows would be for the Rosetta@Home boinc builds or the Windows Foldit builds, where Windows support is an absolute necessity. Even then, it's a real frustration to the people making the builds. I'd recommend avoiding it, if at all possible.

Sat, 2013-12-21 14:32

Thanks for the reply, I attached the flag file used on windows. I am not sure it was the flag file that caused the error, because rosettaligand ran smoothly using exactly the same flag file in cygwin emulation window.

And another problem came up with MPI version. When I tried to share "last_accepted_pose_" between worker processes in MPI enviroment in MonteCarlo object's boltzmann() method by using disk file( for my advisor told me that sharing by memory object is problematic ), I got the error message:
"ligand_dock.mpi.linuxgccdebug: src/numeric/deriv/dihedral_deriv.hh:80: void numeric::deriv::dihedral_deriv_second(const numeric::xyzVector&, const numeric::xyzVector&, const numeric::xyzVector&, const numeric::xyzVector&, P, P&, numeric::xyzVector&, numeric::xyzVector&) [with P = double]: Assertion `std::abs(std::abs(theta) - thetaU) < 1e-2' failed."

What does this mean? It looks like some constraints that must be met were breached.Is it possible to share the best pose ever sampled by any process with all other processes?

Sun, 2013-12-22 03:51

I'm not sure what's going on with the flag file. As I mentioned, we're not in a position to troubleshoot Windows-specific issues too extensively. My suggestion is to just use the full options name (e.g. "-out:path:pdb ." instead of using the indentation based approach.

Regarding sharing the pose, how were you trying to write it to the disk? I would suggest using the existing structure IO methods. The dump_pdb(filename) method on Pose is probably the easiest way of doing it (use the core::io::pdb::build_pose_from_pdb_as_is(pose, filename) function to read the file back in), but you may run into issues with numeric precision rounding, foldtree differences, etc.

You may want to try the binary silent file format instead, as that stores structures with more numerical precision and additional Rosetta-specific information. To output, create a new core::io::silent::BinaryProteinSilentStruct object. Process your pose with the fill_struct(pose, output_tag) method. Then create a core::io::silent::SilentFileData object, and call the write_silent_struct( silent_struct, filename ) method. Read the structure back in with the read_file(filename) method of a fresh core::io::silent::SilentFileData object, followed by sfd.get_structure( output_tag ).fill_pose( pose ). (This is assuming you're working with standard fullatom poses - using centroid or other residue type sets is a bit more work.)

One caveat of using silent files is that it tends to renumber the pose using pose numbering (consecutive residue numbers starting from 1), so if you're depending on the PDB residue numbering, you probably want to stick with PDB output. Also, be sure to implement the appropriate semaphores to ensure that only one process is reading or writing to a particular silent file at a time.

Tue, 2013-12-31 07:55