BOINC (https://boinc.berkeley.edu) - das heißt Zuarbeit zu wissenschaftlichen Projekten in Form von Rechenleistung durch jedermann. Das ist toll. Und jedermann sollte mithelfen - eine zielgerechtere Spende für einen guten Zweck gibt es kaum. Da unsere Rechner (Computer) weiterhin besser werden, wir für das Browsen von Webseiten oder das Schreiben von Blog Einträgen aber kaum Rechenzeit benötigen und beinahe dauerhaft online sind, liegt diese Rechenkraft also brach. Das ist ärgerlich, denn es werden nicht nur die Rechner besser sondern auch deren Einbindung in die Wissenschaft. Einige Projekte wie die Suche nach Pulsar-Paaren und Gravitationswellen (Einstein@Home) oder ein Design neuer Eiweiße (Rosetta@Home) publizieren in den besten Journalen als Ausdruck wissenschaftlicher Exzellenz und gesellschaftlich herausragender Bedeutung. Das von IBM gesponsorte WorldCommunityGrid mit adoptierten Projekten wie FightAids@Home oder der Identifikation von Erkennungsmechanismen für Krebs weiß auch was es tut.

Es macht aber nicht jeder mit. Zum einen sind die Projekt-Präsentationen überwiegend englisch und spätestens damit außerhalb jedermanns täglicher Routine. Der Verein Rechenkraft.net (www.rechenkraft.net) hilft mit eigenen deutschsprachigen Foren und das Programm „BOINC“ selbst ist mehrsprachig. Etwas mehr Werbung für die Projekte könnte wohl auch nicht schaden. Wenn die eingesammelte Gesamt-Rechenkraft aber auch weiterhin steigt, so sinkt hingegen die Anzahl von Mitwirkenden. Der Grund hierfür liegt gerade auch an der zunehmenden Nutzung energiebewusster Laptops.  Möchte man ein Hochfahren der Lüfter vermeiden, so bietet BOINC an, dessen Rechenlast auf eine tolerierbares Maß zu senken.

Seit Jahren bei BOINC dabei, ärgert einen doch so ein wenig, nicht stattdessen bei den BitCoins mitgemacht zu haben. Nur ist deren Rechenleistung einfach nur Rechenleistung, um zu verhindern, dass ein neuer Coin zu einfach zu erstellen ist. BitCoins verbrauchen Energie ohne irgendetwas für unsere Gesellschaft zu tun. Stattdessen sollte die Rechenleistung doch lieber in BOINC fließen. Und just dieses wurde mit einer anderen Währung, dem Gridcoin, bereits vor bald 5 Jahren umgesetzt. Aus mir nicht ganz erklärlichen Gründen habe ich ihn erst jetzt für mich entdeckt und bin sehr davon angetan. Es ist sozusagen die erste Kryptowährung mit so etwas wie einem moralischen Wert. Selbst wenn sie von heute auf morgen wertlos sein sollte, so hat man bit dem Coin bereits den Gegenwert einer enormen Rechenleistung erhalten, die der Wissenschaft zugute kam.

Die Technik hinter den Gridcoins entspricht weitestgehend den BitCoins. So gibt es auch viele „online Wallets“ (Geldbörse - Programm zur Aufbewahrungsstätten für die Coins) dafür oder auch solche für das Mobiltelefon. So kann mobil bezahlt werden. Ein Transfer wird in wenigen Sekunden angezeigt ist dann binnen wenigen Minuten genügend oft bestätigt. Verschiedene Online-Börsen bieten Gridcoins zum Tausch an, allerdings bislang nur gegen BitCoins, nicht direkt gegen Bares. Ich habe zum Ausprobieren auch schon bei eBay welche gekauft. Klappt. Meine online Börse bei holytransaction.com funktioniert hervorragend. Mit solch einer Börse hat man in etwas alles, was man dann so braucht. Statt via BitCoin zu tauschen - die muss man auch erstmal haben und wir wollen die ja gerade vermeiden - zur Zeit gibt sie auch keiner her - schlage ich vor, bei ebay.de für einen kleineren Test-Betrag welche zu erstehen. Dann hat man schon etwas Gutes getan.

Möchte man selber coins minen, so bietet sich Analog zum Mining von BitCoins bietet ein Zusammenschluss von Minern zu einem Pool wie https://www.grcpool.com an. Dies sorgt für eine tägliche Zuteilung neuer Coins, während man ansonsten je nach zur Verfügung gestellter Rechenleistung einige Tage oder gar Wochen auf die Umsetzung angesparter BOINC-credits auf neue Coins warten muss. Dann gibt es zwar  entsprechend der Wartezeit mehr Coins, aber eben nicht täglich ausgezahlt. Nutzer eines pools müssen keine eigene wallet betreiben. Die online wallet kann als Auszahlungsziel angegeben werden.

Wegen der einfachen Konvertierbarkeit von Gridcoins zu BitCoins ist überall wo BitCoins akzeptiert werden sind, auch der Einkauf mit Gridcoins grundsätzlich möglich. Aber so wirklich ausgeben kann man an sich gerade kaum eine Währung. Man wird sie hierzu erst wieder in reguläres Geld tauschen wollen. Oder sammeln und sich einfach nur an schönen wissenscahftlichen Arbeiten erfreuen. Der Gridcoin ist derzeit einfach sehr günstig zu haben (chart). Oder: Es will ihn keiner. Gut daran: Eine Investition in Gridcoins kann kaum schiefgehen, schließlich kostet er ja jetzt schon nichts ;o) Ihr sollt aber nicht investieren, Ihr sollt für den guten Zweck mitrechnen und dafür den Gridcoin als Nachweis Eurer Rechenarbeit erhalten.

