Hello Troels Nørgaard,

You are right to worry about too many simultaneous projects slowing down the timely completion of projects, reducing our usefulness. But there is another counter-balancing worry. What happens if, shortly after starting a new project with a newly-written program, one of the scientists suddenly discovers a basic flaw in the methodology of the program? One requiring a partial rewrite that will take 6 weeks to code up and test? Nightmares like this are not unknown in scientific programs. With only one project running, all our options in this case are extremely distasteful.

By comparison, the disadvantages of multiple projects seem trivial. And nelsoc has pointed out a major advantage. Offering projects in multiple areas will draw far more members than any one project will interest. So it is win-win if we commit to several projects. If we try running too many projects at once, I expect that this will be announced by loud screams from the back office area.

mycrofth

There will be a project preference button appear as soon as multiple projects become available sometime within the next few weeks.

Some of the projects coming down the road will not be as long running as the Human Proteome Folding project, so that should help balance things. Additionally, some projects will require more memory, disk space or CPU speed, and other projects will require less. Eventually, we hope to schedule work units based on machine capability. In addition the Linux versions of the project may not launch simultaneously with the Windows versions, so there may be some number of weeks skew there. All of this would leave schedule gaps, which should be filled better by running multiple projects.

In part, this will be a learning experience in balancing everything while running the grid as efficiently as possible.