lp:schroedingersolver

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

23. By Alexander Erlich on 2009-10-08

- finished the documentation. The complete documentation is now available
  in the branch's root folder as readme.pdf.
- executed 'make test' and 'make test_lite' on a different Ubuntu machine:
  all tests were successful.
- added &'s to the makefile's plotting commands (like '> $ plot_command &')
  so the tests are not interrupted by xmgrace plots.

22. By Alexander Erlich on 2009-10-08

[io.f90]
- added compare_data, which serves to make autotest modular. Most of the source code
  which formerly was in autotest is now in compare_data. Now, the programs autotest
 and the newly added autotest_lite (see [makefile]) both use compare_data
- compare_data now also writes error logs when a test was not successful
- write_funcs
 o corrected file output (which held faulty formating information)
 o replaced multiplier in the parameter list by logical whichFfuncs
   (so the multiplier is evaluated internally, but not shown to the outside)
- added filename output in openerror function and adapted openerror calls
- tooClosePoints did an interval endpoint comparisons which has no effect
  in THIS routine. All of the endpoint comparisons moved to checkIntervals
- if tooClosePoints needs to move some interpolation points, a warning is displayed.
  If later in the code, the intervals are found to be inconsistent, a reference
  is made to that warning, making it easier to trace the reason for program
  termination

[main.f90]
- re-inserted write_funcs and thereby abbreviated code
- re-inserted the writing of the sorted discrpot file (as required by importfile)

[makefile]
- added test_lite (called via 'make test_lite', see autotest_lite for explaination)
- expanded plotting capabilities with xmgrace:
 o 'make test' and 'make autotest' now also do some plotting. After the
   comparison of each of the four examples, the both ewfuncs and discrpot are
   shown in one (common) plot
 o 'make solveSGL' now does the same kind of plotting as 'make test'

[autotest.f90 and autotest_lite.f90]
- the normal autotest uses 1999 interpolation points and takes quite a while
  (~7min on my machine). autotest_lite works with 500 points and takes a couple of
  seconds (useful for program testing purposes)
- autotest_lite is completely successful on my machine. the normal autotest partially
  failed on my machine (pottopf3 failed, everything else worked fine). I have overridden
  the pottopf3 files with my own files. On my machine, the test is completely successful
  now. We will test other machines, too.

[all code files]
- All comments, as well as screen outputs, are now entirely in English. Many comments
  had to be entirely re-written and now are much more concise and to-the-point. There
  is no more reference to commit messages, and the overly long comments were
  outsourced to the PDF documentation.

21. By Live session user <ubuntu@ubuntu> on 2009-09-29

Inputdaten für Test beim letzten commit (ausversehen) nicht geadded, da
sie ignoriert wurden.

20. By Live session user <ubuntu@ubuntu> on 2009-09-29

- Autotest implementiert -> make test !!! (autotest.f90)
- Alle *.dat-Dateien werden nun richtig geschrieben, auch wfuncs.dat und ewfuncs.dat
  (main.f90)
- linInterp (math.f90) repariert. Für die do-Schleife war eine Bennenung notwendig, damit
  diese dann auch verlassen werden konnte

19. By Live session user <ubuntu@ubuntu> on 2009-09-28

[main.f90]
- unnötige Variablen entfernt
- wfuncs.dat wird mit Hilfe von wfuncsAr geschrieben (nur als test, es
kann von mir aus auch die momentane Funktion write_funcs benutzt werden)
- energies.dat wird nun geschrieben (sollen da echt nur die eigenwerte
rein?)

[io.f90]
- Parameter WRITE_FORMAT eingeführt
- explizite Schreibformate (unteranderem mit WRITE_FORMAT) eingeführt

[misc.f90]
- lapack-interface in lapack.f90 exportiert (bessere Handbarkeit mit den
use-befehlen)

[math.f90]
- Funktionen linDelta und Routine linspace eingeführt (Dadurch lassen
sich an anderen Stellen einige Zeilen sparen -> wird besser lesbar,
finde ich)
- Routine findEigen in sglSolver.f90 exportiert (wäre vielleicht auch
garnicht nötig gewesen)

18. By Alexander Erlich on 2009-09-16

Habe die readme beendet und den code noch ein wenig gesäubert. Dies ist Version 1.0!

17. By Alexander Erlich on 2009-09-16

