# An issue with GenericMonteCarloMover()

14 posts / 0 new
An issue with GenericMonteCarloMover()
#1

Dear All,

I  have the following code that i wrote back in summer 2017 and it worked perfectly until February. But then I started to get strange errors (and I have not modified my code at all). After investigating it seems that the GenericMonteCarloMover() is deleting the content of the pose after the .apply(pose). In other words, after the mover is done i get an empty pose (no length and no sequence).

I am not sure why that is. I tried to comment in and out other parts of this code but it seems either the GenericMonteCarloMover() is the issue or the score function or the PackStatFilter() mover. In the code I have pointed out the commands that, when commented out, the pose does not get deleted.

Could this have happened after an update? was there a majore update of PyRosetta? I am currently using PyRosetta4.Release.python36.ubuntu.release-170.tar.bz2 released on 2018-02-18.

Or has the structure of the GenericMonteCarloMover() changed and I should modify my code to accept the new changed? I am not sure how to diagnose this issue.

Attached also is the terminal printout.

from pyrosetta import *
from pyrosetta.toolbox import *
init()

pose = pose_from_pdb('test.pdb')
scorefxn = get_fa_scorefxn()

filters = rosetta.protocols.simple_filters.PackStatFilter()

movemap = MoveMap()
movemap.set_bb(False)
movemap.set_chi(True)

mover = pyrosetta.rosetta.protocols.denovo_design.movers.FastDesign()
mover.set_movemap(movemap)
mover.set_scorefxn(scorefxn)

MC = pyrosetta.rosetta.protocols.simple_moves.GenericMonteCarloMover()
MC.set_mover(mover)
MC.set_scorefxn(scorefxn) # <--- Problem Here
MC.set_maxtrials(1)
MC.set_temperature(1)
MC.set_preapply(True)
MC.set_drift(True)
MC.set_sampletype('high')
MC.add_filter(filters , False , 1.0 , 'high' , True) # <--- Problem Here
print('\n\n++++++++++++++++++++++++++++++\n' , pose , '\n++++++++++++++++++++++++++++++\n\n')
MC.apply(pose)
print('\n\n++++++++++++++++++++++++++++++\n' , pose , '\n++++++++++++++++++++++++++++++\n\n')

AttachmentSize
18.38 KB
Category:
Post Situation:
Wed, 2018-03-07 13:57
ac.research

I have been trying to fix this issue but I do not understand what is causing it. I am looking to install an older version of PyRosetta (August 2017) how can I find it?

This same code worked perfectly before (it never deleted the pose), I even benchmarked it. What has changed?

Tue, 2018-03-13 10:18
ac.research

I have no idea.  Its not my code and the person who wrote that code is long gone from Rosetta.  I looked at the GenericMonteCarloMover and nothing I could tell has significantly changed...

Tue, 2018-03-13 10:46

What about the script I posted. What am I doing wrong that is causing the pose to be deleted?

Maybe the scorefxn is interfearing? or the PackStatFilter() is interfering? becuase when i comment out both together the pose does not get deleted.

I don't see any useful printout that explains what is going on, and commenting anything else gives me a [Segmentation fault (core dumped)].

if all fails, is it possible to find a PyRosetta version from around August 2017?

Tue, 2018-03-13 13:56
ac.research

