Roadmap für anewwrithm.exe

Aus Hergipedia
Zur Navigation springen Zur Suche springen

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

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

Ringgröße mit ausgeben

Status
FINISHED
ETA
17.3.2008
Version
0.4.1

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