Die Readme-Dokumentation habe ich viel erweitert, z.B. die ganzen von importfile erzeugten Plots sind nun enthalten und erklärt, das Programm an sich wird besser erklärt, und alle nötigen Pakete sind nun aufgeführt (also auch doxygen, xmgrace, etc). Da mein Latex-Editor, der im *.lyx Format speichert, nicht weit verbreitet ist, habe ich eine PDF der Readme beigefügt.

Die Doxygen-Dokumentation des gesamten Quellcodes ist fertig. Es gibt im Programm jetzt eine recht zuverlässig funktionierende Konsistenzprüfung der verschiedenen Intervalle, d.h. die Beziehung zwischen [xMin, xMax] und [potAr(1,1), potAr(nInterp,1)] wird überprüft und bei linearer und Polynomialer Interpolation unterschiedlich behandelt. Der in revno 15 angesprochene Effekt, dass nach Aufruf von tooClosePoints xMin wie bei einer Ketten-Reaktion (-> Newton-Pendel) nach links verschieben kann, wird nun ebenfalls abgefangen. Auch die Eingabe des kleinsten und größten Eigenwertes fängt nun alle Fehler, die man meiner Fantasie nach machen kann, ab. Ingsgesamt habe ich ziemlich viele user-Falscheingaben getestet und bin nun der Meinung, dass alles überprüft wird und das Programm gegebenenfalls gestoppt wird, und zwar mit präzisen Fehlermeldungen.

Das im letzten commit Problem bzgl. der angeblich nicht ganz richtigen Wellenfunktionen hat sich geklärt: Da das Betragsquadrat physikalische Realität hat und bei der Projekt-Spezifikation und bei dem importfile-Output identisch ist, hat sich die Sache erledigt.

Noch ein Hinweis zu "fremden Inhalten". Folgende Inhalte, von denen weder Andreas (dundanox) noch ich die Autoren sind, habe ich ins repo geadded:

- Projekt_Spezifikation.pdf von Bálint Aradi
- laprint.m und laprintdoc.ps von Arno Linnemann. Laprint ist ein Matlab Script, welches für das Einbinden von Matlab-Grafiken in Latex nützlich ist. Für Bequemlichkeit bei der Nutzung mit Lyx habe ich laprint.m leicht modifiziert.

16. By Alexander Erlich on 2009-09-14

Merge mit Andreas' branch, dadurch übernehme ich das neue Makefile sowie die Beispiel-Dateien. Cherrypick nicht nötig, weil keine Änderungen in den mathematischen Routinen und im main. Habe an der Dokumentation weitergeschrieben.

15. By Alexander Erlich on 2009-09-12

wfuncs und ewfuncs werden nun in Dateien geschrieben und können geplottet werden. Ich habe das Matlab-Skript importfile.m deutlich ausgebaut: Wird es aufgerufen, bekommt man zwei plots:

- linkter subplot(): Graphen aus den von Fortran erzeugten Dateien (sowohl Diskretisierung des Potentials als auch Berechnung der Eigenwerte und Eigenfunktionen)

rechter subplot(): Die Diskretisierung des Potentials wird aus dem Fortran-Programm gelesen, während die Eigenwerte und Eigenfunktionen durch die Matlab-Routine eig() berechnet werden. Dient zum Vergleich und zum debuggen.

Ein Problem, das auftritt, ist dass die Eigenfunktionen sich nicht ganz mit denen aus der Programmbeschreibung decken. Ich konnte den Fehler bisher einfach nicht finden. Dies war eigentlich die Motivation, das importfile.m auszubauen. Das Ergebnis: Die Berechnung der Eigenwerte und Eigenfunktionen sowie das plotten, wie es in ewfuncs gemacht wird, machen FORTRAN/LAPACK und MATLAB stets genau gleich! Der Fehler muss also in der Diskretisierung liegen. Daher habe ich z.B. auch den unendlich hohen Potentialtopf ausprobiert un "geschummelt", indem ich, anstatt meiner linearen Interpolation zu vertrauen, den potInterpAr einfach mit einer Schleife "von Hand", so dass die findEigen-subroutine sowie die write_funcs-subroutine ein eine garantiert richtige Diskretisierung bekommen. Trotzdem sind die wellenfunktionen leicht abweichend von denen der Vorgabe. Die Abweichung besteht _immer_ nur darin, dass eine Funktion (unnötigerweise) einmal um die x- oder y-Achse gespiegelt ist. Möglicherweise hat es auch mit Randbedingungen zu tun, ich kann ansonsten keinen Fehler ausmachen.

