minirosetta segmentation fault

[Anonymous]

Hi,
I’m trying to run minirosetta, and i’m getting a segmentation fault without any further output. I’m attaching my input files, could you please help? (I can’t attach the fragment files, they are too big.)
Thanks,
Sabine

[Anonymous]

First off, you may want to try using a more recent version of Rosetta – with a recent version I’m no longer getting a segfault.

I’m still getting an error, though. The error comes up because of the way the loops are autodetected and extended. It just so happens that for your protein and the constant random seed you’re testing with, the loops for the regions around residues 30 and 34 are merging together, resulting in a crash when it tries to make a foldtree that simultaneously has a loop from residue 27 to 34 and from residue 27 to 35.

The real fix would be to get Rosetta to be smarter about merging overlapping loops. There’s some code there to detect the issue, but it really doesn’t do anything about it. The fix is non-trivial, so the’s several ways around this issue on the user’s end:

Because the loops are grown randomly, only part of the time will this loop building result in an issue. If you have another seed, you’ll get different random numbers and might not run into this issue. For production runs you should be varying the seed anyway, either by removing the -run:constant_seed and -run:jran flags from the option files, or by manually editing things such that -run:jran has a different value for each run. If two runs share the same -jran, they’ll produce the same result structures. (Or in this case run into the same error.)

Another option is to change the value of -loops::random_grow_loops_by. You have it set to 4 now, but if you reduce that you have less of a chance of running into the issue, and if you omit it entirely, you won’t have the problem at all. (As the loops won’t be extended, and they won’t run into each other.)

Another option (one I really don’t recommend) is to change your alignment. If you manually de-align residues 31 to 34, you’ll have only one loop in that region instead of two, which means you won’t end up with the loops merging into each other. A drawback is that you’ll lose the structural information in that region, and larger loops are harder to model.

[Anonymous]

Dear friends,
I also encountered the problem:

Segmentation fault (core dumped)

after running

~/Cheng/rosetta_2014.30.57114_bundle/main/source/bin/minirosetta.linuxgccrelease @ /mnt/hgfs/Cheng/test/LC/in/flags &> LC.log

As rmoretti said, I have tried
1) Not use -run:constant_seed and -run:jran flags
2) Not use random_grow_loops_by
3) A combination of 1) and 2)

However, none of the above three succeeded in solving the “Segmentation fault” problem. Can I ask how to deal with it?

When I use the same method for HC (heavy chain), it worked fine. So I think the problem may relate to the LC (light chain) structure itself.

The log file, LC PDB structure and flags are attached.

Thank you very much.

Yours sincerely
Cheng

[Anonymous]

The issue you’re running into is indirectly related to the following lines:

protocols.looprelax: picking loops by chainbreak score.
protocols.comparative_modeling.util: No chainbreaks found, so not picking any loops!
protocols.comparative_modeling.util: No unaligned residues, no loops found.
protocols.looprelax: no loops found.

The automatic loop finding isn’t working because you don’t have any gaps in your alignment – there really aren’t any loops to remodel because you have no insertions and deletions in your model.

In your case, the template and target proteins are very similar, so using the comparative modeling protocol probably isn’t the best way to do it. The comparative modeling protocol is set up for the common situation where you have insertions and deletions. In this case loop modeling is getting confused because you don’t really have any loops to remodel.

Instead, I’d suggest using the fixbb application with a resfile which introduces the mutations. You can then use the relax application to relax the backbone. This would produce more-or-less the same results as a comparative modeling protocol with no loops.

[Anonymous]

Thanks for figuring out the issue. I was using Rosetta 3.4 but will ask for 3.5 (the latest version?) to be installed. The problem is that I had exhausted my resources for solving the problem (reading the manual, error messages etc.), not having anyone else in my company who knows the software. Thanks for explaining in detail the issue about the loops.

[Anonymous]

Rosetta3.5 is actually not really the latest version – it’s about 9 months old at this point.

In the middle of this year we switched over to a weekly release schedule. (Almost) every week the latest state of the Rosetta code is bundled up for release. As I write this, I believe the most recent version is 2013wk49, though 2013wk50 could be showing up sometime soon. (One may ask if there’s any difference in quality between the weekly releases and the previous annual/semi-annual releases. The short version is not really. We have automated tests that any release version has to pass, so you’re not going to get a broken build, but to be honest there wasn’t an extensive burn-in/testing scheme for the semi-annual releases anyway. One benefit for weekly releases is that if one of them does turn out to be buggy, the fix is just a week or two away. – Assuming it’s not too much of a hassle to download and install the latest version.)

