Closed soundglider closed 10 years ago
hoihoi!
abwicklung und nahtzugabe siehst du in "visual_test_flattened_glider". zu den entsprechenden schnitten werde ich noch skizzen hochladen. unsere "vision" ist in erster instanz eine sammlung von tools um einheitliche schnittmuster mit möglichst wenig nachbearbeitungszeit zu erzeugen.
da alles noch ziemlich im aufbau ist ändern sich die dinge zu schnell als dass es sinn macht diagramme zu zeichnen und alle klassen voll auszudokumentieren. allerdings habe ich angefangen ein bisschen zu dokumentieren: http://openglider.readthedocs.org/en/latest/ (getting started/interactive shell zeigt die idee) Ein wiki ist gut, ich glaube aber dass sich das auch sehr gut mit readthedocs lösen lasst, und beiträge können gemeinsam mit entsprechendem code mit git versioniert werden. ich werde die tage beginnen ein paar klassen zu erläutern.
lg und danke für deine zeit! ;)
hallo,
hast du dir dokumentation und tests angeschaut? die meisten punkte die du angesprochen hast funktionieren schon halbwegs (.obj export für openfoam, abwicklung 3d->2d,..) dokumentation ist nicht gerade umfangreich, aber zb mit 'ipython notebook' lassen sich die klassen sehr leicht erkunden um zb die dokumentation zu erweitern ;) ipython wäre wohl auch das mittel der wahl für einen (zukünftigen) produktiveinsatz...
lg! simon
das hätt ich mir fast gedacht...
Hay,
könntet ihr eine etwas detailliertere Beschreibung des grundlegenden Konzepts - z.B. ins Readme - schreiben?
Folgende Fragen sollten beantwortet werden: Wie stellt ihr euch den Designprozess in Einzelschritten vor? Wie funktioniert dabei die Klassen-/Objektstruktur, wie unterstützt sie den Designer (Vielleicht in einem Diagramm darstellen...)? Welche automatisierten Funktionen gibt es / sind geplant? (z.B. Ballooning mit FEM/CFD Kopplung ausrechnen, Modul für Export/Meshing/Sim in XFoil/OpenFOAM, Abwicklung der gekrümmten Flächen auf ebene Schnittmuster, Nahtzugabe...)
Wichtig wäre dabei nicht nur der jetzige Stand sonder auch eure Vision im Detail. So können potenzielle Mit-Programmierer besser an einem gemeinsamen Ziel arbeiten :-)
Da das Projekt ja im Endeffekt ziemlich umfangreich ist, wäre vielleicht auch ein Wiki nicht schlecht, in das alle Entwickler eine detailliertere Beschreibung ihrer Module/Klassen reinschreiben könnten.