[Genome@Home] Wat gaan we doen? deel 2

Pagina: 1
Acties:

  • Cow_tipping
  • Registratie: Oktober 2001
  • Laatst online: 02-03 12:59

Cow_tipping

On the run for D.B.!

Topicstarter
Eerste FAQ van Stanford over de toekomst van Genome.
linkje
Genome@home Classic & Folding@home 3.0:
Frequently Asked Questions (FAQ)
------------------------------------------------------------

Genome@home Classic and Folding@home 3.0:

What exactly is going on here?

The software development effort behind the Genome@home project is merging with the Folding@home team. A scientific "core" executable which runs the same protein design algorithm as the Genome@home project will be included in the Folding@home project, from the release of the F@h3.0 client on. The current Genome@home project will continue, with no major changes, indefinitely, as "Genome@home Classic". Nothing is being taken away from the Genome@home distributed computing project. What's happening is that we are moving our current and future development over to the Folding@home infrastructure and distributed computing project. Very little further development will take place on the original Genome@home infrastructure.

Is Genome@home ending?

No. Not at all. The scientific research effort behind Genome@home is alive and well, stronger than ever. As well, the Genome@home distributed computing project will continue, with no major changes, as "Genome@home Classic". The only difference is that any new software development that we do as part of our research effort will be done as part of the Folding@home project.

What is Genome@home Classic?

The existing Genome@home project will be renamed "Genome@home Classic". This project will continue to run, as is, indefinitely.

I'm a Genome@home user. How will this affect my stats?

It won't affect them at all. The Genome@home project will continue as is, under the new name of "Genome@home Classic". Because the project is simply continuing, the stats will be unaffected. They will not start over from zero; they will continue on from where they are now. If you continue to run the Genome@home client (currently version 0.99), you'll see no differences whatsoever.

I'm a Folding@home user. How will this affect my stats?

It won't affect them at all. The stats for Folding@home will continue on from where they are now, whether you run the F@h2.x client or upgrade to the F@h3.0 client.

I've been Genoming since Day One! Why are you screwing with us?

We're very conscious of how hard many users have worked to help Genome@home be as successful as it is, and that's exactly why we're continuing the project as Genome@home Classic. The project is fairly stable, many users love the project, and the data we get is extremely useful, so there's no reason for us to end it now. We'll continue to support Genome@home Classic as long as the conditions above hold true.

Why are you merging with Folding@home?

The Folding@home project, especially the 2.x infrastructure and it's soon-to-be-released updated 3.0 client, has been the major focus of the Pande Group's software development and methods research efforts over the last three years. The client and server software is more stable, versatile, and advanced than G@h. Most importantly, as the research efforts of the Pande Group broaden and mature, and the Folding@home research project evolves, we need to avoid duplicating the efforts of our researchers. By running all our biomolecular simulations within one infrastructure, we can consolidate the considerable overhead of running distributed computing projects into just one main project.

What is Folding@home 3.0?

F@h3.0 is just the new Folding@home client. It is not a whole new project, like the jump from 1.0 to 2.0. The Folding@home website, stats, servers, etc. will not change. The main difference for the Genome@home research effort is that the F@h3.0 client will be able run a new "scientific core" which contains the Genome@home protein design algorithm. We encourage Genome@home users to switch to the Folding@home project, as this will be the focus of future software development associated with the Genome@home research effort.

Can I nonet/sneakernet with Folding@home3.0?

No, not in the same way as the G@h0.99 client. This is one of the reasons that we're continuing with Genome@home Classic, for all the hardcore nonetters out there!

I don't want to join the Folding@home project. Can I stay exclusively with Genome@home (now G@h Classic)?

Yes, of course. You can run one or the other, or both if you like! We gladly welcome veteran Genomers to stay aboard and new users and teams to join at any time.

Why should I run G@h Classic? Are the results useful?

Yes, the results from G@h Classic are just as useful as those that will come from F@h3.0 and will continue to be so for the duration of the project.

Will my existing or future Genome@home stats count towards Folding@home?

No. The stats for Genome@home (Classic) will have nothing to do with Folding@home stats. Workunits generated by the G@h client (currently version 0.99) will continue to count exclusively towards the Genome@home stats, on this website. Workunits generated by the Folding@home2.x/3.0 clients will count exclusively towards Folding@home stats, no matter what core generated them. For example, workunits generated by the particular F@h3.0 core which runs the G@h protein design algorithm (Core_c9.exe) will count towards the Folding@home stats, and will never enter the G@h Classic system.

Why can't I migrate my existing Genome@home stats over to Folding@home and just combine everything?

This presents several problems. First of all, the way that accounts are identified in the G@h and F@h infrastructures differ, and for users that run both projects, it's impossible to get a one-to-one matching between existing G@h and F@h accounts. If an existing G@h user wanted to create a new F@h account, and migrate their G@h stats over to that account, it would be unfair to existing F@h users who have never run G@h.