[Anonymous]

Unfortunately, I can’t replicate your issue without all the input files.

If you have a debug-mode compile, it would help if you can run in debug mode, and also increase the logging level (add “-out:levels all:debug” to the commandline). The log for those conditions would be helpful.

Depending on the issue, it might require running the debug-mode compile under a debugger, and getting a backtrace to see exactly how the segfault condition is being triggered.

[Anonymous]

Hi R Moretti,
Sorry, I was using “mode=release” when compiling the Rosetta. Can I update the debug-mode based on the release-mode instead of cleaning Rosetta and re-compiling it again? I am also wondering how slow the data processing will be if a debug-mode Rosetta is compiled?

All of the input files can be downloaded at
https://copy.com/AWDgE1YABHftMtNM

If possible, would you mind testing it by yourself?

# You can put the “Cheng” folder under your mount directory (e.g. /mnt/hgfs/)
# You can launch this within /mnt/hgfs/Cheng/test/LC/
~/Cheng/rosetta_2014.30.57114_bundle/main/source/bin/minirosetta.linuxgccrelease @ /mnt/hgfs/Cheng/test/LC/in/flags &> LC.log &

Thank you very much.

Yours sincerely
Cheng

[Anonymous]

Hi R Moretti,
I installed the debug mode on my Ubuntu. However, my PC crashed after running the minirosetta.gcclinuxdebug. I could not enter the Windows and I have to re-install the PC system. Can I ask do you think it is feasible to run a debug on a PC? In the meantime, I will try to install a debug mode on my cluster. Thank you.

Yours sincerely
Cheng

[Anonymous]

Hi R Moretti,
After changing the working directory within /home/… of my Ubuntu, the debug mode Rosetta can be run with the command line:

~/Cheng/rosetta_2014.30.57114_bundle/main/source/bin/minirosetta.default.linuxgccdebug @/home/lanselibai/Cheng/test/LC/in/comparative_model_LC.options -database ~/Cheng/rosetta_2014.30.57114_bundle/main/database -out:levels all:debug >& /home/lanselibai/Cheng/test/LC/comparative_model_LC.log &

It is said at the end of the log file:

protocols.looprelax: -259.505 -734.572 86.179 415.877 1.481 -83.889 0.761 -16.622 -83.544 -21.952 -13.407 -1.493 -14.321 25.698 206.561 -25.885 -0.379=======minirosetta.default.linuxgccdebug: src/core/kinematics/FoldTree.hh:744: int core::kinematics::FoldTree::root() const: Assertion `!empty()’ failed.
=============================================================================
protocols.looprelax: ===
protocols.looprelax: === Refine
protocols.looprelax: ===
Got some signal… It is:6
Process was aborted!

The log file and options file are attached.
(The log file is splitted into two due to the file size)

All of the input files and log file can be downloaded at:
https://copy.com/BCBJVgXo0r74w6fx

Could you please help me solve the problem of homology modelling for the light chain (LC)? Thank you very much.

Yours sincerely
Cheng

[Anonymous]

Another possibility you can try is to change the flags to “-loops:remodel no” and “-loops:refine no” in your option file to skip the loop remodeling stage.

[Anonymous]

Hi R Moretti,
Thank you very much for your help. I have tried “-loops:remodel no” and “-loops:refine no”. However, there are two problems:

1) The outputs are of some displacement/shift of coordinates from the original structure. As I will finally combine light chain (LC) structure and heavy chain (HC) structure into one PDB file, these coordinates change will make the distance between LC and HC not the same as before.

2) I tested two outputs and they are exactly the same (attached).

I will try “fixbb application” and “relax” as you said.

Thank you.

Yours sincerely
Cheng

[Anonymous]

In order to confirm it is the lack of gaps that cause the “segmentation fault”, my tests are:

1) if the gap (i.e. “-“) is inserted at the same position within the two sequences, the “segmentation fault” still exists.

2) if the gap is inserted at different position (“C226S_4KMT_LC.aln” attached), it works almost fine. The only problem is there are still coordinates shift between the outputs and input structure (attached). However, it is so strange that the coordinate shift did not happen when heavy chain (HC) is used for minirosetta.

[Anonymous]

Coordinate shift discussion continued at https://www.rosettacommons.org/node/3868

[Author]

Posts