Posts by Sarel

1) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 70333)
Posted 13 May 2011 by Profile Sarel
Post:
Hi everybody,

Our paper describing the design of flu inhibitors using Rosetta @ Home has just been published as a Research Article by Science.

To summarize the results, using the resources provided by your computers we were able to identify ~80 designed proteins that might be candidates as flu diagnostics and inhibitors. Two of these proteins bound to Spanish and avian flu hemagglutinin quite tightly and one of them was crystallized in the presence of Spanish flu hemagglutinin to show that the designed interaction is exceptionally accurate.

Beyond the specific application to the flu, your resources have been extremely useful in getting our methods up to scratch to deal with this and other very challenging problems. If you follow some of the previous posts in this thread you can see the sort of problems that we\'re hoping to address with this new method and your contributions. Hopefully, these will help address some significant outstanding challenges in the development of antivirals and in studying recalcitrant biological questions.
2) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 68859)
Posted 22 Dec 2010 by Profile Sarel
Post:
Right! We introduced the RhoA project in this entry:

http://boinc.bakerlab.org/forum_thread.php?id=4477&nowrap=true#66178

Hopefully more on eed soon...

Thanks for your interest, Sarel.

In the last few days I see a lot of new WUs from the *ProteinInterfaceDesigh* series starting from 8, 10 and 16 December.
For example ApBp_eed2_eed2_* or rhoA8Dec2010_1lb1_2bf0_* or AEty_1_eed2_eed2_* etc
Some brief updates on the new search targets?

3) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 68665)
Posted 19 Nov 2010 by Profile Sarel
Post:
Hello,

As you may have read on David\'s blog we\'ve had a lot of exciting developments on the influenza hemagglutinin front lately, including a crystal structure confirming one of the designs and biochemical data with respect to another that show that the protein inhibits the action of hemagglutinin. Hopefully this means that the proteins can serve as platforms for the development of therapeutics and diagnostics for many different flu types. More broadly, the thought that protein design could produce proteins that are as useful as antibodies is a sign of the field\'s maturity. I\'m very pleased to mention also that both of these designs, and in fact 80% of the designs we generated in the hemagglutinin project came from your computers on Rosetta @ Home. This project has been so complex that without your amazing resources it would have been impossible to get working binders.

On a related issue, we\'re designing more putative binders of RhoA, so you will see more design jobs labeled \"design of inhibitors of RhoA\". I previously introduced RhoA in entry:
http://boinc.bakerlab.org/forum_thread.php?id=4477&nowrap=true#66178

Many thanks! Sarel.
4) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 67671)
Posted 9 Sep 2010 by Profile Sarel
Post:
One of the most thrilling directions of research for protein-interface design is generating binding proteins for use as diagnostics in developing countries. The aim here is to develop materials for an early-detection kit, where the materials are cheap and robust enough to last for months or years without refrigeration. Diagnostics kits are typically comprised of antibodies, which are often expensive to mass produce and sometimes deteriorate over long periods of time. We believe that redesigning small stable proteins as binders would provide proteins of the necessary qualities to significantly improve the usefulness of diagnostics.

Our first target with a possible diagnostic application is the envelope protein of dengue virus. Dengue is a mosquito-borne virus that is widespread in the tropics and causes debilitating fever and death. Early-detection kits are extremely important because dengue-infected individuals should be protected from mosquito bites to cut off the spread of disease in their community.

Over the next few weeks I will submit design trajectories to Rosetta @ Home which will be labeled \"Dengue binder design\". I\'m looking forward to seeing the binders that your computers will crunch this time!

To read more about dengue please see:
http://en.wikipedia.org/wiki/Dengue_fever
5) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 67031)
Posted 28 Jul 2010 by Profile Sarel
Post:
One of the most important ways in which molecular biologists learn about the functions of protein systems in the cell is by introducing mutations to the protein and seeing what the effects on cellular functions are. This method is extremely powerful but carries the risks that damage will be indiscriminate and the functional readout would be convoluted by many different effects. A more refined way of perturbing cellular functions would be to inhibit a specific interaction within the cell, keeping all other interactions, including of the target protein, intact. Such specific inhibition is more subtle and reduces unwanted effects, and indeed specific inhibitors of cellular pathways accelerate advances in our understanding of cell physiology.

