• Projekte

    von Veröffentlicht: 05.06.2019 17:20
    1. Kategorien:
    2. Projekte

    SixTrack 5 ist jetzt nach Windows und Linux (64-Bit) auch für weitere Plattformen verfügbar, darunter Android und Linux auf 64-Bit-ARM-CPUs:

    Neue SixTrack-5.02.05-Anwendungen
    Liebe Freiwillige,

    wir freuen uns, die Freigabe neuer Anwendungen der aktuellen Version (v5.02.05) für den Produktivbetrieb (SixTrack) bekanntzugeben. Wir haben neue Anwendungen für FreeBSD (avx/sse2), eine Anwendung für Windows XP (32-Bit), eine aarch64-Anwendung für Linux und eine für Android. Vielen Dank an James, Kyrre und Veronica, dass sie die Zeit zum Erstellen dieser Anwendungen gefunden haben.

    Das Verteilen eine Anwendung, die mit XP-Rechnern kompatibel ist, soll niemanden ermuntern, weiterhin veraltete Betriebssysteme einzusetzen, sondern einen sanfteren Übergang auf neuere Betriebssysteme ermöglichen. Auf diese Weise verpassen Teilnehmer mit XP-Rechnern nicht die Möglichkeit, an der aktuellen Welle von SixTrack-Aufgaben (die recht lang anhalten sollte) teilzunehmen, während sie über Möglichkeiten der Aktualisierung ihrer Rechner nachdenken. Gleichzeitig versuchen wir, 32-Bit-Linux-Anwendungen vorzubereiten. Nehmt zur Kenntnis, dass alle Windows-Anwendungen ohne Filter nach bestimmten Versionen verteilt werden - daher könnten XP-Rechner die normalen Windows-Anwendungen erhalten, welche sofort abstürzen, aber der BOINC-Server sollte schnell lernen, dass die XP-kompatible Anwendung die richtige ist.

    Wir freuen uns sehr, nun auch FreeBSD- und Android-Nutzer in unseren Betrieb einzubeziehen. Für letztere Plattform laufen die aktuellen Anwendungen nicht auf Android-Version 8 oder neuer. James beschäftigt sich noch damit. Da das Scheduler-seitige Filtern nach Android-Version noch fehlerhaft ist (siehe https://github.com/BOINC/boinc/issues/3172, engl.), haben wir die Android-Anwendung als Testanwendung markiert. Daher sollten SixTrack-Teilnehmer mit Android 8 oder neuer keine Aufgaben für die entsprechenden Rechner anfordern oder die Option Die Ausführung von Testanwendung erlauben? in ihren LHC@home-Projekteinstellungen deaktivieren.

    Wir verfolgen auch die Erzeugung von Anwendungen für macOS und sollten diese bald unter sixtracktest testen können.

    Danke für eure fortwährende Unterstützung und Hilfe,
    Alessio für das SixTrack-Team
    04.06.2019, 11:17:02 MEZ

    Originaltext:
    Zitat Zitat von https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5051
    new exes for SixTrack 5.02.05
    Dear volunteers,

    we are pleased to announce the release to production (SixTrack app) of new exes for the current pro version (v5.02.05). We have new exes for FreeBSD (avx/sse2), an exe for XP hosts (32bits), an aarch64 executable for Linux, and one for Android. Many thanks to James, Kyrre and Veronica for finding the time to produce them.

    Distributing an exe compatible with XP hosts is not a way to encourage people to stay with unsupported OSs, but rather a trial to have a smooth transition to more recent OSs. In this way, people with XP hosts do not miss the possibility to contribute to the present wave of SixTrack tasks (expected to be quite long) while considering options for upgrading their hosts. At the same time, we are looking into preparing 32bits Linux exes. It should be noted that all Win exes are distributed without targeting specific kernel versions - hence, XP hosts may receive tasks with regular Windows exes immediately failing, but the BOINC server should quickly learn that the XP-compatible exe is the appropriate one.

    We are also very happy to start involving freeBSD and Android users in our production chain. For the latter platform, the present exe won't run on Android versions >=8 - James is still looking into this. Since the android version filtering needs a fix on the scheduler side:
    https://github.com/BOINC/boinc/issues/3172
    we labelled the Android exe as beta. Hence, Sixtrack beta users with Android 8 and later should not request tasks for that host or untick the test applications flag in their LHC@home project preferences.

    We are pursuing also the generation of MacOS exes, and we should test them soon on sixtracktest.

    Thanks for your continuous support and help,
    Alessio, for the SixTrack team
    4 Jun 2019, 10:17:02 UTC
    von Veröffentlicht: 30.05.2019 08:30
    1. Kategorien:
    2. Projekte

    Kurz bevor auch dieser Monat zu Ende geht, fehlt noch der Blick auf die Primzahlfunde des Vormonats. Davon gab es 123, darunter 10 Erstfunde und 3 Doublechecks von SETI.Germany-Mitgliedern.

    Erneut eine GFN-19- und nach mehrmonatiger Pause wieder eine SR5-Primzahl waren dabei, welche die Top 100 erreichten und daher bereits in den Projektnachrichten bekanntgegeben wurden:


    Acht weitere Funde hatten mehr als eine Million Dezimalstellen:
    • Die 1018745-stellige verallgemeinerte Fermat-Primzahl 59210784^131072+1 wurde am 03.04.2019 um 02:59:42 MEZ von Kellen aus Kanada mit einer NVIDIA GeForce GTX 1080 Ti in Verbund mit einem AMD Ryzen 5 1600X gefunden, wobei für den PRP-Test mit Genefer 6 Minuten 40 Sekunden benötigt wurden. Die Bestätigung erfolgte am 03.04.2019 um 04:28:41 MEZ durch PC10K (Canada) aus Kanada mit einer NVIDIA GeForce 940MX in Verbund mit einem Intel Core i7-8550U, wobei für den PRP-Test mit Genefer 1 Stunde 25 Minuten 48 Sekunden benötigt wurden.

    • Die 1018835-stellige verallgemeinerte Fermat-Primzahl 59305348^131072+1 wurde am 07.04.2019 um 03:52:05 MEZ von Grind29 aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 750 Ti in Verbund mit einem Intel Core i7-3770 gefunden, wobei für den PRP-Test mit Genefer 25 Minuten 10 Sekunden benötigt wurden. Die Bestätigung erfolgte am 07.04.2019 um 04:07:39 MEZ durch stiven (BOINC@Poland) aus Polen mit einer NVIDIA GeForce GTX 1060 3GB in Verbund mit einem Intel Xeon E3-1220 v3, wobei für den PRP-Test mit Genefer 11 Minuten 6 Sekunden benötigt wurden.

    • Die 1018890-stellige verallgemeinerte Fermat-Primzahl 59362002^131072+1 wurde am 09.04.2019 um 16:43:57 MEZ von 288larsson (Sicituradastra.) aus Schweden mit einer AMD Radeon VII in Verbund mit einem Intel Core i7-6800K gefunden, wobei für den PRP-Test mit Genefer 4 Minuten 46 Sekunden benötigt wurden. Die Bestätigung erfolgte am 09.04.2019 um 21:54:09 MEZ durch Luca Bertelloni aus Italien mit einer NVIDIA GeForce GTX 1050 in Verbund mit einem AMD FX-6100, wobei für den PRP-Test mit Genefer 18 Minuten 3 Sekunden benötigt wurden.

    • Die 1018931-stellige verallgemeinerte Fermat-Primzahl 59405420^131072+1 wurde am 11.04.2019 um 20:39:10 MEZ von Skligmund (Prime Ordeal Soup) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1070 in Verbund mit einem AMD Ryzen 7 1700 gefunden, wobei für den PRP-Test mit Genefer 8 Minuten 41 Sekunden benötigt wurden. Die Bestätigung erfolgte am 11.04.2019 um 22:19:33 MEZ durch Matthew D Doenges aus den Vereinigten Staaten mit einer AMD Radeon R9 360 in Verbund mit einem Intel Core i7-6700, wobei für den PRP-Test mit Genefer 45 Minuten 45 Sekunden benötigt wurden.

    • Die 1090691-stellige Proth-Primzahl 951*2^3623185+1 wurde am 11.04.2019 um 23:24:06 MEZ von 288larsson (Sicituradastra.) aus Schweden mit einem Intel Core i9-7940X gefunden, wobei für den Primalitätstest mit LLR auf 2 Threads etwa 18 Minuten benötigt wurden. Die Bestätigung erfolgte am 11.04.2019 um 23:41:00 MEZ durch Randall J. Scalise aus den Vereinigten Staaten mit einem Intel Core i5-4590, wobei für den Primalitätstest mit LLR etwa 1 Stunden 21 Minuten benötigt wurden.

    • Die 1019037-stellige verallgemeinerte Fermat-Primzahl 59515830^131072+1 wurde am 17.04.2019 um 19:08:04 MEZ von Keith (BOINC@Denmark) aus Kanada mit einer NVIDIA GeForce GTX 1070 Ti in Verbund mit einem Intel Core i5-8400 gefunden, wobei für den PRP-Test mit Genefer 7 Minuten 56 Sekunden benötigt wurden. Die Bestätigung erfolgte am 17.04.2019 um 19:59:25 MEZ durch Medijate (The Knights Who Say Ni!) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1080 in Verbund mit einem Intel Core i7-8700K, wobei für den PRP-Test mit Genefer 6 Minuten 43 Sekunden benötigt wurden.

    • Die 1019206-stellige verallgemeinerte Fermat-Primzahl 59692546^131072+1 wurde am 28.04.2019 um 03:50:56 MEZ von CGB (Canada) aus Kanada mit einer NVIDIA GeForce GTX 1080 in Verbund mit einem Intel Core i7-8086K gefunden, wobei für den PRP-Test mit Genefer 7 Minuten 5 Sekunden benötigt wurden. Die Bestätigung erfolgte am 28.04.2019 um 04:45:57 MEZ durch vko (University of Maryland) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 1080 Ti in Verbund mit einem Intel Core i9-7940X, wobei für den PRP-Test mit Genefer 5 Minuten 52 Sekunden benötigt wurden.

    • Die 1019232-stellige verallgemeinerte Fermat-Primzahl 59720358^131072+1 wurde am 29.04.2019 um 09:59:10 MEZ von dh1saj (SETI.Germany) aus Deutschland mit einer NVIDIA GeForce GTX 1080 in Verbund mit einem Intel Core i7-3770 gefunden, wobei für den PRP-Test mit Genefer 6 Minuten 42 Sekunden benötigt wurden. Die Bestätigung erfolgte am 29.04.2019 um 12:02:58 MEZ durch TimT (Aggie The Pew) aus den Vereinigten Staaten mit einer NVIDIA GeForce GTX 950 in Verbund mit einem Intel Core i7-4790K, wobei für den PRP-Test mit Genefer 19 Minuten 33 Sekunden benötigt wurden.


    Weitere 113 Primzahlen entfallen auf die anderen Subprojekte:
    • Proth Prime Search (PPS): 1 Fund: 1101*2^2720091+1 (818833 Dezimalstellen)
    • Proth Prime Search Extended (PPSE): 17 Funde im Bereich 1535128 ≤ n ≤ 1537390 (462124-462805 Dezimalstellen)
    • Sophie Germain Prime Search (SGS): 48 Funde im Bereich 4359102853317 ≤ k ≤ 4414394225787 (388342 Dezimalstellen), darunter acht Erstfunde und drei Doublechecks von DeleteNull
    • Generalized Fermat Prime Search (n=15): 26 Funde im Bereich 119831538 ≤ b ≤ 122579374 (264719-265042 Dezimalstellen)
    • Generalized Fermat Prime Search (n=16): 19 Funde im Bereich 59841338 ≤ b ≤ 61425072 (509674-510418 Dezimalstellen), darunter ein Erstfund von EmmettDe
    • Generalized Fermat Prime Search (n=17 low): 2 Funde: 15091270^131072+1 (940930 Dezimalstellen), 15147290^131072+1 (941141 Dezimalstellen)


    von Veröffentlicht: 29.05.2019 18:35
    1. Kategorien:
    2. Projekte

    Der Suchbereich der orthogonalen diagonalen lateinischen Quadrate neunter Ordnung dürfte in etwa zwei Wochen erschöpft sein. Seit wenigen Tagen wird eine Anwendung (derzeit nur für 64-Bit-Linux verfügbar) für eine Fortsetzung mit Quadraten zehnter Ordnung getestet (Subprojekt RakeSearch for rank 10). Wer für die bisherige Suche die optimierte Anwendung verwendete, wird die app_info.xml löschen oder ergänzen müssen, um WUs des neuen Subprojektes erhalten zu können. Wie lange das neue Subprojekt laufen wird, ist unklar, da der komplette Suchbereich der Quadrate zehnter Ordnung mit heutiger Rechnerkapazität nicht in überschaubarer Zeit abgearbeitet werden könnte.

    Zukunft des Projektes RakeSearch
    Liebe Leute!

    Vor zwei Tagen hat das Projekt den Meilenstein von 95% der geplanten Berechnungen erreicht. Für die aktuelle Suche verbleiben noch etwa 1 100 000 WUs. In den nächsten Tagen wollen wir ein oder mehrere WU-Bündel für eine neue Suche erzeugen - im Raum der diagonalen lateinischen Quadrate zehnter Ordnung. Anfangs werden nur für 64-Bit-Linux Aufgaben verfügbar sein, wenn diese erfolgreich laufen, wird die Windows-Anwendung veröffentlicht.
    Ein paar Worte über die neue Suche. Wir erwarten, dass eine typische Aufgabe im Durchschnitt mehr Quadrate in der gleichen Zeit bearbeitet. Wir werden einige Optimierungen in die Anwendung für die neue Suche einbauen und sie wird deutlich schneller sein als die Standardanwendung für die Suche im Raum neunter Ordnung. Auch der Suchraum selbst ist interessant. Wir vergrößern die Ordnung der Quadrate nur um einen Schritt, von 9 auf 10. Derzeit verwenden wir für die WU-Namen das Format R9_<8 Ziffern> (z.B. R9_022248939) und die erste Ziffer ist stets 0. Aber wenn wir alle WUs der neuen Suche durchnummerieren wollten, müssten wir ein Format wie _0000000000000001 benutzen! (Wir kennen die genaue Anzahl der WUs für eine vollständige Suche im Raum zehnter Ordnung nicht, aber eine grobe Schätzung sind 160 Billionen WUs). Die aktuelle Suche besteht aus 23 Millionen WUs, aber die vollständige Suche im Raum zehnter Ordnung wäre etwa 7 Millionen Mal so groß! Natürlich können wir keine solche Suche durchführen. Nicht einmal mit neuen Ryzen-CPUs.
    Außerdem wissen wir nicht, ob "permutationelle" orthogonale diagonale lateinische Quadrate zehnter Ordnung überhaupt existieren.
    Aus diesen Gründen planen wir, nur einen kleinen Teil des gesamten Suchraums abzudecken - vielleicht 1 Million WUs, vielleicht mehr, aber wir wollen keine endlose Suche ohne irgendwelche Ergebnisse durchführen, da es viele andere interessante und nützliche Projekte gibt.

    Vielen Dank für eure Aufmerksamkeit und Teilnahme!
    26.05.2019, 22:21:30 MEZ

    Originaltext:
    Zitat Zitat von https://rake.boincfast.ru/rakesearch/forum_thread.php?id=176
    Future of the RakeSearch project
    Dear folks!

    Two days ago the project reached a milestone of 95% of completion. As part of the current search, it remains to process about 1100 000 workunits. In the next few days, we plan to generate one or several bunches of workunits for new search - in space of diagonal Latin squares of rank 10. Initially, tasks only under Linux x86-64 platform will be available, if their processing is successful, the application for Windows will be released.
    A few words about the new search. We expect that an typical task will process more squares for the same time (on average). In the application for a new search, we implement some optimizations and it will be significantly faster than default application for search in space of rank 9. Another interesting thing - the search space, itself. We increase a square rank by only one stage - from 9 to 10. Currently, for workunit names we use a format R9_<8 digits> (R9_022248939 for example) and first digit from tuple - always 0. But for the naming of workunits for a new search, if we try to count all of them, we must use a format like _0000000000000001! (We don't know the number of workunits for full search in space of rank 10 precisely, but rough estimate - about 160 millions of millions of workunits). The current search comprises 23 000 000 workunits, but the full search in rank 10 space targets about 7 000 000 searches of rank 9! Of course, we cannot perform a search like this. Even with new Ryzens.
    Also, today we do not know whether or not "permutational" orthogonal diagonal Latin squares of rank 10 exist.
    For the reasons listed below, we plan to perform a search over a tiny part of entire search space - may be 1 million of workunits, may be larger, but we don't want to run an endless search without any results, because many other interesting and useful projects exist.

    Thank you for attention and participation!
    26 May 2019, 21:21:30 UTC
    von Veröffentlicht: 29.05.2019 17:20
    1. Kategorien:
    2. Projekte

    Die Wissenschaftler hinter SixTrack bedanken sich noch einmal explizit für die Zusatzleistung durch den Sprint beim vergangenen BOINC Pentathlon. Kürzlich ist zudem ein Artikel im Fachjournal Physical Review Accelerators and Beams erschienen, der die Ergebnisse früherer Berechnungen über LHC@home verwendet.

    BOINC Pentathlon 2019 ist vorbei - ein großer Dank vom SixTrack-Team!
    Liebe Freiwillige,

    der Pentathlon 2019 ist vorbei und wir möchten allen Teilnehmern dafür danken, unsere WUs gecruncht zu haben! Die unter BOINC zur Verfügung stehende CPU-Leistung hat sich fast verdoppelt und unsere Berechnungen beschleunigt, auch wenn es nur für ein paar Tage war. Wir sind dafür sehr dankbar!

    Das SixTrack-Team möchte auch all euch Freiwilligen danken, die uns regelmäßig mit ihren CPUs unterstützen. Ihr gebt uns die Möglichkeit, unser Verständnis der Dynamischen Apertur zu vertiefen, einer Größe von höchster Wichtigkeit für die Stabilität von Teilchenstrahlen in großen Beschleunigern wie supraleitenden Speicherringen. Zu guter Letzt ein brandneuer Artikel im wichtigsten Journal im Feld der Beschleunigerphysik, welcher Simulationen und Messungen vergleicht, wobei die Simulationsergebnisse dank euch und BOINC erzielt wurden:
    https://journals.aps.org/prab/pdf/10...eams.22.034002 (engl.)

    Viel wurde schon mit eurer Hilfe erreicht, aber in der nächsten Zeit wird noch viel mehr kommen. Wir zählen auf eure Unterstützung!
    Macht weiter so,
    Alessio und Massimo für das SixTrack-Team
    20.05.2019, 9:00:15 MEZ

    Originaltext:
    Zitat Zitat von https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5036
    2019 BOINC Pentathlon is over - a big thank you from the SixTrack team!
    Dear volunteers,

    the 2019 pentathlon is over, and we would like to thank all the participants for having crunched our tasks! We saw the BOINC CPU capacity almost doubled, boosting our calculations, even though it was only for few days. We are very grateful for that!

    The SixTrack team would also like to thank all you volunteers who regularly support us with your CPUs. You give us the possibility to deepen our understanding of the dynamic aperture, a quantity of paramount importance for the stability of particle beams in big research accelerators like superconducting colliders - last but not least a very recent paper on the most important journal in the field of accelerator physics, comparing simulations and measurements:
    https://journals.aps.org/prab/pdf/10...eams.22.034002
    where simulation results have been obtained thanks to you and BOINC!

    A lot has been already done with your help, but a lot more has still to come in the next future. We count on your support!
    Keep up the good work,
    Alessio and Massimo, for the SixTrack team
    20 May 2019, 8:00:15 UTC
    von Veröffentlicht: 28.05.2019 19:00
    1. Kategorien:
    2. Projekte

    Zwei weitere verallgemeinerte Riesel-Vermutungen wurden in den vergangenen Wochen bewiesen. Zum einen ist k=74 die kleinste verallgemeinerte Riesel-Zahl zur Basis b=875:

    Basis R875 bewiesen
    Am 22. April hat whizbang, Mitglied des Teams Ars Technica, die letzte Primzahl zur Basis R875 gefunden.
    Die Primzahl 38*875^256892-1 hat 755780 Dezimalstellen und erreicht die Top 5000 in Chris Caldwells Datenbank der größten bekannten Primzahlen.
    19.05.2019, 15:49:09 MEZ


    Zum anderen ist k=50 die kleinste verallgemeinerte Riesel-Zahl zur Basis b=951, wie durch einen Megaprimzahlfund für das letzte verbliebene kleinere k bewiesen wurde:

    Basis R951 bewiesen / Megaprimzahl
    Am 4. Mai hat whizbang, Mitglied des Teams Ars Technica, die letzte Primzahl zur Basis R951 gefunden.
    Die Primzahl 34*951^371834-1 hat 1107391 Dezimalstellen und erreicht die Top 5000 in Chris Caldwells Datenbank der größten bekannten Primzahlen.
    25.05.2019, 9:50:35 MEZ


    Originaltexte:
    Zitat Zitat von http://srbase.my-firewall.org/sr5/forum_thread.php?id=1182
    base R875 proven
    On 22th of April, whizbang, a member of the team Ars Technica found the last prime for base R875.
    The prime 38*875^256892-1 has 755780 digits and entered the TOP5000 in Chris Caldwell's The Largest Known Primes Database.
    19 May 2019, 14:49:09 UTC
    Zitat Zitat von http://srbase.my-firewall.org/sr5/forum_thread.php?id=1186
    base R951 proven / Megaprime
    On 04th of May, whizbang, a member of the team Ars Technica found the last prime for base R951.
    The prime 38*875^256892-1 [sic!] has 1.107.391 digits and entered the TOP5000 in Chris Caldwell's The Largest Known Primes Database.
    25 May 2019, 8:50:35 UTC
    von Veröffentlicht: 28.05.2019 18:20
    1. Kategorien:
    2. Projekte

    Nachdem der erste Versuch einer GPU-Anwendung letztlich nur zu einer signifikanten Optimierung der CPU-Anwendung geführt hatte, gibt es nun einen neuen Versuch. Mittlerweile werden Anwendungen für NVIDIA-GPUs (Windows und Linux) und AMD-GPUs (nur Linux) verteilt, wobei in den Projekteinstellungen derzeit noch die Option Die Ausführung von Testanwendung erlauben? aktiviert sein muss.

    Neuigkeiten zur GPU-Anwendung
    Seit den letzten Neuigkeiten ist mehr als ein Monat vergangen, aber ich habe jetzt einige gute Nachrichten. Ich habe einige Verbesserungen am GPU-Quellcode vorgenommen und bin nun bereit, die neuen GPU-Anwendungen zu verteilen.

    Ich werde mit der AMD-OpenCL-Version für Linux beginnen. Es wird eine Beta-Version sein. Ich hatte einige Schwierigkeiten damit, wie AMD OpenCL implementiert, und diese Anwendung funktioniert immer noch nicht auf meinem Fedora-System, was meiner Überzeugung nach am Grafiktreiber liegt. Aber ich hatte Hilfe von einem Freiwilligen namens Wiktor und sie funktioniert problemlos bei ihm (ich glaube, er nutzt Ubuntu). Bitte vergesst nicht, dass AMD offiziell nur RHEL und Ubuntu unterstützt, daher wird es interessant sein, ob diese Anwendung bei jemandem mit einer "nicht unterstützten" Linux-Distribution wie meiner funktioniert.

    Ich habe auch OpenCL-Windows-Anwendungen, die mit MinGW cross-kompiliert wurden. Ich habe keine Möglichkeit, diese zu testen, und bin daher noch nicht so weit, diese auszurollen. Aber falls jemand diese offline ausprobieren möchte, lasst es mich wissen und ich schicke sie euch.
    15.05.2019, 23:05:56 MEZ

    Originaltext:
    Zitat Zitat von https://numberfields.asu.edu/NumberFields/forum_thread.php?id=375
    GPU status update
    It's been over a month since our last update, but I now have some good news. I have made some improvements to the GPU code and am ready to start deploying the new GPU apps.

    I will start with the AMD OpenCL version for Linux. This will be a beta version. I have had a hell of a time with the AMD implementation of openCL, and this app still doesn't work on my Fedora system, and I believe strongly it's due to the graphics driver. But I have had the help of a volunteer named Wiktor and it runs fine for him (I believe he runs Ubuntu). Please keep in mind that AMD officially only supports RHEL and Ubuntu, so I will be interested to hear if this app works for anyone with an "unsupported" linux distro like myself.

    I also have openCL Windows apps that were cross compiled using mingW. I have no means of testing these, so I am not ready to deploy them just yet. But if anyone would like to take them for a spin offline, please let me know, and I can send them to you.
    15 May 2019, 22:05:56 UTC
    von Veröffentlicht: 21.05.2019 13:00
    1. Kategorien:
    2. Projekte

    Nach einer Pause für das Ende von GCW-Sieve und den Pentathlon steht nun der dritte Teil der diesjährigen PrimeGrid Challenge Series bevor. Im Fokus steht dieses Mal das Subprojekt The Riesel Problem LLR zu Ehren des Namensgebers Hans Ivar Riesel, der am 28. Mai 90 Jahre alt geworden wäre.

    Hans Ivar Riesel's 90th Birthday Challenge
    Beginn: 24.05.2019, 00:00 UTC = 01:00 MEZ = 02:00 MESZ
    Ende: 31.05.2019, 00:00 UTC = 01:00 MEZ = 02:00 MESZ
    Subprojekt: The Riesel Problem LLR (TRP)


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

    Es zählen für diese Challenge nur WUs des Subprojekts The Riesel Problem LLR (TRP), die nach dem 24.05. um 02:00 Uhr heruntergeladen und vor dem 31.05. 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 Tagen 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>llrTRP</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: 15.05.2019 13:45
    1. Kategorien:
    2. Projekte

    Ähnlich wie das Subprojekt ATLAS Simulation gibt es für bastelfreudige Linux-Nutzer nun auch die Möglichkeit, Theory-WUs ohne VirtualBox zu berechnen. Dafür muss zwingend die Software installiert sein, die sonst in der Virtuellen Maschine bereitgestellt wird, daher ist es wichtig, die Anleitung zur Einrichtung zu befolgen.

    Theory Native (TheoryN) veröffentlicht
    Das Subprojekt Theory Native für Linux hat den Beta-Status verlassen und ist nun allgemein verfügbar. Es ist insofern mit der nativen ATLAS-Anwendung vergleichbar, dass es eine lokale Installation von CVMFS benötigt, es braucht jedoch nicht Singularity, da Linux-Container (runc) genutzt werden. Um eure Rechner für dieses Subprojekt einzurichten, folgt bitte dieser Anleitung (engl.). Folgt den Anweisungen auch, wenn native ATLAS-Aufgaben erfolgreich laufen, um sicherzustellen, dass CVMFS für beide Subprojekte korrekt konfiguriert ist und Linux-Container aktiviert sind. Dies ist ein neues Subprojekt (TheoryN) statt einer alternativen Anwendung für das Subprojekt Theory Simulation, da die Ressourcenanforderungen unterschiedlich sind. Wenn es Probleme gibt, meldet sie bitte im Theory-Forum.
    13.05.2019, 9:07:13 MEZ


    Eine weitere Nachricht gibt es für aktive Teilnehmer des Subprojektes CMS Simulation: Sie werden gebeten, vorerst keine neuen BOINC-Aufgaben zu beginnen, da die Warteschlage für eine Softwareaktualisierung leerlaufen muss.

    Bitte keine neuen CMS-Aufgaben zulassen
    Hallo an alle CMS-Teilnehmer. Wir müssen die Aufgaben-Warteschlange leerlaufen lassen, damit eine neue WMAgent-Version installiert werden kann.
    Könnt ihr bitte auf "keine neuen Aufgaben" stellen, damit eure aktuellen Aufgaben fertiggestellt werden und keine neuen begonnen werden? Wenn ihr WUs habt, die auf die Ausführung warten, pausiert sie bitte oder brecht sie ab.
    Danke, ich werde euch informieren, wenn die Änderung abgeschlossen ist.
    14.05.2019, 15:40:22 MEZ


    Originaltext:
    Zitat Zitat von https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5023
    Native Theory Application (TheoryN) Released
    The Native Theory Application for Linux has moved out of Beta status and is now generally available. It is similar to the Native ATLAS application in that it requires CVMFS to be installed locally but does not require Singulariy as it uses Linux Containers (runc). To setup your machine for this application please follow the instructions.. Even if the Native ATLAS tasks are running successfully, follow the instructions to ensure that CVMFS is configured correctly for both and that Linux Containers are enabled. This is a new application (TheoryN) rather than an alternative version of the Theory application as they have different resources requirement. If there are any issues, please post them to the Theory messages board.
    13 May 2019, 8:07:13 UTC
    Zitat Zitat von https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5028
    CMS -- Please set "no new tasks"
    Hi to all CMS-ers. We need to drain the job queue so that a new version of the WMAgent can be installed.
    Can you please set No New Tasks so that your current tasks can run out and no new jobs start? If you have any tasks waiting to run, please suspend or abort them.
    Thanks, I'll let you know as soon as the change is done.
    14 May 2019, 14:40:22 UTC
    von Veröffentlicht: 10.05.2019 15:10
    1. Kategorien:
    2. Projekte

    Wenn ein Stern oder auch ein kompakter Sternrest Materie aufsammelt, die ihm zu nahe gekommen ist (z.B. von einem Begleitstern, der sich am Ende seiner Lebensdauer stark aufgebläht hat), sammelt sich diese in einer Akkretionsscheibe, welche durch Reibung so heiß werden kann, dass Röntgenstrahlung emittiert wird. Ist das akkretierende Objekt ein Schwarzes Loch, wird gleichmäßig in alle Richtungen (isotrop) abgestrahlt, wohingegen die Röntgenstrahlung akkretierender Neutronensterne eher kegelförmig ausgeht und daher nicht von überall aus sichtbar ist. Ein zur Veröffentlichung im Astrophysical Journal angenommener Artikel beschreibt auf Basis von mit Universe@Home durchgeführten Simulationen verschiedener entwickelter Sternpopulationen, wie sich verschiedene Parameter auf die Anteile von Neutronensternen und Schwarzen Löchern an der Gesamtzahl der ultraleuchtkräftigen Röntgenquellen auswirken und welche Erwartungen daraus für tatsächliche Beobachtungen folgen.

    Emission von ULX
    Nach einer Reihe von Artikeln über Gravitationswellenquellen haben wir auch Ergebnisse zu ultraleuchtkräftigen Röntgenquellen (engl. ultra-luminous X-ray sources, ULX) veröffentlicht. In diesem Artikel untersuchen wir die anisotrope Strahlungsemission dieser Quellen und zeigen, dass sich die tatsächliche Population ultraleuchtkräftiger Röntgenquellen von der beobachteten unterscheidet. Insbesondere in flusslimitierten Durchmusterungen wird die beobachtete Population stark zugunsten akkretierender Schwarzer Löcher verschoben sein, wohingegen akkretierende Neutronensterne in volumenlimitierten Beobachtungen dominieren.

    Der Artikel ist hier zu finden: https://arxiv.org/abs/1811.08998 (engl.)
    10.05.2019, 5:05:38 MEZ

    Originaltext:
    Zitat Zitat von https://universeathome.pl/universe/forum_thread.php?id=415
    Emission from ULXs
    After a series of papers on gravitational wave sources, we published results concerning ultra-luminous X-ray sources. In the paper we analyse the anisotropic emission of radiation from these sources and show that the actual population of ultra-luminous X-ray sources differs from the observed one. Particularly, in flux limited surveys, the observed population will be highly biased toward black hole accretors, whereas neutron star accretors dominate volume-limited observations.

    The work can be found here https://arxiv.org/abs/1811.08998
    10 May 2019, 4:05:38 UTC
    von Veröffentlicht: 09.05.2019 00:10
    1. Kategorien:
    2. Projekte

    Für die LLR-Subprojekte wird nun ein neuer Wrapper verwendet, der mit leicht erhöhter Prozesspriorität läuft (die eigentliche LLR-Anwendung läuft weiterhin mit Leerlaufpriorität). Das kann einige seltene Probleme verhindern, auch der Wrapper für 321-Sieve wird in Kürze entsprechend aktualisiert. Diese Funktion wird jedoch nur von hinreichend aktuellen BOINC-Clients (ab 7.4 von Juni 2014) unterstützt, wer eine noch ältere Version verwendet, sollte also über eine Aktualisierung nachdenken.

    Ein Grund, weshalb ihr BOINC aktualisieren solltet
    "Repariere nichts, was nicht kaputt ist" ist nicht die schlechteste Faustregel, trifft hier aber nicht zu.

    Wir haben gerade die meisten PrimeGrid-Anwendungen aktualisiert, aber um daraus Vorteile zu ziehen, müsst ihr eine BOINC-Version verwenden, die nicht allzu sehr veraltet ist.

    Bei den Anwendungen, welche Wrapper benutzen (aktuell alle LLR-Anwendungen und 321-Sieve), wird die Prozesspriorität des Wrappers höher als Leerlaufpriorität eingestellt. Das kann dabei helfen, einige seltene Abstürze aufgrund des Wrappers zu vermeiden. Ihr braucht mindestens BOINC 7.4, um von dieser Funktion zu profitieren. Die LLR-Anwendungen sind bereits aktualisiert und 321-Sieve wird in naher Zukunft aktualisiert.

    Alle Anwendungen werden nun gzip-komprimiert geschickt, was die Dateitransfers um etwa 50% reduziert. Ihr braucht mindestens BOINC 7.0, um von dieser Funktion zu profitieren.

    Falls ihr eine wirklich alte BOINC-Version verwendet, habt ihr nun einen Grund für die Aktualisierung!
    08.05.2019 | 14:03:36 MEZ

    Originaltext:
    Zitat Zitat von https://www.primegrid.com/forum_thread.php?id=8578
    Reason you should upgrade BOINC
    "If it ain't broke, don't fix work" isn't a terrible rule of thumb, but not in this case.

    We've just updated most of PrimeGrid's apps, but to take advantage of them you'll need to be running a version of BOINC that isn't too ancient.

    On the apps that use wrappers (currently all of the LLR apps and 321-Sieve) the priority of the wrapper is increased above idle priority. This may help avoid some infrequent crashes attributed to the wrapper. You'll need at least BOINC 7.4+ to take advantage of this feature. The LLR apps are already updated, and 321-Sieve will be updated in the near future.

    All of the binary files will now be sent gzipped, which will reduce data transfer by about 50%. You'll need at least BOINC 7.0+ to take advantage of this feature.

    If you're running a really old version of BOINC, you now have a reason to upgrade!
    8 May 2019 | 13:03:36 UTC
    Seite 2 von 64 Erste 1 2 3 4 12 52 ... Letzte
Single Sign On provided by vBSSO