• Projekte

    von Veröffentlicht: 07.08.2019 07:10
    1. Kategorien:
    2. Projekte

    Eine neue Version der GPU-Anwendungen behebt ein Problem, das dazu führen konnte, dass große Teile der WU auf CPU berechnet werden:

    neue Version der GPU-Anwendungen
    Ich habe festgestellt, dass die bisherige Version der GPU-Anwendungen beim Datensatz 15x271 sehr langsam war. Ich habe das Problem gefunden - ein großer Teil der Diskriminanten war zu groß für die fest programmierte Genauigkeit. Wenn das passiert, übergibt die GPU an die CPU, um damit umzugehen. Daher verbrachte die GPU mehr Zeit im Leerlauf, während sie darauf wartete, dass die CPU die Aufgabe beendet. Als Nebeneffekt konnten die WUs auch fast einen ganzen CPU-Kern nutzen.

    Ich habe die fest programmierte Genauigkeit erhöht und mit den schwierigen Datensätzen sowie dem neuesten Datensatz 16x271 getestet. Das Problem scheint behoben, aber bitte meldet etwaiges unerwartetes Verhalten.
    07.08.2019, 6:39:56 MEZ

    Originaltext:
    Zitat Zitat von https://numberfields.asu.edu/NumberFields/forum_thread.php?id=396
    new GPU app versions
    I was noticing a slow down with the GPU app versions on the 15x271 data set. I found the problem - a large fraction of the discriminants were exceeding the hard coded precision. When this happens the GPU kicks it back to the CPU to handle. As a result, the GPU spent more time idling as it waited on the CPU to finish the task. A side effect of this was that the WU would also use almost an entire CPU core.

    I increased the hard coded precision and tested on the troublesome data sets as well as the newest 16x271 data set. The issue seems to be fixed, but please report any unexpected behavior.
    7 Aug 2019, 5:39:56 UTC
    von Veröffentlicht: 30.07.2019 13:00
    1. Kategorien:
    2. Projekte

    Nur kurz ist die Pause nach der vorigen Challenge, hoffentlich aber genug Zeit, dass die Temperaturen wieder in einen ähnlich angenehmen Bereich fallen. Die August-Challenge ist Lennart Vogel gewidmet, ohne dessen Arbeit in früheren Jahren PrimeGrid nicht das wäre, was es heute ist, und der hoffentlich in diesen Tagen seinen 65. Geburtstag feiert.

    Lennart Vogel Honorary Challenge
    Beginn: 03.08.2019, 00:00 UTC = 01:00 MEZ = 02:00 MESZ
    Ende: 10.08.2019, 00:00 UTC = 01:00 MEZ = 02:00 MESZ
    Subprojekt: Extended Sierpinski Problem LLR (ESP)


    Der offizielle Thread zur Challenge im PrimeGrid-Forum ist hier zu finden.

    Es zählen für diese Challenge nur WUs des Subprojekts Extended Sierpinski Problem LLR (ESP), die nach dem 03.08. um 02:00 Uhr heruntergeladen und vor dem 10.08. um 02:00 Uhr zurückgemeldet werden! Das gewünschte Subprojekt kann in den PrimeGrid-Einstellungen festgelegt werden.

    Anwendungen gibt es für Windows, Linux und MacOS (Intel), jeweils 32- und 64-Bit. Wer in den letzten Monaten keine WUs von einem PrimeGrid-LLR-Subprojekt berechnet hat, sollte dies vielleicht schon vor der Challenge mit kleineren WUs wie SGS nachholen, um die relativ große Anwendung (~35 MB) bereits auf dem Rechner zu haben.

    Die verwendete LLR-Anwendung belastet die CPU sehr stark und toleriert keinerlei Fehler. Daher bitte nicht zu stark übertakten und auf gute Kühlung achten!

    Die Laufzeiten liegen auf aktuellen CPUs im Bereich von einigen Stunden, sofern mehrere CPU-Kerne an einer WU arbeiten, was auf den meisten Rechnern auch im Hinblick auf die Effizienz zu empfehlen ist. Das lässt sich mit einer app_config.xml erreichen (im Beispiel für 4 Kerne):
    Code:
    <app_config>
      <app_version>
        <app_name>llrESP</app_name>
        <cmdline>-t 4</cmdline>
        <avg_ncpus>4</avg_ncpus>
      </app_version>
    </app_config>
    Dieser Text muss als app_config.xml im Unterverzeichnis projects\www.primegrid.com des BOINC-Datenverzeichnisses (unter Windows standardmäßig C:\ProgramData\BOINC) gespeichert werden. Die Einstellung wird durch Konfigurationsdatei einlesen oder Neustart für neue WUs übernommen.

    In jedem Fall haben moderne Intel-CPUs durch die automatisch benutzten Optimierungen (AVX, FMA3, AVX-512) einen erheblichen Vorteil. CPUs, die Hyperthreading unterstützen, laufen oft effizienter, wenn Hyperthreading nicht benutzt wird.

    Die Punkte für die Challenge-Statistik sind identisch mit den BOINC-Credits, werden jedoch sofort gutgeschrieben, während die BOINC-Credits erst vergeben werden, wenn das Quorum von 2 übereinstimmenden Ergebnissen erreicht ist.

    Team-Stats bei PrimeGrid
    User-Stats bei PrimeGrid

    Team-Stats bei SETI.Germany
    Detail-Statistik für SETI.Germany
    User-Stats bei SETI.Germany

    Zum Diskussionsthread
    von Veröffentlicht: 28.07.2019 22:55
    1. Kategorien:
    2. Projekte

    In Vorbereitung eines kommenden Fachartikels stellt das Projekt nun eine Datenbank der Simulationsergebnisse für Populationen Schwarzer Löcher in unterschiedlichen Umgebungen bereit:

    Ergebnisdatenbanken
    Nach der letzten Server-Aktualisierung habe ich auch Netzwerkspeicher mit Ergebnisdatenbanken vorbereitet.
    Hier ist die Ergebnisseite, auf welcher ihr alle von unserem Projekt bearbeiteten Daten herunterladen könnt.
    26.07.2019, 18:12:14 MEZ

    Originaltext:
    Zitat Zitat von https://universeathome.pl/universe/forum_thread.php?id=436
    Results databases
    After last server update I have also prepared NFS based folders with results databases.
    So, here is rsults page where you can download all processed data from our project.
    26 Jul 2019, 17:12:14 UTC
    von Veröffentlicht: 28.07.2019 22:45
    1. Kategorien:
    2. Projekte

    Eine zu aggressiv eingestellte serverseitige Firewall kann derzeit für Verbindungsprobleme zum Projekt sorgen. Wer geblockt wurde, kann zwar manuell entsperrt werden, das dürfte aber praktisch nur für Teilnehmer mit fester IP-Adresse sinnvoll sein.

    Schwarze Liste der Firewall
    Ich wurde darauf aufmerksam gemacht, dass einige Teilnehmer auf die Schwarze Liste des Firewall-Systems der Universität gelandet sind. Das bedeutet üblicherweise, dass der Teilnehmer keine Aufgaben herunterladen oder sich auch nur mit der Webseite verbinden kann.

    Wir versuchen derzeit, die Einschränkungen der Firewall zu verringern, damit das nicht mehr passiert. In der Zwischenzeit kann ich als Notlösung die IT-Abteilung bitten, einzelne IP-Adressen auf die Weiße Liste zu setzen.

    Falls ihr oder jemand, den ihr kennt, Verbindungsprobleme habt, lasst es mich wissen, damit ich euch auf die Weiße Liste setzen lassen kann.
    27.07.2019, 3:07:06 MEZ

    Originaltext:
    Zitat Zitat von https://numberfields.asu.edu/NumberFields/forum_thread.php?id=389
    firewall black listing
    It has come to my attention that some users have been black listed by the university firewall system. This usually means that the volunteer cant download tasks or even connect to the website.

    We are currently looking at ways to reduce the firewall restrictions so this will stop happening. In the meantime, the work around is for me to request the IT department to white list an IP address on an individual basis.

    If you or someone you know is experiencing connection problems, please let me know so I can have them added to the white list.
    27 Jul 2019, 2:07:06 UTC
    von Veröffentlicht: 28.07.2019 22:25
    1. Kategorien:
    2. Projekte

    Eine Nachricht vom Tomáš Brada Experimental Grid beschreibt die technischen Abläufe des laufenden Subprojekts zu pseudo-assoziativen diagonalen lateinischen Quadraten (engl. pseudo-associative diagonal Latin squares, PADLS):

    Subprojekt PADLS Total läuft einwandfrei
    Besser spät als nie. Das in diesem Thread beschriebene PADLS-Total-Experiment (russ.) läuft einwandfrei auf diesem Server und produziert gute Ergebnisse.

    Technischer Hintergrund: Der Suchbereich wurde in sogenannte Segmente aufgeteilt. Aus jedem Segment wird eine WU erzeugt. Die WUs können beliebig groß sein, derzeit sind sie so eingestellt, dass sie etwa zwei Stunden auf meinem Rechner laufen. Sobald das Ergebnis einer WU an den Server gemeldet wird, greift das Validator-Programm es auf. Das Programm überprüft die Gültigkeit des Ergebnisses, speichert das Ergebnis in der Datenbank und erzeugt eine neue WU, um das Segment weiter zu bearbeiten.

    Die Ergebnisse werden zweimal am Tag exportiert und können als Text- oder SQL-Datei heruntergeladen werden.

    Der Suchalgorithmus ist nicht der effizienteste, gibt aber vernünftige Ergebnisse. Es wurde angeregt, das Subprojekt auf dem Server boinc.Progger.info zu installieren.
    25.07.2019, 9:37:19 MEZ

    Originaltext:
    Zitat Zitat von https://boinc.tbrada.eu/forum_thread.php?id=3039
    Padls Total subproject running fine
    Better late than never. The PADLS Total experiment described in this thread is running fine on this server and is producing good results.

    Technical: the search space has been split to so called segments. From each segment one workunit is generated. The workunits can be made any size, but are currently set to run approximately two hours on my computer. Once result of a workunit is returned to the server, it is picked up by the validator program. This program checks the result validity, saves the result into the database and generates a new workunit to continue processing the segment.

    Results are exported twice a day in, and they are available for download as text or sql.

    The search algorithm is not the most efficient, but gives reasonable results. A effort was initiated to install the subproject over at boinc.Progger.info server.
    25 Jul 2019, 8:37:19 UTC
    von Veröffentlicht: 21.07.2019 08:45
    1. Kategorien:
    2. Projekte

    Am morgigen Montag, den 22. Juli, werden einige Teile der Projektinfrastruktur neu gestartet, was dazu führen wird, dass laufende WUs des Subprojekts CMS Simulation abbrechen werden. Der zuständige Administrator rät daher dazu, rechtzeitig keine neuen Aufgaben mehr herunterzuladen:

    CMS@Home-Unterbrechung am Montag, den 22. Juli
    Ich habe die folgende Nachricht aus der CERN/CMS-IT-Abteilung bekommen:

    >> als Folge der Hypervisor-Neustartserie, die von der CERN-IT hier angekündigt wurde: https://cern.service-now.com/service...o?n=OTG0051185
    >> werden die folgenden Virtuellen Maschinen, die zum CMS-Production-Openstack gehören, am Montag, den 22. Juli ab 08:30 MESZ neu gestartet:
    ...
    >> | vocms0267 | cern-geneva-b | cms-home

    worauf ich antwortete:
    > Danke Alan. Auf vocms0267 läuft das CMS@Home-Projekt. Sollte ich die Freiwilligen vor der Unterbrechung warnen oder wird das eher unsichtbar verlaufen?

    und diese Antwort erhielt:
    Laufende Aufgaben werden fehlschlagen, da sie sich nicht mit dem schedd-condor_shadow-Dienst verbinden können. Das wird die für die Teilnehmer sichtbare Auswirkung sein. Es wird auch ein kurzes Zeitfenster geben (bis ich den Software-Agenten neu gestartet habe), in welchem keine ausstehenden Aufgaben im Condor-Pool sein werden.
    Also könnte es sinnvoll sein, die Teilnehmer zu informieren.

    Meine Empfehlung ist daher, dass ihr ab Sonntagnachmittag keine neuen Aufgaben von CMS@Home zulasst, damit die laufenden Aufgaben vor dem Neustart um 08:30 MESZ fertig werden. Ich lasse euch wissen, sobald Alan mich informiert, dass vocm0267 wieder läuft.
    17.07.2019, 14:14:12 MEZ

    Originaltext:
    Zitat Zitat von https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5087
    CMS@Home disruption, Monday 22nd July
    I've had the following notice from CERN/CMS IT:

    >> following the hypervisor reboot campaign, as announced by CERN IT here: https://cern.service-now.com/service...o?n=OTG0051185
    >> the following VMs - under the CMS Production openstack project - will be rebooted on Monday July 22 (starting at 8:30am CERN time):
    ...
    >> | vocms0267 | cern-geneva-b | cms-home

    to which I replied:
    > Thanks, Alan. vocms0267 runs the CMS@Home campaign. Should I warn the volunteers of the disruption, or will it be mainly transparent?

    and received this reply:
    Running jobs will fail because they won't be able to connect to the schedd condor_shadow process. So this will be the visible impact on the users. There will be also a short time window (until I get the agent restarted) where there will be no jobs pending in the condor pool.
    So it might be worth it giving the users a heads up.

    So, my recommendation is that you set "No New Tasks" for CMS@Home sometime Sunday afternoon, to let tasks complete before the 0830 CST restart. I'll let you know as soon as Alan informs me that vocm0267 is up and running again
    17 Jul 2019, 13:14:12 UTC
    von Veröffentlicht: 20.07.2019 18:30
    1. Kategorien:
    2. Projekte

    Rosetta@home hat zu zwei neuen Veröffentlichungen beigetragen, die an dieser Stelle nicht vorenthalten werden sollen.

    Koevolution im Proteombereich
    Letzte Woche wurde in der Zeitschrift Science ein Bericht veröffentlicht, der die Identifizierung von Hunderten von bisher nicht charakterisierten Protein-Protein-Interaktionen bei E. coli und dem pathogenen Bakterium M. tuberculosis beschreibt. Dazu gehören sowohl bisher unbekannte Proteinkomplexe als auch bisher nicht charakterisierte Komponenten bekannter Komplexe. Diese Forschung wurde von Qian Cong geleitet, dessen Team auch der ehemalige Baker-Laborabsolventen Sergey Ovchinnikov, heute John Harvard Distinguished Science Fellow in Harvard, angehört. Rosetta@home wurde für einen Großteil der für diese Arbeit erforderlichen Datenverarbeitung verwendet. Herzlichen Glückwunsch und Dank an alle R@h-Freiwilligen.

    Für weitere Informationen über diese Arbeit klicken Sie bitte hier.

    Originaltext:
    Zitat Zitat von https://boinc.bakerlab.org/rosetta/forum_thread.php?id=13197#90911
    Last week, a report was published in Science describing the identification of hundreds of previously uncharacterized protein–protein interactions in E. coli and the pathogenic bacterium M. tuberculosis. These include both previously unknown protein complexes and previously uncharacterized components of known complexes. This research was led by postdoctoral fellow Qian Cong and included former Baker lab graduate student Sergey Ovchinnikov, now a John Harvard Distinguished Science Fellow at Harvard. Rosetta@home was used for much of the computing required for this work. Congratulations and thank you to all R@h volunteers.

    For more information about this work click here.



    Protein-Arrays auf mineralischen Oberflächen
    Letzte Woche veröffentlichte das Baker Lab in Zusammenarbeit mit dem De Yoreo Labor bei PNNL einen Bericht in Nature, der das Design von synthetischen Proteinarrays beschreibt, die sich auf der Oberfläche von Glimmer, einem gewöhnlichen und außergewöhnlich glatten kristallinen Mineral, zusammensetzen. Diese Arbeit bietet eine Grundlage für das Verständnis, wie Protein-Kristall-Interaktionen systematisch programmiert werden können. Obwohl R@h nicht direkt für diese Forschung verwendet wurde, wurden zuvor entworfene Untereinheiten mit R@h validiert. Herzlichen Glückwunsch an alle R@h-Freiwilligen und vielen Dank für Ihre kontinuierlichen Beiträge.

    Für weitere Informationen klicken Sie bitte hier.

    Originaltext:
    Zitat Zitat von https://boinc.bakerlab.org/rosetta/forum_thread.php?id=13196
    Last week, the Baker Lab in collaboration with the De Yoreo lab at PNNL published a report in Nature describing the design of synthetic protein arrays that assemble on the surface of mica, a common and exceptionally smooth crystalline mineral. This work provides a foundation for understanding how protein-crystal interactions can be systematically programmed. Although R@h was not directly used for this research, previously designed subunits were validated using R@h. Congratulations to all R@h volunteers and thank you for your continued contributions.

    For more details click here.
    von Veröffentlicht: 20.07.2019 11:45
    1. Kategorien:
    2. Projekte

    Die bekannte BOINC-Statistiksammlung BOINCstats und die daran angeschlossene Kontenverwaltung BAM! kommen seit heute in neuem Gewand daher. Das neue Design ist für Geräte mit kleineren Betatsch-Bildschirmen optimiert, leider ist die Möglichkeit entfallen, andere Sprachen als Englisch einzustellen (wobei diese in vielen Fällen kaum gepflegt wurden und die deutschsprachige Version von Sänger hier auch oft verschmäht wurde).

    Die neue BOINCstats-Webseite ist da!
    Die neue BOINCstats-Webseite ist da!

    Wie ihr seht, wurde die BOINCstats-Webseite gründlich erneuert. Das Design ist komplett neu und funktioniert hervorragend auf Mobiltelefonen und Tablets. Die Sicherheit wurde verbessert, die Seiten und Formulare wurden optimiert. Es ist eine große Änderung, aber die meisten Seiten können an der gleichen Stelle wie bisher gefunden werden.

    Angepasste Sprachen werden nicht mehr unterstützt, die meisten wurden nicht vernünftig gepflegt. Für diejenigen, die wirklich eine übersetzte Version benötigen, könnte eine browserinterne Übersetzung ausreichen. Für Niederländisch fand ich das recht anständig.

    Ich hoffe, dass es euch gefällt, aber falls ihr euch wirklich nicht mit dem neuen Design anfreunden könnt, ist die alte Version von BOINCstats auf https://classic.boincstats.com zu finden, aber seid euch bewusst, dass diese Version nicht mehr gepflegt wird und außer Sicherheitsupdates keine Aktualisierungen mehr erhalten wird!
    20.07.2019

    Originaltext:
    Zitat Zitat von https://www.boincstats.com/forum/8/12258
    The new BOINCstats website is here!
    The new BOINCstats website is here!

    As you can see the BOINCstats website has been thoroughly renewed. It's an all new design which plays nicely with mobile phones and tablets. Security is improved, pages and forms are optimized. It's a big change but most pages kan be found in the same place as before.

    Support for customized languages has been dropped, most were not properly maintained. For those who really need a translated version the build in translation of the browser may do the trick. I found it to be pretty decent for Dutch.

    I hope you like it but if you really can't get used to the new design, the old version of BOINCstats can be found at https://classic.boincstats.com, but be aware, that version will no longer be maintained and will receive no updates other than security patches!
    2019-07-20
    von Veröffentlicht: 19.07.2019 19:15
    1. Kategorien:
    2. Projekte

    Der Juni konnte den Mai noch einmal überbieten. Insgesamt wurden 154 Primzahlen gefunden, Mitglieder von SETI.Germany traten stolze 33-mal als Erstfinder und 13-mal als Doublechecker in Erscheinung.

    Drei Top-100-Funde (zwei bei SR5-LLR, einer bei GFN-19) wurden bereits in den Projektnachrichten gewürdigt:

    • 88444*5^2799269-1, 1956611 Dezimalstellen, gefunden von Scott Brown (Team: Aggie The Pew) aus den Vereinigten Staaten am 21.06.2019 um 02:30:42 MEZ, bestätigt von DaveSun am 21.06.2019 um 15:50:01 MEZ
    • 322498*5^2800819-1, 1957694 Dezimalstellen, gefunden von Jordan Romaidis (San Francisco) aus den Vereinigten Staaten am 23.06.2019 um 15:39:48 MEZ, bestätigt von Scott Brown (Aggie The Pew) aus den Vereinigten Staaten am 24.06.2019 um 21:59:33 MEZ
    • 2877652^524288+1, 3386397 Dezimalstellen, gefunden von Tabaluga (Sicituradastra.) aus Deutschland am 29.06.2019 um 01:54:18 MEZ, bestätigt von carlo am 29.06.2019 um 09:52:47 MEZ


    Fünf weitere Megaprimzahlen wurden gefunden:

    • Die 1020008-stellige verallgemeinerte Fermat-Primzahl 60540024^131072+1 wurde am 03.06.2019 um 06:49:52 MEZ von DeleteNull (SETI.Germany) aus Deutschland mit einer NVIDIA GeForce RTX 2080 in Verbund mit einem Intel Core i7-7800X gefunden, wobei für den PRP-Test mit Genefer 3 Minuten 3 Sekunden benötigt wurden. Die Bestätigung erfolgte am 03.06.2019 um 07:20:34 MEZ durch Dingo (BOINC@AUSTRALIA) aus Australien mit einer NVIDIA GeForce GTX 1660 Ti in Verbund mit einem Intel Core i5-8400, wobei für den PRP-Test mit Genefer 6 Minuten 13 Sekunden benötigt wurden.

    • Die 1020104-stellige verallgemeinerte Fermat-Primzahl 60642326^131072+1 wurde am 06.06.2019 um 15:24:58 MEZ von DeleteNull (SETI.Germany) aus Deutschland mit einer NVIDIA GeForce RTX 2070 in Verbund mit einem AMD Ryzen 7 1700X gefunden, wobei für den PRP-Test mit Genefer 3 Minuten 35 Sekunden benötigt wurden. Die Bestätigung erfolgte am 06.06.2019 um 16:09:07 MEZ durch Johnny Rotten (SETI.USA) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1080 in Verbund mit einem Intel Core i7-5930K, wobei für den PRP-Test mit Genefer 8 Minuten 4 Sekunden benötigt wurden.

    • Die 1094460-stellige Proth-Primzahl 639*2^3635707+1 wurde am 14.06.2019 um 15:37:12 MEZ von 288larsson (Sicituradastra.) aus Schweden mit einem Intel Core i9-7980XE gefunden, wobei für den Primalitätstest mit LLR etwa 44 Minuten benötigt wurden. Die Bestätigung erfolgte am 14.06.2019 um 17:26:21 MEZ durch Randall J. Scalise aus den Vereinigten Staaten mit einem Intel Core i5-8500, wobei für den Primalitätstest mit LLR etwa 1 Stunde 50 Minuten benötigt wurden.

    • Die 1020468-stellige verallgemeinerte Fermat-Primzahl 61030988^131072+1 wurde am 19.06.2019 um 16:18:33 MEZ von Johny (Czech National Team) aus Tschechien mit einer NVIDIA GeForce RTX 2070 in Verbund mit einem AMD Ryzen 7 2700 gefunden, wobei für den PRP-Test mit Genefer 4 Minuten 39 Sekunden benötigt wurden. Die Bestätigung erfolgte am 19.06.2019 um 18:22:13 MEZ durch Corla99 [Lombardia] (BOINC.Italy) aus Italien mit einer NVIDIA GeForce GTX 1660 Ti in Verbund mit einem AMD Ryzen 5 1600X, wobei für den PRP-Test mit Genefer 5 Minuten 20 Sekunden benötigt wurden.

    • Die 1020688-stellige verallgemeinerte Fermat-Primzahl 61267078^131072+1 wurde am 29.06.2019 um 21:03:25 MEZ von vko (University of Maryland) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1080 Ti in Verbund mit einem Intel Core i9-7940X gefunden, wobei für den PRP-Test mit Genefer 6 Minuten 2 Sekunden benötigt wurden. Die Bestätigung erfolgte am 29.06.2019 um 21:58:01 MEZ durch TeardropOnFire aus dem Vereinigten Königreich mit einer NVIDIA GeForce GTX 1060 3GB und einer NVIDIA GeForce GTX 650 in Verbund mit einem Intel Core i7-4790K, wobei für den PRP-Test mit Genefer 46 Minuten 1 Sekunden benötigt wurden.


    Von den kleineren Funden sei ein erweiterter verallgemeinerter Fermatzahl-Teiler hervorgehoben:

    • Die 463950-stellige Proth-Primzahl 1659*2^1541195+1 ist ein Teiler der erweiterten verallgemeinerten Fermat-Zahl xGF(1541191,12,11)=12^2^1541191+11^2^1541191. Sie wurde am 22.06.2019 um 05:16:09 MEZ von Alex aus Deutschland mit einem Intel Xeon E5-2630 v3 gefunden, wobei für den Primalitätstest mit LLR etwa 20 Minuten benötigt wurden. Die Bestätigung erfolgte am 22.06.2019 um 05:16:25 MEZ durch tng* (Sicituradastra.) aus den Vereinigten Staaten mit einem Intel Core i7-4790, wobei für den Primalitätstest mit LLR etwa 13 Minuten benötigt wurden.


    Die 145 weiteren Primzahlfunde verteilen sich folgendermaßen:

    • Proth Prime Search (PPS): 6 Funde im Bereich 2730620 ≤ n ≤ 2737282 (822002-824007 Dezimalstellen)
    • Proth Prime Search Extended (PPSE): 14 Funde im Bereich 1540018 ≤ n ≤ 1541648 (463595-464087 Dezimalstellen). darunter ein Erstfund von ID4
    • Sophie Germain Prime Search (SGS): 82 Funde im Bereich 4470397401717 ≤ k ≤ 4537174923435 (388342 Dezimalstellen), darunter fünfundzwanzig Erstfunde und zwölf Doublechecks von DeleteNull, vier Erstfunde von trebotuet sowie ein Erstfund von kh9
    • Generalized Fermat Prime Search (n=15): 31 Funde im Bereich 127302742 ≤ b ≤ 131107928 (265580-265999 Dezimalstellen), darunter ein Doublecheck von C. Ketelsen
    • Generalized Fermat Prime Search (n=16): 12 Funde im Bereich 62840404 ≤ b ≤ 63434268 (511066-511334 Dezimalstellen)


    von Veröffentlicht: 18.07.2019 20:30
    1. Kategorien:
    2. Projekte

    Etwa einen Monat nach Fertigstellung des bisherigen Subprojekts steht fest: Alle gut 5 Billiarden diagonalen lateinischen Quadrate neunter Ordnung wurden durchsucht. Die weiteren Ergebnisse werden in nächster Zeit durchforstet und weitere Graphen erstellt, auch ein Artikel im Rahmen einer russischen Supercomputer-Konferenz ist in Arbeit.

    Projektergebnisse für die 9. Ordnung
    Liebe Teilnehmer!

    Am heutigen 11. Juli wird unser Projekt 23 Monate alt! Im Juni kamen die letzten Ergebnisse aus dem Raum der diagonalen lateinischen Quadrate (engl. diagonal Latin squares, DLS) neunter Ordnung herein und wir beginnen, diese zusammenzufassen! Das erste und wichtigste ist die Anzahl der DLS neunter Ordnung. In jeder WU wurde die Anzahl der verarbeiteten DLS aufgezeichnet und wir erhalten insgesamt die Zahl 5 056 994 653 507 584, welche mit dem Ergebnis unserer Kollegen von Gerasim@Home übereinstimmt, das in der Online-Enzyklopädie der Zahlenfolgen aufgeführt ist. Da die Rechenwege unabhängig voneinander entwickelt wurden, nicht derselbe Algorithmus verwendet wurde, die Aufteilung des Suchraums in einzelne Aufgaben unterschiedlich war und außerdem Daniels optimierte Anwendung verwendet wurde, ist das ein sehr wichtiges Ergebnis, das die erste Einschätzung und die Tatsache, dass die Suche alle DLS neunter Ordnung abgedeckt hat, bestätigt!

    Darüber hinaus wurde ein Artikel über das Projekt in die Serie Communications in Computer and Information Science aufgenommen als ausgewählter Artikel der Konferenz Russian Supercomputing Days. Er wird im Jahr 2019 veröffentlicht und wir werden den Link mit euch teilen.

    Eine russischsprachige Diskussion ist hier zu finden.
    11.07.2019, 5:50:45 MEZ


    Das neue Subprojekt im Bereich der Quadrate zehnter Ordnung (RakeSearch for rank 10) wurde derweil nach Behebung eines Problems mit der Anwendung fortgesetzt, nach einem Test für 64-Bit-Linux inzwischen auch wieder mit Anwendung für 64-Bit-Windows. Neu ist dabei, dass nicht nur orthogonale Quadrate aufgezeichnet werden (die für Ordnung 10 womöglich gar nicht existieren), sondern auch teilweise orthogonale Quadrate ab einem bestimmten Orthogonalitätsgrad (zur Definition siehe hier, engl.).

    Neuer Durchlauf für RakeSearch R10
    Liebe Leute!

    Wir haben die ersten WUs der neuen Suche im Raum zehnter Ordnung erzeugt. Derzeit für 64-Bit-Linux. Die neuerliche Suche verwendet eine neue Anwendung, die Laufzeiten sind mehrfach länger und die neue Anwendung liefert mehr Daten als die bisherige. Wenn die WUs erfolgreich bearbeitet werden, ergänzen wir morgen die Einzelheiten!

    Vielen Dank an Daniel von BOINC@Poland für seine Aufmerksamkeit, wissenschaftlich-kritische Beobachtung und Hilfe!
    15.07.2019, 20:49:07 MEZ


    Originaltexte:
    Zitat Zitat von https://rake.boincfast.ru/rakesearch/forum_thread.php?id=187
    Project results for rank 9
    Dear participants!

    Today, on July 11, our project turns 23 months! In June, the latest search results were obtained on the DLS space of rank 9 and we begin to sum it up! The first and very important one is the number of diagonal Latin squares of rank 9. Each result recorded the number of processed DLSs and now, summing them up, we got the number 5 056 994 653 507 584, which coincided with the result of our colleagues from Gerasim@Home, listed in OEIS. Since the computational modules were developed independently, they did not use the same algorithms, the division of the space into tasks was different, and the optimized Daniel’s application was also useds, this is a very important result confirming the first assessment and the fact that the search covered all DLSs of rank 9!

    Another result is that a paper on the project has been accepted to a “Communications in Computer and Information Science” series as one of selected papers of a conference “Russian Supercomputing Days”. It will be published in 2019 and we will share the link with you.

    Discussion in Russian is here.
    11 Jul 2019, 4:50:45 UTC
    Zitat Zitat von https://rake.boincfast.ru/rakesearch/forum_thread.php?id=188
    New run for RakeSearch R10
    Dear folks!

    We created the first bunch of tasks for new search in rank 10 space. Currently - under Linux x86-64. Renewed search use a new application, runtime increased in several times and new application return more data than previous. If tasks processing is successful tomorrow we add details!

    Great thanks for Daniel from BOINC@Poland for attention, scientific critical perception and help!
    15 Jul 2019, 19:49:07 UTC
    Seite 11 von 76 Erste ... 9 10 11 12 13 21 61 ... Letzte
Single Sign On provided by vBSSO