The design of protein inhibitors promises to take this approach and make it widely available to systems that have been recalcitrant to the development of specific inhibitors to date. Since protein interactions have very large surface areas we can design inhibitors that would be exquisitely specific to the target protein as we\'ve done for influenza hemagglutinin. In a posting above, I mentioned that we\'re designing proteins that would inhibit MDMX but not MDM2, despite very close homology between the two proteins.

A new protein target that we\'re interested in is called ERGIC-53. A complex between ERGIC-53 and another protein called MCFD2 has been shown to be an important cargo receptor that shuttles proteins between various compartments in mammalian cells. Even though the complex has been extensively studied major questions about its function remain unanswered, among which are how the complex interacts with its cargo proteins. A specific inhibitor of the interaction between ERGIC-53 and MCFD2 will provide a way to control the formation and dissociation of the cargo receptor in a time-controlled manner, decreasing unwanted effects, and hopefully increasing our understanding of this important system.

I should mention that mutations in either ERGIC-53 and MCFD2 have been identified in human populations and cause an inherited bleeding disorder. For more information on this link between the cargo receptor and disease, please see
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1895703/

Over the next few weeks I will submit workunits with different strategies for designing anti-ERGIC proteins. Thank you very much for your contributions to this project!
6) Message boards : Number crunching : simIF2...ProteinInterfaceDesign...-tasks (Message 66973)
Posted 22 Jul 2010 by Profile Sarel
Post:
Hi Joe,

I\'m trying to figure out whether these fc tasks are giving you trouble as well. I see that for both of these fc tasks they ran for many hours and produced many models and you got credits accordingly. As far as I know in-between models are saved so you would have gotten plenty of credit for these if you stopped them mid-way, wouldn\'t you?

Sarel.

These two tasks ran for about 4 hours, according to the taks details. But they both had been running for more than 7 hours, when I turned off the computer. So they fell back to the last save point, which was near to 4 hours on both tasks, when I turned it back on.
Looking at the computation time, they are giving me trouble, since I have lost 3 hours of work per tasks.
I was suprised about the amount of credits granted on this two tasks, but you can\'t predict, how much credit is granted for the fc_A_noSmallMvs-tasks:
Low credit:
http://boinc.bakerlab.org/rosetta/result.php?resultid=353446268
http://boinc.bakerlab.org/rosetta/result.php?resultid=353455781
High credit:
http://boinc.bakerlab.org/rosetta/result.php?resultid=353279271

cu Joe


Thanks, Joe! We\'ll next figure out different ways to reduce considerably the number of long-running trajectories. In the meantime, to make sure that you don\'t lose computing time as you suspend jobs, Mod.Sense\'s suggestion makes a lot of sense. In the boinc manager, go to Advanced/Preferences, select the \"disk and memory usage\" tab and check the \"leave applications in memory while suspended option\".
7) Message boards : Number crunching : simIF2...ProteinInterfaceDesign...-tasks (Message 66953)
Posted 20 Jul 2010 by Profile Sarel
Post:
Hi Joe,

I\'m trying to figure out whether these fc tasks are giving you trouble as well. I see that for both of these fc tasks they ran for many hours and produced many models and you got credits accordingly. As far as I know in-between models are saved so you would have gotten plenty of credit for these if you stopped them mid-way, wouldn\'t you?

Sarel.

This are the two results:
fc_A_noSmallMvs_fc6x_1tev_ProteinInterfaceDesign_20Jun2010_21458_110_1
fc_A_noSmallMvs_fc6x_2ije_ProteinInterfaceDesign_20Jun2010_21458_53_0

They were both automatically ended shortly after turning the computer on. The first one had been running for 7:30 and the second one had been running for 7:10 when I turned off my computer in the morning.
So this type of ProteinIntefaceDesign-tasks might have a similar problem.

cu Joe

8) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 66541)
Posted 10 Jun 2010 by Profile Sarel
Post:
It varies, but I think that 750Mb would be a good guesstimate. Though that\'s not too bad, another thing that makes these trajectories a poor fit for Rosetta @ Home is that they might take several hours to produce output. Since we only do these runs for a few tens of the best of what we found on Rosetta @ Home, we can do it efficiently on our own machines.

That\'s a very good question! With respect to the ProteinInterfaceDesign simulations, on Rosetta @ Home our goal is to scan the vast conformational-sequence space in order to get good leads. Sampling for those is then intensified on our own machines where we can run high-memory trajectories for longer.


