久しぶりに、よく動いている地すべりのコアを見ました。
しっかり破砕されています。
一時期、地すべりばかり扱っていた頃を思い出しました。道具が良くなったのか、オペさんの腕が良いのか、粉砕されている個所から礫を含む箇所、基岩との接触面、基岩の破砕部など、全区間でコアはきれいに取れています。樹脂加工したいくらいです。CTも欲しいですね。
こういった綺麗なコアが並べられていると、人が集まります。そして議論が始まります。地質屋さんも設計屋さんも一緒になって、あーだ、こーだと。
ありがたいですね。
暑い中でも妥協せず、丁寧な仕事をしていただいたオペさんに感謝です。
2017年7月25日火曜日
BIDO
円形アレーが組めるようになりましたので、データ整理ソフトを整備していました。
よく利用している表面波探査のソフトが SPAC に対応していますし、同じ要領でS波速度構造まで計算・表示できます。
それだけでも良いのですが、できれば今回教えてもらった産総研さんの BIDO を使いたい所です。マニュを読む限り、BIDO は分散曲線を多くの手法で一度に計算・表示してくれる優れモノ。CCA にも対応していますので、ジャストポイントで調査できない場合でも計算できます。事前に仕込んでおく価値はあるでしょう。
が、2〜3日試行錯誤しても全くダメ。 VF や gfortran の環境では完走しません。Win + Cygwin も Ubuntu 系 Linux もダメ。公開当時の g77 環境を再現できれば動くのでしょうか？それにしても、g77 って。ちなみに、g77のありかはこちら。φ(..)
https://askubuntu.com/questions/837618/need-the-gnu-g77-fortran-compiler-on-ubuntu-16-04-having-issues
あきらめかけた4日目、CentOS7 64bit ＋ gfortran で計算は走りました（plotはダメ）。古いマシンにCentoOSを入れて、gcc 関連を一通り入れて、コンパイルし直すと OK でした。ふー。
詳細は分かりませんが、ライブラリのパスが関係しているようでした。
今日はここで時間切れ。グラフを表示してくれませんので、正しい結果が出ているのかわかりません。後日、結果をEXCELに持って行って確認しましょう。どのみち、BIDO では S波構造を逆解析してくれないようですので、分散曲線を Win に持っていく必要があります。ん？そういえば、分散曲線を読み込んで逆解析できたかな？
良いこともありました。
BIDO の引用文献を追っていくと、逆解析時の初期モデルで波長の1/3（1/2～1/4）を深度とする根拠（と思われる文献）を見つけました。今まで気にかかっていたところです。
Ballard, R. F. and Jr. (1964) Determination of soil shear moduli at depth by in situ vibratory techniques, U. S. Army Waterways Experiment Station
紺野克昭 (1997) レイリー波の分散曲線の近似計算法の提案と地下構造推定への応用, 土木学会論文集, I-41, pp. 89-105
高田 至郎, J. P. WRIGHT (1980)ライフライン系解析のための相対地盤震動, 土木学会論文報告集, No. 299, pp. 13-21
2つ目の文献の図を見る限り、1/4でも良いかなあと。そうすると、道路橋示方書の固有周期の算出式と同じ形になります。ただ、波の来る方向は縦と横で異なる（と思っている）ので、いまいちイメージできません。今までの理解が間違っていたのかしら？わからなくなってきました。ここはプロに聞いてみましょう。
若干ですが、進んだように思います。
とりあえず、 計算結果を見てみましょう。それがクリアできていたら、データを取りに行きたいですね。
**************************************************
20170726追記
gnuplot が入っていませんでした。グラフが表示されないはずです。
入れるとOK。計算結果もOKでした。
よく利用している表面波探査のソフトが SPAC に対応していますし、同じ要領でS波速度構造まで計算・表示できます。
それだけでも良いのですが、できれば今回教えてもらった産総研さんの BIDO を使いたい所です。マニュを読む限り、BIDO は分散曲線を多くの手法で一度に計算・表示してくれる優れモノ。CCA にも対応していますので、ジャストポイントで調査できない場合でも計算できます。事前に仕込んでおく価値はあるでしょう。
が、2〜3日試行錯誤しても全くダメ。 VF や gfortran の環境では完走しません。Win + Cygwin も Ubuntu 系 Linux もダメ。公開当時の g77 環境を再現できれば動くのでしょうか？それにしても、g77 って。ちなみに、g77のありかはこちら。φ(..)
https://askubuntu.com/questions/837618/need-the-gnu-g77-fortran-compiler-on-ubuntu-16-04-having-issues
あきらめかけた4日目、CentOS7 64bit ＋ gfortran で計算は走りました（plotはダメ）。古いマシンにCentoOSを入れて、gcc 関連を一通り入れて、コンパイルし直すと OK でした。ふー。
詳細は分かりませんが、ライブラリのパスが関係しているようでした。
今日はここで時間切れ。グラフを表示してくれませんので、正しい結果が出ているのかわかりません。後日、結果をEXCELに持って行って確認しましょう。どのみち、BIDO では S波構造を逆解析してくれないようですので、分散曲線を Win に持っていく必要があります。ん？そういえば、分散曲線を読み込んで逆解析できたかな？
良いこともありました。
BIDO の引用文献を追っていくと、逆解析時の初期モデルで波長の1/3（1/2～1/4）を深度とする根拠（と思われる文献）を見つけました。今まで気にかかっていたところです。
Ballard, R. F. and Jr. (1964) Determination of soil shear moduli at depth by in situ vibratory techniques, U. S. Army Waterways Experiment Station
紺野克昭 (1997) レイリー波の分散曲線の近似計算法の提案と地下構造推定への応用, 土木学会論文集, I-41, pp. 89-105
高田 至郎, J. P. WRIGHT (1980)ライフライン系解析のための相対地盤震動, 土木学会論文報告集, No. 299, pp. 13-21
2つ目の文献の図を見る限り、1/4でも良いかなあと。そうすると、道路橋示方書の固有周期の算出式と同じ形になります。ただ、波の来る方向は縦と横で異なる（と思っている）ので、いまいちイメージできません。今までの理解が間違っていたのかしら？わからなくなってきました。ここはプロに聞いてみましょう。
若干ですが、進んだように思います。
とりあえず、 計算結果を見てみましょう。それがクリアできていたら、データを取りに行きたいですね。
**************************************************
20170726追記
gnuplot が入っていませんでした。グラフが表示されないはずです。
入れるとOK。計算結果もOKでした。
2017年7月17日月曜日
微動計
「微動計を4つ買ったよ」という連絡がありました。
おお、アレー組めるね、ということでテスト状況を見に行きました。
「NHKスペシャルで新機種を使っているのを見たので、問い合わせて買った」とのこと。なるほど。それ、私も見ていました。
番組では、アレーを組むために1mくらいのスケールを作られていて、それに合わせるだけで配置できるよう工夫されていました。その様子に「うまく考えられているなあ」と感心していました。
その話をすると、「これでしょ」と見せてくれました。オプションでついていたそうです。おお、実物もなかなか良い。
では、iPadのアプリは？と聞いてみますと「それは開発中で販売されていなかった」とのこと。
実はこれが最も印象に残っていました。宅地地盤の評価をそのアレーサイズでやっているの？でも、アプリは欲しい！と。
詳細は分かりませんでしたが、データをWi-Fiで吸い上げ、その場で分散曲線を確認でき、S波構造までiPadで出せるとなると、お手軽です。アレー結果を整理する PC ソフトは持っていますが、それを現場で実施しようとすると、机が欲しいところですので。
ま、開発が遅れるようなら自作すればよい話です。モバイルのアプリは組んだことがありません。チャレンジしてみましょうか？
いずれにしても、これで自由に（無線で制約なく）アレーが組めるようになりました。いくつかの現場で使ってみましょう。
おお、アレー組めるね、ということでテスト状況を見に行きました。
「NHKスペシャルで新機種を使っているのを見たので、問い合わせて買った」とのこと。なるほど。それ、私も見ていました。
番組では、アレーを組むために1mくらいのスケールを作られていて、それに合わせるだけで配置できるよう工夫されていました。その様子に「うまく考えられているなあ」と感心していました。
その話をすると、「これでしょ」と見せてくれました。オプションでついていたそうです。おお、実物もなかなか良い。
では、iPadのアプリは？と聞いてみますと「それは開発中で販売されていなかった」とのこと。
実はこれが最も印象に残っていました。宅地地盤の評価をそのアレーサイズでやっているの？でも、アプリは欲しい！と。
詳細は分かりませんでしたが、データをWi-Fiで吸い上げ、その場で分散曲線を確認でき、S波構造までiPadで出せるとなると、お手軽です。アレー結果を整理する PC ソフトは持っていますが、それを現場で実施しようとすると、机が欲しいところですので。
ま、開発が遅れるようなら自作すればよい話です。モバイルのアプリは組んだことがありません。チャレンジしてみましょうか？
いずれにしても、これで自由に（無線で制約なく）アレーが組めるようになりました。いくつかの現場で使ってみましょう。
2017年6月28日水曜日
EXCELで LandXML 読み込み
CTC さんの GEORAMA で地質モデルを作ると、各地層サーフェスが LandXML 形式で geotmp フォルダに書き出されます。
分布範囲のみではあるものの、そこから座標を取り出して変換すれば、他のソフトに楽に持っていけるのになあ、と以前より考えていました。数年前に調べた限りでは、そのような変換ソフトがなく放置していたのですが、「TXT データを成形するだけなのですぐ書けるでしょう」「XML の理解に繋がるでしょう」などと思い自分で組むことに。幸い、EXCEL VBA を始め、各種言語で XML を取り扱う情報は Web 上にあふれていました。便利な時代になったものです。
作業は順調に進んでいたのですが、MSXML パーサーのバージョンに引っ掛かりました。
Win10 ＋ EXCEL 2013 VBA で 6.0 を参照していたのですが、Web 上では古いVer.を参照したコードが多いようで、それらをコピペして動かしてもエラーを吐きます。それが Ver. 違いということに気づくまで、少し時間を要しました。（特にココ→MSXML2.DOMDocument60）
他にも、名前空間（xmlns） に引っ掛かりました。ええ、まったくの初心者です。
XML では情報がタグ付けされているため、欲しい箇所へのアクセスが容易です。そのため、最終的には思ったよりもすっきりしたコードになりました。拡張もアクセスも楽、コードも簡素、なかなか良い仕様・特徴だと思います。XML が広まった理由、少し理解できました。
結果的には理解するのに２晩かかったのですが、良い経験になったと思います。
分布範囲のみではあるものの、そこから座標を取り出して変換すれば、他のソフトに楽に持っていけるのになあ、と以前より考えていました。数年前に調べた限りでは、そのような変換ソフトがなく放置していたのですが、「TXT データを成形するだけなのですぐ書けるでしょう」「XML の理解に繋がるでしょう」などと思い自分で組むことに。幸い、EXCEL VBA を始め、各種言語で XML を取り扱う情報は Web 上にあふれていました。便利な時代になったものです。
作業は順調に進んでいたのですが、MSXML パーサーのバージョンに引っ掛かりました。
Win10 ＋ EXCEL 2013 VBA で 6.0 を参照していたのですが、Web 上では古いVer.を参照したコードが多いようで、それらをコピペして動かしてもエラーを吐きます。それが Ver. 違いということに気づくまで、少し時間を要しました。（特にココ→MSXML2.DOMDocument60）
他にも、名前空間（xmlns） に引っ掛かりました。ええ、まったくの初心者です。
XML では情報がタグ付けされているため、欲しい箇所へのアクセスが容易です。そのため、最終的には思ったよりもすっきりしたコードになりました。拡張もアクセスも楽、コードも簡素、なかなか良い仕様・特徴だと思います。XML が広まった理由、少し理解できました。
結果的には理解するのに２晩かかったのですが、良い経験になったと思います。
2017年6月25日日曜日
R apply の問題
Rでは、for 文の代わりに apply 群を使われる方が多いようです。
確かに、apply 群を使って書く方が、簡素で読み易いと思います。また、for 文より速くなる場合があるようで、web上ではしきりにお勧めされていました。（apply の中で for が使用されていましたので、劇的に、ということはないと思いますが）。
念のため、apply や lapply を使用して書き直し。
もともと、dependency を算出する関数が、ベクトルを扱えなかったこと、並列化をもくろんでいたことからfor を使っていました。今回は、関数の引数にリストから値を代入する関数を作り、それを apply や lapply で呼んでみました。
で、計算!
が、ダメ。
夜中に計算をかけて、朝に「終わったかな？」と確認しようとすると、動きが異常に遅い。SSDにスワップファイルを作っているようです。リソースモニターを見ると、物理メモリ24GBを使い切っていました。for や foreachであれば、ループのたびに変数を入れ替えながら計算が進むため、それほど大きなメモリは必要としません。が、apply 群では大きなマトリックスをそのまま保持して計算が進んでいくため、いくつかの計算ステップが進めば簡単にメモリ不足に陥るのでしょう。
計算が進むたびに途中経過をディスクに書き出せばメモリを解放できますが、遅くなります。ま、扱うデータの容量を考えながら、方法を選択しないといけないのでしょうね。ビッグデータを扱う場合のパッケージもあるようですので、必要になった段階で検討してみましょう。
いずれにしても、今回は並列化のほうが速いという結果になりました。
コア数 計算時間 メモリ
for（Single） 11.5h 300MB
foreach（4） 3.7h 1.5GB
foreach（6） 3.8h 1.8GB
apply（Single）6hで中止 20GB以上
これで進めてみましょう。
確かに、apply 群を使って書く方が、簡素で読み易いと思います。また、for 文より速くなる場合があるようで、web上ではしきりにお勧めされていました。（apply の中で for が使用されていましたので、劇的に、ということはないと思いますが）。
念のため、apply や lapply を使用して書き直し。
もともと、dependency を算出する関数が、ベクトルを扱えなかったこと、並列化をもくろんでいたことからfor を使っていました。今回は、関数の引数にリストから値を代入する関数を作り、それを apply や lapply で呼んでみました。
で、計算!
が、ダメ。
夜中に計算をかけて、朝に「終わったかな？」と確認しようとすると、動きが異常に遅い。SSDにスワップファイルを作っているようです。リソースモニターを見ると、物理メモリ24GBを使い切っていました。for や foreachであれば、ループのたびに変数を入れ替えながら計算が進むため、それほど大きなメモリは必要としません。が、apply 群では大きなマトリックスをそのまま保持して計算が進んでいくため、いくつかの計算ステップが進めば簡単にメモリ不足に陥るのでしょう。
計算が進むたびに途中経過をディスクに書き出せばメモリを解放できますが、遅くなります。ま、扱うデータの容量を考えながら、方法を選択しないといけないのでしょうね。ビッグデータを扱う場合のパッケージもあるようですので、必要になった段階で検討してみましょう。
いずれにしても、今回は並列化のほうが速いという結果になりました。
コア数 計算時間 メモリ
for（Single） 11.5h 300MB
foreach（4） 3.7h 1.5GB
foreach（6） 3.8h 1.8GB
apply（Single）6hで中止 20GB以上
これで進めてみましょう。
2017年6月23日金曜日
R foreach で並列化
R で並列化・高速化を扱う場合、以下の2通りがあるようです。
1. 関数をC/C++ に移植。さらにCUDAを利用
2. foreach による並列化
頻繁に使うツールであれば前者でしょうが、今回はそこまでの頻度・意欲がありません。で、2を選択。
最初はビルド時の自動並列化のようなオプションがあるのか？と思い探してみましたが、見当たりません。代わりに見つけたのが 2 の foreach 。
R では、for を foreach に変更するだけで並列化してくれるようです。容易なためか、メジャーな手法のようですね。
先日のコードに対し foreach を使って並列化。
が、今度は排他制御に関するコマンドが見つかりません。複数のスレッドから同一変数への書き込みを避け、ファイルに追記するよう変更したのですが、タイミングが重なった場合にデータが飛んでしまいます。このあたりを制御するコマンドが見当たりません。また、foreach 内の break も効かないようです。
そのままではうまく動いてくれなかったので、部分的にコードを書き直し。
っで、計算！
今度はうまくいきまた。
1 コアで 11.5 時間だったのが、4 コアで 3.7 時間まで短縮できました。
6 コアでも計算してみましたが、頭打ち。メモリへのアクセスが集中しますので、遅くなったのでしょうか。
ま、それほど早い計算時間でもないのですが、このあたりが落としどころでしょうね。これ以上は 1 の方法、R から C へ移植しするしかないでしょう（実務なら、迷わずそちらを選びますが）。
扱いたいデータがもっと大きなサイズですので、3.7時間という結果は大きな制約です。データの前処理を考えないとだめでしょうね。なんだかベクトル化の方が早いかも？と思えてきました。
で、もう一度チャレンジ。
今度はクリアーできましたが、新たに問題発生。
続きは後日。
1. 関数をC/C++ に移植。さらにCUDAを利用
2. foreach による並列化
頻繁に使うツールであれば前者でしょうが、今回はそこまでの頻度・意欲がありません。で、2を選択。
最初はビルド時の自動並列化のようなオプションがあるのか？と思い探してみましたが、見当たりません。代わりに見つけたのが 2 の foreach 。
R では、for を foreach に変更するだけで並列化してくれるようです。容易なためか、メジャーな手法のようですね。
先日のコードに対し foreach を使って並列化。
が、今度は排他制御に関するコマンドが見つかりません。複数のスレッドから同一変数への書き込みを避け、ファイルに追記するよう変更したのですが、タイミングが重なった場合にデータが飛んでしまいます。このあたりを制御するコマンドが見当たりません。また、foreach 内の break も効かないようです。
そのままではうまく動いてくれなかったので、部分的にコードを書き直し。
っで、計算！
今度はうまくいきまた。
1 コアで 11.5 時間だったのが、4 コアで 3.7 時間まで短縮できました。
6 コアでも計算してみましたが、頭打ち。メモリへのアクセスが集中しますので、遅くなったのでしょうか。
ま、それほど早い計算時間でもないのですが、このあたりが落としどころでしょうね。これ以上は 1 の方法、R から C へ移植しするしかないでしょう（実務なら、迷わずそちらを選びますが）。
扱いたいデータがもっと大きなサイズですので、3.7時間という結果は大きな制約です。データの前処理を考えないとだめでしょうね。なんだかベクトル化の方が早いかも？と思えてきました。
で、もう一度チャレンジ。
今度はクリアーできましたが、新たに問題発生。
続きは後日。
2017年6月21日水曜日
R の for 文
以下の文献に掲載されているアルゴリズムの実装に取り組んでいました。
榊原ほか「 ラフ集合を用いたデータマイニングによるがけ崩れ発生要因の抽出に関する研究」 土木学会論文集 No. 658/VI-48, p. 221-229, 2000. 9
フローは単純ですので、単コアでの実装は容易です。dependency（「整合度」と訳されている）の計算部分も、R のパッケージに関数として組まれていますので、特に悩む必要はありません。一晩で（といってもかなり遅くまでかかりましたが）実装は終わりました。
**************************************
20170623追記
dependency を算出する関数の引数にリストから値を代入する関数を作り、それを apply lapply で呼んでやることはできました。が、新たな問題も発生。こちらに関しては後日。
榊原ほか「 ラフ集合を用いたデータマイニングによるがけ崩れ発生要因の抽出に関する研究」 土木学会論文集 No. 658/VI-48, p. 221-229, 2000. 9
(1) 整合度の要求水準を設定する.
(2) 要因数が1っの場合の整合度を求め, 要求水準と比較する. 少なくとも1つの要因において整合度が要求水準上回った場合, 最小必要要因数は1となる.
(3) すべての要因について, 整合度が要求水準を下回っていた場合, 2つの要因の組み合わせに関する整合度を求め, 要求水準と比較する.
(4) 以下順次要因数を増加させ, 整合度が要求水準を初めて上回った時点における要因数を最小必要要因数とする.
要は、順次総当たりでラフ集合の下近似を計算し、dependency を求め、閾値を上回れば終了といった内容です。
いくつかの会社や大学が特許を取られているようですので、実務で使わないほうがよさそうです。https://www7.j-platpat.inpit.go.jp/tkk/tokujitsu/tkkt/TKKT_GM301_Detailed.action
ま、研究では近年の深層崩壊でも使われていますので、研究やデータマイニングツールとして使えそうです。
いくつかの会社や大学が特許を取られているようですので、実務で使わないほうがよさそうです。https://www7.j-platpat.inpit.go.jp/tkk/tokujitsu/tkkt/TKKT_GM301_Detailed.action
ま、研究では近年の深層崩壊でも使われていますので、研究やデータマイニングツールとして使えそうです。
フローは単純ですので、単コアでの実装は容易です。dependency（「整合度」と訳されている）の計算部分も、R のパッケージに関数として組まれていますので、特に悩む必要はありません。一晩で（といってもかなり遅くまでかかりましたが）実装は終わりました。
で、計算！
遅い！
for で 118万回ループさせた dependency の計算でしたが、完走するまで11.5時間かかりました。
R の for 文 は遅くなることで有名なようでしたが、本当に遅かった。
dependency を算出する関数がベクトルを受け付けてくれませんので、仕方ありません。ま、for ループを使っておけば、次の並列化が楽になるだろうという目論見もあったわけですが。
やはり並列化・高速化が必要でしょう。
続く。
**************************************
20170623追記
dependency を算出する関数の引数にリストから値を代入する関数を作り、それを apply lapply で呼んでやることはできました。が、新たな問題も発生。こちらに関しては後日。
登録:
投稿 (Atom)