Nach großen Änderungen am Programmcode über die letzten Tage und teilweise verschiedenen in Konflikt stehenden Versionen und Ansätzen mussten wir zunächst Zeit darauf verwenden, bisherige Ergebnisse zu sortieren.
Im Anschluss haben wir uns mit Abschnitten aus Perrins „Brownsche Bewegung und die wahre Existenz der Moleküle“ und insbesondere seiner Vorgehensweise bei der Betrachtung Brownscher Teilchen auf verscheidenen Höhenstufen innerhalb einer Probe unter dem Mikroskop beschäftigt, mit dem Ziel, daraus Ideen für unsere eigene Simulation mitzunehmen.
Bei Perrin trat das Problem auf, dass er aufgrund der optischen Einschränkungen seines (trotzdem hochpräzisen) Mikroskops nur jeweils eine kleine Horizontalschicht von weniger als zehn Mal des Teilchendurchmessers Dicke beobachten konnte, die die Teilchen unter Umständen auch schnell wieder verließen.
Angelehnt daran wollten wir unser Programm so umschreiben, dass wir überprüfen können, ob sich das Brownsche Teilchen während 50 Schritten (die Schrittzahl, die Perrin und Chaudesaiges in der berüchtigten Zeichnung zu Papier brachten) in einer bestimmten Schicht befindet. Unseren bisherigen Erfahrungen nach schien diese Zahl allerdings sehr hoch zu sein.
Wir haben dafür zunächst in der Umgebung des bestehenden Programms für Kollisionen in 3 Dimensionen1) eine Projektion auf die XZ-Ebene (also eine Seitenansicht) geplottet, die Horizontalschicht in Form von einer Ober- und einer Untergrenze darauf angelegt und gezählt, wie oft das Teilchen diese verlässt.
Abb.1: Brownsches Teilchen verlässt bei niedriger Teilchendichte sehr schnell die Horizontalschicht
Das Ergebnis der vorangegangenen Betrachtungen ist eng verknüpft mit der zweiten Hauptbemühung des Tages, der Anpassung der Quasi-Platzhalterwerte in der Simulation an tatsächliche physikalische Werte. Wir wollten zumindest annähernde oder aber immerhin begründet abweichende tatsächliche Teilchenradien, Massen und Geschwindigkeiten, Werte für Gravitation und Behältergröße etc. einführen, auch um uns an einem späteren Zeitpunkt evtl. die Arbeit mit weiteren relevanten Größen wie Temperatur oder z.B. der Boltzmann-Konstante zu erleichtern oder überhaupt zu ermöglichen. Allerdings konkretisierten sich dabei unsere Befürchtungen, dass es uns, da wir durch die Beschränkung der Rechenleistung und damit der drastischen Untertreibung der Teilchenzahl, nahezu unmöglich sein würde, stets „realistische“ Werte zu nutzen. Aber auch die Umstellung auf höhere Geschwindigkeiten, längere Zeitintervalle (denn um in einer „kleinen“ Box für einen außenstehenden Beobachter sichtbar zu sein, müssen sich Teilchen entweder sehr langsam bewegen, oder aber es müssen sehr kurze Zeitintervalle betrachtet werden- wir tun bislan defacto letzteres) und kleinere Massen führte uns nur zu fehlerhaften Programmen oder, unter der Maßgabe die Eigenschaften der Simulation in irgendeiner Weise beibehalten zu wollen, für uns nur sehr schwer zu entwirrenden Ketten aus Interdependenzen der verschiedenen Größen. Letztendlich haben wir uns dafür entschieden,nur Verhältnisse zu ändern, die detaillierten Anpassungen ans Ende zu verschieben und uns zunächst weiteren Punkten zu widmen. Nichtsdestotrotz sind weiterhin offene Probleme:
s = markersize²
.(ax2.get_window_extent().width*(BROWNSCHESTEILCHEN_RADIUS/WIDTH)) ** 2)* 72./fig1.dpi
beheben, im 3D-Plot funktioniert diese Methode leider nicht.Weiterzuführen ist hauptsächlich die Untersuchung der Horizontalschicht mit mehr Teilchen und in diesem Zuge auch die historische Beschäftigung mit der Arbeit Perrins und insbesondere seinen diesbezüglichen Messergebnissen, außerdem die generelle Behandlung der Konzentration in Abhängigkeit von den Höhen. Gegebenenfalls müssen wir auf VPython umsteigen. Zudem sollte der Plot für die Geschwindigkeitsverteilung wieder eingefügt und verbessert werden.
Hier wird sehr ausführlich erklärt, was es mit den markersizes in matplotlib auf sich hat stand_13.03._hoehenformel.rar ← Aktueller Stand, enthält sehr rechenaufwendige multiplots. Ggfs. muss main_1_precompute.py ausgeführt werden, um im Voraus eine Animation zu rendern. Das kann je nach Teilchenzahl und Simulationstiefe eine Weile dauern.