Out of curiosity, how much memory do the more intense studies that are in-house require and is that a limiting factor to the lab\'s throughput? I assume all the computational limitations (in-house and R@H) are limiting in some way...

9) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 66530)
Posted 9 Jun 2010 by Profile Sarel
Post:
That\'s a very good question! With respect to the ProteinInterfaceDesign simulations, on Rosetta @ Home our goal is to scan the vast conformational-sequence space in order to get good leads. Sampling for those is then intensified on our own machines where we can run high-memory trajectories for longer. So, in a sense we are implementing a primitive version of your suggestion. During energy minimization, by the way, we have exactly this delta energy criterion that you mention as a stopping condition.

What you are suggesting is actually being attempted now in a more sophisticated form than what I mentioned above by some of the people on the Rosetta team for structure prediction of very large proteins, where very many trajectories are run, clustered and the best few are then intensified. From what I\'ve seen this is an extremely promising direction of research so let\'s keep our fingers crossed for it!

Thank you. Now it is clear from this acceleration comes. Due to the possibility of modeling is not all the protein completely, but only the most important (for the current study), part of it.

2 Sarel
And yet another question. I am not a scientist, so this may seem silly, but as a result of observing the process of calculations I had the idea.
It concerns the limit of 500 steps in modeling protein-protein including the last MDMX. It is clear that the shorter limit is introduced to speed up processing. And in most cases it seems to be enough - a graph of energy usually manages to \"find minimum\" for these 500 steps and more just jumping around him.

But periodically I see a model in which the energy almost continuously go down, but the simulation of the same breaks at the limit of 500 steps. (Obviously not a straight line, but with variations here and there, but the overall trend is absolutely clear - down) Though if given the additional steps would be found a configuration with a much lower energy. And since this model does not differ from the total mass, because its calculation was stopped before she could reach its minimum. Simply increasing the number of steps are not very effective way, because it increase the use of computing resources in times (or reduce the number of models with fixed resources), for 5% of models (about as much on my observations do not manage to reach the \"saturation\") is not effective. (Though perhaps this is the most valuable model, so that theoretically could be more valuable than the other 95%)

But what if instead of a fixed hard limit on the number of steps to use a dynamic limit is based on \"delta energy\" criteria? Ie compare the minimum energy found suppose the last 100 steps (for example, concrete value must be chosen experimentally), with previous values. If there is some improvement, then give the model additional steps, and so until the reduction of energy does not stop. The fixed limits (in particular number of steps) are also needed, but only as a acceptable framework - minimum (say cover those 500) and maximum (it should be big enough, but within reasonable limits. To finish on time \"bad model\", without waiting for the activation of watchdog).

Perhaps this idea has already been tried before? Then it would be interesting to know the results and why abandoned.

10) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 66522)
Posted 8 Jun 2010 by Profile Sarel
Post:
Thanks for your feedback! Mod.Sense\'s replies on the conformational sampling is very accurate. With regard to the size of the protein, you are right that MDMX is a much larger protein than what we are modeling in these design trajectories. What we are interested in is the interaction surface of MDMX with p53. That is (thankfully) a very small domain allowing us to do things more quickly and efficiently.

Only I went to ask about a new type of tasks, which drew my attention... And here is a ready description posted already. Excellent speed.
But the question still is: it is simple (short) protein? (But in wiki i found info about 490-amino acids, it is not short i think) Or improve of algorithm? This type of job (MDMX_ *) generates much more decoys for the same time, compared with other protein-protein tasks i saw before. From a few hundreds to 1200 decoys in only 2 hours (7200 sec) tasks at mid-level processor. I already had a lot of these tasks, that\'s only 3 for example:

http://boinc.bakerlab.org/rosetta/result.php?resultid=343957927
http://boinc.bakerlab.org/rosetta/result.php?resultid=344057490
http://boinc.bakerlab.org/rosetta/result.php?resultid=343943380

And judging by the normal ratio between Claimed and Granted credit is not a feature of my computer, but it happens at all.

