iwt – Referenzprojekt der Modul-Architektur

Zusammenfassung

iwt (IWT-Simulation, Weber-Dynamik) ist das Referenzprojekt der Modul-Architektur: Es zeigt, wie die eigenen Bibliotheken in einer realen Anwendung zusammenspielen. Die Anwendung ist bewusst dünn – das GUI-Skelett kommt aus libraries/gui, die GPU-Rechnung aus libraries/ocl, Vektoren aus libraries/vector, Strings aus libraries/string. iwt liefert nur noch die eigentliche Logik und die App-spezifische GUI-Schicht.

Benutzung der Bibliotheken (real)

  • gui – Virtual-Hooks in Reinform. Die Bibliothek deklariert weak Defaults; iwt/src/gui.c definiert sie stark:
    callback bool gui_application(gui_event_type_t event, gui_application_t core);
    callback void gui_main_window(gui_main_window_t core, gui_event_t e);
    callback void gui_button(gui_button_t core, gui_event_t e);   /* Motion/Beta/Gamma/Threshold */
    callback void gui_gl(gui_gl_t core, gui_event_t e);           /* Realize/Render */
    Die Bibliothek liefert Ablauf + GTK-Signale, die App die Logik – exakt das api-Muster aus dem api-Artikel.
  • ocl – GPU-Kernel für Flux, q-Aktualisierung, Massen-/Ladungs-Rechen, Redshift-Dämpfung, Cluster-Wellen (OCL_KERNEL_IWT_*).
  • vector – 3D-Vektorrechnung (long double) für die Weber-Kräfte-Dynamik.
  • string – gebundene Strings/Pfade (Konfiguration, Pfad-Helfer).

Projektstruktur

src/
├── main.c, init.c              # Einstieg, Init-Cfg/-Runtime (private Interna)
├── gui.c, gui_input.c,         # App-GUI-Schicht: Callbacks, Kamera,
│   gui_math.c, gui_shader.c    #   Mathe/Shader für die Darstellung
├── iwt_kernel.c, iwt_kernel_frozen.c   # Simulationskernel (CPU-Seite)
├── iwt_detect_cluster.c,       # Cluster-Detektion (flood fill)
│   iwt_move_cluster.c          # Weber-Kräfte-Bewegung (private Helfer)
├── iwt.c, iwt_analysis.c, dodecahedron.c
└── python/analyse.py           # nur Auswertung (Python = unterstützend)

Die Einheiten der Simulations-Schichten sind Modul je Konzept (iwt_kernel, iwt_move_cluster, iwt_detect_cluster, gui_*), interne Helfer sind private (aus api) innerhalb der eigenen .c.

CMake-Muster (App-Seite)

Alle Bibliotheken kommen per add_subdirectory (transitiv PUBLIC, siehe Modul-Konventionen):

add_subdirectory(../../libraries/ocl ${CMAKE_BINARY_DIR}/ocl)
add_subdirectory(../../libraries/string ${CMAKE_BINARY_DIR}/string)
add_subdirectory(../../libraries/gui ${CMAKE_BINARY_DIR}/gui)
add_subdirectory(../../libraries/vector ${CMAKE_BINARY_DIR}/vector)
target_link_libraries(iwt PUBLIC ocl string gui vector m PkgConfig::GDKPIXBUF)

Weitere Konventionen: add_compile_definitions(_POSIX_C_SOURCE=200809L), Ausgaben nach ${CMAKE_BINARY_DIR}/lib und /bin, Projekt-Stand in PROJECT_STATUS.md (zuständig für die nächste Entwicklungs-Session / KI: Performance, Engpässe, Optionen, Konventionen).

Abhängigkeits-Closure (alle PUBLIC)

iwt ──► gui ──► logging, threading, string, api
    ──► ocl ──► logging, threading, api
    ──► vector, string            (+ System: m, gdk-pixbuf, GTK3, OpenCL)

Das komplette Closure ist inzwischen öffentlich unter GitHub mit Apache-2.0 – das Referenzprojekt liefert damit auch den Beleg, dass die Bibliotheken konsistent und eigenständig baubar sind.

Quellen

  • apps/iwt (CMakeLists.txt, src/*), libraries/{gui,ocl,vector,string}
  • Repos (Apache-2.0): iwt, gui, ocl, vector, string

Verwandte Artikel