Mittwoch, 30. November 2011

Debian Med und Bio-Linux veranstalten einen gemeinsamen "Sprint" fuer ein gemeinsames Lösen von bekannten Problemen und dem Beschreiben von neuen. Unsere Veranstaltungsseite ist http://wiki.debian.org/DebianMed/Meeting/Southport2012. Wir sind schon mehr oder minder "voll" wie in "der Frühstücksraum des Hotels fasst nicht mehr Leute". Aber 2-3 können wohl noch kommen.

Dieses Jahr findet insbesondere auch ein ganztägiges Tutorial durch die Firma SciEngines zum FPGA computing statt. Das wird richtig spannend, denke ich. Die Kunst wird sein, die Community von dem Gewinn durch FPGA acceleration zu überzeugen. Wenn alles gut läuft, so kommt damit die dann auf bislang ungedachte Ideen und die Technologie erlebt einen ähnlichen Höhenflug wie aktuell die OpenCL oder CUDA GPU Programmierung. Nur noch schneller soll es bitte sein. Und ganz sicher wird es deutlichst energieeffizienter. Ich bin mir nicht so ganz supersicher, dass programmierte hardware more tangible ist als Software - vielleicht ein wenig. Ich freue mich jedenfalls - auf das Tutorial und einen allgemeinen Trend zur Beschleunigung über die CPU-eigene hinaus.

Ansonsten wird der Sprint einige Leute zusammenführen, die bislang noch nicht so lang so eng zusammensaßen. Wir haben insbesondere eine recht dicht gepackte Skill-Liste zusammen von der Sequenz-Bioinformatik in Reinstform über alle Graustufen bis hin zur Struktur-Bioinformatik. Wir haben viel davon nun bereits in Debian - so etwa Ensembl, Jalview und die tools von PredictProtein. STRAP und genometools.org schaffen wir vielleicht nicht rechtzeitig bis zum Sprint, aber wohl fast. Auch in Richtung Systembiologie wird einiges geschenen. Aber ein erreichbareres Ziel ist vielleicht zunaechst eine Integration dieser Neuankömmlinge mit dem Workflow Tool Taverna.

Mein besonderer Dank gilt denjenigen, die die Amazon links nutzten. Das vergangene Jahr brachte insgesamt 29 Euro - und davon sind 6,90 von unserem Hundefutter und irgendwer hat offenbar allein im September richtig viel über den Link bestellt. Ich werde diesen Betrag zur Unterstützung des Sprints verwenden. An Gelegenheit dazu wird es nicht fehlen.

Samstag, 3. September 2011

Debian führt seit einigen Jahren das Paket AutoDock. Zur Verfollständigung des BOINC Server Projektes schaute ich nun nochmal vermehrt nach gescheitem Input für AutoDock und wurde fündig bei einer Aktion des WorldCommunityGrid Projektes FightAids@Home, das eben auch mit diesem Werkzeug arbeitet. Dort hat man verständliche Teilmengen der ZINC Datenbank in vorprozssierter Form abgelegt. So hat man etwa auf einen Schlag Zugriff auf alle von der FDA bereits zugelassenen Wirkstoffe.

Für diesen Datensatz ist es nicht gar so nötig, doch hat Debian seit ein paar wenigen Wochen das Werkzeug getData. Und na klar wollte ich das hierfür ausprobieren. Ich bereite also ein Ergänzungspaket für AutoDock und AutoGrid vor, das insbesondere nun eine Abhängigkeit von getData hat und eine Entsprechende Erweiterung des Wissens von getData in /etc/getData.conf.d/autodock-zinc.getData steckt.

Man kann sich nun das Anschauen

$ getData --list | grep zinc
zinc_natural_products
zinc.pdbqt.asinex ZINC - PDBQT formatted – asinex
zinc.pdbqt.chembridge_buildingblocks_pdbqt_1000split ZINC - PDBQT formatted – chembridge_buildingblocks_pdbqt_1000split
zinc.pdbqt.drugbank_nutraceutics ZINC - PDBQT formatted – drugbank_nutraceutics
zinc.pdbqt.drugbank_smallmol ZINC - PDBQT formatted – drugbank_smallmol
zinc.pdbqt.fda_approved ZINC - PDBQT formatted – fda_approved
zinc.pdbqt.human_metabolome_pdbqt_1000split ZINC - PDBQT formatted – human_metabolome_pdbqt_1000split
zinc.pdbqt.otava ZINC - PDBQT formatted – otava
zinc.pdbqt.zinc_natural_products ZINC - PDBQT formatted – zinc_natural_products

und eben auch per Knopfdruck installieren. Und ganz Nebenher wird nun das AutoDock binary auch noch schneller, da g++ 4.6 inzwischen angekommen ist und damit auch die link time optimisation.