11) Message boards : Number crunching : minirosetta 2.14 (Message 66497)
Posted 6 Jun 2010 by Profile Sarel
Post:
I found the problem, it was an error in one of the input files that would sporadically show up (so it didn\'t come up on my local tests). I\'ve now fixed it and tested it locally and will gradually resubmit the jobs to the queue (the new jobs will be dated 6Jun2010 rather than 4Jun2010). Please let me know if you have more problems with these new jobs.

Thanks for mentioning the specific task that gave you problems! It made tracking down the problem very easy.

Best, Sarel.

Thanks for your posts! It looks like a problem with the MDMX protocol that I put up earlier. I\'ve now eliminated these jobs from the queue until I figure out what\'s wrong with these (but some jobs might still be rolling out on your machines). I\'ll let you know once I figure this out!

Thanks again, Sarel.

I\'m seeing a lot of these lately in my results. Anything to worry about?


ERROR: ERROR: Residue not supported by Placement coordinate constraint machinery
ERROR:: Exit from: ..\\..\\src\\protocols\\ProteinInterfaceDesign\\movers\\PlaceUtils.cc line: 281
called boinc_finish


I\'m getting them here too - so I am going to guess that it is not a problem with your system. Interesting that they are declared a \"success\" even though they end with an error.

Task 343850781

ERROR: ERROR: Residue not supported by Placement coordinate constraint machinery
ERROR:: Exit from: src/protocols/ProteinInterfaceDesign/movers/PlaceUtils.cc line: 281


Task 343814609

ERROR: ERROR: Residue not supported by Placement coordinate constraint machinery
ERROR:: Exit from: src/protocols/ProteinInterfaceDesign/movers/PlaceUtils.cc line: 281


I am running X64 Linux on systems based on AMD Phenom II CPUs






12) Message boards : Number crunching : minirosetta 2.14 (Message 66495)
Posted 6 Jun 2010 by Profile Sarel
Post:
Thanks for your posts! It looks like a problem with the MDMX protocol that I put up earlier. I\'ve now eliminated these jobs from the queue until I figure out what\'s wrong with these (but some jobs might still be rolling out on your machines). I\'ll let you know once I figure this out!

Thanks again, Sarel.

I\'m seeing a lot of these lately in my results. Anything to worry about?


ERROR: ERROR: Residue not supported by Placement coordinate constraint machinery
ERROR:: Exit from: ..\\..\\src\\protocols\\ProteinInterfaceDesign\\movers\\PlaceUtils.cc line: 281
called boinc_finish


I\'m getting them here too - so I am going to guess that it is not a problem with your system. Interesting that they are declared a \"success\" even though they end with an error.

Task 343850781

ERROR: ERROR: Residue not supported by Placement coordinate constraint machinery
ERROR:: Exit from: src/protocols/ProteinInterfaceDesign/movers/PlaceUtils.cc line: 281


Task 343814609

ERROR: ERROR: Residue not supported by Placement coordinate constraint machinery
ERROR:: Exit from: src/protocols/ProteinInterfaceDesign/movers/PlaceUtils.cc line: 281


I am running X64 Linux on systems based on AMD Phenom II CPUs





13) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 66469)
Posted 5 Jun 2010 by Profile Sarel
Post:
We\'ve started to design proteins against another exciting target called MDMX. MDMX is known to interact with one of the key tumor-suppressor genes, p53. p53 has such a central role in physiology that it has been called \"guardian of the genome\". MDMX inhibits p53 and causes its degradation through a complex mechanism. But, the specific role of MDMX in p53 inhibition is something of a mystery because a close homolog of MDMX called MDM2 is involved in very similar interactions with p53. The difficulty in deciphering the specific roles of MDMX lie in the fact that to date a specific inhibitor of MDMX has not been identified. That is, inhibitors of MDMX inhibit MDM2 to the same extent so that perturbing MDMX alone (and vice versa) is very difficult.

Our goal in this project is to design an inhibitor of MDMX that would not interact with MDM2. We plan to take advantage of subtle differences between the two proteins in order to design a protein that will be highly specific to MDMX. Hopefully with this protein in hand, research into the role of MDMX will gain a new and important tool.

Over the next few weeks I will submit jobs with the word MDMX in their title to Rosetta @ Home. I\'m very excited to see what comes out!

In the meantime, here\'s some further reading for those who are interested in the intricacies of this important system:
http://en.wikipedia.org/wiki/Mdm2
http://en.wikipedia.org/wiki/P53
http://en.wikipedia.org/wiki/MDM4 (MDMX is also known as MDM4)
14) Message boards : Rosetta@home Science : Design of protein-protein interfaces (Message 66178)
Posted 17 May 2010 by Profile Sarel
Post:
Hello,