Bei grcpool.com gibt es nette Einführungsvideos. Denen für den Schnell-Einstieg einfach folgen. Nach zwei/drei Tagen sollten die ersten Gridcoins da sein. Die Auszahlung wird wegen der nicht-linearen Mittelung der BOINC-Zuarbeiter erst nach mehreren Tagen oder gar Wochen auf dem Höchststand sein - auch wegen zunächst noch fehlenden Bestätigung der Arbeitpakete. Auf https://www.gridcoin.us ist dies als „Pool Crunching“ beschrieben. Und wer nur einen oder zwei Rechner zur Verfügung stellen möchte, ohne ich weiter kümmern zu wollen, der sollte dies so machen.

Viel Erfolg!

Der Gridcoin ist wie auch der Bitcoin keine zentrale Einrichtung. Implementiert wird er durch den Betrieb einer Gridcoin-Geldbörse bei den ganz normalen Mitmachern. Es gibt ein paar fest verankerte Geldbörsen, mit denen sich Neueinsteiger verbinden. Und die stellen dann andere Mitwirkende vor, die die Neuen dann auch selber kennen und so weiter. Die Geldbörse gibt es als GUI Programm oder als im Hintergrund laufendes Programm für die Kommandozeile. Dieselbe Börse kann mit beiden Programmen verwaltet werden, aber immer nur mit einer der beiden zur selben Zeit. Da der Start des Programms ein wenig Zeit in Anspruch nimmt, ist für mich die Kommandozeile mit einer dauerhaft laufenden Wallet am einfachsten. Ich habe mir gar dazu einen mini-Rechner bei hetzner.de gemietet - sehr entspannend für 3 Euro/Monat - und er verdient auch brav Gridcoins mit.

Gridcoins müssen ständig neu erstellt werden, da ständig neue Rechenzeit investiert wird. Hier liegt ein wesentlicher Unterschied zu Bitcoins, die es nur endlich viele (aber immer noch sehr viele) gibt. Etwas irritierend ist, dass auch die Verwaltung bereits existierender Gridcoins mit einer Art Zins belohnt wird, dh. propotional zum eigenen Vermögen ausgestellte Zusatz-Coins in erwarteter Höhe von etwa einem 1,5%. Habe nicht verstanden, warum das so sein soll. Aber es gibt ein Gridcoin-eigenes demokratisches Abstimm-Verfahren, mit dem dann dies wohl auch abgestellt werden kann. Irgendwann. Hoffentlich.