Es gibt noch sehr viele freie Programme die das DebiChem team oder (na klar) auch Debian Med gern für die weitere Bearbeitung der Rezeptoren oder dieser Liganden in Debian sehen würde. Wenn jemand die freie Kapazität hätte, sich hier als Maintainer zu betätigen, so wärte das sehr hilfreich. Ziel ist die weitere Komplettierung von Workflows in der computational biology. Bitte melden. Auch interessieren mich Ideen für den Einsatz von getData und dessen Weiterentwicklung.

Samstag, 27. August 2011

BOINC+AutoDock+Debian ... Walk-Through für eigene BOINC Projekte

Es ist ja ein wenig frustig. Die Anzahl der BOINC (Berkeley Open Infrastructure for Network Computing) Installationen stagniert. Die Projekte verzeichnen allesamt einen Rückgang der Teilnehmerzahl (boincstats.com). Woran das liegt? Vielleicht an einer zunehmenden Anzahl von laptops? Die Rechenleistung steigt zwar weiterhin, aber wegen der technischen Entwicklung.

Für Rechencluster, die eine übersichtliche Menge von sich regelmäßig verbesserten Anwendungen nutzen, ist BOINC einer super Alternative sogar zu regulären batch systems wie Torque oder die Sun Grid Engine. Schliesslich muss man sich nach einer initialen Installation von BOINC um nichts mehr kümmern. Updates und Architektur-Abhängigkeiten lösen Server und Client alleine. Und dies macht BOINC auch für diejenigen interessant, die gar keine eigene Recheninfrastrukur haben.

Auf wiki.debian.org/BOINC/ServerGuide gibt es nun eine recht komplette Einführung in die Nutzung von BOINC mit sogenannten legacy Anwendungen. Gemeint sind damit solche, die von dem BOINC API nichts wissen. Man benötigt hierfür einen Wrapper. Neben den Beispielprogrammen haben wir (mein 2011 Google Summer of Code Student Dhananjay und ich) insbesondere das molekulare Docking als biochemische Anwendung im Auge gehabt. Wie verständlich ist das ganze? Es sollte von einem versierten Schüler oder einem Informatik Studi in den ersten Semestern alles hinzubekommen sein. Kommentare bitte hierher, direkt an die Wiki Seite oder an mich. Danke.

Samstag, 13. August 2011

Bioinformatik Hardware

Die Sequenz-Bioinformatik sah bereits in den späten 90ern, als 12 CPUs in einer Maschine noch etwas Besonderes waren und wegen 80 GB Festplattenplatz man in Aufregung verfiel, den direkten Support durch sündhaft teure aber sehr schnelle Hardware. Das waren entweder ASICs oder FPGAs. Seit damals gibt es
 TimeLogic
 ParaCell
und neu dazu sind gekommen
 StoneRidge
 SciEngines (aus Kiel)
 AcceleratedDataConcepts (auch in der Struktur-Bioinformatik aktiv)
 CLCbio (aus Aarhus, kümmern sich liebevoll um den Biologen als Ganzes)
 Convey
 die vergessenen trage ich nach ...
Das buzzword dazu ist "application acceleration".  Die Konkurrenz zu den FPGAs sind die GPUs, von denen man meint, sie ja sowieso schon mitgekauft zu haben.

Nun, die FPGA Programmierung will ich lange schon erlernen. Mich hat bislang vor einer entsprechenden Investition insbesondere meiner Zeit gerettet, dass beinahe alles in dieser Richtung mit Windows geschieht. Und Windows habe ich nicht. Der Linux support bessert sich allerdings allmählich. Tatsächlich bietet insbesondere Xilinx seit langem auch eine Linux-Variante ihrer Entwicklungsumgebung an [1,2]. Ich sollte auch die OpenGraphicsCard und die drumherum erhältlichen Software tools erwähnen [3].

Aber wenn man Logiken auf den FPGAs programmiert, so will man die sich auch mit einem logic analyser betrachten können. Und wer da Consors oder ELV aufschlägt, findet nichts mit Linux. Aber nun passierten zwei Dinge:
  • beim doodlen im web stieß ich auf den Open Workbench Logic Sniffer, den Logic Analyser als Open Source Projekt für 50 Dollar [4]
  • bei der Suche nach FPGA und Linux bei Ebay fand ich ein Angebot von der ZTEX GmbH [5]
Nun. Den Logic Analyser habe ich gleich bestellt. Nach vier Wochen oder so war der dann auch da. Und hättte ich genauer gelesen, hätte ich auch gleich die Kabel dazubestellt. Die waren dann etwas schneller.  Die Software dazu habe ich dann auch gleich für Debian gepackt [6]. Funktionierte ... aber spannende Signale, hm, die bekäme ich vom FPGA.

