You are here

Abinitio Calculations - typical parameters

6 posts / 0 new
Last post
Abinitio Calculations - typical parameters

Dear all,
I am using rosetta for abintio calculations for a while now. I am curious to know what are other parameter other than mentioned in the documentation, to play with to simulate protein size of 150 aminoacids. I am not really satisfied with the results obtained with typical parameters and wondering my laptop took only like one hour to complete the job ( but heard previously it is computationally intensive process)

Here is my flag file
-database /home/vamsi/Programs/Rosetta31/rosetta_database/
-in:file:fasta inputs/t000_.fasta
-in::file::psipred_ss2 inputs/t000_.psipred_ss2
-in:file:frag3 inputs/aat000_03_05.200_v1_3
-in:file:frag9 inputs/aat000_09_05.200_v1_3
-out:nstruct 2
-out:file:silent p1_silent.out

please suggest me any other parameters or any other steps to simulate the folding process i.e number of cycles.

Thank you for advice in advance

With regards,

Post Situation: 
Thu, 2010-11-11 07:06

I can't address most of your question. However, I do know that the computational intensity for abinitio comes from nstruct. nstruct of 2 is nothing; nstruct of 10000 is starting to approach a reasonable number and nstruct of one million is not unheard of.

Thu, 2010-11-11 10:42

Thank you for your suggestion ..please advise me how to proceed with ( -nstruct 10000 with -abinitio:relax parameter or without it). In addition, how to proceed from 10000 structure to single out most probable structure.

I have a long confusion, how to validate the structure predicted in abinitio protocol without crystal structure availability ( please advice me any parameter, any tools ect)

Fri, 2010-11-12 00:29

I'm not the right person to answer your question, hopefully one of the abinitio people will come along and take a look.

If you can afford the time, run with relax. If you can't afford the computer time, then run relax on the best of the results instead.

Determining the most probable structure from thousands of results is based on two things: clustering, and the score. If you find that many, many models cluster into one group, and several of those models have better scores than other clusters' best members, then Rosetta thinks that's how the protein folds. If you get no clear clusters, or no score discrimination between clusters, then Rosetta doesn't have a solid prediction.

Validation of these structures is an entire field in itself. You have to decide based on your system what you want to do to validate. The most obvious thing is making point mutations of buried interactions in the protein. If your mutation would destroy a predicted interaction, and the protein unfolds, then it's consistent with the structure. If the mutation doesn't stop folding, then the prediction is wrong. Experiments in this vein can get endlessly complex.

Tue, 2010-11-16 03:40

Thank you very much for your insightful suggestions.currently , i am generating 10000 structures. How much rmsd cut off you suggest is good for clustering and how do i proceed to improve the predicted structures. I don't have any slightest idea how my structure look like, as you suggested inducing point mutations is very good idea, unfortunately, my work is only insilico. so are there any ways of computational structural validation .

Finally, i am curious to know, when you are going to release rosetta3.2 ( looking for flexipepdock module)

your suggestions will greatly help my research

Thu, 2010-11-25 03:12

The best method for computational structural validation is trying different methods and seeing that they return similar results. I've heard good things about the Zhang Server/I-TASSER.

RMSD cutoff for clustering is dependent on the system, but you want a number that give you a manually manageable number of clusters without allowing the clusters to vary too much internally. I think realistic numbers are in the 1-10 sq angstrom range but that's a guess.

The codebase was branched for 3.2 but I don't know how far along the validation process is before we can release it. There is a specific plan for 3.3 in mind tied to certain publications; at this point 3.2 may get delayed and we'll merge 3.3 into 3.2 (which would delay 3.2 until February or so). The lab managing the release is the lab that wrote flexpepdock so you can always try asking them directly.

Thu, 2010-12-02 06:56