# Segmentation fault (core dumped) in rosetta_scripts.default.linuxgccrelease after blueprint file reading

13 posts / 0 new
Segmentation fault (core dumped) in rosetta_scripts.default.linuxgccrelease after blueprint file reading
#1

Dear Sir and Madam,

When I run such a script "~/rosetta_src_2020.08.61146_bundle/main/source/bin/rosetta_scripts.default.linuxgccrelease -parser:protocol Design.xml -s some_relaxed_protein.pdb -database ~/rosetta_src_2020.08.61146_bundle/main/database/ -restore_talaris_behavior true -remodel:use_pose_relax true -score:set_weights pro_close 0 cart_bonded 0.5 -nstruct 10 -out:prefix design_" for insertion one amino acid, replacement one original amino acid into another and building additional disulphide I meet with the following error:

"[FILE]: SIGSEGV

[LINE]: 11

[START_MESSAGE]

Segmentation Fault"

The inserted line in the blueprint file looks in the following way:

21 N L R

0 C L DM_start DM_stop

22 F L R

I deleted last empty line in .blueprint file for prevention of such an error, as it has been advised in https://www.rosettacommons.org/docs/latest/application_documentation/design/Remodel, but it didn't solve this problem.

I suppose, that the problem lies in the src/protocols/forge/remodel/RemodelWorkingSet.cc file on the ground of the following output from the rosetta_script running:

protocols.forge.remodel.RemodelWorkingSet: workingSetGen(): length change found. last blueprint line index: 51, last blueprint line original_index: 50

protocols.forge.remodel.RemodelWorkingSet: Adding lines to temp_for_truncation vector.

AN INTERNAL ERROR HAS OCCURED. PLEASE SEE THE CONTENTS OF ROSETTA_CRASH.log FOR DETAILS.

Segmentation fault (core dumped)

On a base of file inspection I would hazard to guess that this error is located somewhere near 200th lines in the src/protocols/forge/remodel/RemodelWorkingSet.cc file. Does this error arise out of this adding lines to temp_for_truncation vector? Furthermore, I suspect that the problem lies in line "translate_index[ temp_for_truncation[ ii ].original_index ] = ii + 1; // i is zero based, we want one based translation" in this code fragment:

for ( int ii = 0, ie = (int)temp_for_truncation.size(); ii < ie; ii++ ) { // loop to update keep vector according to what's found

keep[ temp_for_truncation[ ii ].original_index ] = true;

if ( temp_for_truncation[ ii ].original_index != 0 ) { // correct for the use of "0" in marking extensions, original index should start from 1

//TR << "temp_for_truncation[ ii ].original_index: " << temp_for_truncation[ ii ].original_index

// << ", translate_index[ " << temp_for_truncation[ ii ].original_index << " ] set to " << ii + 1 << std::endl;

translate_index[ temp_for_truncation[ ii ].original_index ] = ii + 1; // i is zero based, we want one based translation

}

}

// soooo, temp_for_truncation, keep, and translate_index got created and then are not used anywhere else. wtf?

// translate_index may get used somewhere since it's a class member variable, but the other two?

I am in favour of opinion, that it would be better to convert expression "ii+1" to "ii" in the foregoing line. It is a good solution of this problem? Could anyone here explain me, how can I handle such an error, please?

I will be sincerely grateful for your response and I am looking forward to it.

Best regards,

Corvin.

AttachmentSize
3.95 KB
Category:
Post Situation:
Tue, 2020-06-30 00:36
Corvin

I have already made a correction in src/protocols/forge/remodel/RemodelWorkingSet.cc file at line 215 by replacement of expression "translate_index[ temp_for_truncation[ ii ].original_index ] = ii + 1; // i is zero based, we want one based translation" into "translate_index[ temp_for_truncation[ ii ].original_index ] = ii; // i is zero based, we want one based translation". This correction consists in deletion the "+ 1" expression in "ii + 1" statement. But this fix didn't solve this error and I got the same error after rosetta_scripts run:

protocols.forge.remodel.RemodelWorkingSet: workingSetGen(): length change found. last blueprint line index: 51, last blueprint line original_index: 50 protocols.forge.remodel.RemodelWorkingSet: Adding lines to temp_for_truncation vector.

AN INTERNAL ERROR HAS OCCURED. PLEASE SEE THE CONTENTS OF ROSETTA_CRASH.log FOR DETAILS.

Segmentation fault (core dumped)

