AB INITIO WITH METALLOPROTEIN

[Anonymous]

Hello everyone!

I’m new in the community and I would like to know where I find information about ab initio with metalloproteins (metalloprotein abinitio relax). I just found this link in the forum that talks about docking with metal but it’s not exactly what I’m looking:

http://www.rosettacommons.org/node/2259

I’m trying to generate the same results in Wang et al., 2010 (Prediction of structures of zinc-binding proteins through explicit modeling of metal coordination geometry, 2010, Protein Science)

I would be very grateful if someone could help.

[Anonymous]

On the site there is the supplementary material: http://onlinelibrary.wiley.com/doi/10.1002/pro.327/suppinfo. However I would like to have information about the protocol.

[Anonymous]

Chu (the author) has moved on from the Rosetta community. Here’s his reply to the request for documentation:

~~

I don’t remember writing [documentation], and below is an email I sent to [a Rosetta person] a while ago regarding how to set zinc constraints in Rosetta. Maybe you can put it somewhere for people to refer to (since I don’t have written access to Rosetta svn repository any more). Thanks.

Chu

~~
[forwarded email]
I have not been following up with updated versions of Rosetta for a while, but there should be an integration test in the following location with all example input files. I am not sure there is a formal documentation around, but the protocols are based on standard protein folding and loop modeling protocols with additional constraint files. Here are a few additional files you will need:

/trunk/mini/test/integration/tests/metalloprotein_abrelax/input

1. fasta — more annotated than the standard one with [CYZ] or [HIS] to mark the residues that chelate the zinc, and Z[ZN] at the end for extra “zinc” residue.
2. residue_pair_jump_cst — explanation after ##

BEGIN ## starting marker
jump_def: 3 60 59 59
## a rigid-body jump from the residue 3(first zinc-chelating residue) to 60(zinc) with a cut point starting at 59 and ending at 59 (last protein residue) This is to define how the fold tree is generated.
aa: CYS ZN
## the residues on both sides of the jump
cst_atoms: SG CB CA ZN V1 V2
## how distance, angular and dihedral parameters are defined
jump_atoms: C CA N ZN V1 V2
## how the jump is defined between in the atom tree
disAB: 2.20
angleA: 68.0
angleB: 70.5
dihedralA: -150.0 -120.0 -90.0 -60.0 -30.0 0.0 30.0 60.0 90.0 120.0 150.0 180.0
dihedralAB: -150.0 -120.0 -90.0 -60.0 -30.0 0.0 30.0 60.0 90.0 120.0 150.0 180.0
dihedralB: 120.0
## all the degrees of freedom as defined in Figure 1 and Table 1 to generate various jump transformations between CYS and ZN
END ## ending marker

each blocks as above can define one zinc binding site and if you have more than one zinc, append more blocks like this.

3. cen_cst or fa_cst files.– this is used to define constraints to keep chelating geometry optimal between zinc and other three chelating residues. The files are in standard Rosetta distance and angular constraints format.

Hope this helps.

~~~

[Anonymous]

Hi smlewis

Thanks for your reply. To generate a fragments library I believe we should remove the zinc Z[ZN] from the sequence, right?

[Anonymous]

Hello everyone,
I have to try out the abinitio metalloprotein method with 1dsvA, which is given in rosetta.

My input is:

/users/stud09/crietze/rosetta_2014.20.56838_bundle/main/source/bin/AbinitioRelax.linuxgccrelease
-database /users/stud09/crietze/rosetta_2014.20.56838_bundle/main/database
-abinitio:relax
-relax:quick
-relax:jump_move
-increase_cycles 0.1
-run:test_cycles
-score:weights score13_env_hb
-abinitio:rg_reweight 0.5
-abinitio:rsd_wt_helix 0.5
-abinitio:rsd_wt_loop 0.5
-abinitio:use_filters false
-fold_cst:no_minimize
-jumps:residue_pair_jump_file ./input/1dsvA.residue_pair_jump_cst
-packing:ex1
-packing:ex1:level 1
-packing:ex2
-packing:ex2:level 1
-packing:extrachi_cutoff 0
-in:file:native ./input/1dsvA.pdb
-in:file:fasta ./input/1dsvA.fasta
-in:file:psipred_ss2 ./input/1dsvA.psipred_ss2
-in:file:frag9 ./input/aa1dsvA09_05.200_v1_3
-in:file:frag3 ./input/aa1dsvA03_05.200_v1_3
-constraints:cst_file ./input/1dsvA.cen_cst
-constraints:cst_weight 1.0
-constraints:cst_fa_file ./input/1dsvA.tetraL.fa_cst
-constraints:cst_fa_weight 1.0
-out:nstruct 6000
-out:path:pdb
-out:pdb
-out:output
-out:file:silent
-run:no_prof_info_in_silentout
-mute core.io.database

