Roadmap für anewwrithm.exe

DONE - Molekülnummer aus comment auslesen und in output schreiben

Sicherheitsmaßnahmen um beim Vergleich mit xyz2cane outputs keine

Fehler zu machen.

Status

FINISHED - und installiert auf den acids

ETA

16.3

Version

0.3

DONE - explizite Angabe des Ringes als Liste von Atomnummern

ermöglicht Behandlung von Molekülen mit Dreifachbindungen.

Status

FINISHED - und installiert auf den acids

-Problem: Openbabel will switch numeration from 1 to 0 with next version (2.2 -> 3.0)

-Lösung: zusätzliche offset Kommandozeilenoption.

Umsetzung

• neue Kommandozeilenoption mit Dateinamen für Ringselektion - DONE

-r filename

Format:

Kommentarzeilen beginnen mit #

enthält die Atomnummern der Selektion, separiert durch Leerzeichen.

-o offset

Offset für die Nummerierung der Atome. Hilfreich, wenn

z.B. das neue Avogadro die Atome von 0 aus nummeriert, Hyperchem,

Gaussview und das alte Avogadro von 1 aus :-[

• neue Funktion - DONE

read_ring_atomnumbers

liest obiges Fileformat und wandelt um in eine Openbabel-Ringdefinition.

• flags für Nummerierung der Atome - DONE

--uid/-u unique identifiers from Title-String/Commentline.

--sequential/-s Sequenznummer für Multimolekülfiles.

ETA

17.3.2008

Version

0.4

DONE - Ringgröße mit ausgeben

Status

FINISHED

ETA

17.3.2008

Version

0.4.1

in progress - Validierung

Status

started 17.3.2009

Version

0.5

ETA

20.3.2009

Definition des Testumfangs

• Status: DONE
• BIGRING: große Ringgrößen Autoerkennung. Hat der OpenBabel-Patch funktioniert?

• RINGGFILE: funktioniert die --ring Funktion
  • explizite Ansage des Rings, triple-bond
  • offset testen
  • ungültige Eingabewerte

• RZEPA: Rzepas Moleküle (ohne BIGRINGS), Vergleich mit Literaturdaten

• VERBOSE: funktioniert die -v Option?

• UID-SEQNR:
  • funktioniert die --uid Funktion? diverse Titelzeilen
  • funktioniert die --seqnr Funktion? diverse Titelzeilen

Evaluierung möglicher Implementierungen

Status

DONE - Git ist der Sieger

• Git als Vorbild - sieht gut aus

Testdirectory t

• Makefile
• Einzelner Test als numeriertes Shell-Script t[0-9]+.sh (Naming convention in t/README)
• Test-Datadirs wenn nötig

• Dejagnu als Vorbild ?
• Webrecherche

• makefile-basiert

Pro: konsistent, gute Übersicht auf Toplevel

Kontra: die eigentlichen Tests auf Skriptbasis, kein Gesamtfehlerzählen,

• python-basiert

Pro: gut wartbar

Kontra: initialer Aufwand, Deployment uU schwierig (Pyton2->3)

• tcl-basiert

Pro: mittelgut wartbar

Kontra: initialer Aufwand, hässliche Syntax?

Programmieren der Test-Skripte

nach Variante git

Status

begonnen 17.3.

1. README kopieren/anpassen - OK
2. Makefile kopieren/anpassen
3. test-lib.sh kopieren/anpassen
4. aggregate-results kopieren/anpassen
5. gogogo, den ersten Test schreiben und schauen, was noch so an Hilfsfunktionen fehlt

Generieren der Eingabedaten

Status

---

Einarbeiten in die Dokumentation

Status

---

CANE-Deskriptor errechnen und ausgeben

Wäre ja mal eine Möglichkeit, die CANEs unters Volk zu bringen.

Status

Die CANE Klassen existieren, müssen noch kopiert und angepasst werden.

ETA

---

Version

0.6