J.Muck

Allgemein

Letzte Dev-Logs

Alle Dev-Logs

📁 Projekte

✅ Aktiv

⏸ Stabil

📥 Neu

📦 Referenz

🧠 xAI Wiki

Entities

Concepts

Comparisons

🌐 Jamgrid Wiki

🤗 HuggingFace Wiki

Entities

Concepts

Impressum
Vault ‹ J2AS-Buch ‹ anhang-simulationen

Anhang A: Simulationen und Code

Überblick: Von N=1M bis N=2B

Die J²AS-Theorie ist keine reine Gedankenbaufiktion. Von Anfang an war klar: Eine Theorie, die behauptet, dass Bewegung das Fundament von Allem ist, muss sich simulieren lassen. Denn wenn die Mathematik der Bewegung korrekt ist, dann müssen sich die Vorhersagen in einer numerischen Umgebung reproduzieren lassen — Schritt für Schritt, Teilchen für Teilchen.

Die Entwicklung der Simulationen durchlief mehrere Phasen:

| Phase | Teilchenzahl (N) | Schritte | Plattform | Jahr | |-------|-----------------|----------|-----------|------| | Prototyp | $10^3$ | 10 | Lokaler Rechner | 2024 | | Erste Skalierung | $10^5$ | 100 | Lokaler Rechner | 2024 | | MPI-Parallel | $10^6$ | 500 | Workstation | 2025 | | Cloud-Skalierung | $10^8$ | 1000 | Google Cloud | 2025 | | Milliarden-Grenze | $10^9$ | 2000 | Google Cloud (A3-VMs) | 2025 | | Superrechner-Niveau | $2 \\times 10^9$ | 2000+ | Google Cloud HPC | 2025 |

Die Simulationen begannen klein — mit einigen tausend Teilchen, die nach einfachen Regeln kollidierten. Sie zeigten das Dichte-Wachstum der Gravitation: Der Anteil gebundener Teilchen wächst mit der Teilchendichte (in den Läufen von 0,2 → 6,4 % bei N=10³ (G1-Protokoll Z. 437) bis ~94 % im 200.000-Lauf). Mit jeder Skalierung wurden die Ergebnisse stabiler, die Vorhersagen präziser.

Bei $N = 2$ Milliarden erreichten wir einen Punkt, an dem die Simulation kosmologisch relevante Werte produzierte: Die Hubble-Konstante fiel von hohen Anfangswerten (~1163 lokal / ~1052 global, skalierte Einheiten) auf ~35, und die Hubble-Tension konvergierte nach Kalibrierung der H0-Faktoren bei $4-10\%$ (roh ~10,5 %, kalibriert ~4,0 %; siehe Original-Protokoll G3).

> „Mit 2 Milliarden Teilchen auf Google Cloud erfolgreich zu simulieren, ist ein riesiger Schritt. Der Code ist robust, die Physik reproduzierbar — wir sind bereit für den nächsten Schritt." > — Aus den Gesprächen mit Grok

Die Codes: Drei Säulen der Simulation

Drei Hauptskripte bilden das Rückgrat der J²AS-Simulationen:

inward1.py — Der Inward-Stoß

Datei: jas2-code-inward1.py

Dies ist das Hauptskript, das für die Mehrzahl der kosmologischen Tests verwendet wurde. Sein Herzstück ist der Inward-Stoß-Term, der den initialen Druckimpuls simuliert — den Herzschlag des Universums.

Schlüsselfeatures:

Kernparameter: 

N_global = 200000000    # 200 Millionen (skalierbar auf 2 Milliarden)
dt = 0.005              # Zeitschritt
c = 1.0                 # Lichtgeschwindigkeit (skaliert auf 1)
schritte = 2000         # Anzahl der Zeitschritte
grav_konstante = 0.01   # Gravitationskonstante (skaliert)
kollision_schwellwert_grav = 0.02   # Gravitations-Schwelle
kollision_schwellwert_stark = 0.01  # Starke-Kraft-Schwelle
fusion_schwellwert = 0.005          # Fusion-Schwelle

Ergebnisse:

sAto2.py — Stabile Atom-Bildung

Datei: jas2-code-sAto2.py