Ok, standard caveat applies (I am not a current rosetta developer, and it's been a long time since I stayed at a holiday inn express).

I can confirm that your code does indeed result in a deleted pose.  If you make the following change:

MC.set_preapply(True) to

MC.set_preapply(False)

Then the code does not end up deleting the pose.  Can you check whether that fixes the issue for you?  If it does, it raises the question as to whether you really need pre_apply to be set to True for your particular example.

Fri, 2018-03-16 09:39
SenyorDrew

Oh my god it worked.

I have been goign crazy for the past two weeks trying to figure this out.

I think the default setting is at True, because i removed that line several times while trying to debug and it did not solve the issue.

Thank you very much !!!!!!!!!

Fri, 2018-03-16 09:49
ac.research

Glad it worked.  Now - as to whether you want pre_apply to be True or not ...

Looking at the code, it looks like the pose is wiped out when pre_apply is True and NO accepts are made.  In a case where you're trying maxtrials at 1, there's a good chance that you won't have any accepts (especially if your filters are prone to fail when evaluating the pose).

If you really want the pre-apply behaviour if a safer way, you could always just apply your mover once to your pose, and then set up the GenericMonteCarlo mover with pre-apply set to False.  (Basically you'll be doing the pre-apply yourself by calling the mover once and letting it modify your pose).

Like I said, I'm not a rosetta developer, but it would be useful if one of the rosetta developers checked whether this is indeed true and maybe made the GMC safer by not wiping out the pose in the specific case where pre-apply is true and no accepts are made.

Hope that helps.

Fri, 2018-03-16 10:03
SenyorDrew

Thank you very much,

The code above was just a demo that replicates the error for debugging purposes. In reality my code has .set_maxtrials(10) but it takes around 3 hours to complete (which also failed afterwards - pose deleted), so i turned it to 1 just so i can cycle through the code quickly.

Rosetta's GMC's preapply description says:

Defaulting to true for historical reasons, it is highly recommended to set this to false unless you know you need it to be true.

I will re-benchmark my code and see if i get different results from my previous benchmark. if i get bad results i will apply your suggestion. :-)

Thank you very much

Fri, 2018-03-16 10:17
ac.research

For the past week I have tested PyRosetta4.ubuntu.release-172 for python 2.7 and 3.5 and 3.6 on Ubuntu 16.04 LTS and 17.04 and 17.10, they all give the same problem, the GenericMonteCarloMover() keeps deleting the pose, why? I do not understand. There is nothing that explains this phenomena and no error is given.

Anyone is facing this same issue?

What is the correct way to use the GenericMonteCarloMover() function?

Anyone can explain to me, or send me an example script so I can figure it out?

Thu, 2018-03-15 07:40
ac.research

We only keep limited version of PyRosetta binaries on our site because they take a lot of space. If you need early builds then i think building from source is probably the best option. To do so you will need to get academic version of PyRosetta source tree (or probably academic version of Rosetta Git repository) and then follow PyRosetta build instructions here: http://www.pyrosetta.org/documentation#TOC-Building-PyRosetta-from-source

Thu, 2018-03-15 10:09
Sergey

ok, i have no problem with trying to build it from source. I have an academic licence for PyRosetta and Rosetta.

So i have to compile PyRosetta from an older Rosetta version? is this what is mean by that document?

Thu, 2018-03-15 10:37
ac.research

Hi Sergey,

I tried building PyRosetta from Rosetta 3.8 (March 2017) several times, but I got the following error:

FAILED: tools/clang/tools/extra/binder/CMakeFiles/binder.dir/fmt/format.cc.o
/usr/bin/c++  -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_OBJC_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/tools/extra/binder -I../tools/clang/tools/extra/binder -I../tools/clang/include -Itools/clang/include -Iinclude -I../include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG -MD -MT tools/clang/tools/extra/binder/CMakeFiles/binder.dir/fmt/format.cc.o -MF tools/clang/tools/extra/binder/CMakeFiles/binder.dir/fmt/format.cc.o.d -o tools/clang/tools/extra/binder/CMakeFiles/binder.dir/fmt/format.cc.o -c ../tools/clang/tools/extra/binder/fmt/format.cc
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed/limits.h:194:0,
from /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed/syslimits.h:7,
from /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed/limits.h:34,
from /usr/include/c++/7.3.0/climits:42,
from ../tools/clang/tools/extra/binder/fmt/format.cc:34:
../tools/clang/tools/extra/binder/fmt/format.cc: In member function ‘void fmt::internal::BasicArgFormatter<Impl, Char>::visit_char(int)’:
../tools/clang/tools/extra/binder/fmt/format.cc:466:20: error: expected unqualified-id before numeric constant
const unsigned CHAR_WIDTH = 1;
^
ninja: build stopped: subcommand failed.


I used the latest Ninja, CMake, and Clang 5. I tried several time but I get the same error, I also tried using and not using the flag -j24 with the build.py command. There is no information on trouble shooting, what can I do?

Alternativly, how can i fix my script on the top to prevent the GenericMonteCarloMover() function from deleting my pose.

Thank you for your time. I know you are very busy.

Fri, 2018-03-16 08:07
ac.research

> So i have to compile PyRosetta from an older Rosetta version?

Yes, you will need to get older Rosetta version and use it to build PyRosetta. Our download for academic should provide access to git repository that hold most of previously released version of Rosetta source code so getting it and then checking out desired releases should probably be the easiest way to get the right version.

Re compilation error above: looks like you using the latest GCC-7.3 and that caused the problem. I would recommend to try to either downgrade GCC or try to install and use Clang instead.

Fri, 2018-03-16 11:04
Sergey
Fri, 2018-05-11 10:59
ac.research