• Dennis-TW

    von Veröffentlicht: 30.10.2019 11:55
    1. Kategorien:
    2. Projekte

    Es gibt ein neues Projekt bei WCG: Africa Rainfall Project

    Hier ist die deutsche Übersetzung der Beschreibung von WCG:

    Was wäre, wenn dein Computer Simulationen von Regenschauern in Afrika südlich der Sahara durchführen könnte, und diese Simulationen genutzt werden könnten, um Landwirten zu helfen, ihre Ernte erfolgreich anzubauen?

    Problem
    In Afrika südlich der Sahara sind 95 Prozent der Landwirtschaft auf Niederschläge angewiesen, weshalb genaue Wettervorhersagen unerlässlich sind. Da die Niederschläge in diesem Gebiet jedoch oft lokalisiert sind - manchmal fast auf der Ebene nur eines Bauernhofes - ist es schwierig, mit Satellitendaten eine genaue Vorhersage zu treffen, da diese nur größere Wettermuster darstellen.

    Lösungsvorschlag
    Im Rahmen des Africa Rainfall Project werden Forscher der Delft University of Technology hochauflösende Computersimulationen von lokalisierten Regenschauern in Afrika südlich der Sahara erstellen. Da sie die massive gesammelte Rechenleistung der Freiwilligen aus dem World Community Grid nutzen, können sie Simulationen mit einer viel höheren Auflösung durchführen - genau das, was für lokalisierte Regenfälle benötigt wird. Dies wurde noch nie für Regenfälle in dieser Region getan.

    Wenn die Forscher des Africa Rainfall Project die Ergebnisse dieser Simulationen erhalten, werden sie mit Niederschlagsdaten von The Weather Company, Satellitendaten und Bodenbeobachtungen verglichen. Dies wird den Wissenschaftlern helfen, diese Stürme besser zu verstehen und die Vorhersagemodelle zu verbessern. Letztendlich kann dies zu genaueren Niederschlagsvorhersagen für das subsaharische Afrika führen. Dies wiederum könnte den Landwirten rechtzeitigere Informationen über den Zeitpunkt der Pflanzung geben, ihnen helfen, eine Versicherung abzuschließen und gegenüber dem Klimawandel widerstandsfähiger zu werden.

    Wie du helfen kannst
    Als Freiwilliger von World Community Grid lädst du ein sicheres Softwareprogramm auf deinen Computer herunter. Und wenn dein Computer im Leerlauf ist oder nicht seine volle Rechenleistung nutzt, führt er ein simuliertes Experiment im Hintergrund durch. Dann kontaktiert dein Computer den World Community Grid Server, um ihm mitzuteilen, dass er die Simulation abgeschlossen hat, die dann auf unseren Server hochgeladen wird. All dies geschieht unauffällig, während du deine normalen Aktivitäten nachgehst, z.B. das Schreiben einer E-Mail, das Surfen im Internet oder während dein Computer im Leerlauf ist, aber eingeschaltet bleibt.

    World Community Grid empfängt die Ergebnisse, die du zurücksendest (oft als Arbeitseinheiten oder Forschungsaufgaben bezeichnet), kombiniert sie mit Hunderttausenden von Ergebnissen anderer Freiwilliger auf der ganzen Welt und sendet sie an das Delfter Forschungsteam. Die Forscher beginnen dann mit der schwierigen Arbeit der Datenanalyse. Obwohl dieser Prozess immer noch Jahre dauern kann, wird er dennoch beschleunigt, da er ansonsten Jahrzehnte dauern würde oder sogar unmöglich wäre.

    "Dies ist das erste Mal, dass wir den größten Teil Afrikas für eine ganze Regenzeit kartieren können, was auf dieser Lösungsebene noch nie zuvor geschehen ist", sagt Professor Nick van de Giesen, leitender Forscher des Africa Rainfall Project.

    Werde noch heute Mitglied im World Community Grid, damit du und dein Computer dazu beitragen können, diese äußerst wichtige Forschung zu beschleunigen.

    Badges: usw.

    Bitte beachten!

    Aufgrund höherer Systemanforderungen (laut WCG ca. 1 GB RAM und 1,5 GB Speicherplatz pro WU) ist per Standard nur die Berechnung von jeweils 1 WU eingestellt. Wenn man mehr als 1 WU gleichzeitig rechnen möchte, so kann dies nach der Anmeldung auf der WCG Seite unter

    - "Settings" (oben rechts)
    - "Device Manager" (linke Seite)
    - Klick auf das entsprechende Geräteprofil (meist "Default")
    - Weit herunterscrollen bis "Project Limits"
    - Einstellung der Anzahl der gewünschten WUs in der Auswahlliste neben Africa Rainfall Project

    eingestellt werden.
    von Veröffentlicht: 13.10.2019 17:00
    1. Kategorien:
    2. Projekte

    FightAIDS@Home - Phase 2 - Originaltext

    Ich habe gerade unseren monatlichen Anruf mit dem FAAH2 Forschungsteam abgeschlossen.

    1. Sie sind fast vollständig mit den aktuellen Arbeitseinheiten fertig und bereit, die Analyse der von WCG erhaltenen Daten zu beginnen.
    2. Für diese aktuelle Gruppe von Arbeitseinheiten sind noch etwa 1-2 Wochen Arbeit (GESCHÄTZT) übrig. Sobald sie ausgelaufen sind, gibt es eine Pause. An dieser Stelle sind wir uns nicht sicher, wie lange die Pause dauern wird.
    3. Ihr Analyseprozess wird wahrscheinlich einige Wochen dauern, wenn alles reibungslos läuft. Der Zweck der Analyse ist es zu sehen, ob sie die Andockziele weiter verfeinern können.
    4. Die FAAH1 Forscher könnten weitere Ziele an die FAAH2 Forscher senden, die in Zukunft mit WCG betrieben werden könnten (sie waren während der Telefonkonferenz dieses Monats nicht anwesend). Die beiden Gruppen werden sich in den nächsten Wochen in Verbindung setzen.

    Status der Arbeitseinheiten am 9. Oktober:

    In Bearbeitung: 99.883 Arbeitseinheiten
    Abgeschlossen: 3.878.277 in den letzten 30 Tagen - 12.9276 Durchschnitt pro Tag


    Help Stop Tuberculosis - Originaltext

    Wir haben gerade unseren monatlichen Anruf mit dem HSTB Forschungsteam abgeschlossen.

    1. Das WCG-Technologieteam diskutierte mit den Wissenschaftlern andere Einsatzmöglichkeiten von Gromacs (die Software, die die Forscher für das Projekt verwenden) und erhielt ihre Meinung darüber, wie Gromacs möglicherweise für andere ehrenamtliche Computerprojekte eingesetzt werden könnte. (Wir haben keine solchen Projekte in Arbeit, wir hatten in der Vergangenheit nur Fragen von anderen Wissenschaftlern.)
    2. Wir haben auch über die laufende Suche nach einem weiteren Teammitglied gesprochen, was dadurch erschwert wird, dass die Bewerbungen für Doktoranden- und Postdoc-Stellen um ~75 Prozent gesunken sind. Wir hoffen, dass es bald gute Nachrichten gibt!

    Status der Arbeitseinheiten am 9. Oktober:

    In Bearbeitung: 62 Batches (6.200 Arbeitseinheiten)
    Abgeschlossen: 22.503 Batches - 139 in den letzten 30 Tagen - durchschnittlich 4,6 pro Tag


    Mapping Cancer Markers - Originaltext

    Wir hatten heute unseren monatlichen Anruf mit dem MCM Forschungsteam.

    1. Sie haben einen Entwurf des Datensatzes für Sarkom Arbeitseinheiten und hoffen, uns einige Testarbeitseinheiten irgendwann nächste Woche zu schicken. Sobald wir sie erhalten haben, wird das WCG-Team im Laufe dieses Monats Alpha-Tests an dieser Einheit durchführen. Wir werden jeden wissen lassen, wenn sie in den Beta-Test geht, hoffentlich im November.
    2. Wir informierten sie über ein neues Team, das von einem Teenager in den USA mit einem ambitionierten Rechenziel gegründet wurde.
    3. Wir diskutierten, auf welche Krebsarten sich das Projekt in Zukunft nach Abschluss der Sarkomarbeit konzentrieren könnte. Die Forscher sind noch nicht kurz davor, Entscheidungen zu treffen - nur ein sehr frühes Brainstorming. Sie werden wahrscheinlich einen Krebs wählen, der mit den Krebsarten zusammenhängt, die sie bereits untersucht haben (Lunge, Eierstock und Sarkom).

    Status der Arbeitseinheiten am 9. Oktober:

    Verfügbar zum Download: 212 Batches
    In Bearbeitung: 812 Batches (6.102.542 Arbeitseinheiten)
    Abgeschlossen: 54.052 Batches - 758 in den letzten 30 Tagen - durchschnittlich 25,3 pro Tag
    Geschätzter Überhang: ca. 8 Tage


    Microbiome Immunity Project - Originaltext

    Hier sind Notizen aus dem heutigen monatlichen Gespräch mit den MIP Forschern.

    1. Sie arbeiten daran, mehr Batches zu erstellen - in der Regel möchten sie mindestens 2.000 zum Herunterladen zur Verfügung haben, aber sie möchten in Zukunft einen größeren Überhang haben. Der erste Schritt (an dem sie arbeiten) besteht darin, mehr Ziele zu erzeugen, um sie zu betrachten.
    2. Sie legen einen informellen Bericht auf einem Pre-Print-Server (keine offizielle Publikation) auf, der einen Überblick darüber gibt, wie die Forscher die MIP-Daten nutzen wollen. Sobald der Bericht fertig ist, werden wir ihn im MIP-Forum veröffentlichen. Dieser Bericht gilt als Vorwort (oder Einführung) zu den drei formalen Berichten, über die sie in ihren Projekt-Updates gesprochen haben.
    3. Die drei kommenden Berichte werden sich mehr auf die Vorhersage der Proteinfunktion und die Biologie konzentrieren.
    4. Der Forscher in Polen hielt vor einigen Wochen bei einem lokalen Treffen einen hochrangigen Vortrag über das Projekt.

    Aktualisierung des Fortschritts der Arbeitseinheit (Stand 1. Oktober):
    Verfügbar zum Download: 1.730 Batches*
    In Bearbeitung: 9.925 Batches (16.285.432 Arbeitseinheiten)
    Abgeschlossen: 22.1948 Batches gesamt, 7.749 in den letzten 30 Tagen, 258/Tag durchschnittlich

    *HINWEIS - Die Forscher bauen mehr Batches - das ist nur die Zahl, die zum Zeitpunkt dieses Beitrags zum Download zur Verfügung steht. Die Forscher haben keine Schätzung, wie viele Gesamtbatches sie für das Projekt einreichen werden.


    OpenZika - Originaltext

    Wir hatten heute unseren monatlichen Anruf mit dem Forschungsteam.

    1. Die Forscher bestätigten, dass sie die letzten Arbeitseinheiten an uns geschickt haben. Basierend auf den geschätzten Prognosen unseres Technikteams sind etwa zwei Wochen Arbeit vorhanden.
    2. Einer der Forscher wird Anfang Dezember auf einer Konferenz in den USA sprechen.
    3. Sie haben mehrere Berichte in Arbeit - meist in der Schreibphase.
    4. Sie machen Pläne für die Analyse ihrer Daten - das Projekt hat eine riesige Menge an Informationen produziert.

    Status der Arbeitseinheit (Stand 14. Oktober):

    Verfügbar zum Download: 0
    In Bearbeitung: 6.807 Batches (7.753.614 Arbeitseinheiten)
    Abgeschlossen: 457.567 Batches - 6.155 Batches in den letzten 30 Tagen - durchschnittlich 205 pro Tag


    Smash Childhood Cancer - Originaltext

    Unser monatliches Gespräch mit den Forschern ist gerade beendet worden.

    1. Das Forschungsteam hat vorläufig ein neues Ziel ausgewählt, das mit Hilfe von WCG untersucht werden soll. Das neue Ziel könnte für eine Reihe von Keimzelltumoren vielversprechend sein. Wir werden weitere Informationen zur Verfügung stellen, sobald wir sie von den Forschern erhalten. Die nächsten Schritte sind die Fertigstellung der Zielauswahl, der Aufbau erster Arbeitseinheiten, Alpha-Tests, Beta-Tests und die Freigabe von Arbeitseinheiten an alle Freiwilligen, die sich für das Projekt angemeldet haben.
    2. Die Forscher beantragen einen kleinen Zuschuss, um die Kosten für die Arbeit an dem neuen Ziel zu decken, und das WCG-Team wird ein Unterstützungsschreiben für ihren Antrag schicken. (Dies geschieht häufig bei aktiven Forschungsprojekten).
    3. Sie bereiten sich darauf vor, Labortests an einigen vielversprechenden Substanzen durchzuführen - dies befindet sich im Kauf- und Genehmigungsstadium.

    Status der Arbeitseinheit am 9. Oktober:

    21 Batches (78.1641 Arbeitseinheiten)
    Abgeschlossen: 3.665 Batches - 302 in den letzten 30 Tagen - durchschnittlich 10 pro Tag
    von Veröffentlicht: 06.04.2019 08:00
    1. Kategorien:
    2. Projekte

    Die Entwicklung der GPU-Anwendung hat zu einer signifikanten Optimierung der CPU-Anwendung geführt, wodurch nun im Umkehrschluss die typische GPU nur noch so schnell wie zwei bis drei CPU-Kerne und daher weniger effizient ist.

    Neuigkeiten zur GPU-Anwendung
    In der letzten Woche hat es einige neue Entwicklungen gegeben. Sie sind sowohl gut als auch schlecht.

    Zuerst einmal etwas Geschichte. Der Grund, warum ich so lange gewartet habe, um eine GPU-App zu entwickeln, ist, dass die Berechnung stark von Multipräzisionsbibliotheken (gmp) und zahlentheoretischen Bibliotheken (pari/gp) abhängig war. Beide verwenden dynamisch zugewiesenen Speicher, was bei GPUs ein großes Tabu ist. Ich fand online eine Multi-Präzisionsbibliothek, die ich verwenden konnte, indem ich die Genauigkeit bis zum maximal erforderlichen Wert (ca. 750 Bit) fest kodierte und so die Abhängigkeit von Speicherzuweisungen beseitigte. Das nächste Teil des Puzzles bestand darin, eine polynomale Diskriminanzfunktion zu kodieren. Danach konnte ich endlich einen Kernel für die GPU kompilieren. Das ist die Historie für die aktuelle GPU-App. Sie ist etwa 20 bis 30 mal schneller als die aktuelle CPU-Version (abhängig von WU und CPU/GPU-Geschwindigkeiten).

    Aber dann dachte ich nach.... mein GPU polynomialer Diskriminanzalgorithmus unterscheidet sich von dem in der PARI-Bibliothek (ihrer funktioniert für jeden Grad und meiner ist auf Grad 10 spezialisiert). Um also einen direkten Vergleich zu machen, habe ich den PARI-Algorithmus durch meinen in der CPU-Version des Codes ersetzt. Ich war schockiert von dem, was ich fand.... die CPU-Version war jetzt etwa 10x schneller als früher. Ich hätte nie gedacht, dass ich in der Lage wäre, einen Algorithmus zu schreiben, der 10x schneller wäre als eine gut etablierte Bibliotheksfunktion. WTF? Jetzt trete ich mir in den Hintern, weil ich das nicht früher gemacht habe!

    Das bringt gemischte Emotionen mit sich. Auf der einen Seite ist es toll, dass ich jetzt eine CPU-Version habe, die 10x schneller ist. Aber es bedeutet auch, dass mein GPU-Code totaler Mist ist. Mit all der Leistung in einer heutigen GPU würde ich erwarten, dass sie mindestens 10x schneller ist als die entsprechende CPU-Version. Im Vergleich zur neuen CPU-Version ist die GPU nur 2 bis 3 mal schneller. Das ist inakzeptabel.

    Der neue Plan sieht also wie folgt aus:
    1. Neue CPU-Ausführungsdateien bereitstellen. Da sie um das 10-fache schneller sind, muss ich die Credits um den Faktor 10 reduzieren. (Die Credits pro Stunde bleiben für die CPU gleich, fallen aber für die GPU offensichtlich ab).
    2. Entwicklung neuer und verbesserter GPU-Kernel.

    Ich kann es den GPU-Benutzern nicht verübeln, dass sie an dieser Stelle das Schiff verlassen haben. Offen gesagt, die Ineffizienz der aktuellen GPU-App macht es einfach nicht wert (für sie oder das Projekt).

    Wie dem auch sei, ich hatte openCL-Versionen gebaut. Die Nvidia-Version funktioniert perfekt. Die AMD-Version ist aus irgendeinem Grund fehlerhaft, ebenso wie die Windows-Version. Da ich die Kernel sowieso ändern werde, hat es keinen Sinn, sie noch zu debuggen.
    06.04.2019, 00:40:01 MEZ

    Originaltext:
    Zitat Zitat von https://numberfields.asu.edu/NumberFields/forum_thread.php?id=366
    GPU app status update
    So there have been some new developments over the last week. It's both good and bad.

    First of all, some history. The reason I waited so long to develop a GPU app is because the calculation was heavily dependent on multi-precision libraries (gmp) and number theoretic libraries (pari/gp). Both of these use dynamically allocated memory which is a big no-no in GPUs. I found a multi-precision library online that I could use by hard coding the precision to the maximum required (about 750 bits), thereby removing the dependence on memory allocations. The next piece of the puzzle was to code up a polynomial discriminant function. After doing this, I could finally compile a kernel for the GPU. That is the history for the current GPU app. It is about 20 to 30 times faster than the current cpu version (depends on WU and cpu/gpu speeds).

    But then I got thinking... my GPU polynomial discriminant algorithm is different from the one in the PARI library (theirs works for any degree and mine is specialized to degree 10). So to do a true apples-to-apples comparison, I replaced the PARI algorithm with mine in the cpu version of the code. I was shocked by what I found... the cpu version was now about 10x faster than it used to be. I never thought I was capable of writing an algorithm that would be 10x faster than a well established library function. WTF? Now I'm kicking myself in the butt for not having done this sooner!

    This brings mixed emotions. On one side, it is great that I now have a cpu version that is 10x faster. But it also means that my GPU code is total crap. With all the horsepower in a present day GPU I would expect it to be at least 10x faster than the equivalent cpu version. Compared with the new cpu version, the gpu is only 2 to 3 times faster. That is unacceptable.

    So the new plan is as follows:
    1. Deploy new cpu executables. Since it's 10x faster, I will need to drop the credit by a factor of 10. (Credits/hour will remain the same for the cpu but will obviously drop for the GPU)
    2. Develop new and improved GPU kernels.

    I don't blame the GPU users for jumping ship at this point. Frankly, the inefficiency of the current GPU app just makes it not worth it (for them or the project).

    For what it's worth, I did have openCL versions built. Nvidia version works perfectly. The AMD version is buggy for some reason, as is the windows version. Since I will be changing the kernels anyways, there is no point in debugging them yet.
    5 Apr 2019, 23:40:01 UTC
Single Sign On provided by vBSSO