create submodule diagnostics

[skuschel]

diagnistics: function from shot to result.

[skuschel]

Moin! Ich habe die datasources sortiert, aber bei den Diagnostiken bin ich jetzt nicht durchgekommen -- insbesondere, da ich es auch gerade nicht testen kann. Koenntest du die in das diagnostik submodul sortieren? im Prinzip sollten die filterfactories.py und die filters.py in dem diagnostic submodul aufgehen, wenn sie einen shot als input erwarten.

Erwarten die Funktionen daten als input sind es eigentlich eher algorithms, oder? Oder sie gehoeren halt in eine neue gemini2018.py in einem userconfigs oder examples submodule? Evtl koennen die examples ja dann auch gleich wieder als tests laufen, so wie bei postpic.

[Ablinne]

Die meisten der Funktionen nehmen ein Field als input, viele davon geben auch wieder ein Field aus. Die meisten Diagnostics sind Ketten (Pipes) von solchen Funktionen. Vor PR #16 gab es noch die Filter LoadImage und ReadRaw, die einen Shot als input hatten und die meisten Ketten haben mit einem davon angefangen. Die Ketten waren also am Ende "Diagnostiken", wurden aber erst im Setup-File konstruiert. Mit den LazyReadern im Shot ist es jetzt so, dass die meisten Ketten mit "GetItem" anfangen um den Lazy access durchzuführen. Mir ist unklar, wie wir das so genau sortieren sollen. Im Prinzip ist die filterfactories und filters nur ein Lego-Baukasten um sich dann im Setup die nötigen Diagnostics aufzubauen.

[skuschel]

Der Baukaste muss natuerlich erhalten bleiben. Da oben drauf wuerde ich aber Ketten, die man gerne wiederverwendet in einem Modul sammeln. Vielleicht sogar in submodules diagnostics.gemini oder diagnostics.lclsneh oder auch thematisch diagnostics.magnetspectrometer. Ich denke dass es total okay ist dort eine substruktur zu bauen, in die man leicht seine eigenen routinen einbauen kann und an die wir keine so grossen Anforderungen setzen.