kml 書き出しの制限（Civil3D2015）

昨日、Civil3D 2015 のモデルをストリートビューで確認したいと思い、 kml 書き出し機能を使用してみました。

残念ながら、表示されません。
Google Earth の制限か？と思い、ArcGIS でも読み込んでみましたが、ダメ。書き出された ｋｍｚ ファイルが一般的な仕様、Ver. になっていないのでしょう。

ひょっとすると、と思い、 ファイル名から日本語を消してみましたが、ダメ。
次いで 書き出し中の「名前」から日本語を消して数字のみにすると・・・OK。表示できました。2byte文字がダメなのか、半角カナがダメなのか。ソフトは日本語化されていても、たまに見かける制限です。

肝心の表示結果は、イマイチ。期待が高すぎたようです。
地下は見えないですね。何とかならないでしょうか？

水質の分類

stiff-diagram（hexa-diagram） で水質を分類する際、何か定量的な指標はないか？と探していたところ、後輩から以下の文献を紹介されました。

永井茂「目でみる水質表示法」

出典は不明です。引用文献からは、1970年前後の古い資料だと推定されます。残念ながら定量的な指標は載っていませんでした。

以下は比較的新しい文献です。こちらにも key-diagram による定量区分と、stiff の定性区分が載っています。

中島ほか（2012）佐賀県の地下水の水質による分類, 佐賀大学農学部彙報, Vol.97 p.27 -35
http://portal.dl.saga-u.ac.jp/handle/123456789/119478

stiff の良いところは、見た目で区分しやすい点、マッピングしやすい点でしょう。中間的な水質では判別を迷うこともありますが、説明資料として利用しやすいグラフだと考えます。イオンバランスをチェックされていない方が作られた図では、一目で再採水の必要なデータも抽出できます。
昔はAquaChem を利用して描画していましたが、どなたかがキーを紛失して以降、Grapher を利用していました。http://www.goldensoftware.com/products/grapher
EXCELの散布図でも代用できます。上記文献では、公開されたEXCELデータを利用されています。

誰でも手軽に図化でき、直感的に判別しやすいstiff。定量区分の piper を併用しておけば、特に問題にはならないでしょう。

座標の維持（V-nas Clair 2015, Civil3D 2015）

V-nas のデータを AutoCAD に持ち込む際（あるいは、その逆も）、設定していた座標が外れてしまい、再度、CADに応じた設定を行うことが頻繁にありました。

同じデータを扱っていても、設計者が選ぶCADによって作業が増えるというのは無駄ですね。

今日、V-nas のサポートの方と話をしていて、座標を欠落させない（座標を気にしなくて良い）受け渡し方法があることを知りました（感謝）。  以下、V-nas Cｌａｉｒ 2015 ＋ Land_Kit （3D地形オプション）を使用した、その手順の備忘録です。

=====================================================

①V-nas Clair 2015 から、座標を保持したままdwg（AutoCAD）へ書き出す手順
1. 3D地形オプション → エクスポート → 地図エクスポート
2. 保存
3. 単位「m」
※「XY表示」での作業です。
※座標系はCivil3Dで設定する必要があります。

②Civil3D 2015 のデータ（TINサーフェス等）を、座標を保持したまま V-nas Clair 2015で読み込み
Civil3D 2015 での作業
1. 受け渡しに必要なデータ以外削除（or 後で非表示にできるようレイヤ区分）
2. TINサーフェスは「サーフェススタイル編集」で三角形のみ表示
3. ファイル → 書き出し → AutoCADに書き出し → 2010形式
V-nas Clair での作業
4. 3D地形オプション → インポート → 地図インポート
5. 読み込む dwg ファイルを選択
6. （V-nas 側で座標系設定済みであれば）「現在のものをそのまま使用」
   スケール 1/1 → 1/1000
   AutoCAD ファイルの単位「m」 でOK
※「XY表示」での作業です。
※インポート先のレイヤが「非編集」だと、それと同名のレイヤにあるオブジェクトは読み込まれません。

