membrane ab initio error after montecarlo

[Anonymous]

Hello,
I’m running rosetta 3.4 membrane abinitio protocol. Right after it says the total weighted score of the monte carlo of the second stage I get this error messege:

ERROR: seqpos <= size()
ERROR:: Exit from: src/core/conformation/Conformation.hh line: 289
membrane_abinitio2.linuxgccdebug: src/utility/exit.cc:155: void utility::exit(const string&, int, const string&, int): Assertion `false’ failed.

my command line is:
/home/advas/tools/rosetta3.4/rosetta_debug/rosetta_source/bin/membrane_abinitio2.linuxgccdebug -in:file:spanfile 5annA.span -in:file:lipofile 5annA.lips4 -in:file:frag3 frags.200.3mers -in:file:frag9 frags.200.9mers -in:path:database /home/advas/tools/rosetta3.4/rosetta_database -abinitio:membrane -score:find_neighbors_3dgrid -membrane:no_interpolate_Mpair -membrane:Menv_penalties -in:file:fasta 5annA.fasta -sf score_abinitio_anna.fsc -nstruct 1

I tried version 3.2 and got segmentation fault.

I would appriciate it very much if anyone could help.

Thanks,
Adva

[Anonymous]

That error means that something, somewhere, is out of residues: some code has tried to access a residue number greater than the number of residues present (the 51st residue in a 50-residue protein, for example).

Check that all your inputs are for proteins of the same length. Is the protein vanilla, or are you expecting something like a metal ion or ligand in your structure as well?

[Anonymous]

Hi,

I get the same error from minirosetta.linuxgccrelease when attempting to model a transmembrane protein. The template did have metal ions but after cleaning it with clean_pdb.py they were removed. I use an alignment produced from LOMETS meta-server, adjusted in the appropriate format. Do you reckon it has to do with the metal ions? If yes how should I fix it?

thanks,
Thomas

[Anonymous]

If there are metal ions in some of your inputs but not others, it will cause problems like this. Either have the metals in all inputs or in no inputs.

[Anonymous]

No, I don’t think it has to do with the metal ions. It brakes during loop relax at the point the membrane spanfile is read. Please have a look at the log file I have attached and the flags I used.

[Anonymous]

It’s definitely a trying-to-access-more-residues-than-there-are error. Check all the input files, and make sure you’re not accidentally listing more residues than there really are. In addition to typos, a common mistake is to use PDB numbering in places where pose numbering is called for. (If the PDB chain A runs from 3-55, talking about pose number residue 54 is a mistake, as pose numbering would run 1-53.)

I also don’t know if loop remodeling can deal with a “loop” that runs to the end (or even very close to the end) of the protein. If you have a loop region very close to the end of the protein, try setting it to be fixed instead, and see if that changes things.

Past that, the current error message really isn’t giving us enough information to track down things. You could try increasing the tracer output level to higher values (e.g. -out:level 500 [default is 300]) to see if there’s more specific output just before the crash that narrows things down. (If you do this, run the program in the terminal without any sort of redirection to files – sometimes redirection causes buffering issues that results in losing part of the tracer output on errors.) Or you could try running things in debug mode, and see if an assert triggers and earlier and more informative error. Or probably more usefully, run the program under a debugger to get a backtrace, showing where exactly in the code the non-existant residue is being accessed from. (We could possibly do this for you, if we were provided with enough inputs to reproduce the issue locally.)

[Anonymous]

Many thanks for the thorough explanation. My silly mistake was that I pass to -in:file:fasta the sequence of the template instead of the query protein.

[Author]

Posts