Von ZTEX wurde ich hervorragend beraten. Die verticken nicht nur, die entwickeln auch. Und freundlich sind sie zudem noch, geben gar Rabatte für Open Source Entwickler. Im Herbst, wenn die Sonne abends nicht mehr scheint, soll mein Einstieg in die FPGA Welt stattfinden.

[1] http://www.linuxjournal.com/article/6857
[2] http://xilinx.wikidot.com/
[3] http://wiki.opengraphics.org
[4] http://www.seeedstudio.com/depot/open-workbench-logic-sniffer-p-612.html
[5] http://www.ztex.de
[6] http://packages.qa.debian.org/s/sump-logicanalyzer.html

Montag, 25. April 2011

BOINC 6.12(.22) in Testing

Die Debian Pakete zur BOINC 6.12.X Reihe, upstream's development tree, hingen bislang stets mit dem gleichen Fehler bei den build daemons zu kfreebsd-{i386,amd64}. Das war zunächst auch ganz recht so, schließlich wurde aktiv an dem Paket noch geschraubt und das Paket kam gerade erst aus experimental herüber. Aber mit zunehmender Zufriedenheit sollte doch auch testing das neuere BOINC sehen. Aber wie den FTBFS korrigieren?

Nach viel Denken und Greppen konnte ich keinen Fehler feststellen. Nachfragen auf debian-devel und der Suche nach einem kfreebsdler, der einem vielleicht spontan zur Seite springt, ergaben nichts. Der Zugriff auf die Developer Maschinen blieb mir versagt, da mein ssh key update dort nicht ankommen wollte. Also baute ich die kfreebsd-Y Pakete auf lokalen virtuellen kfreebsd Installationen. Das war nicht sonderlich flott, aber funktionierte - die Pakete bauten, auf squeeze wie auf unstable. Das war dann wohl ein buildd Problem. Argerlich dabei ist selbstredend die Zeit, die dieses Selberbauen kostete.

Nun ist also BOINC 6.12.22 (PTS) in testing und 6.12.25, mit einem Fix für die Erkennung der GPU als coprozessor, wurde zu den buildds geschickt. Upstream war auch so freundlich, ein FTBFS auf HURD zu korrigieren, obwohl es wohl so bald keine BOINC Projekte auf HURD geben wird; also nur für uns. Falls jemand BOINC unter HURD oder auch kfreebsd nutzt, bitte ich um eine Zusammenfassung der jeweiligen Erfahrungen. Man darf gespannt sein.

Update [12.6.2011]: Seit 6.12.32 gibt es nun BOINC auch auf HURD (build logs). Die kfreebsd buildds bauen noch immer nicht - oder nicht immer.

Update [21.6.2011]: Alles ist nun gut.

Update [3.1.2012]: BOINC 7.0.7 ist nun in Debian. Die Erkennung der GPUs funktioniert hervorragend, Erläuterungen für die Konfiguration von OpenCL mit AMD Stream sind hier, solche für CUDA mit NVidia Karten sind hier. Naja, die NVidia Erläuterungen könnten auf die für CUDA noch zu installierenden Pakete ein wenig mehr eingehen.

Dienstag, 19. April 2011

Debian Med hat nun einen Blog

Auf http://debianmed.blogspot.com/ gibt es nun einen Blog für diverse Notizen rund um Debian's Pakete zur Bio- und Medizininformatik. Dank an Will für den Stimulus.

Freitag, 11. Februar 2011

CRAN, BioConductor, Debian, gibt's nun auch zusammen.

