AbinitioRelax with very small peptides

[Anonymous]

Hello,

I’ve been using Rosetta Abinitio for some time as a part of a larger docking simulation program. Normally the peptides are 11 amino acids to 30 amino acids long. However, in the latest system I’ve been working out it is desirable to test some very small peptides of length 6 amino acids to compare to some successfully docked larger peptides. I use the following inputs for the abinitio run:

**********************************************
-database ./rosetta3.4/rosetta_database

-in:file:fasta ./APRXC.fasta

-in:file:frag3 ./aaAPRXC03_05.200_v1_3
-in:file:frag9 ./aaAPRXC09_05.200_v1_3

-abinitio:relax
-relax:fast

-abinitio::increase_cycles 10
-abinitio::rg_reweight 0.5
-abinitio::rsd_wt_helix 0.5
-abinitio::rsd_wt_loop 0.5

-out:pdb true

-nstruct 2000
**************************************

Using this protocol with the larger peptides everything has worked very smoothly with very few problems. However, now with smaller peptides I can no longer use the 9mer fragment file and have been having some difficulty getting the program to run without it. I’ve tried removing that input and changing to a 5mer file with the command “-in:file:frag5 ./aaAPRXC05_05.200_v1_3”, but when I do this I get the following error:

************************************
+ mpiexec -np 6 ./AbinitioRelax.mpi.linuxgccrelease @AbFlags
ERROR: Option matching -in:file:frag5 not found in command line top-level context

---

mpiexec has exited due to process rank 0 with PID 26765 on
node node004 exiting without calling “finalize”. This may
have caused other processes in the application to be
terminated by signals sent by mpiexec (as reported here).

---

************************************

I’ve also tried just using the 3mer file in the flags and not including any path to a 9mer or 5mer file and get the following error:

************************************
ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289
ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289

---

MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 911.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

---

ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289
ERROR:

seqpos <= size()ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289
289

ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289

---

mpiexec has exited due to process rank 2 with PID 352 on
node node004 exiting without calling “finalize”. This may
have caused other processes in the application to be
terminated by signals sent by mpiexec (as reported here).

---

[node004:00349] 5 more processes have sent help message help-mpi-api.txt / mpi-abort
[node004:00349] Set MCA parameter “orte_base_help_aggregate” to 0 to see all help / error messages
************************************

Furthermore, in the hopes of gaining more information on my difficulties I used my 5mer file as the input as the 9mer file to see what kind of errors that would produce:

************************************
ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289
ERROR: seqpos <= size()

---

MPI_ABORT was invoked on rank 3 in communicator MPI_COMM_WORLD
with errorcode 911.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

---

ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289

ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289

ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289

ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289

ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289

---

mpiexec has exited due to process rank 1 with PID 6463 on
node node004 exiting without calling “finalize”. This may
have caused other processes in the application to be
terminated by signals sent by mpiexec (as reported here).

---

[node004:06461] 5 more processes have sent help message help-mpi-api.txt / mpi-abort
[node004:06461] Set MCA parameter “orte_base_help_aggregate” to 0 to see all help / error messages
************************************

The output is pretty much identical. Overall, my question is: Am I doing something wrong in how I am dealing with the very small peptides in Abinitio, or is Rosetta3 simply not equipped to work with such small peptides? I’m aware that abinitio on the small peptides may seem like a bit of overkill in the creation of peptides for docking simulations, but for comparison purposes it would be highly desirable to create the peptides in a manner consistent with how the larger peptides have been created in those docking simulation runs (which have all used Rosetta Abinitio). Any help would be greatly appreciated and I’ll be happy to clarify any parts of the procedure that I’ve left unclear.

Thanks,
-Jamie

[Anonymous]

A) it is best to post debugging information from single-threaded (rather than MPI) runs to make the logs easier to read

Rosetta is pretty well hard-coded to use 3mers and 9mers. There is lip-service for other lengths, and stuff like LoopHash uses them, but for externally-supplied libraries 3 and 9 is pretty well it.

Trying to pass your 5mers as 9mers was the thing I would have tried first. Why is it 5mers instead of 6mers? Are we fenceposting the fact that only 5 phi/psis exist?

The next thing I’d try is passing legitimate 9mers to the 9mers flag. It won’t be able to use them, but maybe just having actual 9mers will prevent it from crashing.

Failing that, I think we’ll need to just turn off the machinery that tries to read in fragments (that may be nontrivial…)

[Anonymous]

Thanks for the quick reply.

In getting the single-threaded Abinitio run set up I noticed even when I didn’t have either of the frag3 or frag9 files in the necessary folder the only error that was thrown is the following:

***************************************
core.init: Mini-Rosetta version unknown from unknown
core.init: command: ./AbinitioRelax.default.linuxgccrelease @AbFlags
core.init: ‘RNG device’ seed mode, using ‘/dev/urandom’, seed=-1128871718 seed_offset=0 real_seed=-1128871718
core.init.random: RandomGenerator:init: Normal mode, seed=-1128871718 RG_type=mt19937
protocols.abinitio.AbrelaxApplication: read fasta sequence: 6 residues
LRPWYR
protocols.evaluation.ChiWellRmsdEvaluatorCreator: Evaluation Creator active …
core.chemical.ResidueTypeSet: Finished initializing centroid residue type set. Created 1980 residue types

ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289
**********************************************

So seemingly my issue arises prior to any check on the frag files at all (I guess the frag5 error I got before comes from an initial check of the flags that I input, so that preempts the “seqpos <= size()" error). Does anyone have an idea of where that type of error generally arises in Rosetta? From the error output it would seem some part of the preprocessing of the peptide information is going awry. I’ll try to track it down in the source code, but hopefully someone has seen this before and can help. Thanks,
-Jamie

[Anonymous]

Well, we’ve seen “ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289” before…the problem is that it is hopelessly generic. All it means is that Rosetta tried to access a residue that doesn’t exist. I’ll see if I can reproduce on LRPWYR locally. Did you get fragments off Robetta, and if so are they still there?

[Anonymous]

I generate the fragments myself. I’ve attached the 3mers file if you need that. Obviously there isn’t a 9mer file to attach.

Thanks for the help,
-Jamie

[Anonymous]

It fails immediately (as yours did) even without fragments at all. I suspect there’s a hardcoded need for 9 residues somewhere. I’m grinding through a debug build now (of 3.4) to track it down.

[Anonymous]

Wow, thank you so much.

[Anonymous]

It’s in our bug tracker now:

https://carbon.structbio.vanderbilt.edu/mantisbt/view.php?id=95

[Anonymous]

There’s a truly bizzarre debugging statement someone left in:

1125 extended_pose.set_omega( pos, 180 );
1126 }
1127 tr.Debug << "CHECK PHI/PSI/OMEGA pos 8: " << extended_pose.phi( 8 ) << " "
1128 << extended_pose.psi( 8 ) << " " << extended_pose.omega( 8 )
1129 << std::endl;
1130

This is the immediate failure point. Delete the debugging statement (lines 1127-1129) and it will probably work. I’m testing this locally now. I expect it may fail somewhere else due to fragments, though.

[Anonymous]

OK, I made the code change suggested (delete src/protocols/abinitio/AbrelaxApplication.cc lines 1127-1129, which ought to look like those above) and recompiled and it runs ok.

It insists on getting a fragment file for -frag9, but I just passed your 3mer fragments for both -frag3 and -frag9 and it did not complain. I’m not sure what it’s doing with the fragments but at least it runs. I let it run through a full PDB output and it looked like a reasonable structure (right sequence, all atoms present, nothing exploded). Let me know if this works for you…

[Author]

Posts