Ich habe noch eine Funktion tooClosePoints geschrieben, über die ich mir viele Gedanken gemacht habe. Sie ist gedanklich eng mit dem bubblesort, der die vom user angegebenen Interpolations-Stützpunkte sortiert, verknüpft. Die Idee basiert darauf, dass beim Bubblesort zwei gleiche (wirklich gleiche) Werte niemals die Reihenfolge wechseln. Wenn es passiert, dass (wie z.B. beim endlich hohen Potentialtopf) zwei Werte die gleiche x-Koordinate, aber unterschiedliche y-Koordinaten haben, muss das Programm einen der Werte um eine Dikretisierungs-Länge verschieben. Welchen es zu verschieben hat, kann es prinzipiell nicht wissen. Deshalb gehe ich folgende "Vereinbarung" mit dem user ein: Alle x-y-Stützpunkt-Paare können in beliebiger Reihenfolge eingegeben werden und werden dann automatisch sortiert. Dabei wird aber die Reihenfolge von Punkten, die gleiche x-Werte, aber unterschiedliche y-Werte haben, prinzipiell beibehalten. Dieses Verfahren kann natürlich auch mit dem Fall, dass alle Punkte schon sortiert sind, umgehen - in diesem Fall wird bubblesort nichts machen.

Jetzt konkret zu tooClosePoints: bubblesort sortiert nur, verändert die x-Werte der Punkte aber nicht. tooClosePoints geht mit Problemen wie dem Potentialtopf um, in dem es eine Art Newton's-Pendel-Prinzip (so nenne ich das mal) benutzt. Es wird der Array der Potential-Stützpunkte im sortierten Zustand genommen (potAr) und von links nach rechts geprüft, ob der x-Abstand zweier Punkte kleiner als eine Diskretisierungs-Länge ist. Wenn ja, wird der jeweils linke Punkt um eine Diskretisierungs-Länge verschoben und die Suche wieder ganz von links gestartet. Der Grundgedanke ist: man kann nie einen Punkt an einem anderen vorbeischieben, denn das würde ja bedeuten, dass der Punkt, der "vorbeigeschoben" wird, einen kleineren Abstand als die Diskretisierungs-Länge zu dem Punkt hätte, an dem vorbeigeschoben wird - das hätte das Programm im Schritt davor aber erkannt. Deshalb: Newton's Pendel. Im schlimmsten Fall, wenn alle Punkte sehr nahe aneinander sind (kleiner als Diskretisierungs-Länge), wanderen alle Punkte nach links, und der, der am weitesten links steht, wandert am weitesten. Dazu mache ich wohl noch ein Schaubild für die Dokumentation; es hat einige Zeit verschlungen, bis ich das das begriffen habe ;-) Es gibt nur einen kritischen Fall: aufgrund der Punkte-Wanderung xMin auch nach links wandert. In dem Fall muss das Programm abgebrochen, den Fall habe ich noch nicht abgefangen.

Die lineare Interpolation an sich (unabhängig von bubblesort und tooClosePoints) habe ich genauer gemacht, indem ich nicht mehr nur den Anfangswert (bei x=xMin) als Stützwert nehme und dann alles dazu relativ rechne, sondern bei jedem betrachteten Punktepaar im vom user vorgegebenen Potential die Geradengleichung bestimme. Es gibt noch einen "Schönheitsfehler", den ich noch beseitige: In demm Fall, dass man eine sehr scharfe Zacke vom user übergeben bekommt, wird sie im interpolierten Potential abgeschnitten. Das könnte man vermeiden, indem man, unmittelbar bevor das nächste vom user übergebene Punktepaar betrachtet wird, dem letzten interpolierten Punkt den y-Wert des vom user übergebenen Stützpunktes gibt, der unmittelbar folgt (also kurz vor dem "Wechsel" zum nächsten user-Punktepaar). Das sollte mit einer einfachen Abfrage einbaubar sein.

Schnittstellen-Doku fehlt noch, an die Readme setze ich mich gleich.

14. By Alexander Erlich on 2009-09-10

Wie in revno 13 von diesem branch beschrieben, ist ein weiterer "cherrypick-merge" vom makefile nötig. Dabei "merge" ich die das makefile der revno 9 von Andreas branch in meinen branch.