Why can't the F@h3.0 workunits generated with the "G@h core" count towards my Genome@home stats?

This presents the same problems as discussed above. As well, we're moving to shift all future research and software development work in the Pande Group to the F@h2.x/3.0 distributed computing infrastructure, and this includes the stats. For consistency, there will be no cross-talk between the G@h Classic and F@h2.x/3.0 infrastructures.

Why don't you do x instead?

Let us know if you have ideas or concerns. Email me (smlarson@stanford.edu) or go to the Genome@home Yahoo forum.

“The first principle is that you must not fool yourself, and you are the easiest person to fool.“


  • NightHawk4
  • Registratie: September 2000
  • Laatst online: 13-05 19:19

NightHawk4

Lotte is Liev :>

Hi,

Just a quick update to address these issues. Our current thinking is that
Genome@h... users will be able to run the F@h... client and have the option
to only recieve G@h... core workunits and have these workunits count towards
the original Genome@h... project stats. This way, Genomers can run the new
client and still stay solely within the Genome@h... project as far as
workunits and user/team stats are concerned. I think this type of solution
would go a long way to addressing many of the concerns we've heard.

Thanks - Stefan
Bron

  • Cow_tipping
  • Registratie: Oktober 2001
  • Laatst online: 02-03 12:59

Cow_tipping

On the run for D.B.!

Topicstarter
Dit is de informatie zoals ze tot nog toe door Stanford (lees Stefan) wordt gebracht.
> We are not asking for merged statistics. (That might be good, or it
> might be bad, but it would be a coding nightmare.) We are not asking
> for you to keep a new statistics system running. (You already said
> the G@H... statistics system would be semi(?)-maintained.)

The existing G@h... (Classic) stats system will be maintained completely as is.

> We >> are << asking that the G@H... routines in new core be given the
> same access to the same statistics that the G@H... uses.
>
> The userids that exists in G@H... want to continue to exist. The teams
> that exists in G@H... want to continue to exist. Ditto for F@H...
> Somebody running the combined client will still have to choose which
> one represents themself.

You've hit the nail on the head here. We've heard, thought about, and
discussed, both within our group and outside, a lot of options (and there
are *countless* permutations) for what to do with stats. Aside from keeping
the F@h... and G@h... clients, stats, and projects completely separate (sort of
our null hypothesis at this point), this approach you've mentioned above
seems to be the most viable alternative. It might be possible to set things
up such that a user could run the F@h... client and have the units generated
by the G@h... core in that client count towards G@h... Classic stats.

> You already said that (at some point) the F@H... client will allow you
> to choose to fold, to design genes, or both. Simply add the option
> that any genes which are designed by F@H... be returned to either the
> F@H... project or to the G@H... project. (I could go look up a quote where
> you already promised to do that. . . ;-) )
>
> You do NOT need to code a new interface, you simply need to port the
> existing one into the new client.
>
> Sure, selecting those options will be essentially the same as running
> G@H... It will, however, demonstrate that the Pande group
> intends to respect the G@H... public (read: G@H... userids and G@H... teams)
> by letting them continue to exist within the new client. It will
> also demonstrate that if the scientifie code has truly been optimized
> to run 20x as fast (which I doubt) or other major improvements are
> made to the science, that the G@H... project should benefit from such
> improvements.

You're right to doubt that the code is 20x times faster, because it's not.
The code in the G@h... core is only marginally faster than the
existing G@h... client. The 10x-20x speedup you're probably referring to is
a new F@h... molecular dynamics algorithm
(http://folding.stanford.edu/FAH3.html).

> This will also provide a soft transition where those who choose to
> migrate to the F@H... statistics engine can do it at their own speed.
> It is important to include the possibility of working both projects
> concurrently with the F@H... client to ease the transition toward a
> unified project.
>
> - Bruce Borden
> = The Genome Collective

This is a very nice way of putting it. A "soft transition" is what we're
aiming for. We're going to make some final decisions about all this on
Monday, so we should have some news then. In the meantime, Bruce, thanks so
much for these insighful comments.

Cheers - Stefan
Dus maandag (hopelijk ;)) meer info over de functies die worden geimplementeerd.

“The first principle is that you must not fool yourself, and you are the easiest person to fool.“


  • Ercewee
  • Registratie: Juli 2000
  • Laatst online: 10-01 11:52

Ercewee

a.k.a. K

Op dinsdag 28 mei 2002 17:55 schreef Cow_tipping het volgende:

[..]

Dus maandag (hopelijk ;)) meer info over de functies die worden geimplementeerd.
maandag? welke maandag? >:)

Bedankt voor de info Cow_tipping. Hopelijk nemen ze snel een beslissing..... Zoals het er nu uitziet, gaat het de goede kant op. :)

50.110 144.300 432.200 1296.200 2320.200 3400.200 10368.200