2013年12月9日月曜日

透過反応壁とPHREEQC その2

結果が微妙に異なるのは、使用していた熱力学データベースが文献と異なっていたようです。


WATEQ4f で計算していたのですが、文献は PHREEQC でした。扱っている鉱物の数が倍半分ですので、結果も異なったのでしょう。ま、傾向は同じですし、どちらが正解に近いかは、試験室でないとわかりません(局所平衡を仮定し、EQUILIBRIUM_PHASES を使用した Test Run であって、地下水の流れを再現しているわけではありません)。

ZVI は PHASES で Fe を分解し、logK、enthalpy を与えています。ま、その値が分からずに今まで何もしなかったのですが。手元にある参考書には logK しか載っていなかったので、温度変化が扱えなかったんですよね。

とにかく、PHREEQC で再現できたのは収穫です。input ファイルの組み方が確認できましたので、次は PHAST で透過させてみましょうか。

2013年12月8日日曜日

透過反応壁とPHREEQC

以前より、ZVI を用いた PRBs の計算をしたかったのですが、情報が少なく、そのままにしていました。

先日より、また気になりだして資料を探していました。

今回、一番に引っかかったのは Amazon。洋書でした。
「なか見!」で本の中を見ましたが、モデリングの詳細は書かれていませんでした。買う必要はないと思い、そこの引用文献だけ検索してみました。(便利な時代になりました)。
引用文献は PDF で入手できました。古い米空軍の PRBs に関する資料です。

これ、当たりでしたね。PHREEQC による簡単な計算結果が載っています。
ただ、肝心な ZVI のモデル化が抜けており、掲載されているinputファイルそのままでは動きません。たぶんこのように組んだはずだと、文献を読みながら作成。で、計算!


結果を見ますと、傾向は合っているのですが、数値が微妙に合いません。

続きは後日。


2013年12月6日金曜日

スタックサイズの変更

並列化済みの Dtransu を動かす場合、スレッド数やスタックサイズは、batファイル内で指定していました。

後輩から、それをソース内で固定できないか?といった問い合わせがありました。
ソース内で固定したことはないのですが、当然可能だろうと触ってみたところ、うまくできません。力不足です。

調べてみると、スレッド数の指定はすぐに引っかかりました。Win7 + Fortran では以下の通り。

call OMP_SET_NUM_THREADS(スレッド数)


しかし、スタックサイズの指定が分かりません。オプションの中を見てもわからなかったので、その日は解決できず。


後日、調べてみましたが、結局明示する方法はわからず。最終的に、Win7側で環境変数を固定することにしました。

OMP_STACKSIZE を追加すればOKです。スタックサイズはそれほど変更することがないので、固定しておいても問題ないですね。画像では、OMP_NUM_THREADSも追加していますが、ソース内で指定する場合は不要です。






しかし、これらを解決するのに、3夜かかりました。
プロがそばに欲しいですね。


2013年12月4日水曜日

玉石径は3倍?

今日、突然電話がかかってきました。

「玉石の径を推定する場合、ボーリングで確認した長さを3倍するが、これ、何かに書かれていないか?」

前からよく聞かれます。が、使わないので忘れます。せっかくなので、書き残しておきましょう。


玉石径3倍についての記載は、基準類には書かれていません。調べてみましたが、参考書では、以下のp126の一文だけでしょう。
近代図書「ボーリングデータの見方と活用ノウハウ」

HPではいくつかあります。
例えば、東北地質調査業協会でも、3倍の説明があります。
http://www.tohoku-geo.ne.jp/technical/qa/07/index.html

発表要旨もいくつかあります。しかし、3倍で良い、3倍じゃダメ、いろいろです。いずれにしても、発表程度では会検に耐えられません(ココまで指摘されるんですね)。


個人的には、地質によって長短比が異なるため、実際に河原などで測るようにしています。でも、それが3倍よりも小さいと、設計者は3倍として扱うことが多いようです。

ま、そのようなところまで根拠を求める方もいらっしゃると、頭の片隅においておきましょう。


2013年12月3日火曜日

面流量

要素の面を通過する流量について。

境界面なら、節点流量で計算できます。が、モデルの中の節点は+-0なので、集計できません。

計算するとすれば、以下の手順でしょうか?

要素No.チェック
面No.チェック
面の構成節点チェック
節点の座標チェック
3点から2辺のベクトル作成
2辺のベクトルから外積計算
要素流速から合成ベクトル作成
法線ベクトルと合成ベクトルの内積計算
面積をかけて流量とする。


いえ、適当です。組み立てていかないと、正しいかどうか分かりません。書いている途中から実務では無理だと思いましたので。

やはり、ポスト処理のソフトを使うべきですか。


2013年12月1日日曜日

NHKスペシャル 汚染水 ~福島第一原発 危機の真相~

NHKスペシャル 汚染水 ~福島第一原発 危機の真相~
http://www.nhk.or.jp/special/detail/2013/1201/

地下水の流れに汚染がのることは、TEPCOさんなら、重々承知されていたことでしょう。
ただ、わかっていても、できなかったのだと思います。

一方、番組では現在も漏洩の原因を究明していく体制が映されていました。現場で船を操作する映像にも、後ろに余裕のありそうな方が映っていました。

違和感の多い番組でしたね。

浸透流計算が収束しない その2

また、後輩からヘルプ。Dtransu で初期定常が収束しないとのこと。
http://phreeqc.blogspot.jp/2012/08/blog-post_25.html

改良済みの UNSAF なら回るのに、Dtransu だと回らないそうです。地下水や雨がオーバーフローした時の取り扱い方が違うのでしょうね。
Dtransu は、降雨浸透境界に降雨があり、さらに正の水圧がかかると P=0 の水頭固定となります。私は UNSAF を使用しませんので、どのように改良されたか知りません。知る必要がありますね。

原因としては境界条件の張り方や透水係数のオーダーなどいくつかあったのですが、やはり根本は不飽和特性。
これを簡易に回避している資料が、原子力安全基盤機構さんより公開されています。
http://www.jnes.go.jp/content/000117846.pdf
なお不飽和特性に関しては、収束性の観点より飽和度の低い領域では比透水係数の最小値の最小値を0.2として設定して補正を行った(図3.8は補正を行う前のものである)。
なお、AC-UNSAF3DにおいてはDtransu・3D・ELとほぼ同様な結果が得られた。
3D-SEEP及びTOUGH2においては,上述の通り適切な涵養量を設定できずDtransu・3D・EL等にて設定した降雨強度をそのまま使用したため、地表において飽和となった領域に対しても設定した降雨強度を無理やり押し込むと言った計算になってしまい水頭が異常に高い結果となってしまった。特にTOUGH2においては、収束性をよくするための不飽和特性曲線に対する補正が行えず、今回設定した収束条件を満たすまで解を収束させることが出来なかった。
広域解析では比透水係数の最小値を0.2とした補正を施したが、小域は山岳部が存在しないことから負のサクション圧が大きくなることはないと考えられること、メッシュ分割が細かいため解析が収束しやすいこと等を考慮し、小域解析では比透水係数の最小値を0.01に補正した不飽和特性曲線を使用した(図3.9は補正を行う前のものである)。

うーん、0.2は大きいですね。
解決したといえるのかわかりませんが、ま、悩んでいるのは私たちだけではないということです。