2012年2月9日木曜日

亀裂面の反応特性を測りたい

難しいですね。

岩盤からの湧水は、通常、亀裂面を通過して出てきます。そのため、水質は母岩の鉱物量比ではなく、亀裂面のそれに規制されます(dual porosity で表すべきものは除く)。

亀裂面の鉱物比のみを定量化するのは、力技でできるでしょうが、反応特性は難しい。鉱物脈のみ取り出したり、粉砕したりすると比表面積が変わりますし、脈の形成順序(時間的な水質変化)も反映できなくなります。鉱物比を定量化するために片側のコアをつぶしてしまうと、通水もできなくなります。

コアに縦方向の亀裂があれば、通常の3軸圧縮試験機で透水係数とともに反応特性を求めることは容易でしょう(厳密には拡散特性を考慮する工夫をしないといけませんが)。
しかし、横方向や斜めの亀裂となると困難ですね。そのような亀裂面のみ通水できる装置は見たことがありません。縦亀裂になるように、コアからの再コアリングもできなくはないですが、通常、開口亀裂では崩れてしまいます。

何か良い装置は無いでしょうか?しかも水質にまったく影響しない素材で何とかしたい。
うーん。難しい。

2012年2月7日火曜日

海底トンネル事故

このニュースを聞いた時、貯槽関連か?と緊張が走りました。が、違いました。
http://www3.nhk.or.jp/news/html/20120207/t10015852681000.html

原因は何だろう?海底下も風化帯が厚い場所なのに、浅い箇所を掘る設計だったのだろうか?などと想像しながら帰宅。ニュースを見ると、鹿島さん。すぐ近くを何年も掘っていたでしょうに、と思いながら続きを見ると、海底トンネルといってもNATMではなく、シールドでした。地表(埋め立て)から深度30mの竪坑より発進している絵が紹介されていましたが、海底からは何mだったのでしょう?詳細はいずれ明らかになるでしょう。

私も海底下で数年間働いていましたので、人ごととは思えません。あのような状況で海水が入ってきたらと思うと・・・とにかく、早く見つけてあげて下さい!

2012年2月6日月曜日

Kinect Hack

キネクトハックがブームのようです。

Kinect は MS 社のゲーム機 Xbox の周辺機器です。私も持っていますが、この性能が凄い。初めて触れた時は驚きました。

これ、PC に接続できます。SDK は Win7 専用のようですが、以前よりハックされ、XP などでも動作可能になっています。また、今月に入って、「Kinect for Windows」も発売されました(なぜかゲームよりかなり高い)。

PC につなぐことで、以下のようなアプリの開発が可能となります。

光学迷彩


本来の使い方?

3Dスキャナー (ic2020)


熱狂するはずです。
ic2020、現在ソースは公開されていませんが、似たようなアプリは次々出てくるでしょう。3D スキャナーとしての利用は随所にUPされていますし、アプリを公開されている方もいらっしゃいます。洞窟や管内、人の立入れない現場のスキャンに使えそうですね。当然、3Dですからシミュの土台にも利用できるでしょう。
本来の使い方であるモーションキャプチャーも使い方によっては面白いですね。静的なスキャンはもちろん、動的3Dスキャンも可能なところがポイント高いです。

仕様上、現段階では明るい屋外利用は難しいと思います。遠方のスキャンもダメ。また、kinectの電源処理も工夫が必要でしょう。。
しかし、家庭用ゲーム機の周辺機器でこんなことができる時代になっていたのです。発想とプログラミングのスキルで、いろんな可能性が生まれるでしょう。

2012年2月5日日曜日

Optical Flow (Block Matching)

OpenCVのサイトにあったVer.1, 1.1用ブロックマッチングのサンプルコードを試してみました。
http://opencv.jp/sample/optical_flow.html#optflowBM
先日入れたVer.2.2、2.3.1に追加で古い1.1を入れてから試してみました。

が、動きません。以下のエラーが出ます。
OpenCV Error: Sizes of input arguments do not match () in unknown function,file ..\ocv\opencv\modules\video\src\optflowbm.cpp, line88
このファイルはタイムスタンプよりVer.1.1ではないようです。中身をみると、どうも以下の個所で引っかかったようです。
    CvSize velSize =
    {
        (srcA->width - blockSize.width)/shiftSize.width,
        (srcA->height - blockSize.height)/shiftSize.height
    };
    if( !CV_ARE_SIZES_EQ( srcA, srcB ) ||
        !CV_ARE_SIZES_EQ( velx, vely ) ||
        velx->width != velSize.width ||
        vely->height != velSize.height )
        CV_Error( CV_StsUnmatchedSizes, "" );