Hier noch ein paar Dinge, die mich zu meiner Anfangszeit mit meiner eigenen wallet quälten - vielleicht hilft dies dem einen oder anderen Neu-Einsteiger. Die RSA gibt eine „Earliest Payment Time“ (Zeitpunkt frühestmöglicher Auszahlung)  an. Der liegt angeblich im Jahr 2106 - voraussichtlich nach meinem Tod. Und das, obwohl die Magnitude von 19 schon gar nicht mal so schlecht ist.

$ gridcoinresearchd rsa
[
  {
    "RSA Report": "1551915393"
  },
  {
    "CPID": „meinecpid“,
    "Earliest Payment Time": "02-07-2106 06:28:15",
    "Magnitude (Last Superblock)": 19,
    "Research Payments (14 days)": 0,
    "Daily Paid": 0,
    "Expected Earnings (14 days)": 53.2,
    "Expected Earnings (Daily)": 3.8,
    "Fulfillment %": 0,
    "CPID Lifetime Interest Paid": 0,
    "CPID Lifetime Research Paid": 0,
    "CPID Lifetime Magnitude Sum": 0,
    "CPID Lifetime Accuracy": 0,
    "CPID Lifetime Payments Per Day": -0,
    "Last Blockhash Paid": "",
    "Last Block Paid": 0,
    "Tx Count": 0
  },
  {
    "Magnitude Unit (GRC payment per Magnitude per day)": 0.2
  }
]

Das muss irgendein Artefakt sein. Etwas verlässlicher (aber immer noch konservativ) zeigte sich die mininginfo:

$ gridcoinresearchd mininginfo
{
  "blocks": 1535231,
  "stakeweight": {
    "minimum": 4,
    "maximum": 400000,
    "combined": 587644,
    "valuesum": 7345.5877693,
    "legacy": 7345.5877693
  },
  "netstakeweight": 10317152285.82833,
  "netstakingGRCvalue": 128964403.5728542,
  "staking": true,
  "mining-error": "",
  "time-to-stake_days": 26.09003472222222,
  "expectedtime": 2254179,
  "mining-version": 10,
  "mining-created": 0,
  "mining-accepted": 0,
  "mining-kernels-found": 0,
  "InterestPending": 2.40699037584004,
  "kernel-diff-best": 5.320836667567343,
  "kernel-diff-sum": 0.0001562226974061569,
  "difficulty": {
    "proof-of-stake": 6.980298925762844,
    "last-search-interval": 1551915392
  },
  "errors": "",
  "pooledtx": 0,
  "stakeinterest": 0.015,
  "testnet": false,
  "PopularNeuralHash": "54cff7d18277976540595dc72a44c",
  "NeuralPopularity": 15.06493506493507,
  "MyNeuralHash": "",
  "CPID": „meinecpid“,
  "RSAWeight": 100000,
  "Magnitude Unit": 0.2,
  "BoincRewardPending": 37.1120949,
  "MiningInfo 1": "Boinc Mining",
  "MiningInfo 2": "Poll: Fund_Creation_of_HD_Wallet_for_GridCoin",
  "MiningInfo 5": "",
  "MiningInfo 6": "",
  "MiningInfo 7": "",
  "MiningInfo 8": ""
}

Da kann man sehen, dass die „time-to-stake“, d.h. die erste Belohnung für die geleistete Rechenarbeit, bereits in 26 Tagen erwartet wird. Nach der dann kurz darauf erfolgten ersten Auszahlung (nach etwa zwei Wochen?) sah es dann so aus:

$ gridcoinreserachd rsa
[
  {
    "RSA Report": "1552000445"
  },
  {
    "CPID": „meinecpid“,
    "Earliest Payment Time": "03-07-2019 15:24:00",
    "Magnitude (Last Superblock)": 19,
    "Research Payments (14 days)": 39.61,
    "Daily Paid": 2.829285714285714,
    "Expected Earnings (14 days)": 53.2,
    "Expected Earnings (Daily)": 3.8,
    "Fulfillment %": 74.25946756655418,
    "CPID Lifetime Interest Paid": 10,
    "CPID Lifetime Research Paid": 39.61,
    "CPID Lifetime Magnitude Sum": 19,
    "CPID Lifetime Accuracy": 1,
    "CPID Lifetime Payments Per Day": 117.730365681654,
    "Last Blockhash Paid": "85b83f0d9cbbd6d6ed707b7219fcada6374d93943ed4768272243a7cffa914",
    "Last Block Paid": 1535877,
    "Tx Count": 1
  },
  {
    "Magnitude Unit (GRC payment per Magnitude per day)": 0.2
  }
]

