You are here

symmetrical membrane modeling

6 posts / 0 new
Last post
symmetrical membrane modeling

Hi everyone,

I'm trying to create a model using the ccd loop modeling and symmetrical modeling application. I am getting this error:

loopmodel.default.linuxgccdebug: src/numeric/xyzVector.hh:671: numeric::xyzVector< >& numeric::xyzVector< >::normalize() [with T = double]: Assertion `length_ != Value ( 0 )' failed.

Does this mean there is something wrong with my template? I was able to create a monomer using pretty much the same files but I'm just not sure where this model is failing and how to fix it. here is my input command line.

../../rosetta_source/bin/loopmodel.default.linuxgccdebug \
-in:path:database ../../rosetta_database \
-ignore_unrecognized_res \
-in:file:centroid_input \
-in:file:spanfile kv7-4.span \
-membrane:center_search \
-score:weights membrane_highres_Menv_smooth.wts \
-symmetry:symmetry_definition out2_tetramer_draft.symm \
-symmetry:initialize_rigid_body_dofs \
-loops:input_pdb out2_tetramer_zeroloop.pdb \
-loops:loop_file kv74225.loop \
-loops:frag_sizes 9 3 1 \
-loops:frag_files kv74225_09_05.200_v1_3 kv74225_03_05.200_v1_3 none \
-loops:remodel quick_ccd \
-loops:intermedrelax fastrelax \
-loops:refine refine_ccd \
-loops:relax no \
-loops:strict_loops \
-loops:build_attempts 20 \
-loops:extended true \
-relax:bb_move false \
-max_inner_cycles 30 \
-outer_cycles 1 \
-out:prefix msymm-ccd-loop-${1} \
-out:file:scorefile msymm-score.fsc \
-nstruct 1 \
-out:output \
-overwrite \

I'd be happy to provide any of the input files but I did want to attach all of them here sincer there are quite a few of them. any suggestions on how to trouble shoot this or where it might be failing?



Post Situation: 
Tue, 2013-10-29 03:41

Unfortunately, the given error message is a little to general/low-level to be of use. If you're willing to run under a debugger, a backtrace is likely to be more informative.

If you have GDB installed (it should come with gcc), then you can launch it by running "gdb ../../rosetta_source/bin/loopmodel.default.linuxgccdebug" at the command prompt. At the gdb prompt, issue a "catch throw" command, and then a "run" command, listing your commandline parameters. (I might suggest sticking them, one per line, in a text file, and then just using "@filename.flags" as your commandline parameter to Rosetta.) Eventually, when Rosetta finishes and give you the error message, you can issue a "backtrace", and get the backtrace to the error printed out. If you post that here, we may be able to get a better sense of where/why the program is erroring out. (BTW, to leave the gdb command prompt after the backtrace, simply use the command "quit")

Wed, 2013-10-30 08:05

Hi everyone,

I am having the same problem as reported here with loop model. I have been able to reproduce it using Frank DiMaio's cryoEM tutorial files for loop modeling, so I am fairly certain that this is either not an input file error or it is some incompatibility issue between Rosetta versions that I am not aware of.

I did, as suggested above, download the most recent weekly build (2013, week 42), compile the debug version of Rosetta and run GDB and have attached the output as a text file.

Any help on where to go from here would be greatly appreciated.



Mon, 2013-11-04 10:19

Thanks for the GDB session, Marissa. Unfortunately, I forgot that the HBond scoring code uses exceptions internally in normal processes. You need to "continue" through those until you get to the point where you see the error that you normally get by running the debug mode on the commandline. (Slightly annoying, I agree.) But since you mentioned you were getting it with Frank's cryoEM tutorial, I was able to locate the commands and files I believe you're running with, and replicate the issue myself.

What I think is happening is that you're using the -loops:input_pdb flag for the input PDB. While this was valid in previous versions of the loop_modeling protocol, it is apparently no longer used. I believe (but am not sure) that you should be using the standard "-s" flag instead for inputting your PDB. As your commandlines stand now, you're actually operating on an empty PDB, which results in errors when the protocol starts to operate on it.

Mon, 2013-11-04 17:14

Thanks so much - that seems to have resolved it.

Tue, 2013-11-05 09:29

I should point out that rmoretti just pushed a fix for this in dev trunk:

Tue, 2013-11-05 10:40