$ cd /.../alexander_current_branch
$ bzr merge /.../andreas_current_branch/makefile
Weitere Änderungen...
$ bzr commit -m "dieser Text"

Zu den weiteren Änderungen: Ich habe in der durch den merge importierten io-Datei von Andreas noch einige Zusatz-Abfragen eingebaut, so dass das Programm besser auf user-Eingaben reagiert. Insbesondere wird nach Einlesen von nInterp jetzt geprüft, ob tatsächlich mehr oder weniger Punkte als nInterp in der Input-Datei angegeben worden sind. In beiden Fällen gibt es einen Abbruch mit dem jeweiligen Hinweis, dass mehr oder weniger x,y-Wertepaare angegeben worden sind, als vorher (über nInterp) spezifiziert wurde. Der rechtzeitige Abbruch verhindert in jedem Fall, dass auf ein Element des potAr-Arrays geschrieben wird, welches einen größeren Index hat, als die Dimensionierung von potAr zulässt. Außerdem ist die Fehlermeldung beim Lesen mit jeder read-Anweisung jetzt immer eine andere, so dass der user lesen kann, warum das Programm gestoppt werden musste, d.h. ob das Programm durch fehlerhafte Angabe z.B. der Masse, oder vielleicht bei Eingabe der x,y-Wertepaare der Potential-Stützpunkte abgebrochen werden musste.

Ich habe etwas 'rumporbiert' und bin der Meinung, dass alle möglichen nicht sinnmäßigen Angaben in der Inputdatei jetzt mit einem stop und einer Fehlermeldung bestraft werden, bis auf zwei:

1) Das allerletzte x,y-Paar der Potential-Stützpunkte in der Input-Datei muss einen line terminator ('\n' unter Linux) haben, bevor EOF erreicht wird. Andernfalls wird die letzte Zeile einfach nicht in den Array eingelesen, also der Stützpunkt ignoriert.

2) Das Intervall aller x-Werte der Stützpunkte, welches durch den größten und den kleinsten x-Wert berandet wird (ich nenne es mal [xPotMin, xPotMax]), ist nicht vollständig in [xMin, xMax] enthalten.

3) Die gewünschten Eigenwerte müssen beide kleiner sein als nPoint, das ist nicht weiter problematisch abzufragen.

Zu 1) Praktisch tritt das Problem auf, dass im input file nach dem letzten x-y-Wertepaar ein Zeilenumbruch erfolgen muss, damit die letzte Zeile wirklich eingelesen wird. Ich habe dieses Problem anhand eines Minimal-Beispiels in comp.lang.fortran gepostet (unter meinem 'realname', Thread: "How to read the last line before the EOF is reached?" von 09.09.2009). Hier ein Link dazu:

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/cc3157a233bf2d46#

Wie dort bisher geantwortet wurde, gibt es nur "complicated workarounds", um dieses Problem zu beheben. Auch sind die line terminators betriebssystemabhängig (siehe insbesondere Post von "Dave Allured") und außerdem ist der text record im Fortran Standard nicht definiert (siehe Post von Richard Maine), was das Problem erschwert. Somit bleibt im Moment meiner Meinung nach nicht übrig, als das Problem in der Dokumentation anzusprechen und den user deutlich darauf hinzuweisen, nach dem letzten x,y Wertepaar eine neue Zeile zu beginnen.

Zu 2) In der Programm-Spezifikationen gibt es einige Beispiel-schrodinger.inp-Dateien, mit denen das Programm umgehen können muss. Mir ist aufgefallen, dass bei allen linear interpolierten Beispielen das den user interessierende Intervall [xMin, xMax] in der linken und rechten Grenze tatsächlich mit den vom user angegebenen Stützpunkten des Potentials übereinstimmt. wie gehen wir mit Fällen um, wo dies nicht so ist? Ist z.B. [xPotMin, xPotMax] vollständig in [xMin, xMax] enthalten, könnte man das Potential bis zum user-Intervallrand auf beiden Seiten verlängern, also parallel zur x-Achse, oder einfach auf 0 abschneiden. Komplizierter wird es, wenn [xPotMin, xPotMax] größer ist als [xMin, xMax]. Dann könnte man den interpolierten Funktionswert des Potentials bei xMin und bei xMax finden und diese beiden Werte als Stützpunkte des Potentials "definieren". Oder, vielleicht einfacher, man könnte den user lediglich auf seinen "Gedankenfehler" hinweisen und die Berechnung stoppen.