Ausgangsversion für alle Änderungen

Grundlegende Version für alles weitere ist ​benchmark-1.1.

Roadmap

1. [Lukas] JuBE als Test zum Vergleich der jeweils einzelnen Entwicklungsstände, mögliche Testparameter:
   • Trajektorien und Anzahl der Wechselwirkungen einzelner Teilchen (erste, letzte, irgendwelche in der Mitte - nur halt immer dieselben :-) ) ^{​benchmark-1.2}
   • Energie^{​benchmark-1.4} (im Madelung-Test)
   • Gesamtimpuls
   • Coulomb-Explosion Beispiel aus der heraeus-branch. Vergleich der Daten zur radialen Teilchendichteverteilung.
2. [Jeder] Alle branches, die nicht zurückgeführt werden können oder sollen, werden in archive verschoben und nicht weiter genutzt.
3. Statustreffen aller Beteiligten
4. Einzufügende Modifikationen in folgender Reihenfolge:
   1. [Mathias] alle (!!) Compilerwarnungen beseitigen (siehe Attachment) ^{​benchmark-1.3}
   2. [Mathias] periodische Randbedingungen, changes von ​hier und ​hier ^{​benchmark-1.4}
   3. [Robert] Baumaufbau mit _local, _global, _exchange statt der alten Struktur? Speicherbedarf prüfen! ^{​benchmark-1.5}
   4. [Helge] neuer branching Algorithmus
   5. [Helge] Hilbertkurve
   6. [Robert & Lukas] Sortierer & tree_domains() aufräumen. Ganz alte Sortierer weg, sl_parts entfernen, evtl. pbalsort in Bibliothek kapseln.
   7. [Lukas] Reduced tree #41
   8. [Robert & Mathias] Memwatch, flexible shortlist-Länge. sollte auf jeden Fall nach Bedarf abschaltbar sein. Ausserdem ist die Überwachung des genutzten Speichers eine gute Messgröße gegen algorithmische Fehler
   9. [Lukas & Paul] OpenMP: tree_walk() & sum_forces() Parallelisierung sowie Überlegungen zu weiteren OpenMP-Ansätzen
      • Schlüsselgenerierung
      • tree_build: die einzuordnenden Schlüssel in "chunks" aufteilen die jeder Thread einordnet? (gleichzeitiger Zugriff auf Hashtable der einzelnen Threads)
   10. [Lukas] I/O. Converter Sion/Binär/ASCII-PEPC --> VTK verfügbar machen. #40
   11. [Mathias] Beispiele und andere Neuerungen (z.B. timings-modul) aus heraeus-branch einfügen & zugehörige Dokumentation vorbereiten.
5. All diese Änderungen in ​ScaFaCos einfügen. #39
6. Benchmark-Daten generieren und auf benchmark/results updaten. #33

Richtungsentscheidungen

• Wechselwirkungslisten bleiben uns bis auf weiteres erhalten, da sie bessere Lastverteilung garantieren. ^{mit pthreads-walk weggefallen}

Denkbare Modifikationen fuer Eingabeparameter