Es ist insbesondere die earliest payment time deutlich näher gerückt. Die „Earliest Payment Time“ ist aber weiterhin unrichtig. Ich bekam inzwischen eine zweite Belohnung und das Datum blieb unverändert:

$ gridcoinresearchd mininginfo
{
  "blocks": 1536194,
  "stakeweight": {
    "minimum": 4,
    "maximum": 160000,
    "combined": 262957,
    "valuesum": 3287.00563988,
    "legacy": 3287.00563988
  },
  "netstakeweight": 6612695246.583182,
  "netstakingGRCvalue": 82658690.58228979,
  "staking": true,
  "mining-error": "",
  "time-to-stake_days": 16.62271990740741,
  "expectedtime": 1436203,
  "mining-version": 10,
  "mining-created": 1,
  "mining-accepted": 1,
  "mining-kernels-found": 1,
  "InterestPending": 0.9933265577034762,
  "kernel-diff-best": 0.1074484817591667,
  "kernel-diff-sum": 0.0001421939878357695,
  "difficulty": {
    "proof-of-stake": 7.718779402123279,
    "last-search-interval": 1552000400
  },
  "errors": "",
  "pooledtx": 0,
  "stakeinterest": 0.015,
  "testnet": false,
  "PopularNeuralHash": "",
  "NeuralPopularity": -1,
  "MyNeuralHash": "",
  "CPID": „meinecpid“,
  "RSAWeight": 0,
  "Magnitude Unit": 0.2,
  "BoincRewardPending": 0,
  "MiningInfo 1": "Boinc Mining",
  "MiningInfo 2": "Poll: Fund_Creation_of_HD_Wallet_for_GridCoin",
  "MiningInfo 5": "",
  "MiningInfo 6": "",
  "MiningInfo 7": "",
  "MiningInfo 8": ""
}




Die Gridcoin community ist sich der Unschönheiten bewusst, die ihre Werkzeuge noch haben. Dies soll besser werden.

Meine "Research Payments (14 days)" liegt aktuell bei 74.7. Für diese knappen 75 Gridcoins arbeiten bei mir mehrere Computer, zwei davon auch mit Grafikkarte, also zwei Wochen. Bei eBay kosten 65  Gridcoins ganze 1,55 Euro (EBay findet  „Griechin“ stadt „Gridcoin“, eigentlich lustig). Der Anbieter hat nach eigenen Angaben viele Grafikkarten eingespannt, was ihn sehr leistungsfähig macht, dafür kann er (technisch eingegrenzt) nicht bei allen wissenschaftlichen Fragstellungen mithelfen, jedenfalls nicht denen, die mich besonders interessieren und deswegen kaufe ich auch dort auch nicht regelmäßig. Aber abundan dann eben doch.

Ich selber hatte und habe jedenfalls meinen Spaß mit dieser mir angenehmen Währung. Und so ein cooles „GPU mining rig“ für einen guten Zweck, so wie der bei eBay, das will ich auch haben. Die eine oder andere Einsatzmöglichkeit für die eigene Bioinformatik gibt es für solch eine Technik durchaus - gerade in der Sequenzanalyse oder für das deep learning. Und man lernt mit jedem neuen Werkzeug auch etwas hinzu. Aber nun wird es erstmal Sommer. Das ist dann doch eher etwas für die Wintertage, auch zur besseren Nutzung der Abwärme.

Debian Med Sprint 2016 bei Kopenhagen

Kopenhagen liegt direkt am Wasser, passt! Wir treffen uns ja schließlich jedes Jahr an der Küste. Dieses Jahr biegen wir dies ein wenig zurecht und sind in Nachbarschaft zur Dänischen Technischen Universität an einem See, nicht am Meer.

