JMEも.NETで使える

JMEも.NETで使えるらしい。

http://chemhack.com/archives/tag/chemoinformatics/

.NETでCDKを使う

CDKはjavaのmolecular class libraryのようなものです。java版のpipeline pilotであるKnimeではメインのChemistry engineとして採用されています。

CDKを.NET環境で使うためのやり方が紹介されていたのでやってみました。

Using the CDK with the .Net framework and Mono

まずjavaのjarファイルを.NETのクラスライブラリー化するためのツールIKVMをダウンロードします。私が落としたのは「ikvmbin-0.42.0.3」です。

ついでCDKのjarファイルを落とします。私が落としたのは「cdk-1.2.4.1.jar」です。

IKVMを使ってこのCDKをdll化します。
コマンドプロンプトでikvm.exeのあるフォルダーに移動して

ikvmc -assembly:cdk_dotnet -target:library cdk-1.2.4.1.jar

と打つとcdk_dotnet.dllが出来ます。この際にWarningが多く出ますが無視。

VisualStudio2008のC#のコンソールアプリケーションを作成して、参照設定にcdk_dotnet.dllを含めikvmのbinフォルダーの中のdllをすべて登録します。

これでCDKが使えるようになりました。

具体的なコードは上記のサンプルコードを参照してください。Molファイルを読み込んで計算値を出力してくれました。

using System;

namespace CDK_test

{

    //Using aliases for convenience and to avoid importing whole

    //packages

    using FReader = java.io.FileReader;

    using TPSA = org.openscience.cdk.qsar.descriptors.molecular.TPSADescriptor;

    using LogP = org.openscience.cdk.qsar.descriptors.molecular.XLogPDescriptor;

    using DoubleResult = org.openscience.cdk.qsar.result.DoubleResult;

    using Builder = org.openscience.cdk.DefaultChemObjectBuilder;

    using IMol = org.openscience.cdk.interfaces.IMolecule;

    using MolReader = org.openscience.cdk.io.iterator.IteratingMDLReader;

    using Consts = org.openscience.cdk.CDKConstants;

    class Program

    {

        static void Main(string[] args)

        {

            FReader fReader = new FReader("C:\Test.mol");

            MolReader molReader = new MolReader(fReader, Builder.getInstance());

            IMol mol;

            DoubleResult dr;

            LogP logP = new LogP();

            TPSA tpsa = new TPSA();

            double logPVal, tpsaVal;

            string name;

            while (molReader.hasNext())

            {

                mol = (IMol)molReader.next();

                dr = (DoubleResult)logP.calculate(mol).getValue();

                logPVal = dr.doubleValue();

                dr = (DoubleResult)tpsa.calculate(mol).getValue();

                tpsaVal = dr.doubleValue();

                //the title of each mol in the file is the name of the mol

                name = (String)mol.getProperty(Consts.TITLE);

                Console.WriteLine("{0} {1} {2}", name, logPVal, tpsaVal);

            }

            Console.ReadLine();

        }

    }

}

今回は純粋な.NETのclass libraryしか参照していないので、そのままSpotfireのツールに出来そうです。

OpenBabelをTIBCO Spotfireへ実装する

OpenBabelをTIBCO Spotfireへ実装することにしました。

Spotfireはご存知の通り、大量データの可視化ツールですが、開発環境にC#を採用することで、適用できるツールの範囲が広がりました。

もちろんOpenBabelの.NETモジュールを使うことでTIBCO Spotfireなら比較的簡単に実装が可能です。

ひとつ問題があります。旧タイプのDLL（Win32 APIなどを呼び出すときの仕様）はVisualStudioでは使用可能ですが、TIBCO SpotfireのBuilderでは登録を拒否されます。このあたりは要改善事項です。

OpenBabel .NETはこのタイプのDLLを使っているので、そのままでは登録できません。