As you\'ve seen on David\'s thread a design from your Rosetta @ Home contributions is a tight binder of influenza\'s hemagglutinin protein making it a candidate to serve as an inhibitor and hopefully a therapeutic. This is exceptionally good news. Many thanks to all of the participants!

This news is making us all very excited of course and we are starting to think about the next steps. One promising avenue for future research is to use this computational technology to design specific inhibitors of proteins that are important regulators of cellular activity but where experimental research has been stymied by the lack of specific, non-toxic effectors. Let\'s take a few steps back and try to see the broader picture. Our understanding of molecular biology progresses through the identification of key players and systems in the cell and then by modulating these effectors and observing the results on cell viability and function. This process parallels the concept of reverse engineering of mechanical and electronic systems.

A major tool in this process involves the use of genetic knockouts. These are mutations to genes that disable a protein\'s function. Using this technique myriad gene functions have been described, including genes that are important tumor-suppressors or promoters, metabolite importers and regulators of cell size, form, and fate. But, gene knockouts are not very subtle tools and they often have far-reaching consequences on cell viability, making it difficult to interpret the results of the knockout experiment. For a beautiful and accessible description of the parallels between reverse engineering and molecular biology and where the difficulties lie, see \"Can a Biologist Fix a Radio?\" (Biochemistry (Moscow), Vol. 69, No. 12, 2004, pp. 1403-1406; protein.bio.msu.su/biokhimiya/contents/v69/pdf/bcm_1403.pdf).

One way to deal with these difficulties is by using specific inhibitors that are invoked at specific times to block a certain protein function rather than pulling the brakes on a protein from the cell\'s inception. The ideal inhibitor would selectively modulate one interaction without affecting other interactions, thus allowing a subtle study of the significance of interactions in the cell. Thus specific inhibitors, where they have been discovered and deployed, have yielded very important lessons on the function of proteins that are crucial in many cellular signaling pathways, to give but one example. But, these inhibitors are rare and very difficult to identify. We think that similar to the influenza binder, we should be able to use computational protein design to generate novel and highly specific protein inhibitors of important cellular players and help in elucidating their functions.

Over the next few weeks we will launch new jobs on Rosetta @ Home that target proteins where an inhibitor could help make progress in our understanding of cell biology. As we prepare each of these targets for Rosetta @ Home we will describe the rationale for pursuing them in this thread.

One of these targets is RhoA. This protein belongs to the family of oncogenic Ras proteins which are involved in cell division and regulation. RhoA is known to be a major player in cancer. As mentioned above, knocking out RhoA causes many different problems for cell viability. It is easy to understand why if you merely look at the number and variety of its interaction partners (see, http://en.wikipedia.org/wiki/RHOA)! By generating a specific inhibitor of RhoA we hope to enable probing the effects of its modulation at specific points in the living cycle of the cell and under different conditions -- studies that are nearly impossible to perform today.

Finally, I\'d like to thank all of the participants in Rosetta @ Home for the immense boost in computational throughput over the past few weeks! Without the 40% increase in computational power it would have been impossible for us to work on these targets in parallel to the needs of the group who are working on CASP! Please keep these contribution levels!
15) Message boards : Number crunching : Minirosetta 2.10 (Message 65764)
Posted 17 Apr 2010 by Profile Sarel
Post:
The crashes with bad alloc all come from the same set of runs, which share in common a different type of input file. I\'m not sure what\'s causing the crash so in the meantime, I\'ve eliminated these runs from the queue. Work units that have already been sent out will still run (and it looks like the crashes are rare events) but they should be ending within the next day or two. I\'ll let you know before I relaunch this type of job what was the problem. Thanks, Sarel.
16) Message boards : Number crunching : Minirosetta 2.10 (Message 65737)
Posted 13 Apr 2010 by Profile Sarel
Post:
As David mentioned in his recent posts (see link below), we\'ve recently identified a redesigned protein that binds specifically to influenza. We\'re all very excited about this result and experimental tests are under way. Importantly, this design came from one of the previous batches of ProteinInterfaceDesign protocols that I sent out during January and February and this would not have been possible if it weren\'t for your contributions! I\'m very excited to see whether we can get more designs that bind so effectively to influenza!