Es gibt das diese nicht nur bei Bioinformatikern beliebte Sprache R, mit
der man ohne es wirklich zu merken plötzlich funktional programmiert
und statistische Probleme löst. Hierzu gibt es weit über 2000
Pakete (Bibliotheken) im CRAN (aufgebaut in Analogie zu Perl's CPAN) und excellente bioinformatische Lösungen bei BioConductor mit nochmal über 1000 Bibliotheken und Datensammlungen.

Mehrere Gruppen habe bereits Ansätze, diese Umgebung fü Linux Distributionen verfügbar zu machen. Hier nun für Debian's amd64 Umgebung eine weitere, und vielleicht die erste mit BioConductor. Für eine Nutzung mit Debian, die folgende Zeile bei /etc/apt/sources.list mit angeben, apt-get update und die Pakete sind verfügbar. Dies sollte die Systemadministration bei vielen Unis erleichtern, aber hoffentlich insbesondere auch an Schulen oder unter den Privatpersonen eine höhere Anzahl von Nutzern dieser Bibliotheken zur Folge haben.

deb http://master.dermacloud.uni-luebeck.de/cran2deb/rep testing main

Mich interessiert nun primär, wie Ihr ein solches Repository nutzen wolltet. Sollte es Teil von BioConductor/CRAN sein? Oder Teil von Debian? Wie wichtig ist die Beschreibung der Pakete. Gebaut wurden sie allesamt automatisch mit cran2deb, d.h. jedes Paket mit den dazu passenden Abhängigkeiten in Debian. Die Beschreibungen der Pakete sind direkt denselbigen der R Pakete entnommen. Würden alle mitziehen, Verbesserungen zu den Texten den Autoren zu schicken, um allmählich die Güte der Paketierung den regulären Paketen Debians anzupassen? Wie aktuell müssen die Pakete sein? Ist eine Anbindung an Debian hilfreich? Benutzten viele die Bibliotheken auf ARM und anderen weniger häufigen Platformen? Meldet Euch mal.


Die Pakete sind signiert mit diesem GPG Schlüssel:

pub   4096R/CD2AB519 2011-01-31 [expires: 2016-01-30]
Key fingerprint = 4DEC 8FEF E7B9 926B 9720 CAEA 1672 CF4C CD2A B519
uid Debian Med cran2deb
sub 4096R/D4D62F0C 2011-01-31 [expires: 2016-01-30]

Dienstag, 4. Januar 2011

Hin zu BOINC-Server als Debian Paket mit verbesserter Anleitung zur Paketierung mit git

Einige werden BOINC bereits kennen, diese Infrastruktur zum verteilten Rechnen. Es nutzen diese das Scripps Institut mit Hilfe von IBM im WorldCommunityGrid, ein Max-Planck-Institut bei Einstein@Home und freilich auch SETI@Home, die Autoren der freien Software.
Was nun, so frage ich mich, würde sich ändern, wenn die Verfügbarkeit dieser Technologie nun so groß wird, dass Firmen diese für lokale Projekte einsetzen können? Es müssten die Kosten Rüstzeiten, also insbesondere die Einarbeitungszeit der Mitarbeiter und die Portierung der Anwendung auf die Architekturen der Client Rechner, deutlich kleiner werden als die Beschaffung und das Maintenance eines lokalen Clusters oder der Nutzung von Maschinen in einer Cloud.

Nun habe ich keine Idee, ob das wirklich zu schlagen ist. Und ich weiss auch nicht, ob dieser Ansatz nun der bestmögliche ist, aber für mich ist er naheliegend: eine Linux Distribution sollte ein Server Paket anbieten. Die Portierung muss zwar weiterhin geleistet werden, aber eine initiale Hürde wird damit vielleicht bei der einen oder anderen Gelegenheit genommen.

Debian Experimental hat es nun bereits, ein Debian Paket mit dem BOINC Server. Das Faszinierende an diesem Paket ist, dass es eigentlich gar keines ist, schließlich stellt es gar keine eigene Server Funktionen zur Verfügung. Es sollte dieses Paket vielmehr heissen "BOINC Server Maker", denn es kopiert die wesentlichen Dateien über das Skript "make_project" in ein separates Verzeichnis. Und dieses Verzeichnis dann kann zusammen mit Apache, MySQL, Perl und PHP dann als BOINC Server funktionieren. Das BOINC-Server Paket selbst kann anschließend wieder gelöscht werden - könnte.

Es existiert nun eine neue Seite (http://wiki.debian.org/BOINC/ServerGuide) auf dem Debian Wiki zur Beschreibung des Aufbaus eines BOINC Servers mit Debian. Sie wurde initiiert von chalet16, einem von Debian's Google code-in Studis. Wenn es auch alles noch nicht so ganz so fertig ist, das Paket ist nicht umsonst erst noch in der experimental Sektion von Debian, so gibt die Beschreibung doch einen guten Überblick über die notwendigen einzelnen Schritte.

Debian ist eine sehr offene Linux Distribution. Sie lädt zum Mitmachen ein, daher schließlich auch das Engagement für all die Google Summer of Code und nun auch Code-In Initiativen. Und damit das Mitmachen einfacher wird, gibt es auch diverse Anleitungen. Eine gewisse Hürde stellt für viele das System zur Verwaltung des Source Codes dar. Die BOINC Paketierer nutzen git und wie das geht, ist beschrieben auf http://wiki.debian.org/BOINC/Development/GitUsage. Die Hoffnung ist, dass sich insbesondere jüngere Geister angesprochen fühlen, die Pakete, den upstream code, oder die Beschreibungen auf dem Wiki zu perfektionieren.