I have done a score-cutoff and I have plot score-rmsd. but the best structures looks completely different than the native structure (the beta-sheet is not occur in the calculate structures). I have the same problem Without in:file:native ./input/1dsvA.pdb.
Where is my mistake?!
Thanks.

[Anonymous]

Thanks a lot.

Rosetta ignore the command in the -in:file:psipred_ss2 ./input/1dsvA.psipred_ss2 completely, but where could be the mistake?! Rosetta doesn`t show any mistake in this calculation, but also doesn`t mention the psipred in the log file.

[Anonymous]

Thank you very much. I also believe that Rosetta doesn`t use the psipred file for this calculation.

I have use the 1dsvA fragments, which are given in Rosetta. But the calculated structures looks completely different (have different rmsd-values and the atom_pair_constraints are high) . What can be the source of defect?! Is it only a fragment problem?!

Than I have two additional questions. Rosetta give me the jumps file as an output:

S_00000001 7.86273 0 1 19.2922 5 32 | cuts: 31

and the values in the jump-pre file are the following:

S_00000001 26.5119 68659.5 1 28.008 5 32 | cuts: 31

The 5 stands for the beginning of the jump, the 32 for the end of the jump and the 31 is the cutoff. But what mean this values?!

My last question is: for what stand the “no pdb UpJump” and the “no_pdb_Down_Jump” in detail, which are occurrence during the calculation ?!

protocols.jumping: JUMPFRAME 1 2
protocols.jumping: 1 0 no_pdb UpJump
protocols.jumping: 2 0 no_pdb DownJump RT 0.86639 0.412749 0.281081 ….

[Anonymous]

I’m sorry, I’m not quite understanding where you’re getting the “S_00000001 7.86273 0 1 19.2922 5 32 | cuts: 31 ” and “S_00000001 26.5119 68659.5 1 28.008 5 32 | cuts: 3” values from. They are not in the file you’re passing to -jumps:residue_pair_jump_file, are they?

The UpJump and DownJump stand for “upstream of jump” and “downstream of jump”. “no_pdb” simply indicates that the “JUMPFRAME” wasn’t derived from a PDB. (Technical detail – that output is actually coming from the fragment machinery, so it’s there for outputting fragment information, which are derived from source PDBs.)

[Anonymous]

Thanks a lot.
The values are from the “jumps_pre.log” and “jumps.log” file. This are two files, which I get seperatly, when I do metalloprotein-calculation.
Ok. And what can I imagine under “upstream of jump” and “downstream of jump” ?!

[Anonymous]

Probably. I guess try it both ways if the first thing you try doesn’t work.

[Anonymous]

The -in:file:native will only be used to calculate RMSD statistics, so it shouldn’t affect the structures you get in the output.

If it’s an issue of not finding the appropriate secondary structures, my guess is that the problem might lie in the fragments you used. If the secondary structural prediction for this protein is off, you’ll have a difficult time getting good results. I’d check the settings and any intermediate files used in the fragment generation step, and confirm that the secondary structure prediction matches what you expect it to be. (The psipred_ss2 should contain information about the secondary structure predictions.) If it’s incorrect, you may want to adjust the settings on the fragment generation to get results with correct secondary structure annotations.

Another thing to check is to look at other (poorly scoring) structures. Do any of them get close to the native? Do any of them have the correct beta sheet? If so, it might be a scoring issue, rather than a secondary structural issue. If you have any experimental or knowledge-based constraints you can put on the folding run, that can help correct for biases in the naive Rosetta runs.

[Anonymous]

While the abinitio run itself might not use the psipred_ss2 file, when the fragments were generated the secondary structure predictions there were used for predicting what types of fragments should be generated. Bad predictions mean bad fragments.

I’m assuming you generated the fragments with the Robetta server? If it’s been less than a week or so, the secondary structure prediction files associated with the fragment generation run should be available with Result Details -> Downloads. As I understand it, there’s actually three secondary structure predictions there. The psipred_ss2 file, the jufo_ss file, and the rdb file. Examine those and see if the secondary structure predictions match what you expect from this protein. (H = helix, E= extended beta strand, U/C/L – unstructured/coil/loop – Numbers are the confidence level. The higher the confidence the less chance of picking non-matching fragments. For example, if you’re predicted as 0.99 H, you’re not going to have many beta sheet fragments in the fragment file for that position.)

If it’s been longer than a week, the files may have been deleted from the server. Rerun to regenerate, and double check that you’re using the correct fasta file (you want exactly the same one as the one you’re giving to the abinitio run). A fasta/fragment mismatch can also mess up your abinito runs.

If the automatic secondary structure prediction doesn’t work for you, there really isn’t a way to change the prediction with the Robetta server – you’d have to run the fragment picker locally. That’s a little bit of a pain, so first make sure that’s really the problem you’re encountering.

[Author]

Posts