=====================================================

これでCivil3D＋GEORAMA で作成した地層面を、座標変換なしでそのまま V-nas に取り込むことが可能となりました。 また、設計者が V-nas で作成したモデルを、Civil3D に「同一位置に貼り付け」で取り込むことも可能となりました。2つの CAD 間で座標を気にしなくてよくなった、シームレスになったというのは大きいですね。

上記方法で地形と地層面1枚、構造物やコンターラインを V-nas Clair に同時に取り込み、いろいろな角度から眺めてみました。地表面を透過させ、地下と構造物を重ねて表示させていたのですが、Civil3D の 「リアリスティック」と似たような表現になりました。動きが比較的軽いのと、面の色が個々に反映できる点で、表示させるオブジェクトによっては V-nas 優勢かもしれません。
数年先、ソフトウェアに依存しない（かつ地質屋の意図を反映させることの可能な）地層面推定手法のルール作りが進めば、Civil3Dから脱却できるかもしれません。時間はかかると思われますが、技術的にはさほど困難ではないでしょう。楽しみです。

V-nas Clair 2016 では地形の LandXML を扱えるようになるそうですので、上記よりも手順を省く音ができるかもしれません。来週発売予定ですので、また、確認しましょう。

3D モデルの引継ぎ

国交省山形河川国道さんが、東北中央自動車道の橋梁計画の3Dモデルを掲載されています。
http://genba-story.com/yamagata4/drawing.html

見た瞬間吐き気を。
いえ、プロからすればたいした内容ではないのでしょうが、私は絶対手を出したくないですね。

地形は UAV + Recap360 だそうです。動画は Infraworks ですね。橋梁は Civil3D でしょうか？
動画を見ていると、ゲームを思い出しました。ゲームグラフィックデザイナーなら、FPV で操作までできそうですが（ゲーム制作は、お金がかかるのでしょうね）。


帰社すると、設計者から下部工の3Dモデルが届いていました。
それを地層境界面に載せて可視化。簡単に疑問点が見つかりました。私はこの程度で十分ですね。
下部工モデルの修正は大変ですが、地層境界面の修正も場合によっては大ごとになります。複数の地質・岩級をつなげて支持層としているような面の修正は容易でありません。また、ボーリングを一本追加すると、そこを中心に広い範囲で（思いもよらない個所まで）変更が生じます。自社のデータであれば1日で修正できますが、他社さんのデータは取り扱いに困るでしょうね。ソフトや面の発生アルゴリズムによって、全く異なる曲面ができてしまうため、特に設計が進んだ段階ほど修正に気を使う必要が出てきそうです。

CIM においてデータの引き継ぎを考えた場合、地層面の取り扱いは構造物とは異種の問題を含んでいるようです。

ボーリング柱状図作成及びボーリングコア取扱・保管要領

全地連さんのHPをのぞいてみると、 以下の要領が公開になっていることに気づきました。

「ボーリング柱状図作成及びボーリングコア取扱・保管要領（案）・同解説」平成27年6月
http://www.zenchiren.or.jp/koukai/kousiki_0928.html

半年以上前ですね。全く気づきませんでした。幸い、｢地質・土質調査成果電子納品要領（案）｣がまだ改訂されていませんので、大部分は適用になっていないようです（改訂の予定があるのでしょうか？）。ソフトの更新案内も着ていませんね。

内容を確認してみましたが、柱状図作成に大きな変更点はありませんでした。

増えたのはコアの取り扱い・保管に関する内容です。といっても、通常実施している作業が整理されているだけですので特に目新しいものはありません。コア箱に排水孔を設ける、コアを洗うといった一連の作業が追記されているまでです。

