地元の反対

新規事業に対し、地元の方々より反対意見の出ることは多々あります。

先日、Google アラートに、トンネル計画に対する異質の反対意見が引っかかりました。

産経ニュースより
http://www.sankei.com/smp/west/news/160114/wst1601140003-s.html

「神々の怒りを招きかねない」「都市の繁栄を脅かす」－。広島市の中心部で予定されている高速道路のトンネル工事について、一部住民からこんな理由で反対の声があがっている。この場所が広島の「鬼門」に当たり、工事は「風水」的によくないというのだ。ＪＲ広島駅周辺の混雑緩和が期待される道路計画だが、地盤沈下を懸念する住民の反対運動が起きたことで工期は大きく遅れている。そんな中、持ち上がった風水による反対はどんな影響を及ぼすのか。

弱りましたね。どうするのでしょう。
技術論なら技術者でも説明できますが、風水となると専門外。宮司？祈祷師？風水師？安倍清明みたいな方に依頼して調査・対策を提示するのでしょうか？あるいは西洋占星術やタロットカードなど、西洋起源の鑑定で対抗するのでしょうか？ピンときませんね。

立場によって、技術は知っているが風水を知らない、あるいは風水を知っているが技術を知らないというところの問題もあるのでしょう。
無知は罪なり、知は空虚なり、英知持つもの英雄なり、です。どのような英雄？が、どのように話を収めるのか、楽しみですね。

Civil3D 2015 縦断ビューの不具合

Civil3D 2015 で縦断ビューの地形にズレの生じる現象が発生しました。

測点位置で確認すると、地形に2m程度のずれが生じます。
これについて先々週よりサポートとやり取りしていたのですが、結局、原因は特定できず。可能性の一つとして、「オブジェクトから線形を作成」の手順に問題があるということのようです。

測量屋さんや道路屋さんから平面線形の入った図面を頂いた場合、中心線が測点毎で切られたポリライン等で描かれている場合が多々あります。これを利用して「オブジェクトから線形を作成」すると、ズレの発生する可能性があるとのこと。不要な変化点が作成されてしまうためだそうです。
不要な変化点が作成されていても縦断ビューでズレの発生する仕様にはなっていないそうですが、今回はそれが原因でズレの発生した可能性があるとの見解でした。

もともと、20mピッチ等の要素を拾って「オブジェクトから線形を作成」機能を使うのは想定外 = レアケース といったロジック？で、原因調査は実施しない、という結論だそうです。Autodesk さんらしいですね（やはり、以前の Infraworks のサポート担当さんが優秀だったのでしょう）。
当面の対策としては、想定内のつくり方（この場合は直線上や円弧上の頂点を削除してから「「オブジェクトから線形を作成」）で作ってほしいとのこと。大丈夫でしょうか、Autodesk さん。

個人的な感想ですが、日本の土木設計に関わる箇所の信頼性やサポートの質は、やはり日本製に分があるように感じます。ターゲットが世界か日本かの違いでしょうね。機能はまだ Civil3D 優勢と感じていますが、そのうち追いつくかもしれません。期待しましょう。

うーん。今まで中心線形 xml を頂けない場合は、この作り方を多用していましたので困りました。過去の図面、チェックしなくてはなりません。
これからどうしましょうか。

Hyper KANAKO と Civl3D

年末のテコ入れで、それなりに動く様になった Hyper KANAKO。

後輩が頑張って計算をかけているのですが、まだ不具合が出ている様です。

計算・書き出し・ファイル容量を軽くするため、一次元領域を 50 mピッチに変更していたのですが、それでは結果の断面表示に問題の生じることがわかりました。ま、計算値はテキストで書き出されていますから、なんとかなるでしょう。

天然ダムの縦断方向の延長は入力できませんので、一次元のピッチに合わせて複数の入力になります。案外、その方が利点もありました。天然ダムの横断幅と高さを個々に反映できるのです。

