# mr_protocols with symmetry and ligand

5 posts / 0 new
mr_protocols with symmetry and ligand
#1

Hello,

I have been trying to use mr_protocols on a homologous pdb into a cryo-em density. When I run the protocol with symmetry and without the ligand it works properly. The trouble comes when I try to include a ligand. The resulting pdb is does not contain the ligand. This is the mr_protocol that I have submitted:

#####################################################

#!/bin/bash

$ROSETTA3/bin/mr_protocols.linuxgccdebug \ -database$ROSETTA3_DB \
-MR::mode cm \
-in::file::extended_pose 1 \
-in::file::fasta ./input_files/kubeta2.fasta \
-in::file::alignment ./input_files/kubeta2_1zsx.ali \
-in::file::template_pdb ./input_files/1zsx.pdb \
-in::file::fullatom \
-cm::min_loop_size 4 \
-cm::loop_close_level 0 \
-cm::loop_rebuild_filter 150 \
-MR::max_gaplength_to_model 10 \
-loops::frag_sizes 9 3 1 \
-loops::frag_files ./input_files/aakubeta2_09_05.200_v1_3 ./input_files/aakubeta2_03_05.200_v1_3 none \
-loops::remodel quick_ccd \
-loops::relax relax \
-loops:random_grow_loops_by 5 \
-loops:random_order \
-loops:extended \
-relax::default_repeats 2 \
-relax::jump_move true \
-ignore_unrecognized_res \
-nstruct 1 \
-extra_res_fa ./input_files/NAP.params \
-edensity::cryoem_scatterers \
-edensity::mapfile ./input_files/run1_class001.b400.mrc \
-edensity::realign min \
-edensity::mapreso 4.9 \
-edensity::grid_spacing 2.5 \
-edensity:sliding_window_wt 0.5 \
-edensity:sliding_window 5 \
-symmetry:symmetry_definition ./input_files/1zsx.symm \
-symmetry::initialize_rigid_body_dofs

#####################################################

I have also tried to use only relax but the results are worst, to the point that the pdb is completely disorganized. Again here is the relax that I used:

#####################################################

#!/bin/bash

$ROSETTA3/bin/relax.linuxgccdebug \ -database$ROSETTA3_DB \
-in::file::extended_pose 1 \
-in::file::fasta ./input_files/kubeta2.fasta \
-in::file::alignment ./input_files/kubeta2_1zsx.ali \
-in::file::template_pdb ./input_files/1zsx.pdb \
-in::file::fullatom \
-relax::default_repeats 1 \
-relax::jump_move true \
-ignore_unrecognized_res \
-nstruct 1 \
-extra_res_fa ./input_files/NAP.params \
-edensity::cryoem_scatterers \
-edensity::mapfile ./input_files/run1_class001.b400.mrc \
-edensity::realign min \
-edensity::mapreso 4.9 \
-edensity::grid_spacing 2.5 \
-edensity::whole_structure_allatom_wt 0.1 \
-edensity::score_symm_complex true \
-symmetry::symmetry_definition ./input_files/1zsx.symm \
-symmetry::initialize_rigid_body_dofs

#####################################################

Is there a reason for the ligand disappearing with mr_protocols and the pdb disorganization with relax?

Thank you,

jhm13c

AttachmentSize
4.13 KB
6.44 KB
Category:
Post Situation:
Mon, 2017-02-27 11:59
jhm13c

The reason relax is giving you a junk structure is that you're starting with an extended chain. The regular relax application (e.g . "relax.linuxgccdebug") is intended to take decent (but not great) structures and make them better. It's not intended to start from really bad structures (like extended chains) and fold them from scratch. -- It can try, but it's highly dependent on the exact system whether it will get anything decent.

On your issues with ligands in mr_protocols, do you have the ligand in your FASTA file? It doesn't matter if the ligand is in the template PDB if it's not also in your FASTA file and alignments. If you give Rosetta a FASTA file with just the protein residues, it will model exactly that -- just the protein residues.

Tue, 2017-02-28 10:24
rmoretti

Hello,

Thank you for the quick response.

I do not have the ligand in the FASTA file, so that is why the resulting model do not have the ligand present. Is there a quick way around it?

Second, I do not really understand why in relax it is starting from an extended chain. An initial pdb is provided and the structure is very similar.

- jhm13c

Tue, 2017-02-28 11:55
jhm13c

The quick solution to not having a ligand in your fasta file is to add it.

In your ligand params file (NAP.params), in the IO_STRING line should have both the three letter and one letter code that is used for the residue. The three letter code is used in the PDB files, and the one letter code is used in FASTA files. Except that the one letter code is probably not going to be enough for Rosetta to figure out what the ligand is (for most ligand we set this to 'Z'). To fix this, you need to use the "annotated sequence" format, where after the one letter code of the ligand, you put the full name (the entry in the NAME line of the params file) of the ligand in square brackets. So the total entry for your ligand is probably going to looks something like Z[NAP]  Put that in the FASTA sequence wherever it goes. (For non-polymeric residues, it's typically at the end.)

Then in your alignment file, be sure to add the one-letter code for the residue at the appropriate location (the full type can be found from the PDB or the FASTA, so in your alignment files you don't have to - and shouldn't - use the annotated sequence format in the alignment file.)  If you want to have a correspondence between the ligand in the template structure and the target structure, be sure that you align the corresponding one letter codes in the template and target.

On the relax issue, you have the -in::file::extended_pose option in your commandline, which tells Rosetta (or at least certain Rosetta protocols) to use an extended chain input format. In my quick read I thought this was what was controlling your input, but looking into things closer, it looks like relax is going to ignore that, and use the -in::file::template_pdb to give you a threaded PDB instead.

I'm not sure why this is an issue. One thing I'd check is to make sure that the PDB threading is happening correctly. For this, run score_jd2 instead of relax, with the same commandline, but also add -out:pdb. This will give you a minimally-changed structure: basically what Rosetta makes from threading before starting the relax process. Double check that that makes sense.

The other issue may be that if you start with a really bad structure, relax can cause the structure to fly apart, and then has a very difficult time putting it back together. One thing to try is to remove the electron density options and add the option -constrain_relax_to_start_coords instead. This should give you a relatively decent starting structure, which you can then feed back into the with-electron-density relax refinement command, using something like -in:file:s instead of your current -in::file suite.

Wed, 2017-03-01 14:50
rmoretti

Thank you for the explanation. I will digest this information and try to apply it. I will post updates once I have tried the suggestions.

Thank you,

jhm13c

Thu, 2017-03-02 12:01
jhm13c