洗う道具として、刷毛や筆が紹介されています。これ、結構悩ましい問題です。
指や軟らかい毛を使えば、コアの乱れを抑えることができます。が、かなり時間がかかります。一方、ブラシなどの硬いものを使用すると、短時間で綺麗になるのですが、割れ目でコアが動いたり粘土が流れたりするなど、非常に乱れやすくなります。地質によって道具を変えてみるのですが、なかなかコレといった決定打はありません。
最近使ってよかったのは、洗車スポンジ。火山性軟岩を洗う際、最初にマッドケーキをあらかた落としてから、洗車スポンジを使用しました。ちょうど良い組み合わせだったようで、綺麗に落ちました。水を多く含むので噴霧器も不要です（噴霧器の水圧が強いとコアを乱してしまいます）。

 このあたりのノウハウが要領に記載されるようになった背景には、観察側の意識の変化は勿論、ボトムなどツールの変化や、オペさんの試行錯誤・尽力などの背景があるように感じます。近年、無水のコアはほとんど見ませんし、打ち込みですら「縮む」という理由で使わないオペさんもいらっしゃいます。お互い、良いものを求めていく姿勢の一端が、この様な形として表われてきたのではないかと感じます。

地質に詳しくないお客様にはほとんど気付かれない、仕事に対する姿勢の話になるのかもしれません。ただ、技術者と名乗り続ける以上は、このような姿勢を持ち続けたいものです。

初期値圧測定

トンネル設計に関与している先輩から質問を受けました。

「水圧破砕法って知ってる？」

ええ、存じております。久しぶりに聞きましたが。
どうも初期値圧測定を提案しようとした方から、その計画立案をお願いされたようでした。

以前、初期地圧の整理をした際、各深度・位置での方向がバラバラで解釈に苦労した記憶があります。それが水圧破砕法の結果でした。水圧破砕法の精度が相対的に悪いということは、当時、既に知られておりましたので、それもバラツキの1因かと考えていたのですが、断定はできませんでした。

オーバーコアリングを追加で実施することになった際も、プレボーリングでコアを確認し、試験位置を決め、ワクワクしながら結果を待った記憶があります（その結果は忘れましたが、かなり高めの側圧係数になっていたような気がします）。
 
初期値圧に対し、個人的には以下の印象を持っています。
・岩盤中の応力を計ることは可能だが、それをサイト特性として解釈することは難しい。
・場所や深度によってばらつきがある。1点ではダメ。
・それでも、データは有用。変形解析を実施する特殊時山などでは、測定しておくべき。
・初期値圧でゾーニングできる可能性がある。亀裂構造図と重ねて評価すべき。
 
再度チャレンジしたいとは思っていますが、それ以降チャンスに恵まれません。今回も鉛直ボーリングの水圧破砕法では、欲しい方向の応力が得られない、ということで計画をやめられたようです。
初期値圧のゾーニング、いつかリベンジしたいですね。

V-nasClair STR_Kit

橋梁設計者から相談がありました。

「3次元で下部工と支持層の関係を表示できないか？1週間後に協議に行くので持っていきたいのだが？」

ええ、地質は3次元で作っていますので、「下部工の3Dデータがあれば可能」です。

昨年度、橋梁や堰堤などの設計図面から3D化という作業を実施しました。が、結構時間がかかります（地質の可視化のついでに頼まれたイレギュラーな仕事で、本職ではありません）。ましてや、今回は十数箇所。私の能力でこの工程は無理ですね。いえ、そもそも構造物の可視化は私の専門ではありません。

適当な形状で良いなら、V-nas Clair2015 + STR_Kit が良いと思います。別の橋梁設計者に聞くと、「まだまだ設計では使えないレベル」「表示に難あり」だそうですが、私のような門外漢にとって、短時間で似たような形状を作成・配置できることの方が重要です。躊躇なく選択・使用しますね。
https://www.kts.co.jp/seijyou/v_3dsub/index.html

Clair で下部工を作るには、まず線形を作成します。それに幅員や縦断形状を設定します。ココまではCivil3Dも似たようなものでしょうか。
で、ここから STR_Kit の威力発揮。形状を選択し、構造物の詳細な数値を入力、線形のどこに配置するかを決めて「更新」です。これで下部工の3Dモデルが完成です。設計結果を完全に反映されないため設計者には申し訳ないのですが、非常にお手軽でありがたいツールです。