So, it seems as if the problem lies elsewhere than at 215 line of the RemodelWorkingSet.cc file. I would be really grateful, if anyone gave me a hint how to solve this error concerning blueprint file, because I really have no idea, where a problem lies.

Sincerely,

Corvin.

Wed, 2020-08-19 08:16
Corvin

There are a few reasons why a bluprint causes a crash.

First, does the PDB start from 1 (i.e. is the same as pose numbering) and have no missing residues or is your blueprint in PDB or pose numbering? I never remember which way round it should be, so the easiest thing is to make everything pose numbering.

You said your bluprint aims to insertion one amino acid, replacement one original amino acid into another and building additional disulphide and have this, which is rather odd:

21 N L R
0 C L DM_start DM_stop
22 F L R

I am not sure what is going on as there are a few synthax errors.

So to insert a residue you need the neighbouring ones to wiggle:

21 N L NATAA
0 X L PIKAA C
22 F L NATAA

You can write instead of NATAA, NATRO or PIKAA N, but you cannot write

21 N .
0 X L PIKAA C
22 F .

To use the DM_ and DS_ codes you need disulfide design flag.

21 N L PIKAA N
0 X L PIKAA C DS_start DS_stop
22 F L PIKAA F

If you are adding missing density that is fine. If you are adding a residue in a turn say, you need to wiggle a bit more residues than the neighbours. Also, you might want the generic amino acid to be glycine not valine.

Wed, 2020-08-19 10:45
matteoferla

Dear matteoferla,

thank you very much for your response.

I made such a correction to my blueprint file:

21 N L NATRO

0 X L PIKAA C DM_start DM_stop

22 F L NATRO

Further, I met with the following error:

ERROR: Assertion !( has_lower_terminus && has_upper_terminus ) failed. ERROR:: Exit from: src/protocols/forge/build/SegmentRebuild.cc line: 430 protocols.rosetta_scripts.ParsedProtocol: [ ERROR ] Exception while processing procotol:

File: src/protocols/forge/build/SegmentRebuild.cc:430 [ ERROR ] UtilityExitException ERROR: Assertion !( has_lower_terminus && has_upper_terminus ) failed.

After that I inspected the SegmentRebuild.cc file and found the next piece of code, which is related to this error:

// If the following runtime_assert is triggered, that likely means you

// tried to replace the entire length of the Pose or an entire chain of

// a multi-chain Pose. This class currently doesn't handle those cases

// properly and will likely break.

// but when only the case of single chain is allowed

if ( pose.conformation().num_chains() != 1 ) {

runtime_assert( !( has_lower_terminus && has_upper_terminus ) );

}

Does it mean, that this code piece can handle only with single-chain protein?

On top of that, I would like to specify that the inserted Cysteine is placed at the very end of the first protein chain. May it lead to the foregoing error?

Concerning your question about the replacement of original amino acid into another one, this replacement is written in the res file, not in the blueprint one.

Many thanks in advance.

Sincerely,

Corvin.

Thu, 2020-08-20 09:44
Corvin

There is a chain argument that allows it to handle multiple chains, but last I tried it (2ya) it was had to many catches so I find it simpler renumbering the PDB. But yes using the standard flags it will otherwise delete the other chains. However, having a single chain with massive jumps is totally fine, unless you touch anything at the jump. So it is the easiest way to deal with it.

So say you have a chain A and a chain B and you want to insert something at the end of chain A, I'd switch them around before making them a single chain. That way you can insert the residue happily at the end of the megachain.

I have never looked at the C++ code for this, but it cannot handle indels at both termini at the same time using the normal flags —I am not sure if something like -use_truncated_termini true will do the trick say.

However, you are not really doing a disulfide design: you know exactly where the disulfide should go. Therefore I would strongly suggest doing the insertion alone and then running relax with the flags -detect_disulf true -detect_disulf_tolerance 5.0. The alternative to these flags is editing the PDB to be with the line

SSBOND   1 CYS A  ???    CYS A  ???                          1555   1555  2.03 

Which is the LINK line equivalent for disulfides. CYX as a residue like in AMBER is not required. And then relaxing.

What do you mean "this replacement is written in the res file, not in the blueprint one."...  A blueprint file is a form of resfile. The remodel binary does not require a separate resfile. Or are you using a Rosetta script that uses the RemodelMover and the Resfile is for another mover??