Es steht als Schwerpunkt ein intensiver Abgleich der Pakete in Debian mit den Anstrengungen des großen EU Projektes ELIXIR an, die als Projekt unseres Gastgebers bei http://bio.tools einen Katalog der verfügbaren bioinformatischen (Teil-)Lösungen betreuen. Desto mehr von den Paketen in Debian wissen und für ihre Arbeit bereit sind zu nutzen, desto schneller kommen wir von einer Konzeptionalisierung einer Lösung zu deren Umsetzung, denn wir können Skripte untereinander austauschen und es bedarf nur einer weiteren Nennung der genutzten Pakete - ohne eine manuelle Installation und damit einhergehenden Unwägbarkeiten der tatsächlichen Verfügbarkeit. Damit bleibt mehr Zeit/Kraft für eine Verbesserung von hierauf basierenden Workflows übrig. Wir freuen uns alle sehr.

Wie jedes Jahr, kommen auch dieses mal wieder einige Neue zu unserem Treffen. Und wir jedes Jahr, bringen sie auch wieder etwas mit, das die community noch nicht kann. Mehr auf http://wiki.debian.org/Sprints/2016/DebianMed2016.

Debian Med Sprint - 30/01 bis 02/02 2015

Es jährt sich das Debian Med Treffen. Ende Januar treffen wir uns nun dieses Mal in Frankreich - wie immer an der Küste - und mit etwas Glück kommen wir wegen eines Sturmes von dort auch so schnell nicht wieder weg. Es war bislang jedes mal ein ausgesprochen konstruktives Miteinander, zu dem wir herzlich einladen. Vergangenes Jahr erschien eine Publikation zu unseren und verwandten Community-Treffen bei BMC Bioinformatics mit dem Titel "Community-driven development for computational biology at Sprints, Hackathons and Codefests" (http://www.biomedcentral.com/1471-2105/15/S14/S7). Weitere Details gibt es auf den dazugehörigen Seiten des Debian Wiki (https://wiki.debian.org/Sprints/2015/DebianMed2015).

AutoDock & MGLTools: Workshop on Computer Aided Drug Design

Zwei Entwickler der AutoDock suite und der MGLTools, Stefano Forli und  Michel Sanner, kommen im September zu uns nach Europa und präsentieren computer aided drug discovery (CADD) im Rahmen eines einwöchigen Workshops.  Viel mehr "tangible computational biology" geht nicht.

Dear all,

We cordially invite you to the workshop

"AutoDock and MGLTools: computer-aided drug discovery "
September 16 - 20, 2013 at the University of Lübeck, Germany.

We are happy to announce that Stefano Forli and Michel Sanner, both lead developers at the Molecular Graphics Lab at The Scripps Institute, La Jolla, California, offer a week of their time to present overviews and interna of AutoDock and the MGLtools for in silico drug screening and protein visualisation. They will introduce participants into their workflows comprising the whole process

• from ligand preparation
• via job control for high throughput docking
• to result evaluation.

The workshop offers lectures and exercises to support the participants in
gaining experience and improving their skills in the above described
tasks. Participants are encouraged to bring their own data for a
fruitful exchange among themselves and the developers.

For more details please visit http://www.gradschool.uni-luebeck.de/autodock.
Pleased forward this workshop announcement to potentially interested colleagues. Hoping to welcome many of you in September in Lübeck,

with kind regards,

Steffen Möller, Department of Dermatology, University of Lübeck
Katja Dau, Graduate Scool for Computing in Medicine and Life Sciences, University of Lübeck

BitCoins minen ... ein Sprungbrett für FPGA?

Wie praktisch sind nun denn wohl FPGAs? Nimmt man sie sich geschwind zur Hand, wenn man etwas größeres mit FPGA Unterstützung zu rechnen hat? Angeschlossen, wenn nicht im Rechner breits verbaut, sind sie schnell per USB Kabel. Spannend ist der Vergleich mit handelsüblichen GPUs und der CPU, wie sie bereits in regulaeren Rechnern vorliegen, also eher nichts zusätzlich kosten. Seit bereits einem halben Jahr habe ich die ZTEX 1.15 mit einem Xilinx LX75 - und noch nichts damit gemacht ausser einem "Hello World", dieses aber immerhin von A bis Z.  Nun gibt es aber BitCoins als Zahlungsmittel und FPGAs sind gut darin, diese zu "minen".  Gemessen werden getestete Hashes pro Sekunde. Alles ist Open Source und sollte auf allen Platformen funktionieren.

Auf einem 1.8GHz dual Celeron bekam ich 0.5Mhashes/s. Ein 3.2GHz i5 core kommt auf 2.5 Mh/s. Eine 650 MHz AMD/ATI HD5670  Grafikkarte schafft 64Mh/s. Der FPGA mit 184MHz bringt 92 Mh/s. Nun ist das nicht die bestmögliche Grafikkarte, aber es ist auch bei weitem nicht der breiteste FPGA. Jedenfalls macht der anders als die Grafikkarte keinen Krach da passiv gekühlt und verbraucht deutlich weniger Energie. Steckt man ihn sich schnell an? Ich denke schon. Es werden auch FPGA-Karten mit mehreren FPGA darauf angeboten, und zudem kann man diese Karten auch clustern. Hier sollte sich doch ein Open Source Markt entwickeln können - wenigstens für die Bioinformatik.

Das BitCoin Mining ist nicht sonderlich attraktiv anzuschauen. Man sieht links die Grafikkarte mit Phoenix 2.0. Rechts ist der FPGA mit ZTEX's BTCMiner. Abundan kommt ein Treffer und der wird, so man nicht alleine arbeiten möchte, an einen Server geschickt - ganz in Analogie zu BOINC. Es gibt eine ganze Reihe solcher "pools". Diese organisieren eine beeindruckende Rechenleistung von >3000000 Mh/s (3000 Gh/s), also etwa 30000 FPGA der Art wie ich einen habe oder eine Million guter CPU cores.

Der screenshot oben ist nun schon wieder etwas überholt. Ich bin nun drei Stunden dabei und damit wird sich mein Ausflug zum Bitcoin Mining wohl auch beenden. Immerhin habe ich inzwischen etwa 0,02 Euro eingespielt. Über den Tag hinweg wären das vielleicht 0,16, in der Woche ein Euro. 

Wenn über USB angeschlossen, sind FPGA wohl auch über virtuelle Maschinen anzusprechen. Wir sollten also bald vermehrt FPGA in Clouds sehen. Probiert habe ich das aber noch nicht. Reizen würde mich auch eine Integration mit BOINC. Ähnlich den GPUs benötigt man selber die hohe Rechenleistung nun einmal nur für kurze Zeit, die andere Zeit stünde die Maschine zur Verfügung. Wenn man sieht, wieviel Rechenleistung da hinter den paar Euro herjagt, wäre es vermutlich geschickter, wenn BOINC sich organisieren würde, um Bitcoins für getane Arbeit an ihren Projekten direkt zur Verfügung zu stellen.

Ich danke den BitCoinern, da sie FPGA plötzlich für die Masse so viel interessanter machen. So wie GPUs die Spiele brauchten, habe ich nichts dagegen, wenn sich FPGAs über BitCoins in die Herzen spielen. Mein nächster Bericht zu FPGA ist aber hoffentlich irgendwie bioinformatisch.

BitCoins und FPGA zur technischen Vorbereitung auf die Bioinformatik

Nach vielem Lesen darüber wollte ich es diese Woche nun auch mal probieren: 1KJqLGAEaVMLWNVEq3McPv4KGqSwYLpxEP ist nun meine BitCoin Adresse für diesen Blog. Probiert es doch mal aus, ich freue mich über jeden μBitcoin :o)  Mein Einstieg war bei BitCoin.de.