KANAKO での天然ダム位置入力は GIS 上でのマウス指定ですので、複数の横断箇所を一定ピッチで入力するのは困難です。Civil3D で縦横断を切り、帯の値などを EXCEL に手入力したほうが容易です。

幸い、KANAKO では流路が SHP ファイルになっていますので、それを Civil3D で読めば、線形に指定できます。（と思ったのですが、あまり綺麗な形状で読めなかったので、ArcGIS 経由で Polyline 化し、読みました。）

崩壊前地形、崩壊後地形、線形を利用し、Civil3D で縦横断を作成。それを後輩に返し、KANAKO に反映させ、計算！

うまくいったようです。

KANAKO の次 Ver. 公開が、今月上旬というアナウンスでした。制限や不具合が取れていることに期待しましょう。

現場透水試験と孔径

お客様より「現場透水試験はφ86mmだろう」と言われた設計者。あわてて上司に聞きに来られました。

これ、私もわかりません。
いえ、国交省系はφ86mm以上の積算が標準となっています。が、なぜφ66でないのかが不明なのです。（以下の資料に各種調査に必要な孔径が記載されています）

国交省設計業務等標準積算基準書平成23年度版<標準積算基準書>
＜参考資料＞第３編　地質調査業務
http://www.mlit.go.jp/tec/gyoumu_sekisan.html

ただ、上記資料の根拠は古いと思われ、現状とは合致していないものがあります。例えば、LLTは20年ほど前にφ66タイプのゾンデが発売・利用されています。が、積算基準はφ86mmのままです。トリプルサンプリングのφ116mmも、現在はφ86mmが主流です。これは以前、書き残しています。
http://phreeqc.blogspot.jp/2013/09/blog-post_3.html

ただ、現場透水試験は私が入社した頃からφ66mmが主流でした。φ86mmである理由を探しても見当たらないのです（ 上司も御存知ないようでした）。ケーシング法のケース挿入をカウントしているのかと考えましたが、通常、ケースは3インチですのでφ86mmでは過大請求になります。それに、ケースの設置費用はφ66mm掘削に含まれていると理解しています（国交省さんの基準には明示されていませんが、農林さんの基準や全地連の赤本には「含まれる」旨が記載されています。いや、これが勘違いでしょうか？）。

技術的には、φ66mmでも問題ないと考えています。
お客様には「φ66mmでも大丈夫ですよ。」と伝える一方、理由が分からすモヤモヤしています。

CIMモデル作成ガイドライン

昨年、土木の各専門分野では、CIM モデル作成ガイドラインの整備に着手されたようです。

幾つかの専門分野が公表、それを更新すべく、議論が進められています。

また、ソフトウェアベンダーも自社ソフトを使用したセミナーや、トレーニングテキスト作成などを実施されてさいるようです。が、その多くは、そのソフトでどのようにして3次元モデルを作るか？程度の内容にとどまっているのが現状です。2年前と何も変わってません。売り込みのチャンスですから、CIM =「 とりあえず3次元化」といった流れを見せ、ユーザーを取り込むのも一つの戦略なのでしょう。
http://phreeqc.blogspot.se/2014/06/3.html
ただ、ココまででしたら CG や三次元解析に携わってこられた方なら（ソフトを問わず）実施されてきた内容です。CIM ではその先の話が本質でしょうし、今後、ベンダーがセミナー等でガイドすべき内容だと考えます。ユーザーも「三次元化だけではダメだ」と、そのうち気付きくことでしょうし。

休暇前に、CIM トンネルモデル作成ガイドライン Ver.1.0 に沿ったトレーニングテキストを入手していました。数量計算や掘進時の計測結果の表示方法等があればと期待しましたが、残念ながら皆無でした。どのようにして3次元のオブジェクトを作成していくかに留まっていました。遅れています。
昨年12月中にはVer.2.0になる予定でしたが、こちらもまだ公表されていないようです。