サンプルコードでは以下のように設定されており、このサイズ違いがエラーの原因になったのでしょう。
rows = int (ceil (double (src_img1->height) / block_size));
  cols = int (ceil (double (src_img1->width) / block_size));
  velx = cvCreateMat (rows, cols, CV_32FC1);
  vely = cvCreateMat (rows, cols, CV_32FC1);
ちなみに、velxのサイズの計算式がVer.1.1と2.1の説明で異なっています。
http://opencv.jp/opencv-2.1/c/motion_analysis_and_object_tracking.html
仕様変更でしょうか?Ver.1のサンプルを動かす時は、当たり前ですがVer.1のみの環境にしておいたほうがよいのでしょう。今回は上位Ver.でファイルを上書きしてしまったのかもしれません。

とまあ、アタリはついたので、サンプルコードの rows、cols の計算式を2.1と合うように変更してやりました。結果、問題なく動きました。

実際に画像処理を行うときは、block_size や shift_size を画像の特徴や欲しい解像度に合わせて調整する必要があるようです。コンパイラー上で動かした方が良さそうですね。
これで、実装されているアルゴリズムのうち、LK, HS, BM の3種は用意できました。

2012年2月3日金曜日

密度流

解析PCが遊んでいたので、頓挫していた密度流の計算をかけてみました。

22万節点の3次元密度流計算です。
以前はオリジナルに近い Dtransu で、シミュ上の1日の予測計算に、丸1日(実時間)かかっていました。これ、予測になっていません。
今回は並列化済みのDtransuです。早速計算をかけてみました。

が、1.7日/1日のペース。劇的な速度向上は見えません。まあ、汚染を投入した初期の計算なので時間はかかるのでしょう。Δtの刻みが大きなままで、チューニングしていないのも原因の一つでしょうね。

もう少し、様子を見ましょう。

----------------------------------------------------------------------------------
2月12日追記

速度の向上が見られなかったため中止しました。1日の計算が丸1日かかるなんて。モデルを作る段階から考えないといけませんね。当たり前ですけど。

2012年2月1日水曜日

Jarosite の生成 その2

Jarositeに不飽和な問題の続きです。
http://phreeqc.blogspot.com/2012/01/jarosite.html

前回のモデルでは、K-Jaに不飽和でした(SI=-7.6)。
しかし、Alunite のSIが16。研究職に指摘され、現場で再度サンプリング。赤黒い析出物をXRDでチェックしてもらうとAluniteでした。汚れか、Fe の酸化物or水酸化物かと思いこんでおり、ノーチェックでした。

そこで、PHREEQC 上で Alu を析出させてみました。結果、析出でKを消費したので、K-Ja の SI がより低くなってしまいました(SI = -30)。

その後、いくつか現実味のある鉱物組み合わせでチェックしていくと、以下の条件が必須となることが分かりました。
  1. Alu の析出が必須
  2. K のソースを加えることで K-Ja が過飽和になる
XRD などのチェックで把握しきれていないKのソース(例えば K-fsp など)があるはずです。しかも、K/Al が高くないといけません。

実際は local equilibrium に達していないでしょうから、これらの計算通りの答えにハマることはないでしょう。しかし、定性的には十分な Alu, K-Ja の析出モデルができました。

地道な努力

先月購入した教科書、読み始めて3週間が経過しようとしています。

が、進みません。まだ30ページ。書き下しているからということもありますが。このペースだと、全部読んだら7カ月、読みたい箇所だけでも2.5カ月かかります。は~。

今読んでいるのは reactive transport model に関する検討事例なのですが、この方、すごいです。試験をして調べていく過程と、分からないこと(メインは鉱物相)を仮定し、シミュして判断すると言った過程の両方を用いて検討されています。しかも、後者を160ケース実施されています。すばらしい!というか、知識のある方がこのような地道な努力をされるとお手上げです。私は努力しないとプロと話ができないレベルだと自覚していますので、通常のシミュでも100ケースくらい検討します。しかし、この方160。しかも、あたりをつけて絞り込んで160です。1次元の水-反応連成計算とはいえ、160はすごい数です。深い知識がないと、これだけのリアリティーある鉱物組み合わせを、思い浮かべることすらできないでしょう。

色んな面で刺激を受けますね。
ゆっくり読んでいきましょう。