Ein BitCoin ist in etwa soviel wert wie es kostet, ihn zu berechnen und damit der erste zu sein.  Das sind derzeit etwa 4 Euro. Gehandelt wird er bei Börsen wie eben BitCoin.de oder man berechnet ihn eben selber. Wer besonders effiziente Maschinen hat, hat einen Vorteil. Und die in einem früheren Posting bereits erwähnte Firma ZTEX aus Dresden bietet bereits einen FPGA-BitMiner an. Wer sich also ein Gerät besorgen möchte, das sich vermutlich viermal schneller als Solarzellen amortisiert, der greife zu und lerne dabei ... und nutze sein so gemehrtes technisches Wissen dann für die bioinformatische Forschung, bitte.

Debian+Science+PR

Debian Science und Public Relations ... "we suck at PR". Da sind sich alle Mitwirkenden bei Debian Science oder Debian Med recht einig. Naja, aber wer will schon etwa auf Kongressen an einen Debian Stand stellen statt den Präsentationen zuzuhören. Schliesslich kostet das auch alles Zeit und  Geld. Beides haben wir dafür eher nicht übrig. Selbst Open Access Veröffentlichungen kosten. Wer Debian Geld gibt (Spenden hierhin oder rechts an der Seite via Amazon das eine oder andere bitte kaufen), der gibt dies vermutlich eher für die Verbesserung von Debian, nicht für dessen Verbreitung, frei nach: wer Debian finden möchte, der findet Debian. Und wer mitmachen möchte, der kann ja mitmachen (Debian Diversity Statement).

