"Logbuch" für wissenschaftliche Simulationen

Im Allgemeinen stimme ich Ihnen zu:

• XML ist weit verbreitet, es gibt Tonnen von Werkzeugen, um das Logbuch in Form zu bringen.
• Es ist flexibel, Sie können später zusätzliche Attribute hinzufügen, ohne alte Skripte zu zerstören
• Es ist dateibasiert, ein Dokument, eine Datei, verwenden Sie das Dateisystem, um Logbuchseiten zu organisieren.
• Es ist dateibasierter und einfacher Text, Tools wie find, grep, diff (auf Knopfdruck) können Ihnen in dringenden Fällen helfen
• Es ist Ihre eigene Lösung, Sie können alle Informationen nachverfolgen, die Sie benötigen, und wenn Sie es für wichtig halten, Sonnenlicht Stunden den Parametern zuzuordnen, tun Sie es.

Das sollte ich hinzufügen, das Speicherformat hängt vom typischen Anwendungsfall ab, wenn Sie herausfinden müssen, warum jeden Montag nach Vollmond der Optimierer keine Lösungen finden kann, wird es schwer (na ja, härter) sein Erstelle den notwendigen XPath / XQuery-Hacker, um weil von der Nicht-Normativität deiner Struktur zu machen.

Nun, all die Schattenseiten, an die ich denken kann:

• Es ist sehr ausführlich, XML-Dokumente in meinem Bereich sind eher 20 bis 40 GB groß, während die Informationen wahrscheinlich in mehr als 500 MB dargestellt werden könnten.
• Es ist langsam (hängt davon ab, wie Sie es verwenden), RDBMs oder sogar Nosql-Lösungen verwenden Techniken wie Indexierung, um Lesen schneller zu machen.
• Es ist flexibel, das ist auch ein Nachteil: Wenn Sie zwei neue Attribute pro Tag hinzufügen, erhalten Sie nur einen markierten freien Text. Wenn Sie ihn in strukturfokussierte Systeme importieren möchten, muss er gründlich poliert werden (SQL, CSV, JSON, ...)
• Es ist deine eigene Lösung, du musst sie schreiben und pflegen

Wie für das zweite Bit: git describe --always HEAD

Die einfachste Option besteht darin, Ihr Programm zu einer reinen Funktion zu machen, d. h. alle sich ändernden und möglicherweise ändernden Parameter in Programmoptionen auszulagern, so dass eine Simulation vollständig durch die Optionen und eine git commit-Kennung spezifiziert wird.

Boost.Program_options hilft sehr bei der Implementierung eines solchen Schemas.

Das hört sich auf einer Programmierseite vielleicht merkwürdig an, aber ich habe mehrere Simulationsarbeiten gemacht, dass das beste Logbuch ... nun ... ein Logbuch war.

Insbesondere habe ich dieses ausführlich genutzt (Link zu Amazon). Es mag sein, dass ich aus einem nassen Labor / Biologie-Hintergrund kam, aber ich fand etwas Anziehendes an einem alten toten Baum-Notizbuch. Es ist zugegebenermaßen nicht automatisiert und wird nicht gut funktionieren, wenn Sie eine große Anzahl von verschiedenen Parameterkombinationen ausführen oder wenn Ihre Simulation eine große Anzahl von Parametern aufweist.

Aber für das Projekt, an dem ich gearbeitet habe, das ungefähr 20 Parameter hat, die variieren könnten, habe ich gerne Freiformnotizen über meine Gedanken aufnehmen können, sie in einer leicht tragbaren, leicht zu erinnernden und ziemlich dauerhaften Form haben, und für viele Kollegen Kollegen, "Keep a lab notebook" schien mit einer physischen Sache besser zu funktionieren.

Ihre Kilometerzahl kann natürlich variieren.

Sie könnten das bestimmte Commit auch kennzeichnen. Einzelheiten finden Sie Ссылка .

Verwenden Sie durch Kommas getrennte oder durch Tabstopps getrennte Werte. Von Menschen lesbar und editierbar, wenig Speicheraufwand, leicht in fast alles (einschließlich R und Excel) zu importieren.

Die Welt der Teilchenphysik verwendet meist ROOT für die Datenerfassung, Speicherung und Analyse. Dies beinhaltet Daten aus der Simulation. ROOT macht es möglich - in der Tat einfach - einen vollständigen Satz von Metadaten zu behalten mit die Ergebnisse.

Wenn wir große Datenmengen haben, behalten wir auch eine Datenbank bei, aber das macht es bequem, Abfragen zu konstruieren: Die eigentliche Aufzeichnung erfolgt in den enthaltenen Metadaten.