線形はレベルで適当に作成し、3D下部工を作成。それをdwgで保存。Clair での出来上がりイメージは、このような感じです（デフォルトに近い橋台・橋脚を配置しています）。

これをCivil3Dで読み込んで計画位置に配置します。橋脚・橋台毎にブロック化されて取り込まれるので、配置も比較的容易です。下部工と支持層サーフェスを表示し、根入れの関係を可視化すれば完成。、ここまでで作り始めてから1時間弱でしょうか？現状は面データですが、Clair 2016ではソリッドになるそうですのです。


3次元可視化の良い点は、とにかく「分かりやすい」ことだと思います。
最近衝撃を受けたのが、ストリートビュー を使ったプレゼンです。3D 下部工を kmz で保存し、Google Earth で重ねて、ストリートビューで見せるといったモノ。kmz で計画を配置するところまではよく見ますし魅力を感じなかったのですが、ストリートビューでも表示されるのは知りませんでした。分かりやすいプレゼンでした。地元説明には良いでしょうね。

ただ、3次元化が「見せるだけ」では切ないですね（ヒトやベンダーによればこれも CIM だそうですが）。

設計に耐えうる形状を容易に検討・反映でき、数量を拾うことの可能なレベルまでソフトをブラッシュアップするには、まだ時間がかかりそうです。こちらを先行した結果、可視化といった付加価値が生まれました、と言うのがCIMの本質でしょう。
まだまだ変化は続きそうです。ついて行かなくてはなりません。

===========================

20150126追記

SRT ではなく、STRですね。structure でしょうか。

LS-RAPID のノウハウ

昨年末から、LS-RAPID で複数現場、10ケース程度の計算を行いました。サポートにお話を伺いつつ、ようやく全体像やノウハウ、ソフトのクセなどがわかってきました。

すべり面のモデル化に関しては、簡易なものはSSA_3Dだけで十分です。多数のすべり面があったり、複雑な形状のモデル化はGEORAMA ＋ Civil3D ＋ SSA_3D が良いと思います。それを LS-RAPID に読み込んで、定数を設定します。

定数については、基本、再現計算でのパラスタです。
が、不具合を抑えるために追加されたパラメーターがクセモノ。流速が大きくならないよう、すべり土塊の厚さによって抵抗を発動させるパラメーターがあるのですが、最初から大きい値のままだと全く流下しません。流速によって発動させる同様のパラメーターがあるのですが、上記パラメーターを使わず、こちらを利用した方がよさそうです。いえ、本来の計算ではこのようなパラメーターを利用しなくても、それなりの流速にならないといけないのですが。意図せず体積が増え続ける、またそれを抑えるパラメーターがあるというのも理解が難しい点です。全体として支配方程式やプログラミングのブラッシュアップが必要だということでしょう。

exeは32bitですので、計算時にはメモリの制限があります。等高線を表示したまま計算しない、モデルは可能な限り小さく、グリッドは許容できる限り大き目で、といった点に留意する必要があるようです。制限に引っかかると、計算途中で落ちます。

長所もあります。
豪雨シミュは試す価値ありですね。雨によって部分的に崩壊・流下し始めます。（正解かどうかの判定は難しいと思われますが）これは良い機能だと思います。LS-RAPIDの個性でしょう。

ソフトにはそれぞれ特徴、クセがあります。それらを見極めることができれば、一つのソフトにこだわることなく問題に適したものを選定することが可能となり、しかも短時間で解決できるようになります。

地元の反対

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

先日、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

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

PSXE 2016 update1 CE for Fortran

この休みに、土砂移動の fortran ソースを見直そうかと考えていました。