In meiner persönlichen Wahrnehmung ist das alles nicht so tragisch. Für PR haben wir Ubuntu. Und in unseren Fachgebieten kennen wir uns alle mehr oder minder oder wenigstens über eine Ecke. In die Welt getragen gehört dort, wie offen wir auch für speziellere Software sind, also die jeweiligen Institute von der Infrastruktur Debians direkt profitieren können und fachliche Kooperationen sich so leichter umsetzen lassen. Wenn sich größere Institute öffentlich zu Debian bekennen, wie etwa gerade das European Synchrotoron, so ist das sehr erfreulich, denn bestimmt stärkt dies die Gemeinschaft. Aber gerade bei Debian Med liegt der Gewinn wohl eher bei den vielen kleineren zerstreuten Gruppen, die durch die direkte Verfügbarkeit von Programmcode und den ausführbaren Dateien viel an Kraft durch Debian/Ubuntu/Mint/... gewinnen. Sollte man die hier nun alle erwähnen? Für wen?

Über die Stärkung des Miteinanders von Workflow engines wie Taverna, Template "Rezepten" in myExperiment.org und Linux Distributionen wie eben Debian versuche ich seit einer Weile, dem Miteinander der vielen kleinen Expertengruppen so etwas wie einen ausführbaren Rahmen zu geben. Bislang klappt das noch nicht so wirklich. Mal sehen.

EURO-Codefest 2012 in Bergamo

Die Bioinformatics Open Source Conference (BOSC) ist dieses Jahr in Kalifornien. Das ist ein wenig weit weg, für viele zu weit. In den vergangenen Jahren gab es zur BOSC stets ein pre-meeting, bei dem es (ganz ohne Vorträge) nur um ein konstruktives Miteinander der vielen Entwickler geht. Man kennt sich, oder die jeweilige software, lernt sich kennen, denkt gemeinsam weiter.

Nun hatte ein niederländisch-italienische Trupp die Idee, doch so ein bioinformatisches Codefest eine Woche später auch in Europa stattfinden zu lassen. Gewählt wurde die direkte Umgebung von Bergamo/Mailand, Lodi, am 19. und 20. Juli. Mehr hier.

Es gibt eine gewisse Überlappung hinsichtlich der voraussichtlichen Teilnehmer zum Debian Med sprint. Und das ist gut so.

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.

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.

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.

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

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.

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.

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]

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.

Apibaso Datensatz nun bei Flattr bekanntgegeben

Man fühlt eine gewisse Blamage, wenn sich (so wie bislang nach 5 Stunden) nicht eine Seele für seinen Datensatz interessiert. Jedenfalls könnt Ihr mir nun via Flattr.com ein paar Pfennige zukommen lassen. Dazu müsstet Ihr nur erklären, dass Euch mein Datensatz zu apikal-basolateral unterschiedlich verteilten Membranproteinen gefällt.



