• Projekte

    von Veröffentlicht: 29.05.2019 18: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 20: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 19: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 14: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 14: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 16: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 01: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
    von Veröffentlicht: 07.05.2019 11:45
    1. Kategorien:
    2. Projekte

    Der gestern begonnene Stadtlauf beim diesjährigen BOINC Pentathlon hat bereits einen nennenswerten Faktorenfund beim Subprojekt ECM hervorgebracht (gefunden von Tom Turbo aus dem Team Planet 3DNow!). Wer der Aufforderung des Projektadministrators in der zum Start veröffentlichten Meldung folgen möchte, sollte jedoch reichlich RAM mitbringen.

    Willkommen an die Pentathlon-Wettkampfteams
    Unser kleiner Server kämpft schwer mit all den geleerten Bunkern, besonders zum Anfang. Wir haben einige Maßnahmen ergriffen, um mit der Last klarzukommen. Wenn jedoch viele Puffer gleichzeitig geleert werden, wird der Transitioner Zeit brauchen, alle zu bearbeiten.

    Beim Subprojekt ECM wurde ein 63-stelliger Primfaktor einer Cullen/Woodall-Zahl gefunden, der die gmp-ecm-Top10-Liste für dieses Jahr erreichen wird.

    Habt Spaß und schnappt euch mehr von den ECM-P2-WUs!

    yoyo
    06.05.2019

    Originaltext:
    Zitat Zitat von https://www.rechenkraft.net/yoyo/
    Welcome Penta Racing Teams
    Our small server heavily fights with all flushed buffers, especially at the beginning. We did some measures to handle the load. But if many buffers will be flushed at the same time, the transitioner will need time to handle all.

    In the ECM project a 63 digit prime as a factor of a CullenWoodall number was found, which will make it into the gmp-ecm Top 10 list for this year.

    Have fun and take more of the ECM P2 workunits!

    yoyo
    6 May 2019
    von Veröffentlicht: 05.05.2019 18:50
    1. Kategorien:
    2. Projekte

    Der fünfte Unterkörper (ℚ(√-5)) bei der Suche nach Zahlkörpern zehnten Grades ist nun fast abgearbeitet. Die WUs der letzten Serie wurden wegen der kürzlich optimierten Anwendung deutlich verlängert, sodass aber auch deutlich weniger WUs berechnet werden müssen. Allerdings werden auch einige bereits vor einiger Zeit vorbereitete WUs für den sechsten Unterkörper (ℚ(√10)) eingestreut, die im Schnitt deutlich kürzer sind.

    Unterkörper 5 erreicht die Schlussphase
    Die letzte Serie von Unterkörper 5 ist angebrochen (16x12).

    Dies ist die erste WU-Serie, die nach der Optimierung der Anwendung erzeugt wurde. Daher werden die Laufzeiten steigen. Diese WUs laufen durchschnittlich 2 Stunden auf meinem AMD Ryzen 2990WX. Es gibt 1,6 Millionen dieser WUs; mit der nicht optimierten Anwendung hätte es 16 Millionen gebraucht, das ist also eine riesige Verbesserung.

    Ich werde in diese Serie einige WUs zu Unterkörper 6 einstreuen. Diese wurden vor einiger Zeit für die nicht optimierte Anwendung erzeugt und werden daher vergleichsweise schnell laufen. Falls ich diese separat laufen lassen würde, könnte dies zu hohe Serverlast erzeugen, daher habe ich mir das als einen guten Weg überlegt, um diese WUs zu erledigen (ohne sie neu erzeugen zu müssen, was mühsam sein kann).
    04.05.2019, 19:25:13 MEZ

    Originaltext:
    Zitat Zitat von https://numberfields.asu.edu/NumberFields/forum_thread.php?id=371
    Subfield 5 entering final phase
    Subfield 5 is now on it's final batch (16x12).

    This is the first batch of WUs generated since the app was optimized. As a result, run times will be going up. These WUs average 2 hour run times on my AMD Ryzen 2990WX. Note there are 1.6 million of them; with the unoptimized app it would have required 16 million, so this is a huge improvement.

    I will be mixing in some subfield 6 WUs with this batch. These were generated a while ago for the unoptimized app, so will run very quickly by comparison. If I were to run them independently, it might put too much of a strain on the server, so I figured this is a good way to get them done (without having to re-generate them which can be tedious).
    4 May 2019, 18:25:13 UTC
    von Veröffentlicht: 04.05.2019 00:30
    1. Kategorien:
    2. Projekte

    Eine komplett überarbeitete Version des SixTrack-Programms hat nun ihren Weg in das BOINC-Projekt gefunden, bisher für Windows (32- und 64-Bit) und Linux (64-Bit) jeweils in einer SSE2- und einer AVX-optimierten Fassung. Neue WUs gab es bisher nur wenige, aber die neuen Funktionen eröffnen so viele neue Möglichkeiten, dass künftige Leerläufe wohl erstmal nicht mehr so lange anhalten sollten wie die nun beendete Pause.

    Neue SixTrack-Version 5.02.05 unter BOINC für Produktivbetrieb freigegeben
    Liebe Freiwillige,

    nach einer langen Entwicklungs- und Testphase freuen wir uns bekanntzugeben, dass wir unter BOINC eine neue Hauptversion von SixTrack haben. Das Entwicklerteam hat eindrucksvolle Arbeit beim Restrukturieren des Codes gemacht, Arrays in dynamische Speicherzuweisung überführt, den Quellcode (der in wenigen, riesigen Quelldateien zusammengefasst war) in fortran90-Module aufgespaltet, die Wartung vereinfacht und eine Menge doppelten Code und riesige Arrays gelöscht - von unzähligen behobenen Problemen, Aktualisierungen der Dokumentation, umgeschriebener Eingabeauswertung sowie Verbesserungen des Erstellungssystems und der Testumgebung ganz zu schweigen.

    Wir haben auch eine Reine neuer Funktionen eingebaut. Die meisten davon sind noch nur auf dem Batch-System am CERN verfügbar (z.B. die Verknüpfung mit Geant4 oder Pythia, Kopplung an FLUKA oder anderen externen Code, Unterstützung für ROOT und HDF5), aber viele können bereits in BOINC-Aufgaben ausgeliefert werden, etwa die Prüfung der Apertur zur Laufzeit, Elektronenlinsen, verallgemeinerte Radiofrequenz-Multipole, Quadrupol-Randfelder und das Hashen von Dateien zwecks Überprüfung. All diese neuen Funktionen werden es uns ermöglichen, neue Maschinenkonfigurationen zu untersuchen und Ergebnisse zu verfeinern, und wir zählen auf eure Unterstützung!

    Vielen Dank nochmals für eure Unterstützung und macht weiter so!

    Alessio für das SixTrack-Team
    03.05.2019, 17:01:25 MEZ

    Originaltext:
    Zitat Zitat von https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5011
    new SixTrack version 5.02.05 released on BOINC for production
    Dear volunteers,

    after a long period of development and testing, we are pleased to announce that we have on BOINC a new major release of SixTrack. The development team made an impressive job to re-factorise the code, porting arrays to dynamic memory allocation, splitting the source code (gathered in few, huge source files) into fortran90 modules, making maintenance easier and deleting a lot of duplicated code and massive arrays - without mentioning countless bug fixes, documentation updates, re-written input parsing, improved build system and test suite.

    We have also implemented plenty of new features. Most of them are still available only on the batch system as CERN (e.g. linking to Geant4 or Pythia, running coupled to FLUKA or other external codes, support for ROOT and HDF5), but many of them can be already deployed by BOINC jobs, like on-line aperture checking, electron lenses, generalised RF-multipoles, quadrupole fringe fields, and hashing of files for checks. All these new features will allow us to study new machine configurations and refine results, and we count on your help!

    Thanks again for your support, and keep up the good work!

    Alessio, for the SixTrack Team
    3 May 2019, 16:01:25 UTC
    Seite 11 von 73 Erste ... 9 10 11 12 13 21 61 ... Letzte
Single Sign On provided by vBSSO