The current update has some features that will help us sample different scaffolds more efficiently. I\'ve submitted a small-scale run to Rosetta @ Home to see that all of the protocols run well on your computers and will gradually increase their size over the next few weeks. Please report any problems. Many thanks!

Link to David\'s blog entry: http://boinc.bakerlab.org/forum_thread.php?id=1177&nowrap=true#65709

If you have any questions and comments on the influenza binder please post them here:
http://boinc.bakerlab.org/forum_thread.php?id=4477
17) Message boards : Number crunching : minirosetta 2.05 (Message 65331)
Posted 15 Feb 2010 by Profile Sarel
Post:
Hello, if these are the Protein-interface Design jobs then this is expected since they work with very large complexes of proteins. If you turn on the graphics you\'ll see that the protein systems are much larger than the typical ones on Rosetta @ Home. These jobs are sent out with a requirement for 512Mb of memory to ensure that large-memory jobs are not sent out to low-resource machines.

Best, Sarel.

I am seeing the 2.05 use more memory than previous versions. Up to 160k from ~60-100k.

18) Message boards : Number crunching : minirosetta 2.05 (Message 65160)
Posted 31 Jan 2010 by Profile Sarel
Post:
Rosetta @ Home has produced many very high-quality designs for our Protein-interface design team! So we\'re likely to submit many more jobs to Rosetta @ Home. To help you recognize these jobs, we\'ll add a _Protein_Interface_Design_ note to every job name that is related to these jobs from now on. This way you\'ll be able to follow these jobs. I also hope that this will help you see where the variable-credit issue is coming from more easily.

Hello, yes! The critstubs jobs are of the same sort of unevenly crediting trajectories as the *gbnnotyr*. You can have a look at Eva-Maria Strauch\'s message on the Protein-interface design thread for details.

Some tasks (for exsample type of abinitio_relax_homfrag_natfrag ....) makes a lot of steps up to 200000 - 400000 for 1 model. Is this normal?

And on another type of job (critStubs_profiled_1dnA_...) one of them was abnormally small credits (1.97 cr and 9 decoys for 7k CPU seconds): http://boinc.bakerlab.org/rosetta/result.php?resultid=314040179
While other WUs of the same type considered normal (about ~20 cr and ~80 decoys for the same CPU time).
This is a bug with partial loss of the results of calculations? Or in this type of tasks just is uneven crediting? (As in the tasks type *gbnnotyr*, where the combined \"small\" and \"huge\" models in the same type of tasks)


19) Message boards : Number crunching : minirosetta 2.05 (Message 65159)
Posted 31 Jan 2010 by Profile Sarel
Post:
Hello, yes! The critstubs jobs are of the same sort of unevenly crediting trajectories as the *gbnnotyr*. You can have a look at Eva-Maria Strauch\'s message on the Protein-interface design thread for details.

Some tasks (for exsample type of abinitio_relax_homfrag_natfrag ....) makes a lot of steps up to 200000 - 400000 for 1 model. Is this normal?

And on another type of job (critStubs_profiled_1dnA_...) one of them was abnormally small credits (1.97 cr and 9 decoys for 7k CPU seconds): http://boinc.bakerlab.org/rosetta/result.php?resultid=314040179
While other WUs of the same type considered normal (about ~20 cr and ~80 decoys for the same CPU time).
This is a bug with partial loss of the results of calculations? Or in this type of tasks just is uneven crediting? (As in the tasks type *gbnnotyr*, where the combined \"small\" and \"huge\" models in the same type of tasks)

20) Message boards : Rosetta@home Science : tyrsim_3gbn (Message 65075)
Posted 23 Jan 2010 by Profile Sarel
Post:
Hello,

These are protein-interface design runs, so they have the same objective as in thread:
http://boinc.bakerlab.org/forum_thread.php?id=4477

The difference between these runs and the previous *gbn* runs is the use of a different protocol, in effect, a different algorithm that tries to get at the same problem from a different angle. In general, I use the free-text description field, rather than the name to give a clearer description of the objective of the run, so you can see that these are all \'design of an inhibitor of hemagglutinin\'.

Best, Sarel.

Ive been getting quite a few of these lately, and each has a high model count. Im curious to know what you guys are looking at with these workunits. Could someone explain? Thanks.



Next 20



©2020 University of Washington
http://www.bakerlab.org