You are here

segmentation fault when using design_hpatch scoring function

6 posts / 0 new
Last post
segmentation fault when using design_hpatch scoring function


I am trying to design the surface of a protein to increase solubility and decrease aggregation. I was able to find the Kuhlman lab paper "Computational protein design with explicit consideration of surface hydrophobic patches." In this paper they had a scoring function hpatch. I looked and as part of the rosetta_scripts scoring functions weights files a design_hpatch.wts was listed. I then implemented a scoring function based on this, as shown below. When I use the hpatch scorefunction I get the segmentation fault. When I replace it with a regular scorefunction the run completes as normal. I am attaching the run output leading up to the segmentation fault. Originally this paper suggests to use fixbb design. When looking through the rosetta script documentation they said to use PackRotamersMover instead.
Any help would be appreciated.




Rosetta flags:

-parser:protocol rosetta.xml
-in:file:s inputs/testSmall.pdb
-packing:no_optH false
-packing:flip_HNQ true
-nstruct 1
-out:prefix output/test1-



        <ScoreFunction name="hpatch" weights="design_hpatch" symmetric="0"/>
        <ScoreFunction name="regular" weights="talaris2014" symmetric="0" />

        <OperateOnResidueSubset name="protein_surface" >
            <Layer select_surface="true" />
            <IncludeCurrentRLT />

        <FavorNativeResidue name="native" bonus="1.5" />
        <PackRotamersMover name="design" scorefxn="hpatch" task_operations="protein_surface" />
        <Add mover="native"/>
        <Add mover="design"/>



hpatchRun.txt44.93 KB
Post Situation: 
Mon, 2018-04-09 11:05

I see your IG alone is 2.7 GB; how much memory is on the machine?  I pinged Brian and Ron to see if anyone is available to help debug.

Mon, 2018-04-09 12:16

I also tried it on our grid with 8GB memory assigned to it and it still segmented. I then tried 24GB and it still segmented.

Tue, 2018-04-10 06:05

hpatch is not particularly well supported anymore, I guess.  Brian Kuhlman's advice was use LayerDesign instead. 

I can see from the log that the correct InteractionGraph is getting set up.  Perhaps Favor Native is interfering (although I'm not sure you have constraint weights set so it may do nothing) - what happens if you turn it off?  Do you get a longer log, or better yet an interpretable assertion failure, if you run in debug mode (compile with mode=debug and run the rosetta_scripts.whateverdebug)?  Does it run fine directly in fixbb without Favor Native?

Tue, 2018-04-10 10:15

Ok, I'll look into LayerDesign. Is there any suggested parameters to use to get the desired effects. I just want to make minimal mutations to the protein surface to increase solubility and reduce aggregation. Thanks


Also when I recompiled with the newest version it seems to be running, but has been running for almost 24 hours. The protein tested is small, only ~130 aa. Even if it does work in the end the amount of time taken is prohibitive of a larger ~900 aa protein. Any suggestions.

Wed, 2018-04-11 08:22

It's taking a while for two reasons:

1) your interaction graph is enormous, so packing will take a while

2) hpatch is slower because it's not quite pairwise decomposable so it takes longer in packing

Presumably you are trying to design away hydrophobic patches, so you only need to design the surface.  The log snippet indicates to me this isn't happening:

core.pack.pack_rotamers: built 223730 rotamers at 940 positions.
core.pack.interaction_graph.interaction_graph_factory: Instantiating PDHPatchInteractionGraph

940 positions says you're doing ALL the protein not just the surface.  You'll make it much faster if you reduce that to smaller number of positions.  I don't know anything about the ResidueSelector you are using (or LayerDesign); if the documentation doesn't help there, let's bump this to a separate thread (that makes it easier for Rocco and I to farm questions out to people who might know answers).

Debug mode, useful for figuring out segfaults, takes 10x longer than release mode - so I'd also double check which executable you are using.

Wed, 2018-04-11 11:45