Member Site › Forums › Rosetta 3 › Rosetta 3 – General › ERROR when run prepacking pdbfile in Rosetta 3.4
- This topic has 14 replies, 3 voices, and was last updated 10 years, 2 months ago by
Anonymous.
-
AuthorPosts
-
-
April 17, 2014 at 7:04 am #1875
Anonymous
Hello everyone,
When I run prepacking for input file with flags:-s dock21.pdb
-database /home/tuongvy/SW/rosetta3.4/rosetta_database-docking:partners P_X
-nstruct 1
-out:pdb
-out:path .
I do not know this flags correct or not and I get this errorERROR: Unable to set up interface foldtree because there are no movable jumps
ERROR:: Exit from: src/protocols/docking/util.cc line: 289how I can fix it?
I attached PDB file below.
Thanks for help -
April 17, 2014 at 3:36 pm #9984
Anonymous
What does your input PDB look like? (It doesn’t look like it attached. You’ll need to change the extension to ‘.txt’ to satisfy the forums spam guards.) Does it have both a P chain and an X chain? (Or have they been renamed to A &
. Also, in light of your previous question, if you discard all the atoms for the chain due to zero occupancy, then you’ll also see a similar error message.
-
April 22, 2014 at 10:55 am #10017
Anonymous
Thank you so much rmoretti
. I can run docking now with your help. but one more problem about read a result. I see a table for scores. How can I analysis the result?
Could you please explain or suggest to me some documents for analysing the result?
Big thank and best regards ! -
April 22, 2014 at 10:55 am #10018
Anonymous
Thank you so much rmoretti
. I can run docking now with your help. but one more problem about read a result. I see a table for scores. How can I analysis the result?
Could you please explain or suggest to me some documents for analysing the result?
Big thank and best regards ! -
April 22, 2014 at 6:27 pm #10020
Anonymous
I don’t think we have any general information regarding analyzing results – it somewhat depends on what you’re wanting to accomplish.
For docking results, you typically want to look at total score and interface energy. Total score will tell you how stable the overall complex is – if you see any structures with a really bad total score, you can discard/ignore them, but that’s primarily a coarse pass. Typically the main evaluator of docking results is the interface energy. You’re looking for the structures with the best interface energy, which will indicate that they’re the most stable complexes.
You may also want to cluster your results. It’s typically been found that the conformations with the largest clusters are typically the native ones. If you get only a few structures which are similar, even if they have the lowest energy, you may be seeing an artifact of the sampling/scoring process, rather than indications of native structures. Often people do a score-vs-rmsd plot to the selected/lowest energy structure, and check that there’s a “funnel” – that is, all the low energy structures are close to the selected structure, and you get larger energies as you move away from the selected structures.
I’d recommend reading papers doing similar things to what you’re hoping to accomplish, and also reading the Rosetta documentation (https://www.rosettacommons.org/manuals/archive/rosetta3.5_user_guide/) for the protocols you’re using. Often those will have information about the types of analysis which would be relevant.
-
April 24, 2014 at 1:54 pm #10025
Anonymous
Thanks rmoretti!
I am trying to understand more about Rosetta. something is going more clear.
With my project, I docking for enzyme and peptide to find binding site. The enzyme have one Zn, and I think docking have to include ion Zn. I try to add Zn like one partner of Docking process (in my case: partner A: enzyme, partner H:Zn, partner B: peptide. But Rosetta can not read Zn. What should I do on my case.
I am looking forward your further help.
Big Thanks….. -
April 24, 2014 at 2:13 pm #10026
Anonymous
Zinc ions should be loaded by default. You may need to be careful about the names, though. The residue name for the zinc should be “_ZN” (where the underscore is actually a space), and the name of the zinc atom itself should be “ZN__” (again, the two underscores should be spaces.)
By the way, if you’re doing peptide docking you may want to look into the FlexPepDock application (https://www.rosettacommons.org/manuals/archive/rosetta3.5_user_guide/d7/d14/_flex_pep_dock.html), which is specifically designed for peptide protein docking, and may work better than trying to repurpose the protein-protein docking application. (Which sort of assumes that the two proteins are stably folded as monomers.)
-
April 25, 2014 at 1:51 am #10029
Anonymous
rmoretti, thanks your reply
I tried to change name residue and atom ZN, but Error is still (unrecognize ZN). Could you please take a look on my pdb file and tell me where is problem or fix it for me. I am total newer with bioinformations. Some questions, maybe, are so stupid
Need your help more!
I will try with Flexpeptdock later, thanks your recommendation. -
April 25, 2014 at 5:12 am #10030
Anonymous
here is pdb file
-
April 25, 2014 at 6:51 am #10031
Anonymous
when I fixed PDB file with your introduction , Rosetta did not complain about Zn anymore. But it did still not work.
THis was the ERROR I got :
ERROR: too many tries in fill_missing_atoms!
ERROR:: Exit from: src/core/conformation/Conformation.cc line: 2636
the cutted PDB file I attach below,please take a look and hepl me!
Thank you so much! -
April 25, 2014 at 2:07 pm #10032
Anonymous
You’re atom name is still off. The “N” of the “ZN” should line up with the H/C/N (the first letter) of the other atom names.
-
April 27, 2014 at 10:48 am #10033
Anonymous
rmoretti, I run successful with docking now. After running, ZN move far away its initial position. How I can constraint ZN or What are commands I need to add on flags to keep ZN?
Thanks!
Thank you again! -
April 28, 2014 at 6:10 pm #10034
Anonymous
Vikram Mulligan has added code recently to more easily deal with metals in Rosetta. The newest weekly releases will have these changes. I post the unedited text from the documentation on it (rosetta_basics/metals). Note that the documentation is not yet public, but will be soon as we transition into a new wiki documentation system.
-J
By Vikram K. Mulligan, Baker Laboratory (vmullig@uw.edu). Documentation created 13 March 2014; changes checked into master branch 14 March 2014.
AT THIS TIME, AUTOMATIC METAL SETUP IS NOT CONSISTENTLY WORKING WELL WITHIN ROSETTASCRIPTS. USE AT YOUR OWN RISK UNTIL THIS IS RESOLVED.
Short summaryThe -in:auto_setup_metals flag has been added to make it easy to import a PDB file containing a metalloprotein and to have Rosetta automatically detect coordinate covalent bonds to metal ions and create appropriate constraints.
Usage casesIn general, there are three broad types of task that a user might want to do with a metalloprotein:
Predict the structure of a metalloprotein, including discovering metal-coordinating residues. This is currently not easy in Rosetta, though this functionality might be added in the future. (Note that there has been some work on predicting metalloprotein structure in situations in which the metal-site geometry is known. See Wang et al. (2010). Protein Sci. 19(3):494-506 for details.)
Carry out de novo design of a metal-binding center in a protein. This is best done with the enzyme design geometric constraints files, which are described elsewhere
Import a PDB file describing a metalloprotein, and then do something to it (e.g. design a binder, redesign a loop, relax the structure, etc.). This documentation is intended for this case.What is Rosetta’s default behavior, and why is this a problem?
By default, Rosetta is able to recognize most of the metal ions commonly found in proteins (Zn, Cu, Fe, Mg, Na, K, Ca, etc.). On import, however, Rosetta knows nothing about the covalent connectivity between the metal ion and surrounding amino acid residues. As the foldtree is set up, the metal is added by a jump, rooted to the first residue. This isn’t ideal, since it means that a small change in the backbone conformation anywhere will not pull the metal along with the surrounding residues.
Because Rosetta knows nothing about metal ion covalent geometry by default, the scoring function will consider van der Waals interactions between the metal ion and surrounding side-chains, meaning that Rosetta will think that it is clashing horribly, yielding huge energy values. Relaxing the structure will push all surrounding side-chains away from the metal, and could result in the metal moving away from the rest of the structure. We probably don’t want that.
Even worse, the protonation state of histidine residues (which commonly coordinate metal ions) is, by default, set without any knowledge of the metal. This often places hydrogen atoms inside the van der Waals radius of the metal ion.
How have metalloproteins been handled in the past?Some people have created Enzdes-style geometric constraints files for each metalloprotein on which they want to work, but this is time-consuming and tedious, and requires user input that shouldn’t be necessary. It also requires that each protocol know how to use an Enzdes-style constraints file, and many do not. Others have used virtual metal atoms, but this means that the scoring function ignores the charge on a metal ion, and creates other problems. Some people have even created new metal-binding residue types that have included the metal, but this creates its own set of problems. Finally, some have just worked with apo-metalloproteins (the metal-free versions of the proteins), which is valid in some cases, but is not a generally-applicable strategy.
What’s the better solution?The -in:auto_setup_metals flag has been added to handle import of metalloproteins from PDB files automatically. This flag ensures the following:
Rosetta automatically sets covalent bonds between metal ions and nearby metal-binding atoms on metal-binding residues.
Rosetta automatically creates distance constraints between metal ions and the atoms that bind them. The distances are based on the geometry in the PDB file.
Rosetta automatically creates angle constraints between metal ions, the atoms that bind them, and the parent atoms to those atoms. The angles are based on the geometry in the PDB file.
Rosetta sets the atom_pair_constraint and angle_constraint weights in the scorefunction to 1.0, if they have not already been set in the weights file.
Rosetta removes hydrogens from atoms that bind metal ions, and adjusts the charge on the residue appropriately (which can be important in special cases in which one residue coordinates multiple metal ions).
Rosetta sets up the fold tree such that the metal atom is connected by a jump to the spatially closest metal-binding residue that precedes it in linear sequence. This means that if the protein’s backbone is moved, the metal will remain close to that residue (though not necessarily close to its side-chain, if that were to move).How do I control the default behavior of the -in:auto_setup_metals flag?
Three additional flags control the behavior:
-in:metals_detection_LJ_multiplier controls the threshold for detecting covalent interactions between metal ions and metal-binding residues. A value of 1.5 means that a time and a half the sum of the van der Waals radii of the metal ion and potential metal-binding atoms is used as the threshold.
-in:metals_distance_constraint_multiplier controls the strength of the distance constraint, with 1.0 being the default. Note that if an atom_pair_constraint weight is set by a protocol or by a weights file, the strength is automatically scaled appropriately (i.e. doubling the atom_pair_constraint weight does not necessitate halving the value set with this flag). If the value is set to 0, no atom_pair constraints are added.
-in:metals_angle_constraint_multiplier controls the strength of the angle constraint, with 1.0 being the default. As before, if an angle_constraint weight is set by a protocol or by a weights file, the strength is automatically scaled appropriately. If the value is set to 0, no angle constraints are added.How does Rosetta know which residue types can bind metals?
Metal-binding residues have the METALBINDING property in their properties list (in the params file). Additionally, metal-binding atoms are specified with the METAL_BINDING_ATOMS … line (also in the params file). Meanwhile, metal ions have the METAL property in their properties list. Note: metal ions must have the metal atom as atom 1.
Does this work for noncanonical amino acid residues, too?Absolutely. The noncanonical amino acid (2,2′-bipyridin-5yl)alanine (BPY) has been added to the database, and can serve as a demonstration case.
How can I confirm that Rosetta is setting the atomic connectivity properly?Explicit CONECT records can be written on PDB export by using the -inout:connect_info_cutoff 0.0 and -inout:dump_connect_info true flags. Bonds to the metal ion will be visible when the PDB output from Rosetta is loaded in PyMOL if you use these flags.
I’d like to do other things with metals in my own protocols.Can you ask that in the form of a question?
Where can I find the code for the functionality described here?Good question. Utility functions are located in src/core/util/metalloproteins_util.cc. (Functions in this file duplicate some of the functionality in src/protocols/toolbox/match_enzdez_util/ with some modifications; in the future, this should probably be consolidated to avoid code duplication.) The is_metal() and is_metalbinding() methods have both been added to both the core::chemical::ResidueType and core::conformation::Residue classes, letting you query whether a residue is a metal ion or a metal-binding residue. For metal-binding residues, the get_metal_binding_atoms() method in ResidueType and Residue provides a list of indices of metal-binding atoms.
CaveatsMetals followed by a “1” or “2” character (e.g. ZN1, CU2, etc.) are interpreted as the corresponding metal on PDB import. This can create problems (e.g. CO2 is interpreted as cobalt, not carbon dioxide).
This has not yet been tested with Cartesian minimization, the cart_bonded score term, or symmetry. These might create problems.Last edited by Vikram K. Mulligan (vmullig), 2014-04-15 20:09:37
Delete this Page
-
April 28, 2014 at 11:40 pm #10035
Anonymous
What Jared said applied to future weekly releases, but if you want to use an older version, there’s several options.
One would be to manually add atom pair constraints (https://www.rosettacommons.org/manuals/archive/rosetta3.5_user_guide/de/d50/constraint_file.html) to the atoms you want to keep together. Many of the protocols will be able to take in and obey such constraint files.
But if you’re using the standard protein-protein docking protocol, I’m surprised that the zinc moves. If you have the chain designations set up appropriately, there shouldn’t be any reason for Rosetta to move the zinc position. The only think I can think of is that Rosetta thinks there’s a clash between the zinc and surrounding residues, and during minimization will move the zinc slightly away to remove the clash – but that should be only just enough to remove the clash. “Far” from the starting position would be unexpected.
What does your runs look like? Can you provide the input files and commandline for a run which shows this behavior?
-
June 18, 2014 at 2:50 pm #10103
Anonymous
I would like to say thank you to you rmoretti, you help me so much. Because of some problem, I skip this job for a short time, and now I have to come back and finish it as soon as possible.
I do not use Docking and change to us e Plexpepdocking. I have Error when I run structure have ZN.
Can you take a look on my pdb file and help me. Thank you so muchThis is flags for pre-packing
-s tryzn.pdb
-database /home/tuongvy/SW/rosetta3.4/rosetta_database-flexpep_prepack
-ex1
-ex2arothis is ERROR
[node09:11746] [ 4] /home/tuongvy/SW/rosetta3.4/rosetta_source/build/src/release/linux/2.6/64/x86/gcc/4.1/mpi/libcore.2.so(_ZNK4core12conformation12Conformation23update_residue_torsionsEmb+0x117) [0x2b4c26f3fac7]
[node09:11746] [ 5] /home/tuongvy/SW/rosetta3.4/rosetta_source/build/src/release/linux/2.6/64/x86/gcc/4.1/mpi/libcore.2.so(_ZNK4core12conformation12Conformation23update_residue_torsionsEv+0x1a5) [0x2b4c26f40045]
[node09:11746] [ 6] /home/tuongvy/SW/rosetta3.4/rosetta_source/build/src/release/linux/2.6/64/x86/gcc/4.1/mpi/libcore.2.so(_ZN4core12conformation12Conformation15setup_atom_treeEv+0xa4) [0x2b4c26f402a4]
[node09:11746] [ 7] /home/tuongvy/SW/rosetta3.4/rosetta_source/build/src/release/linux/2.6/64/x86/gcc/4.1/mpi/libcore.2.so(_ZN4core12conformation12Conformation9fold_treeERKNS_10kinematics8FoldTreeE+0x6ac) [0x2b4c26f41c8c]
[node09:11746] [ 8] /home/tuongvy/SW/rosetta3.4/rosetta_source/build/src/release/linux/2.6/64/x86/gcc/4.1/mpi/libprotocols_c.5.so(_ZN9protocols15flexpep_docking22FlexPepDockingProtocol14setup_foldtreeERN4core4pose4PoseE+0xd3d) [0x2b4c20b6277d]
[node09:11746] [ 9] /home/tuongvy/SW/rosetta3.4/rosetta_source/build/src/release/linux/2.6/64/x86/gcc/4.1/mpi/libprotocols_c.5.so(_ZN9protocols15flexpep_docking22FlexPepDockingProtocol5applyERN4core4pose4PoseE+0xb9) [0x2b4c20b6fbf9]
[node09:11746] [10] /home/tuongvy/SW/rosetta3.4/rosetta_source/build/src/release/linux/2.6/64/x86/gcc/4.1/mpi/libprotocols.1.so(_ZN9protocols3jd214JobDistributor7go_mainEN7utility7pointer10owning_ptrINS_5moves5MoverEEE+0xffc) [0x2b4c24e9e20c]
[node09:11746] [11] /home/tuongvy/SW/rosetta3.4/rosetta_source/build/src/release/linux/2.6/64/x86/gcc/4.1/mpi/libprotocols.1.so(_ZN9protocols3jd225MPIWorkPoolJobDistributor8slave_goEN7utility7pointer10owning_ptrINS_5moves5MoverEEE+0x48) [0x2b4c24ec07e8]
[node09:11746] [12] /home/tuongvy/SW/rosetta3.4/rosetta_source/build/src/release/linux/2.6/64/x86/gcc/4.1/mpi/libprotocols.1.so(_ZN9protocols3jd225MPIWorkPoolJobDistributor2goEN7utility7pointer10owning_ptrINS_5moves5MoverEEE+0x96) [0x2b4c24ebe376]
[node09:11746] [13] /home/tuongvy/SW/rosetta3.4/rosetta_source/bin/FlexPepDocking.mpi.linuxgccrelease(main+0x2e6) [0x40af36]
[node09:11746] [14] /lib64/libc.so.6(__libc_start_main+0xf4) [0x32d861d994]
[node09:11746] [15] /home/tuongvy/SW/rosetta3.4/rosetta_source/bin/FlexPepDocking.mpi.linuxgccrelease [0x40ab59]
[node09:11746] *** End of error message ***
mpiexec noticed that process rank 33 with PID 11746 on node node09.mark.pknu.ac.kr exited on signal 11 (Segmentation fault).I upload pdb file bellow
-
-
AuthorPosts
- You must be logged in to reply to this topic.