CIM と銘打つからには、その先が必要です。数量集計、施工管理や計測・維持管理の効率化・高度化などが期待されるところです（それがなければただの3次元化です）。
平成28年度では、これらの状況を打破すべき内容のガイドラインが出てくることを期待しましょう。

崩壊・流下中のφの変化

土砂移動計算のソースを用意できたので、改変に取り組むことに。

発端は、LS-RAPIDで土砂移動を計算した際、尾根を越えるすべり面（岩盤滑り）では反対斜面へ流下するケースが出てきたことでした。
恐らく、計算開始と同時に尾根越え判定に引っかかってしまうため、内部せん断を計算したのでしょう。どうすれば良いかは明白で、内部摩擦に崩壊初期の岩盤の強度に近い値を入力してやればOK。

と思ったのですが、LS-RAPIDではダメでした。岩盤に近い強度を入れても反対斜面に流れてしまいます。カラム背後の土圧が効くのでしょうか？すべり面強度を上げて流さない様にするしか対策はない様です。イマイチ。
ま、仮に内部の摩擦係数を上げて反対斜面への流下を防いだとしても、本来流れる方向への流下も土砂としての物性が表現できませんので、ダメですね。

ということで、手元にあった他の土砂移動計算コードを改変。

以前に改変した体積変化に加え、内部の動摩擦係数も流下に伴い低下させるアルゴリズムを組み込む方針です。
コードの改変は容易で、前回の体積変化アルゴにφm及びtanφmの変更を含めるだけです。主要部分は1時間ほどで終了しました。半日ほどかけて出力を増やしたり、結果を可視化したりなど、チェックを終えて完了です。

早速、尾根越えすべりの計算！と思ったのですが、これも手元にモデルがありませんでした。仕方ないので尾根を越えない崩壊現場のモデルで計算。

結果は上々。
φの変化に応じ、徐々に崩壊・加速して最終的には一気に流れ出すような結果。岩盤が頑張って耐えている感じが見られます。以前のものは計算スタートでいきなり土砂となり、トップスピードへ向かうような結果でしたので、より現実に近づいたように感じます。


で、肝心の尾根越えすべりですが、モデルをひっぱり出して試してみました。
結果、イマイチ。やはり反対斜面にも若干流れます。改変前のコードと比べても流下範囲は大きく変わりません。パラスタが必要なのか、考え方が誤っているのかわかりません。残念ながらもう少し試行が必要でしょう。

ま、思わぬ効果が得られたので今回は良しとしておきましょう。

SSE と AVX

PSXE2016 for Fortran の変更点が乗っているかと思い、入門ガイドを眺めておりました。

変更点は載っておりませんでしたが、初心者の私にとってはちょうど良い内容の項目がいくつかありました。目を引いたのは自動ベクトル化の箇所。

SIMD 演算でどのような命令が使用されているかに触れられていたのですが、今まで深く考えたことはなかったですね。自分で自分用に（開発環境 = 実行環境として）コンパイルしていますので、自動ベクトル化で問題なかった訳です。
使用しているハイスペック PCの CPU は旧世代の Core i7 ですので、SSE4.2までです（表現が矛盾していますが）。稀に、他支店の後輩にコンパイルしたものを送付することがあるのですが、AVX2 まで対応している CPU を使用していたと思います。そうすると、こちらの開発環境における自動ベクトル化では十分な機能を発揮できません。計算がどの程度早くなるのか不明ですが。
（iSUS の HP に良い記事がありました↓）
http://www.isus.jp/article/compileroptimization/performance-tools-for-software-developers-intel-compiler-options/

ちなみに、手元にあったソースを試すと、以下の通り。このソースではベクトル化に効果が出ませんでした（計算が軽いので、入出力に時間を取られているのでしょう）。

Type	Time
normal	0:00:54
SSE4.2	0:00:52
AVX	0:00:53
AVX-OpenMP	0:00:58
AVX-OpenMP-O3	0:00:59

プロが傍にいませんので手探り状態です。が、入門ガイドに載っている程度の内容は、常識として身に付けておきたいものです。