Wie Ihr vielleicht ahnt, freue ich mich über die Anzahl von Eyeballs wohl noch mehr als über die eh nicht allzu üppig zu erwartenden Euro.

Ungenutzte Idle time der Wissenschaft spenden

Inzwischen haben aktuelle Prozessoren alle so viel power, dass wir alle davon wenigstens während der üblichen Bürotätigkeiten den weit überwiegenden Teil davon entbehren können. Wenn also noch etwas im Hintergrund mitläuft, so merken wir dies gar nicht.

Mit BOINC (boinc.berkeley.edu) wird einem die Suche nach einem an der eigenen CPU interessierten Wissenschaftlers abgenommen. Debian gestaltet die Installation besonders einfach, d.h. mit
apt-get install boinc und dann boincmgr kann man spielend leicht Teil eines solchen internationalen Projektes werden. Ich selber helfe dem BOINC Projekt www.worldcommunitygrid.org und darin FightAids@Home des Scripps Institutes in Kaliformien - na klar, schliesslich sponsore ich ja auch das Debian Paket zu deren autodock suite :)

Neu ist, dass die Debian und Ubuntuaner hinter den BOINC Paketen nun gemeinsam an den Paketen arbeiten, dies also buchstäblich im selben Repository. Mit dem Debian Derivatives Frontdesk, eine Art Kontaktbörse für die Entwickler der verschiedenen Platformen, hatte dies allerdings nichts zu tun. Ist doch schön, wenn das alles auch so klappt :)

Debian kann mit GENtle nun Gene klonieren

"Klonieren" klingt gefährlich, doch geht es bei diesem vielfältigst genutzten Begriff in diesem Fall lediglich um ein Kopieren eines Teilabschnitts unserer DNA. GENtle kann tatsächlich auch noch mehr, so etwa das Schneiden oder Zusammenfügen solcher Konstrukte vorausdenken. Im Labor geschieht dies oft, d.h. immer dann, wenn man das fertige Konstrukt noch nicht kaufen kann, also insbesondere in der Foschung.

Das Programm GENtle (http://gentle.magnusmanske.de/) ist eines der wenigen freien Programme hierzu und seit wenigen Minuten in unstable. Mal sehen, was popcon.debian.org hierzu sagen wird. Einige wenige Molekularbiologen mit Debian oder Ubuntu kenne ich persoenlich, sicherlich koennten es noch einige mehr werden. Hierbei geht es nicht so sehr um die gern gesehene Verdrängung anderer Betriebssysteme, sondern um eine Form des Miteinanders und des Austausches von Methoden, die sich in solchen Programmen widerspiegelt. Debian's community kann allein als Medium für den Austausch solcher Gedanken bereits viel Gutes tun. Abwarten.

Präsentation von Blutzuckerwerten mit Debian und R

Naja, der Link zu Debian hinkt ein wenig, außer dass diese Präsentationsarbeit mir inzwischen mehrere Wochenenden genommen hat, die ich ansonsten u.a. hätte mit Debian-Paketierung verbringen können. Jedenfalls gibt es nun ein Paket für die Statistik-Software R (Debian: apt-get install r-base-core), mit dem die in Diabetes-Tagebüchern eingetragenen Werte besser präsentiert werden (denke ich) als irgendwo anders. Da jeder 1000ste bis 100ste Debian-Nutzer wohl selber etwas mit Diabetes zu tun hat, und noch mehr Debian-Anwender einen Diabetiker in ihrer engen Verwandtschaft haben werden, poste ich dies hier einfach mal und bitte um Kommentare zu meinem Diabetes R Paket. Es ist als "sugaR" nun Teil des CRAN. Ich habe ziemlich viel Arbeit in die Paket-Beschreibung (vignette) gesteckt, die auch erklärt, wir Ihr etwas zur Entwicklung beitragen könnt, wenn Ihr das wollt. Das Auschecken solle mit svn co svn://svn.debian.org/svn/pkg-escience/r-cran-sugaR/ direkt möglich sein, hierzu ggf. zuvor ein apt-get install subversion ausführen.