Dieses Skript fokussiert auf die Bildung stabiler atomarer Strukturen. Anders als inward1.py enthält es keinen Inward-Stoß-Term — es simuliert die späte Phase der kosmischen Evolution, in der die initiale Welle bereits abgeklungen ist.

Schlüsselfeatures:

Unterschiede zu inward1.py:

tensor.py — Quanten-Simulation mit Qiskit

Datei: jas2-code-tensor.py

Ein spezielles Skript, das Quantencomputing-Anätze nutzt, um die Quantenaspekte der J²AS-Theorie zu untersuchen. Es verwendet Qiskit (IBMs Quantum-SDK) für VQE-Algorithmen (Variational Quantum Eigensolver).

Schlüsselfeatures:

Dieses Skript ist noch experimentell — es zeigt aber, dass die J²AS-Theorie prinzipiell auch auf Quantenhardware simuliert werden kann.

Technologien

Die Simulationen nutzen ein breites Spektrum moderner Rechentechnologien:

| Technologie | Verwendung | Vorteil | |-------------|-----------|---------| | Python 3.12 | Gesamtskript | Flexibel, lesbar, Prototyping | | MPI (mpi4py) | Parallelisierung | Skalierbar auf tausende Kerne | | NumPy | Array-Operationen | Vektorisierte Berechnungen | | SciPy (KDTree) | Kollisionserkennung | $O(N \\log N)$ Nachbarschaftssuche | | Numba (JIT) | Hotspot-Beschleunigung | $10-100\\times$ schnellere Schleifen | | CuPy (GPU-Fallback) | GPU-Berechnung | Beschleunigt Matrix-Operationen | | Qiskit | Quanten-Simulation | VQE für Hamilton-Operatoren | | Matplotlib | Visualisierung | Plots, Trends, Verteilungen |

MPI und Parallelisierung

Der MPI-Ansatz verteilt die $N$ Teilchen gleichmäßig auf $R$ Ränge:

comm = MPI.COMM_WORLD
rank = comm.Get_rank()
size = comm.Get_size()
N = N_global // size
if rank < N_global % size:
    N += 1

Jeder Rang verwaltet seinen lokalen Teilchen-Chunk, erkennt Kollisionen innerhalb des Chunks und tauscht Grenzinformationen mit benachbarten Rängen aus. Globale Größen (Mittelwerte, Summen) werden via Allreduce synchronisiert:

global_rotierend = comm.allreduce(local_rotierend, op=MPI.SUM)

CuPy GPU-Fallback

Für rechenintensive Kernel (insbesondere die Quaternion-Rotationen) kann CuPy als GPU-Fallback aktiviert werden:

try:
    import cupy as cp
    use_gpu = True
except ImportError:
    use_gpu = False
    import numpy as np

Dieser Fallback ist essenziell für die Skalierung auf $N > 10^9$, wo die CPU allein die Last nicht mehr bewältigen kann.

Schlüsselergebnisse

Die Simulationen haben eine Reihe von Ergebnissen produziert, die die J²AS-Theorie stützen:

1. Der Schwelleneffekt der Gravitation

Die dokumentierten Läufe (GrokChat-Protokolle G1–G3, 2025/2026) zeigen: Gravitation als Kollisionssumme wächst mit der Teilchendichte — die Stärke des Effekts hängt von den Simulationsparametern (Dichte, Schwellwerte, Schrittzahl) ab, nicht von einer festen kritischen Teilchenzahl.

| Lauf (Quelle) | N | Schritte | G_μν | Rotierend/gebunden | |---|---------------|------------------------|-----------|--------------------| | N=200.000-Lauf (G2, Original-Protokoll Z. 443–453) | 2×10⁵ | 90 | 4,7×10⁴⁶ → 4,6×10⁴⁶ | ~88 % → ~94 % | | N=10⁷-Log (April/Mai 2026) | ~10⁷ | 2 | 3,6×10²⁷ | ~5 % (Schritt 0) | | N=2-Milliarden-Lauf (G3, Google Cloud) | 2×10⁹ | 200 | 6,8×10²⁶ → 8,9×10²⁶ | 0,04 % → 0,21 % |