Okay, as an example, of what I mean I did a quick test using PDB:1ubq (ubiquitin) and saw in PyMOL that N-termus and E18 are close. So I generated the blueprint attached and run the following:

$ROSETTA/remodel.$ROSETTAEXT -database $ROSETTADB -ex1 -ex2 -s 1ubq.pdb -remodel:quick_and_dirty -overwrite -remodel:blueprint 1ubq.blu;$ROSETTA/relax.$ROSETTAEXT -database$ROSETTADB -ex1 -ex2 -relax:fast -s 1ubq_0001.pdb -detect_disulf true -detect_disulf_tolerance 5.0;

Where the variables are just filepaths. And I got a nice disulfide (obvs the quick/fast tags are just because I wanted it done under a minute). Easy peasy.

File attachments:
Fri, 2020-08-21 03:47
matteoferla

Dear matteoferla,

I am sincerely grateful for such a detailed response.

I have found out, that the turning the two-chained structure into one megachain and switching two chains around led to two unwanted consequences: firstly, such chain placement exchange created structure with completely another fold. Secondly, this measure didn't fix the SegmentationFault error after rosettascript running.

So, I decided to choose another path: I deleted all statements regarding disulphides from Remodel Mover. Also, I modified my Bash command for rosettascript to the following:

~/rosetta_src_2020.08.61146_bundle/main/source/bin/rosetta_scripts.default.linuxgccrelease -parser:protocol Design.xml -s someprotein_AB_relaxed_0017.pdb -database ~/rosetta_src_2020.08.61146_bundle/main/database/ -restore_talaris_behavior true -remodel:use_pose_relax true -run:chain A -run:chain B -score:set_weights pro_close 0 cart_bonded 0.5 -nstruct 10 -ex1 -ex2 -out:prefix design_

Despite all the foregoing measures the rosettascript run resulted in such an error:

ERROR: Assertion !( has_lower_terminus && has_upper_terminus ) failed. ERROR:: Exit from: src/protocols/forge/build/SegmentRebuild.cc line: 430 protocols.rosetta_scripts.ParsedProtocol: [ ERROR ] Exception while processing procotol:

File: src/protocols/forge/build/SegmentRebuild.cc:430 [ ERROR ] UtilityExitException ERROR: Assertion !( has_lower_terminus && has_upper_terminus ) failed.

protocols.jd2.JobDistributor: [ ERROR ]

[ERROR] Exception caught by JobDistributor for job design_someprotein_AB_relaxed_0017_0010

[ ERROR ]: Caught exception:

File: src/protocols/forge/build/SegmentRebuild.cc:430 [ ERROR ] UtilityExitException ERROR: Assertion !( has_lower_terminus && has_upper_terminus ) failed.

AN INTERNAL ERROR HAS OCCURED. PLEASE SEE THE CONTENTS OF ROSETTA_CRASH.log FOR DETAILS.

I have attached to this comment my Design.xml file. I hope, it would bring more clarity into the current situation.

Do you have any idea, what could be wrong with such a script?

On top of that I have a question, whether I should conduct all suggested by you operations (remodel, relax) before the stage of protein design or after?

Many thanks in advance.

Sincerely,

Corvin.

File attachments:
Tue, 2020-09-01 09:07
Corvin

UPD:

I have tried to conduct remodelling the unrelaxed and unprepared structure, as you had described in your last comment. Here is the full description of the operation:

~/rosetta_src_2020.08.61146_bundle/main/source/bin/remodel.default.linuxgccrelease -database ~/rosetta_src_2020.08.61146_bundle/main/database/ -ex1 -ex2 -s someprotein_AB.pdb -remodel:quick_and_dirty -overwrite -remodel:blueprint InsAB22.blueprint

But I got the same error, which I described in the foregoing comment:

protocols.forge.remodel.RemodelWorkingSet: workingSetGen(): length change found. last blueprint line index: 51, last blueprint line original_index: 50

protocols.forge.remodel.RemodelWorkingSet: Adding lines to temp_for_truncation vector.

protocols.forge.remodel.RemodelWorkingSet: data.dssp_updated_ss: LHHHHHHLLLLLHHHHHHHELLLLLLLLLHHHHHHHHHHHHHHHLELLLLL

AA for build: VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

protocols.forge.remodel.RemodelWorkingSet: head 1:1, tail 50:51, gap: 51, dssp_updated_ss.size(): 51, insert_ss:

LHHHHHHLLLLLHHHHHHHELLLLLLLLLHHHHHHHHHHHHHHHLELLLLL

protocols.forge.remodel.RemodelWorkingSet: debug: N-term deletion

ERROR: Assertion !( has_lower_terminus && has_upper_terminus ) failed.

ERROR:: Exit from: src/protocols/forge/build/SegmentRebuild.cc line: 430

protocols.jd2.JobDistributor: [ ERROR ]

[ERROR] Exception caught by JobDistributor for job someprotein_AB_0001

[ ERROR ]: Caught exception:

File: src/protocols/forge/build/SegmentRebuild.cc:430

[ ERROR ] UtilityExitException

ERROR: Assertion !( has_lower_terminus && has_upper_terminus ) failed.

AN INTERNAL ERROR HAS OCCURED. PLEASE SEE THE CONTENTS OF ROSETTA_CRASH.log FOR DETAILS.

protocols.jd2.JobDistributor: [ WARNING ] someprotein_AB_0001 reported failure and will NOT retry

protocols.jd2.JobDistributor: no more batches to process...

protocols.jd2.JobDistributor: 1 jobs considered, 1 jobs attempted in 0 seconds

---------------------------------------------------------------

[ ERROR ]: Error(s) were encountered when running jobs.

1 jobs failed;

Check the output further up for additional error messages.

---------------------------------------------------------------

On top of that, I suspect that the turning of all amino acids into Valines in the string "AA for build:" is an another reason for concern.

Would you be kind to suggest the place, where these errors lie and the solutions for them, please?

Kind regards,

Corvin.

Wed, 2020-09-09 09:00
Corvin

Sorry for not replying. Honestly, I started clicked on your design file which blanked my reply and I walked away from the page in annoyance.

> Assertion !( has_lower_terminus && has_upper_terminus ) failed.

Rosetta cannot modify both termini at the same time. Is the blueprint corrent?

> created structure with completely another fold.

Renumbering residues in PyMol, Coot or whatnot should not affect Rosetta. Is the input PDB mangled when opened in another program? Is the blueprint regenerated?

> AA for build: VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

Normal. generic_aa flag controls. You can change it, but valine is good for sheets and helices, while glycine is better for loops —never proline though.

> XML

I did not realise you were using the mover in the scripts and not the binary remodel, apologies for any confusion. Also your script does some odd steps first unrelated to design—a cartesian minimisation and a repacking.

Fri, 2020-09-11 03:54
matteoferla

Dear matteoferla,

many thanks for your well-structured and clear response. I removed a cartesian minimization and a repacking from Design.xml file.

I looked at the .blueprint file and this file has been seemed legit at the first glance. I attach the .blueprint file to this comment. Would you be kind to examine, what is wrong with it, please? As far as I have understood, the single blueprint file shouldn't keep editing both chains simultaneously, haven't I? If this notion is right, do I have to create separate .blueprint file for every chain?

I will be really thankful for your response and I am looking forward to it.

Kind regards,

Corvin

File attachments:
Thu, 2020-09-17 07:56
Corvin

Your protein in the PDB is only 50 AA long and starts with a glycine? Anything present in the PDB file but not in the blueprint will be removed.

The problem may be that from the looks of it you are making it design the whole protein:

1 G L # Design to a loop. "ALLAA" is assumed.
1 G . # Leave alone

Hence why Remodel is having a fit for being asked to design both termini.

About the fact that the chain is discontinuous between 21 and 22 and you are adding a residue after 21, I cannot really comment as I'd have to test it but my guess is that it would try and fix the jump (=discontinuity), fail and give you a valine (the default AA) because after all, it creates a jump to insert a residue.

Fri, 2020-09-18 01:24
matteoferla

Dear matteoferla,

Sorry for no writing so long.

I converted "L" into "." for the first Gly as you had advised in the last comment.

After that the RosettaScript run gave such erroneous output:

protocols.forge.remodel.RemodelWorkingSet: workingSetGen(): length change found. last blueprint line index: 51, last blueprint line original_index: 50

protocols.forge.remodel.RemodelWorkingSet: Adding lines to temp_for_truncation vector.

protocols.forge.remodel.RemodelWorkingSet: data.dssp_updated_ss: LHHHHHHLLLLLHHHHHHHELLLLLLLLLHHHHHHHHHHHHHHHLELLLLL

AA for build: GIVEQCCTSICSLYQLENYCNVFVNQHLCGSHLVEALYLVCGERGFFYTPK