長時間のリモートも面倒なので、Vaio （Windows10）に Parallel Studio XE 2016 update1 CE for Fortran  入れました。が、以前入れていた VS2013 Express Edition に統合できません。
修復・再インストールでもダメ。そういえば、以前も試したことがありましたね。そのときも Express では統合できなかったことを思い出しました。

2015 Community update1 が出ていますので、ついでに VS2013EE も UP しようと考えました。で、両者を uninstall。

とりあえず PSXE2016 だけで 2013 shell がインストールされるのかを試したく、そちらを先に install。
出た警告は以下の通り。

 サポートされている環境が見つからないため、インテル(R) Visual Fortran コンパイラーは動作しません。

              インテル(R) Visual Fortran コンパイラーを利用するには、Microsoft* Visual Studio* / Microsoft* Visual Studio* Express Edition 2010 (IA-32 のみ)、2012、2013、または 2015、あるいは Microsoft* Windows* SDK for Windows* 8.0 または 8.1 がインストールされている必要がありますが、どれも見つかりません。

         Microsoft* Visual Studio* 2013 Shell ベースの Fortran 統合開発環境 (IDE) を利用できますが、先に Microsoft* Windows* SDK for Windows* 8.1 をインストールする必要があります。

              詳細は、「VS2013 Shell に必要な Windows* SDK のインストール」(https://software.intel.com/en-us/vs2013shell-windowssdk (英語)) を参照してください。SDK をインストール後、インテル(R) Parallel Studio XE のインストールを再度実行します。

あれ？2013 Expressで統合できたの？と思いながら、中止。周りにプロがいませんので理由は追求せず。ま、2015 Community を入れて、ダメなら SDK を入れれば良いのでしょう（完全に手探りです）。
で、VS2015を入れた後に PSXE2016 を入れようとすると、以下の警告。

 Microsoft* Visual Studio* 2015 に C++ の「X64 コンパイラおよびツール」コンポーネントがインストールされていません。

         インストールは続行できますが、インテル(R) Visual Fortran コンパイラー (インテル(R) 64) は Microsoft* Visual Studio* 2015 を使用してビルドしません。

         64 ビットのアプリケーションを開発するための Microsoft* Visual Studio* の設定については、リリースノートを参照してください。

 Microsoft* Visual Studio* 2015 に Visual C++* 2015 共通ツールがインストールされていません。

         インストールは続行できますが、インテル(R) Visual Fortran コンパイラー は Microsoft* Visual Studio* 2015 を使用してビルドしません。

         Visual C++* 開発向けの Microsoft* Visual Studio* 2015 の設定については、オンラインの記事 (https://software.intel.com/en-us/articles/intel-c-fortran-compilers-for-windows-integration-into-microsoft-visual-studio-2015 (英語)) を参照してください。

リンク先には以下の指示。

To install the 'Common Tools for Visual C++ 2015' component:

1.    If  Microsoft Visual Studio 2015* is not installed on the system:
   1. During installation select the “Custom” type
   2. Under Optional features to install:
                Expand Programming Languages/Visual C++ and select Common Tools for Visual C++ 2015
      
   3. Continue with the installation.
      
2. If Microsoft Visual Studio 2015* is already installed on the system:
   1. Open the Control Panel and select 'Program and Features'.
   2. Select “Microsoft Visual Studio* 2015”, right-click to open the context menu and select “Change”
   3. Select “Modify” on the next screen
   4. Under Optional features to install:
                Expand Programming Languages/Visual C++ and select Common Tools for Visual C++ 2015
   5.  Continue with the installation.
3. Restart your system.

つまり、VS2013EE の時もデフォルトで共通ツールが入っていなかったため、統合できなかったという訳でしょう（そう思いたい）。

指示通りに共通ツール（一緒にSDKもチェックが入りました）を選択し、インストール。
その後、PSXE2016をインストール。

結果、無事に統合できました（傍にプロが欲しいですね）。


で、ようやくソースの見直しを始めようと思ったのですが、肝心のソースを持ち帰るのを忘れていました。orz