あれやこれやと悩んだのですが、ようやく解決策が見つかりました。DLLのファイルをいったん拡張子をtxtにします。TextファイルならSpotfireのBuilderも安心して登録することが出来るのでClientに送信が出来ます。起動するときにこれらのTextファイルの拡張子をdllに戻してやります。するとOpenBabelがちゃんとdllを認識して動作するというわけです。

なんかウィルスの動きをミミックしているみたいで、どうゆうわけかやな気分ですが、とりあえず動きそうなんで、この仕様でがんばろうっと。

Smilesから2D構造を表示する

Smiles文字列を見ただけで２D構造が浮かぶ人ようなすごい人はいいのですが、全く浮かばない私はSmilesから２D構造を表示して見たいわけです。

通常はDaylight Toolkitのsmi2molを使ってSmilesをSDファイルに変換してからISISやSpotfireなどで見る訳ですが、WindowsとUnixを行ったり来たりするのはうざい。なんとかWindows環境だけで２D構造を起こせないかと探していたらありました。

http://opensource.scitouch.net/indigo/

Indigoの中のDingoというモジュールを使えばSmilesやSmartsに加えてMolファイルやRxnファイルを読み込んで、構造を画像（PDF、PNG、SVG、HDC、Bitマップ、Metaファイル）として出力できます。とりあえず見るという目的ならこれで充分。

しかも.NET Class LibraryもついているのでVisualStudioですぐに動かせます。TIBCO SpotfireのRendererにも転用可能です（というかもう作った）。

これで座標の入ったMolファイルとしても出せればいいのですが、調べたところでは出来なさそう・・・。

OpenBabel：SuperCanonicalizer()

前回はSmilesの/と\で表現される立体異性体の問題を解決してOKかと思ったのですが、またも落とし穴を発見。

それは@です。

@と@@は原子のChirality（鏡像異性）を表してあり、それぞれ反時計回り、時計回りのChiralを表します。

SuperCanonicalをするためにはこのChiralityを取り除く必要があります。

OpenBabelのOBMolクラスにはIsChiral()というMethodがあり原子がChiralかどうか判定できます。これがTrueのときにUnsetStereo()を適用することでChiralを消すことが出来ます。

OpenBabel : Frameworkerを作ろう

FrameWorkを作るには各Fragmentの結合の組み合わせをすべてもれなくPick Upする必要があります。

たとえば下記のFragment構造を持った分子の場合、

可能な組み合わせは

A,B,C,D,E,F

A-B,B-C,B-D,D-E,D-F

A-B-C,A-B-D,C-B-D,B-D-E,B-D-F,D-E-F

・・・

などと組み合わせていく必要があります。

6Fragmentからなる分子の場合で3Fragmentから成るFrameworkは6C3=6*5*4/(3*2*1) = 20通りのなかから連結したFragmentを探すことになります。これらを１～Fragment数分の組み合わせを探すことが必要です。

最初は各Fragmentの連結情報からFragment長にあう組み合わせを網羅的にかつ有機的に探していこうとしました。しかし、分岐問題をスマートに解決する手法がなかなか思いつかず、それならすべての組み合わせの中からちゃんと連結したFragmentを組み合わせを探して、それをFrameWorkとしよう、ということにしました。

これなら、ちょっとだけ時間はかかるけど漏れなくFrameWorkを探せるな、ということです。

OpenBabel：SuperCanonicalizer()

前回は価数の超過に対応して、もうこれで大丈夫と思ったのですが、またまた落とし穴を発見。

今回はStereo Isomerです。

Smilesでは/はUpper Bond、\はDown Bondを表します。これらもinchiで除けるかと思ったのですがだめでした。inchiをかえしてもUpper/Downはそのままでした。

これは一発のコマンドではどうしようもなかったので

foreach (OBBond oneBond in Mol.Bonds())

{

    if(OneBond.IsUp()){oneBond.UnsetUp();}

    if(OneBond.IsDown()){oneBond.UnsetDown();}

}

というような感じで、一個一個Bondをチェックして標準化しました。

しかし、SmilesのくせにStereo Isomerを表現するとは生意気だ。

まだ落とし穴があるかも・・・。