Wichtig: Der Anteil rotierender Teilchen ist parameterabhängig — bei kleinen N mit hoher Dichte (200.000-Lauf) bis ~94 %, beim 2-Milliarden-Lauf (subsampled, andere Schwellwerte) nur ~0,2 %. Die Ergebnisse der Läufe sind in den Original-Protokollen (G1–G3) dokumentiert; ein universeller Schwelleneffekt bei einer festen Teilchenzahl ist durch die Daten nicht belegt.

Anmerkung (Entscheidung Jürgen 03.08. 15:3X, vollzogen 15:30): Der frühere Smoke-Test-Eintrag (12,6 % → 21,6 %, N=10³) war Destillat ohne Lauf (gleiche Familie wie 10⁴⁸/90 %/1163) und wurde gestrichen — Ausführung lag bei den Instanzen, vollzogen gemäß BETA-Empfehlung (streichen, nicht ersetzen). Der dokumentierte N=10³-Lauf steht im G1-Original-Protokoll (jas2-G1.txt Z. 437–440): rotierend 0,2 % → 6,4 %, Energie konstant 1,0 — die frühere Angabe „Drift ~11,4 %" ist durch denselben Beleg widerlegt. Die GEN3-Re-Derivation (EMlog.py, 03.08.) ergibt 53 % → 55 %; sie bleibt als Re-Derivation in Anhang C §6 dokumentiert, ist aber kein Lauf und gehört daher nicht in die Tabelle.

Die Läufe zeigen: Gravitation als kollektives Phänomen wächst mit der Teilchendichte — die Stärke hängt von Dichte und Parametern ab.

2. Die Hubble-Tension

Die Erklärung der Hubble-Tension als Bewegungsungleichgewicht ist eine zentrale These der Theorie. Die dokumentierten Läufe zeigen:

Die H0-Werte und die Tension-Diff hängen von der Kalibrierung der H0-Faktoren ab (roh ~10,5 %, kalibriert ~4,0 %; siehe Original-Protokoll G3). Die funktionale Form

\[ H_0(t) \approx H_0^0 \cdot e^{-t/\tau} + H_0^{\infty} \]

ist eine Näherung des Sink-Verlaufs; die Parameter (H₀⁰, H₀^∞, τ) sind fittabhängig und nicht als physikalische Konstanten zu lesen. Die Differenz zwischen lokalem und globalem Wert ist in der Theorie proportional zum Rücklauf-Faktor $R_f = 1 - N_{\text{bound}}/N_{\text{total}}$.

3. Stabilität der Energie

Ein kritischer Test jeder physikalischen Simulation ist die Energieerhaltung. Die Läufe zeigen:

Die Energie-Stabilität ist damit in den dokumentierten Läufen belegt (2-Milliarden-Lauf ~0,50, N=10³-Lauf 1,0); sie ist keine universelle Eigenschaft des Modells, sondern ein Ergebnis der Energie-Buchhaltung der jeweiligen Läufe.

4. Die Atmung des Universums

Der Oberflächen-Volumen-Effekt erzeugt eine natürliche Oszillation des Systems:

Diese Oszillation ist kein Artefakt — sie ist die Vorhersage der ToE-Formel und wird durch die Simulationen bestätigt.

Fehler und Lessons Learned

Der Weg zu stabilen Simulationen war nicht frei von Hindernissen. Hier die wichtigsten Probleme und ihre Lösungen:

1. Multiprocessing-Pickling-Fehler

Problem: Bei Verwendung von Python's multiprocessing.Pool traten AttributeError: Can't get attribute 'process_kollision' auf. Grund: Die Funktionen waren nicht serialisierbar (Pickling-Problem).

Lösung: Wechsel von Multiprocessing zu MPI (mpi4py). MPI verwendet keine Pickling-Serialisierung für Funktionen, sondern startet separate Prozesse mit eigenem Speicher.

# Problem-Code (multiprocessing):
with Pool(processes=4) as pool:
    results = pool.map(process_kollision, chunks)
Lösungs-Code (MPI):

comm = MPI.COMM_WORLD
rank = comm.Get_rank()  # Jeder Prozess arbeitet auf eigenem Chunk