• Festlegung auf zwei-Sorten-Systeme beseitigen indem die Anzahl NS der Teilchensorten als Eingabeparameter uebergeben wird. Die Teilchenzahl-Eingabeparameter, Massen, Ladungen, etc. sind dann entsprechend Vektoren mit NS Komponenten. Statt des oder zusaetzlich zum PELabel koennte man dann auch ein Array mitfuehren, dass den Teilchensortenindex angibt. Insbesondere alle Auswerteroutinen wuerde das deutlich vereinfachen (z.B. Summation der Energie fuer alle Sorten einzeln, wie es momentan fuer Ionen und Elektronen separat, unterschieden am Label, gemacht wird),
• sollte man danach das setup mal aufraeumen? Beispielsweise mit einer Kombination aus den folgenden drei Parametern:
  • setup_geometry (entspricht weitestgehend dem was momentan in special_start ist, siehe auch randion.f90 in pepc-b):
    • 0: alle Teilchen erstellt aber im Ursprung positioniert (fuer evtl. eigene Modifikationen mit dem setup_modifications parameter)
    • 1: homogen gefuellter Wuerfel ( 0..1 x 0..1 x 0..1 )
    • 2: homogen gefuellte Kugel (Zentrum im Ursprung, Durchmesser 1)
    • 3: zwei homogen gefuellte Kugeln (Zentrum entlang der x-Achse um +/- 0.2 verschoben, Durchmesser 1)
    • 4: Plummer Verteilung nach ​Astronomy and Astrophysics, vol. 37, no. 1, Dec. 1974, p. 183-187.
    • 5: homogene Verteilung auf einer Kugeloberflaeche (momentan deaktiviert, da scheinbar unvollstaendig)
    • 6: 2D homogene Verteilung ( 0..1 x 0..1, z=0 )
    • 7: 3D Madelung-Setup (erst ab periodischer Version benchmark-1.4 dann implementiert)
    • ... ?
  • setup_modifier: Parameter, um die vorigen Setups zu Modifizieren, also beispielsweise
    • Teilchen zu verschieben
    • Ladungen/Massen zu aendern etc...
    --> Dies waere ein Platz um dann Nutzereigene Veranederungen einzupflegen. Mit z.B. setup_geometry=0 waeren alle Teilchen vorhanden, Labels, Massen, Ladungen etc. vorbelegt und koennten angepasst werden ohne viel von pepc-Interna wissen zu muessen.
  • setup_velocities: Parameter um die Geschwindigkeiten der Teilchen anpassen zu koennen, z.B.:
    • 0: alle Teilchen in Ruhe
    • 1: Maxwellverteilung fuer alle Teilchen mit vordefinierten Temperaturen fuer die einzelnen Spezies
    • ... ?

Notwendige Gedanken

• [Paul] sophisticated prefetch implementieren, also vorher gut überlegen, was benötigt wird. Kaputte prefetch-Routine archivieren. #38
• Ist der Reduced-tree Ansatz überhaupt noch notwendig wenn eh alle Informationen über die branches von vornherein verfügbar sind? #41
• Nicht in jedem Schritt sortieren? --> evtl. an Michael Hofman auslagern im Sinne von vorsortierten Teilchen.
• SMPSS Implementierung ^{​text.smpss}
• [Helge] nach dem Sortieren Teilchen/Keys verschieben um die effektive Anzahl von branches zu verringern. Evtl. Michael Hofmann fragen, ob durch 8 teilbare Grenzen das ganze sogar schneller ginge. Dann könnte man beim Sortierer anfordern, die Grenzen jeweils auf einer maximalen Baumebene zu setzen oder so. ^{ist so ähnlich schon im Sortierer umgesetzt}
• evtl. konsistente sourcecode-documentation mit doxygen anstreben ? #30
• kann man langfristig evtl. auf fields_p verzichten? (--> Entmisten von tree_prefetch usw.)
• kann man statt der flachen x-, y-, z-Felder usw. nicht lieber einen strutkturierten Datentyp (record / struct) verwenden, um den Verwaltungsteil des Codes lesbarer zu machen? (Argument dagegen: Der mathematische Teil des Codes, i.e. die Multipolentwicklung ist evtl. in der derzeitigen Version lesbarer).^{source:branches/newstruct}
• kann man die sum_irgendwas Routinen ins Frontend verlagern (insbesondere solche, die eh nur eine Schleife ueber alle Teilchen sind und nicht die Wechselwirkungslisten brauchen). Evtl. kann man auch das Bibliothekskonzept ganz im Sinne eines Frameworks uminterpretieren (d.h. "das frontend muss Routinen namens xyz bereitstellen die vom Backend gerufen werden). Sowas wie ScaFaCos bzw. die Bibliothek an sich waere dann nur ein zusaetzliches Frontend wie auch pepc-e.^{source:branches/newstruct/src/frontends/pepc-s bzw. #12}