[Dune] Re: Deeskalation und stay cool.

Thu Feb 23 09:34:10 CET 2006

Morgen Robert,

ich finde es sehr verständlich, dass du dich ab April vollkommen deiner 
Diss widmen willst. Das muss absolute Priorität haben. Punkt.

Trotzdem finde ich es natürlich bedauerlich, dass du dich mit einem 
"bitteren Nachgeschmack" von Dune verabschiedest. Der Grund ist 
sicherlich mangelnde Kommunikation, wobei ich aber den Eindruck habe, 
dass Christian, Du und Oliver auch bei der Kommunikation gerne 
aneinander geratet. Das fand ich nicht gut und habe mich bemüht die 
Wogen zu glätten aber das ist wohl nicht meine Stärke.

Auf die einzelnen Punkte will ich jetzt nicht wieder eingehen, ich 
glaube aber, dass wir in mehr Dingen einig (z.B. Komplexität, 
Wichtigkeit von Effizienz, Copykonstruktoren, Backup/Restore) statt 
uneinig (Bedeutung von const, Geschwindigkeit von SGrid, iteration count 
im grid) sind. Entschuldigung, dass ich "collective communication" so 
einfach eingebaut habe. War nicht gut.

Grüße

-- Peter

Robert Kloefkorn schrieb:
> Hallo Dune Entwickler,
> hallo Peter, hallo Oliver, hallo Christian, hallo Markus,
> 
> 
> ich möchte hiermit bekanntgeben, dass ich mich nach der Veröffentlichung 
> von Dune 1.0 aus der Dune Entwicklung zurückziehen werde. Besser gesagt, 
> werde ich noch bis Ende März/Anfang April einen Teil meiner Zeit dem 
> Projekt zur Verfügung stellen. Danach werde ich mich ausschließlich um 
> meine Dissertation kümmern. Das ist sicher der wichtigste Grund für 
> diesen Entschluss, wobei allerdings bei mir bisher keine Klarheit 
> darüber herschte, wie ich mich entscheiden sollte, da ich sehr viel in 
> dieses Projekt investiert habe. In den letzten Wochen ging es im Projekt 
> allerdings wieder so drunter und drüber, dass ich, um vor allem für mich 
> Klarheit zu schaffen, in welcher Beziehung ich in Zukunft zu diesem 
> Projekt stehen möchte, nun zu dieser Entscheidung komme. Ich möchte auch 
> klarstellen, dass ich in dieser mail ausschließlich für mich spreche. 
> Weiterhin ist diese mail nicht als "große Abrechnung" zu betrachten. Ich 
> lege Wert darauf, auch weiterhin Kontakt zu allen Mitgliedern des Dune 
> Entwicklerteams zu halten. Falls ich in dieser mail Formulierungen etc. 
> verwende, die dem Einen oder Anderen mißfallen, bitte ich dies zu 
> entschuldigen. Diese mail ist dazu gedacht, mich zu erklären, und nicht 
> um noch mehr Unfrieden zu stiften.
> 
> Es entsteht sicher der Eindruck, es handelt sich um eine 
> Kurzschlußaktion. Dies ist nicht so. Im letzten Jahr der Dune 
> Entwicklung ist so viel schief gelaufen (aus meiner Sicht), dass dies 
> nur die letzte Konsequenz einer längeren Entwicklung ist, die sicherlich 
> durch meine hohen persönlichen Investitionen in dieses Projekt 
> hinausgezögert wurde. Für ein besseres Verständnis meiner Entscheidung 
>  führe noch kurz einige Gründe auf, die die Situation aus meiner Sicht 
> darstellen und für mich Gründe sind, nach 1.0 nicht länger an der Dune 
> Entwicklung teilzunehmen.
> 
> 1) Kommunikationsdefizite -- Die "Eskalationen" der letzten Wochen sind 
> nur ein Problem mangelnder Kommunikation, aus meiner Sicht jedenfalls. 
> Diese behindern die Arbeit jedoch erheblich. Ich habe mehrfach 
> Vorschläge zur Verbesserung dieses Problems gemacht, welche jedoch mehr 
> oder weniger ignoriert wurden. Deshalb bin ich nicht länger bereit, 
> Beeinträchtigungen meiner Arbeit aufgrund dieser Kommunikationsdefizite 
> hinzunehmen.
> 
> 2) Interface und Implementierungen sowie Interfaceerweiterungen -- Viele 
> Diskussionen der letzten Zeit handelten meiner Ansicht nach davon, wie 
> etwas zu implementieren sei, nicht aber, was eigentlich Schnittstelle 
> sein soll. Angefangen von der EntityPointer Geschichte, wo sehr viel der 
> Implementierung und nicht nur (wie es eigentlich sein sollte) das 
> Interface vorgeschrieben wird. Auch finde ich es komisch, das zwar 
> Sachen, die z.B. in Berlin oder Heidelberg als wichtig erachtet werden 
> (GeometryType oder CollectiveCommunication), einfach in das Interface 
> integriert werden, ohne das darüber diskutiert wird in einer Art und 
> Weise, die auch auf die Konsequenzen hinweist. Auf der anderen Seite 
> werden dann Sachen, die aus unserer Sicht sinnvoll sind, mit "completly 
> against" usw. verhindert. Dabei haben wir uns immer sehr sorgfältig 
> darum gekümmert, welche Konsequenzen auftreten können und in wieweit das 
> von allen Gitterimplementierungen mitgetragen werden kann, gekümmert.
> Mit anderen Worten, ich verstehe nicht wie ihr gegen etwas sein könnt, 
> von dem wir 1) überzeugt sind, dass wir es benötigen, 2) uns Gedanken 
> über Ort,Zweck und Konsequenz für andere Implementierungen gemacht haben 
> und 3) die Implementierungsarbeit übernehmen würden. Auf dieser 
> Grundlage läßt sich aus meiner Sicht nicht weiter zusammen Software 
> entwickeln. Mit einer Schnittstelle, in welcher wichtige Funktionalität 
> fehlt, kann ich nicht zufrieden sein. Zeit ist hier ein Problem. Ich 
> möchte nicht erst in 5 Jahren fertig sein, deshalb ist es wichtig, 
> gewisse Dinge in 1.0 zu haben und nicht auf die Weiterentwicklung zu 
> verweisen.
> 
> 
> 3) Effizienz vs. "Schönheit" -- Ich hatte vielfach den Eindruck, an 
> einem Paket für numerische Simulationen mitzuentwickeln, bei welchem 
> Effizienz nicht an vorderster Stelle steht, auf jeden Fall nicht, was 
> den Einsatz von man-power betrifft. Const-Konzept, Copy Konstruktoren, 
> etc. schön und gut, aber nutzlos (zumindest, wenn man wie ich mit der 
> Motivation, etwas effizient rechnen zu wollen, heran geht). Damit 
> rechnet man nichts aus. Dune wird nicht daran gemessen, ob Iteratoren 
> Copy Konstruktoren haben oder nicht. Und das der Code schöner geworden 
> ist, kann man leider auch nicht behaupten. Erst jetzt, da ich seit ca. 3 
> Monaten einem HiWi erklären muss, wie gewisse Sachen implementiert 
> werden sollen, ist mir richtig aufgefallen, wie kompliziert der Code 
> geworden ist, nur damit gewisse softwaretechnische Konzepte verwirklicht 
> werden konnten, die nicht zum Endziel, etwas effizient rechnen zu 
> können, beitragen. Desweiteren verstehe ich nicht, wieso wir den Aufwand 
> betreiben, eine Schnittstelle zu entwickeln, die insbesondere auch 
> struktuierte Gitter einbindet (effizient?), die Implementierungen dazu 
> jedoch entweder langsam oder nicht Schnittstellen konform sind. Diese 
> Tatsachen möchte ich nicht länger in irgendeiner Weise nach "außen" 
> vertreten müssen. Dies ist jedoch nur ein Punkt aus der konvexen Hülle 
> von Adaption, LocalIdSet vs. HierarchichIndexSet, SubEntitäten, 
> Gitterkonstruktoren, Backup/Restore, wo ich explizit die von Dune 
> (zumindest Dune HD/B) vertretene Meinung nicht teile bzw. die Diskusion 
> darüber leid bin und desweiteren auch nicht bereit bin Konsequenzen, die 
> sich daraus ergeben (z.B. gurkige workarounds, die enstehen, weil ich 
> nicht auf die Funktionalität verzichten möchte, oder weil sich er 
> offizielle Weg als uneffizient erweist), weiterhin mitzutragen.
> 
> 
> 4) Baut auf und reißt nieder, dann habt ihr Arbeit immer wieder --
> Inzwischen habe ich aufgehört, die Änderungen, die ich an bestehendem 
> Simulationscode durchgeführt habe, damit er __wieder__ läuft, zu zählen. 
> In dieser Hinsicht lehne ich das Vorgehen, dass sich in Dune 
> eingebürgert hat (wenn es die Schnittstelle schöner macht, dann hat es 
> oberste Priorität), ab. Ich habe keine Lust mehr, ständig Änderungen 
> druchzuziehen, die ich teilweise als nicht sinnvoll erachte, die jedoch 
> meinen Code in kritischer Art und Weise betreffen und meherere Tage und 
> Wochen Arbeit nach sich ziehen. Dies ist vor allem im Hinblick auf meine 
> Dissertation nicht akzeptabel. Ich möchte mit Dune was rechnen und nicht 
> die perfekte Schnittstelle programmieren. Ich hatte das Gefühl, das 
> Andere im Projekt das anders sehen. Das ist ja kein Problem, beide Ziele 
> haben ihre Berechtigung. Ich werde auf jeden Fall keine Arbeit mehr in 
> die Vereinigung dieser konträren Ziele investieren.
> 
> 
> 5) Meine Gesundheit -- Ich habe mich in den letzten Monaten so viel über 
> Dune geärgert, dass ich, bevor es zu gesundheitlichen Schäden 
> meinerseits kommt, die Konsequenzen ziehe. Aus diesem Grund sage ich 
> auch ganz klar, dass ich noch im März an Dune arbeite und helfe, das 
> Release zu verwirklichen. Unabhängig vom Release Datum werde ich mich 
> danach voll und ganz auf meine Dissertation konzentrieren.
> 
> 
> So viel ein kleiner Auszug aus meiner Sicht auf die Dinge. Wie immer 
> besteht viel Interpretationsspielraum, wie das bei mails halt so ist. 
> Ich hoffe niemanden beleidigt zu haben oder dergleichen.
> 
> Ich werde gleich morgen mit frischer Kraft am Gelingen von Dune 1.0 
> weiterarbeiten.
> 
> Ein gute Nacht wünscht:
> 
> Robert
> 
> _______________________________________________
> Dune mailing list
> Dune at hal.iwr.uni-heidelberg.de
> http://hal.iwr.uni-heidelberg.de/cgi-bin/mailman/listinfo/dune
> 
> 

-- 
------------------------------------------------------------------
Peter Bastian, IWR,Uni Heidelberg, INF 348,R 020, 69120 Heidelberg
email: Peter.Bastian at iwr.uni-heidelberg.de   Tel: +49 6221 54 4984
WWW: http://www.iwr.uni-heidelberg.de/~Peter.Bastian Fax: ... 8860