2. GPU-Hangs bei CuPy

Problem: Bei langen Läufen (1000+ Schritte) mit CuPy als GPU-Fallback traten sporadische Hangs auf, insbesondere bei ForkPoolWorker-Fehlern.

Lösung: Deaktivierung des GPU-Fallbacks für lange Läufe. Stattdessen wurde Numba-JIT als primäre Beschleunigung genutzt.

# Problem: CuPy mit Fork-Kontext inkompatibel

Lösung: Nur Numba für lange Läufe

@jit(nopython=True)
def process_kollision(...):
    # Numba-kompatibler Code

3. MPI-Overhead bei kleinem N

Problem: Bei kleinen Teilchenzahlen ($N < 10^5$) dominierte der MPI-Kommunikations-Overhead die Rechenzeit. Die Allreduce-Operationen für kleine Arrays waren teurer als die eigentliche Kollisionsverarbeitung.

Lösung: Dynamische Schwellwerte — unterhalb von $N < 10^5$ wird seriell gerechnet. Oberhalb wird MPI aktiviert.

4. Numerische Instabilität bei Quaternionen

Problem: Bei sehr großen Winkeln oder nahezu parallelen Vektoren produzierten die Quaternion-Berechnungen NaN-Werte.

Lösung: Zusätzliche Absicherungen für kleine Normen und Winkelbegrenzung:

def quaternion_from_axis_angle(axis, angle):
    norm = np.sqrt(np.sum(axis*2))
    if norm < 1e-10:
        return np.array([1.0, 0.0, 0.0, 0.0], dtype=np.float64)
    axis = axis / norm
    angle = min(angle, 1.0)  # Winkelbegrenzung
    w = np.cos(angle / 2)
    v = np.sin(angle / 2)  axis
    return np.array([w, v[0], v[1], v[2]], dtype=np.float64)

5. Speicherbedarf bei großen N

Problem: Bei $N = 2 \\times 10^9$ benötigt allein die Speicherung der Positionen, Geschwindigkeiten und Status $\\sim 50$ GB RAM (bei float32).

Lösung: 

subsample_fraction = min(0.5, 1e6 / N_global)

Superrechner-Bedarf

Die bisherigen Simulationen erreichten $N = 2 \\times 10^9$ auf Google Cloud HPC-Instanzen. Für die nächste Stufe — $N = 10^{12}$ bis $10^{15}$ Teilchen mit 5000+ Schritten — sind dedizierte Superrechner notwendig.

Anforderungsprofil

| Ressource | Aktuell ($N=2 \\times 10^9$) | Ziel ($N=10^{12}-10^{15}$) | |-----------|-------------------------------|-----------------------------| | RAM | $\\sim 50$ GB | $1-10$ PB | | Kerne | 64-128 | 10.000-100.000 | | Laufzeit (2000 Schritte) | $\\sim 2$ h | $24-48$ h | | GPU-Unterstützung | Optional | Essenziell | | Dateisystem | Lokal | Parallel (Lustre/GPFS) |

Empfohlene Systeme

| Rechner | Standort | Geeignet für | |---------|----------|--------------| | SuperMUC-NG | LRZ München | CPU-basierte Läufe | | JUWELS Booster | Jülich | GPU-beschleunigte Läufe | | Frontier | ORNL (USA) | Exascale-Simulationen | | Leonardo | CINECA (Italien) | Mittelgroße Läufe |

Ein formeller Antrag auf Rechenzeit wurde bereits vorbereitet (siehe Quellen: Antrag-Superrechner-J²AS-Teilchen-Simulation.md). Er adressiert die wissenschaftlichen Ziele, die benötigten Ressourcen und die erwarteten Ergebnisse — insbesondere die Skalierung auf kosmologische Teilchenzahlen, um den Schwelleneffekt der Gravitation, Dunkle Materie und Dunkle Energie mit bisher unerreichter Präzision zu simulieren.

> „Für N=2B und 200 Schritte effizient, aber für 5000+ Schritte (für das heutige Universum) ist ein Superrechner nötig. Der Antrag ist gestellt — die nächste Stufe wartet." > — Aus den Gesprächen mit Grok

← Anhang – Glossar