protocols.forge.remodel.RemodelWorkingSet: head 2:2, tail 50:51, gap: 50, dssp_updated_ss.size(): 51, insert_ss:

HHHHHHLLLLLHHHHHHHELLLLLLLLLHHHHHHHHHHHHHHHLELLLLL

protocols.forge.remodel.RemodelWorkingSet: normal rebuild

core.kinematics.FoldTree: [ ERROR ] FoldTree::reorder( 0 ) failed, new/old edge_list_ size mismatch

core.kinematics.FoldTree: [ ERROR ] old_edge_list.size() 2 new_edge_list.size()0

core.kinematics.FoldTree: [ ERROR ] FOLD_TREE EDGE 1 1 -1 EDGE 1 51 -1

double free or corruption (out)

Got some signal... It is:6

Signal 6 (SIGABRT) means that the process was aborted. This usually means an internal Rosetta error caused by (often) bad inputs, (sometimes) developer error, or (rarely) hardware problems.

Firstly, as you noticed in the previous comment, due to adding the residue into the C-end of chain A and trying fixing the jump the RosettaScript still converts Cys into Val. Would you tell me, where I can find the way to fix this problem with jump, please?

Secondly, a problem with FoldTree arose out of the RosettaScript run. I can not understand, why this application turns my set foldtree FOLD_TREE EDGE 21 1 -1 EDGE 21 22 1 EDGE 22 50 -1 into FOLD_TREE EDGE 1 1 -1 EDGE 1 51 -1?

What about the protein, the C-termini of chain A and N-termini of chain B are situated too far for filling the loop, as it was handled on this site http://blog.matteoferla.com/2017/10/hacking-pdbs-for-fusion-protein.html (I found this site on the another comment thread at the RosettaCommons site). Moreover, I don't want to add any amino acids for filling the loop, because it may influence dramatically on the protein properties and conformation. Furthermore, the C-termini of the first chain and N-termini of the second one from that example https://www.rosettacommons.org/demos/latest/tutorials/advanced_scripting_with_rosettascripts/advanced_scripting_with_rosettascripts#controlling-the-foldtree-within-rosettascripts are also placed very far from each other, but, nevertheless, the RosettaScript treats with such a protein in the proper way and there shouldn't be any problem.

So, why the RosettaScript cannot treat adequately with the protein, which is arranged in almost the same way? I would like to find out, how I can to fix this FoldTree error?

Many thanks in advance.

Sincerely,

Corvin.

Thu, 2020-10-08 09:42
Corvin

P. S.

Dear matteoferla,

Would you think that the breaking up the protein into two distinctive chains, and, therefore, writing own blueprint file for each of them and manipulation by them (blueprint files), and, in result, docking these chains with further restoring the old and building the new disulphide bridges, is the better option?

I will be sincerely grateful, if you tell me more about this way of breaking up and docking protein chains.

Besides, I would like to solve the problems regarding jumps, fold trees and turning any AA into Valine, because I really want to have knowledge about tackling these problems with design of multichain proteins.

Kind regards,

Corvin.

Wed, 2020-10-14 09:54
Corvin

Dear matteoferla,

I have already solved the problems with jumps, foldtrees and so on.
Now I met with another problem regarding with the Rosetta Disulfide mover inability to build the disulphide bridge from inserted to the end of the first chain Cysteine. It looks like in the following way:

protocols.rosetta_scripts.ParsedProtocol:
=======================BEGIN MOVER DisulfideMover - Disulphide=======================

ERROR: Error in core::pose::selection::get_resnum_list(): A residue index could not be parsed.
ERROR:: Exit from: src/core/pose/selection.cc line: 179
protocols.rosetta_scripts.ParsedProtocol: [ ERROR ] Exception while processing procotol:

File: src/core/pose/selection.cc:179
[ ERROR ] UtilityExitException
ERROR: Error in core::pose::selection::get_resnum_list(): A residue index could not be parsed.

I would guess that this error has been arisen out of the such a statement in Disulfide mover:

<DisulfideMover name="Disulphide" targets="22A,43B" />

I mean under "22A" inserted to the end of 21aa chain Cysteine. By the way, after such renumber do have the following residues be renumbered (e. g. original "43B" turned into new "44B")?
May you tell me, how to fix this error, please?

Many thanks in advance.

Respectfully,

Corvin.

Tue, 2020-11-10 01:22
Corvin