AMD + nvfortran

Dockerが走らなくなっていたPCは再インストールから。

$sudo apt update
$sudo apt install -y nvidia-container-toolkit
$sudo systemctl restart docker

$sudo docker run --gpus all --ipc=host --ulimit memlock=-1 -it --rm -v /media/user/Data/:/workspace/data/ nvcr.io/nvidia/nvhpc:25.5-devel-cuda_multi-ubuntu24.04

$cd workspace/data/src_gpu
$make

makeファイルのオプション:
FLAGS = -O3 \
         -byteswapio \
         -tp=znver4 \
         -Mfma \
         -Mcache_align \
         -Mvect=simd \
         -acc=gpu,multicore \
         -gpu=cc89,mem:managed \
         -mp=allcores,bind \
         -Minfo=accel,mp,inline

-O3: 最適化レベル
-byteswapio: I/O操作でバイト順序を入れ替え
tp=znver4: AMD Zen4アーキテクチャを対象プロセッサとして指定
-Mfma: 融合乗算加算（FMA）命令を有効化
-Mcache_align: キャッシュ利用効率向上のためのデータアライメント
-Mvect=simd: SIMDベクトル化を有効化
-acc=gpu,multicore: GPUとマルチコア加速のためのOpenACCを有効化
-gpu=cc89: Capability 8.9（Hopperアーキテクチャ）を対象
mem:managed: CUDA管理メモリを使用
-mp: OpenMPの並列処理設定
allcores: 利用可能な全CPUコアを使用
bind: スレッドをCPUコアに固定
-Minfo: コンパイラ情報出力
accel: アクセラレータ（GPU）コード生成情報
mp: マルチプロセッシング/OpenMP最適化情報
inline: 関数インライン化情報

Nvidia HPC SDK on WSL2

WSL2 の Ubuntu 22.04 に Nvidia HPC SDKを入れる方法。
How to install Nvidia HPC SDK on Windows using Wsl (Ubuntu 22.04) | by Aung Khant Thaw | Medium

NVIDIA のサイトが示すインストール方法（sudo apt install）の後に、pathを2つ通す必要がありました。

.barshrc に以下を追記すればOK。

export PATH="$PATH:/opt/nvidia/hpc_sdk/Linux_x86_64/23.7/compilers/bin/"
export LD_LIBRARY_PATH="/usr/lib/wsl/lib/"

AMD + ifort

他支店で、AMD の32コアを積んだ PC を購入したとのこと。

まだ GPU に対応しておらず CPU 並列化のみのソフトは多いので、一つの選択肢かもしれません。が、OS が Windows10 のみ。以前コンパイルしたソフトを動かそうとしたが動かず困っているという連絡でした。

AMD Ryzen は手元に実機がありません。AMD + UBUNTU での並列化はよく聞くのですが、Winはナシ。手探りで始めることに。

エラー内容を見ると、どうやら Intel CPU用の命令が邪魔をしているようでしたので、まずそれを外すことに。そのままでは変更するオプションが多いので、コマンド打ちで０からオプションを追加する方針にしました。

何度か試行して、スタック領域を拡張し忘れていたことに気づき、追加。これで動きました。

今回、ifort ではコンパイルできたのですが、gfortran ではダメでした。何が違うのかわかりませんが、前者の速度と安定感は以前より感じています。

このあたり、いつかプロに御教授願いたいところです。

 

スペクトルの平滑化

連休中に、スペクトルの平滑化プログラムを書いておこうと思いつきました。

大崎本にサブルーチンが載っていますので、それを利用すれば完成するでしょうと高を括っていました。

が、本を持ち帰っていませんでした。

どうしましょうか、と検索してみると、大崎総合研究所から6月にソースコードが公開されていました。（正誤表もあります。）
http://www.ohsaki.co.jp/activity/download/index.html

昔の有名な図書ですので、プロは既にアレンジしたコードをお持ちです。が、私のようなアマにはありがたい。感謝です。

サブルーチンをダウンロードして、プログラムに組み込み、動かしてみました。が、正しく動きません。どこだ？と探しているうちに、連休が終わりました。

そういえば以前、倍精度に変更したサブルーチンをプロからいただいていました（今回も、連休中に頂きました）。それに組み替えると、改善。さらに、引数を変数に変えると正しく動きました。後者はともかく、前者はあるあるでしたね。感謝。

昨日、お礼がてら雑談していると、周波数によってバンド幅を変える方法もあると教えていただきました。バンド幅を決めて平滑化すると、高周波側と低周波側で見え方が変わってきます。それが改善されるのでしょう。良いですね。

といっても、それを使うのに妥当なスペクトルか判断できない知識レベルですので、今回は通常の平滑化で完成。バグ取りに数日かかりましたが、喰わせるデータや単位のチェックもあわせてできたので良しとしましょう。

世間のレベル

Python、なにそれ？とは異なる方との協働の話。

自己紹介もそこそこに協働することになった社外の方。メインの仕事とは外れる部分で、Python スクリプトをやり取りしたり、Fortran ソース、バッチファイル をいただいたり。
事前に確認したわけではありませんが、ある程度の言語スキル保有が前提でのお仕事でした。

先日のように社内の方をお世話するよりも、効率的かつストレスフリーでした。考えさせられます。

 

oneAPI

Intel Parallel Studio XE 2020 Composer Edition for Fortran のSSR更新に関する案内が届きました。

Parallel Studio が廃止され、後継の oneAPI に移行する案内は以前から届いていましたが、まだ前者を使い続けていました。で、更新のタイミングで入れ替えることに。
oneAPI へのライセンスの書き換えはボタンクリックのみ。無償アップグレードでした。

その後、SSR更新費用を確認すると、10万で約倍になっていました。VTune や Adviser が含まれた上位版の後継ですので妥当なのですが、毎年続くと思うと痛い。残念なことにアップする前だと今回に限り6万だったようです。うーん。ま、oneAPI 自体は無償なので、保守契約はやめましょうか。
https://software.intel.com/content/www/us/en/develop/articles/free-intel-software-developer-tools.html

この oneAPI の無償化ですが、大きな転機ですね。NVIDIA さんが Linux 向けに PGI の後継を無償で配布していますので、Intel さんも対抗されたのでしょうか。ユーザーにとってはありがたいことです。今後、Winのデファクトスタンダードになるでしょうね。

で、早速 Wiｎ 版をインストールしてみました。oneAPI 側の制限はなくなりましたが、Visual Studio 側の制限はそのまま。個人利用として継続します。
途中、C＋＋がはいっていませんと注意されます。C＋＋をいれて、Base、HPC の順でインストール。時間がかかります。更新がさらに面倒になりそうです。Linux 版だと apt や Docker で簡単に更新できそうですけど。

インストールが終わり、コンパイル。
exe を動かしてみると、今度は'dllがない'と叱られます。oneAPI からは インストールマシンでも path を通してくれないのでしょうか。うーん、面倒。
libiomp5md.dll cannot be found after upgrading to oneAPI for Windows
https://community.intel.com/t5/Intel-Fortran-Compiler/libiomp5md-dll-cannot-be-found-after-upgrading-to-oneAPI-for/td-p/1258331?profile.language=ja
...\OneAPI\compiler\latest\windows\redist\intel64_win\compiler

エラーが出るたびにdllを検索。都度、Path を追加すれば最終的に動きました。

この oneAPI ですが、OpenMP で Intel の GPU をサポートしているそうです。が、詳細な情報を拾えず。雑誌などで紹介されているかもしれませんので、ゆっくり調べてみましょう。

ま、ゴリゴリ使っているプロでもないので、当面はこの状態で良いかな。

 

passive 手法

passive 手法のテスト。

*** CC-FJpy ******************************
https://github.com/ColinLii/CC-FJpy
CC-FJpy: A Python Package for seismic ambient noise cross-correlation and the frequency-Bessel transform method
・複数の観測点間の相互相関関数をプロット。
・このコードに限りませんが、基本、長期データが必要です。F-netだと申し込み時に制限（１GB以下、リクエスト数（容量）制限）があるため、難しい。

*** noisepy ******************************
https://noise-python.readthedocs.io/en/latest/
・複数の観測点間の相互相関関数をプロット
・SAC を ASDF に変換して読み込み。
・noise_module が import できないエラー（S0B_to_ASDF.py）。

*** AANT *********************************
http://penglipk.github.io/AANT/
Adaptive ambient noise tomography and its application to the Garlock Fault, southern California
・sac 形式のデータを読み込み、速度を推定し、速度場を逆算してくれます（トモグラフィー）。
・cutsac のソースが含まれておらず中止。
・理想的なツールなのですが、更新が止まっています。非常に惜しい。

*** BIDO *********************************
https://staff.aist.go.jp/ikuo-chou/BIDO/2.0/bidodl.html
・時間領域と周波数領域の結果を比較する目的で実施。
・2.0 では 水平動も利用されていましたが、 3.0 では鉛直動のみ扱うとのこと。
・Ubuntu の binary が入っていましたが、動かなかったのでコンパイルしました。
・15分程度のデータであれば動作。速度が異常。
・1時間程度のデータは読み込み時にエラー。ディメンジョン修正箇所がわからず。

*** FMST *********************************
http://rses.anu.edu.au/~nick/surftomo.html
・トモグラフィーのみのようでした。分散曲線を出した後のステップです。
・速度を事前に用意することで、それらを満たす速度場を逆算。
・マニュアルを読みましたが、今回は手を出さず。

*** seismic-noise-tomography *************
https://github.com/bgoutorbe/seismic-noise-tomography
Rayleigh wave group velocities at periods of 6–23 s across Brazil from ambient noise tomography
・Python2.7でした。ライブラリがそろっていた 3.8 環境で動かし始めましたが、変換が面倒になり断念。

*** amb_noise_processing *****************
http://hestia.lgs.jussieu.fr/~boschil/downloads.html
Two-receiver measurements of phase velocity: cross-validationof ambient-noise and earthquake-based observations
・これもPython2.7でした。変換が print 文のみでしたので、3.8 にて実施。

この他、MATLAB を利用した GUI 対応コードもいくつかありました。さすがに購入しようとは思いませんでしたが、仕事で必要になれば選択肢に入るでしょう。

私の環境では、最後の amb_noise_processing のみ分散曲線まで確認できました。詳細を追いましょう。

************************************
20210516追加
「Two-receiver measurements of phase velocity: cross-validationof ambient-noise and earthquake-based observations」より、passive 手法で共通と思われる部分。

• Microseisms are most energetic in the period band between 5 and 30 s. At the shorter period end of this range, surface waves from teleseismic earthquakes are difficult to observe. Local to regional seismicity is needed to obtain phase velocities from earthquake data in the frequency range between about 3 and 10 s (Endrun et al. 2004).
• 1年のデータが必要（１年以上は不要）
• Records are filtered in the frequency band of interest (2–200s). サンプリング周波数1Hz以下⇒容量削減、計算負荷軽減。
• The data is then cut into overlapping time windows (e.g. half an hour with 50 per cent overlap), cosine-tapered at both ends.

 

Hi‐net で F-net をシミュレート その2

続きです。

文献を読み直してみました。
流れは単純なのですが、数式は理解できませんでした。 うーん。

 ★方針

• 地震計は、その固有周波数と減衰係数によって特徴付けられる
• 地震計の固有周期よりも長い周期の地震動は、その特性により減衰される（振り子も地面と一緒にゆっくり動いてしまうので、差が生じないイメージ）。
• 短周期地震計の記録から長周期の地上運動を再構築するためには、観測されたデータをその応答でデコンボルブする必要がある。
• 時間領域でのフィルターを開発し、ブロードバンド地震計をシミュレートする。

★フィルター

• １自由度減衰強制振動式を使って、ラプラス変換により地震計の伝達関数（入出力比）を表現。
• ブロードバンド記録に変換する関数を作成（F-netの伝達関数/Hi-netの伝達関数）。
• 離散データに適用するためz変換を利用。関数を式6に書き換え。
  

★hinet-decon　https://github.com/tktmyd/hinet_decon

  '-o  outfile'   ( indicate output sac filename <sacfile.out>          )
  '-f0 freq'      ( eigen frequency of input signal <1.0>               )
  '-h0 damp'      ( damping constant of input signal <0.7>              )
  '-f1 freq'      ( eigen frequency of output signal <0.00833333>       )
  '-h1 damp'      ( damping constant of output signal <0.707>           )
  '-decon'        ( deconvolve without simulation seismometer           )
  '-int'          ( output displacement record by numerical integration )
  '-fint freq'    ( corner frequency of low-cut filter for integration  )
  '-hint damp'    ( damping constant of low-cut filter for integration  )

f0,h0:Hi-netの地震計特性(概ね、この値です。)
f1,h1:F-netの地震計特性（シミュレートしたい計器の値：JIZFの固有周期は120秒＝0.008333Hz、地震計によっては大きく異なっています。）
下3つはまだ理解できていません。使うことはないので寝かしましょう。

 

★不明点

• 「デコンボリューション」の和訳（カタカナ語としてそのまま使われている文献を見かけましたが）
• 式2の分母（線形常微分方程式のラプラス変換とすると、iはどこから？符号はどこで入れ替わった？）
• 式5の導出（古い文献か洋書）
  

 

★要確認
Fortaranソース(計算の流れ)

Hi‐net で F-net をシミュレート

久しぶりに、楽しめた文献です。

Maeda et al., Interference of long-period seismic wavefield observed by dense Hi-net array in Japan, J. Geophys. Res., 116, B10303, 2011.
http://dx.doi.org/10.1029/2011JB008464

いえ、中身を理解しているわけではありません。が、ここに書かれているような比較をするしかない、とプロと話をしていた直後に見つけた文献でしたので、とても心惹かれました。

Hi‐net と F-net の地震計の伝達関数を組み合わせることで、時間領域でのフィルターを作成。Hi‐net のデータから 100秒までの低周波領域を再現できた、という内容です。2007年のスマトラ島沖地震を例に、とある Hi-net の観測局のデータにフィルターをかけた波形と、そこに近接する F-net 観測局の波形を比較することで妥当性を確認されています。
GitHub にコードが掲載されています。

hinet_decon
https://github.com/tktmyd/hinet_decon

A fortran2003 code to deconvolve Hi-net velocity record by its seismometer response by using inverse filtering technique. 

最終更新が７年前。需要がないのか、より良い手法が出たのかわかりませんが、メジャーにはなっていないようです。

ひとまず、手を動かしてみることに。

*** Ubuntu20.04です。**********************************************

a. Hinet の HP から win32tools をDL、make
b. GIthub から hinet_decon をDL、make

conda で仮想環境構築
Python 3.8 を install
pip obspy hinetpy pandas jupyter

a.で作成したcatwin32、win2sac_32をフォルダにまとめ、パスを通す。
home./profile の最後に書き込み。
export PATH="$PATH:/home/hinet/win32tools/"　など

条件設定：震央の緯度経度、データ取得開始時間、スパンなど

HinetPy  で読み込み、SAC変換。

b.で作成した hinet_decon で時間領域フィルターをかける。

ObsPy で BPフィルター& record section 作画。

******************************************************************************

Fortaran、c、Python で準備されたライブラリやソフトを Python で繋ぐ感覚です。半日で組みあがり、一つのノートブックに仕上がりました。意外と単純で簡単でしたね。条件を指定した後はデータダウンロードから作画までほぼ自動です。各々の作者に感謝。

で、再現した画像がコチラ。データは防災科学技術研究所 Hi-net を使用。
まずは Fig.６(a) 50～100秒（軸が90度回転しています）。
P波は見えませんが、S波とレーリー波は見えます。文献と時間がずれているのは起点の時間が異なるのでしょう。

次は Fig.６(b) 20～50秒。こちらはP波も見えます。

さらに N.JIZH のみを拡大し、Fig.3と比較。完全に再現できています。コードにミスはなく、ライブラリも正しく動いたようです。この分野でよく利用されているらしい SAC 形式で（結果的に）処理したのが良かったのかな？
https://phreeqc.blogspot.com/2019/08/obspy-2.html

676か所の観測局のデータを DL して描き終わるまで、10分もかかっていなかったと感じます（計っていませんでした）。便利な時代です。

あとは頭がついていくかどうか。
hinet_decon の設定はデフォのまま。まだ理解できていない部分があるので、もう一度読み直してみましょう。

 

DO CONCURRENT with GPUs

Accelerating Fortran DO CONCURRENT with GPUs and the NVIDIA HPC SDK
https://developer.nvidia.com/blog/accelerating-fortran-do-concurrent-with-gpus-and-the-nvidia-hpc-sdk/

昨日のブログです。
OpenACC のデータ転送が面倒で困っていたところ、この記事を見かけました。

 All data movement between host memory and GPU device memory is performed implicitly and automatically under the control of CUDA Unified Memory.

これでACCと同程度のパフォーマンスが出たらラッキー。頻繁にメモリへのアクセスがあるので過剰な期待はしていないのですが、いくらか早くなれば嬉しい。早く試したい！

Docker はまだ 20.9 (SDK 単体も)。公開まであと1か月くらいでしょうか？

**************************************

20201217追記

先日、Docker イメージが公開されました。
早速試してみたところ、-stdpar=multicore では OpenMP と同じ結果、速度でした。
が、-stdpar=gpu では発散。うまく計算しません。
コンパイル情報を見てみると、gpu では DO CONCURRENT 内の DO LOOP も自動並列化で GPU に載せられていました。これかな？

NVIDIA HPC SDK

OpenACC を利用しようと考えていました。

ACC の実装は比較的手軽だそうですが、場合によっては CUDA に並ぶことがあるとのこと（以前、チャレンジしたときは失敗しました）。
私はプロではないので、C & CUDA によるゴリゴリチューニングはできません。で、OpenMP からの ACC で、あわよくば狙いです。

OpenACC を gcc がサポートしているようなので使おうかな？などと考えながら、いつもの PGI Community Edition をチェック。以前のVer.と変わらないなあ、と製品版の価格をチェック。すると、以下の表示。

PGI Professional 製品の販売は終了しました。（詳細）

( ﾟДﾟ)？！
3月で販売終了していたとのこと。知りませんでした。

PGI Compilers＆Tools は NVIDIA ブランドの NVIDIA HPC SDK ソフトウェアとして、新しく生まれ変わりました。

NVIDIA HPC SDK
https://developer.nvidia.com/hpc-sdk

ついに PGI の冠が取れたのね。
プロファイラーも以前のまま含まれています。しかも、GPU Cloud で配布されています。
https://ngc.nvidia.com/catalog/containers/nvidia:nvhpc

はい、素晴らしい。さすが NVIDIA。
もうこれは、Linux ＋ Docker ＋ HPC SDK 一択でしょう。

最新のアーキテクチャに対応したコンパイラーが無償で配布されるのも素晴らしいのですが、これ、Win版の Fortran コンパイラーとしても使われだすのではないでしょうか？

俄然、やる気になりました。使ってみましょう。

**************************************
20201113追記

使ってみました。
dockerイメージを走らせただけ（nvidia-docker を使わなくなっていました）。その上で何の問題もなくコンパイルできました。
計算中に GPU を使っています。kernels 構文を差し込んだだけですので、遅いのですが。
チューニングには時間を取られそうですが、制御は拍子抜けするくらい簡単でした。ありがたいですね。

土石流の Fortran コード

Hyper KANAKO の不具合が多く、代替えコードを使用することになりました。

先輩が調達した土石流の Fortran コードを読んでいたのですが、これがとても読み易い。素晴らしい書き方だと感心しながら読んでいました。

中身は高橋モデルの一部が使用されており、少し手を加えることで河川砂防技術基準に適合させることができそうでした。流れがシンプルかつ明快で、偏微分の離散化もわかりやすく、すぐに読み終わりました。

おそらく、KANAKO の計算部分も同様にシンプルなはずです。なのになぜ不具合が多いのでしょう？

おそらく後付けの GUI 側の不具合がメインなのでしょう。GUI はソフトウェアメーカーさんに任せるのが一番良いのですが、残念ながら FORUM8 さんの開発は止まっています。ユーザーが少なく採算に合わないので Ver.UP されないのだと想像されます。

エンジンと GUI を完全に切り離し、データフォーマットをマニュアルに載せておけば扱いやすくなるでしょう。

ま、Fortran コードも整備しながら、ゆっくり待ちましょう。

Fortran と Python

Fortran コードを Python に移植し始めて気づいたのですが、Python には goto 文がありません。
調べてみると、可読性の高さを維持するため設けていないそうです。確かに、While 等で代用できますし、あっちこっち飛ばないので追いかけるのが楽です。

地味に面倒だったのが オリジン。Fortran は one-based、Python は zero-based です。+1するだけなのですが、忘れそうになります。

他には ()と[]の表記の違いでしょうか。これは検索・置換である程度修正できるので問題ないでしょう。

Fortran サブルーチンはコンパイルして Pythonで読めるはずですが、今のところ読めていません。これをクリアすれば main の書き換えが主体となります。上記に留意しておけば、ほぼそのまま移植できます。

自動化されないでしょうか？

TDM-GCC

Fortran を後輩さん（初心者）に使わせたいと相談を受けました。

私は計算速度の点から Intel Parallel Studio を使っているので、フリー版を必要としていません。使うとすれば Cygwin + gfortran や Linux などが選択肢になるのでしょう。

前後の作業効率を考えると、今回は Windows で実装したいところです。しかも手軽に。

探してみるとありました。

TDM-GCC

https://jmeubank.github.io/tdm-gcc/

丁寧な解説はコチラ↓

http://www.compe.media.kyoto-u.ac.jp/syoseki/windows/windows-gfortran.html

手元のソースは問題なくコンパイルできました。計算結果も問題なし。
インストールするだけなので手軽です。Win版でこのような手軽なソフトが配布されているとは知りませんでした。

いくつか試行しないと制限・弱点は見えてこないですが、ひとまずこれが良いでしょう。

事前学習

この週末は、Python でコードを書いてました。

ファイル集計・ピボットテーブル・パターン区分等。
速度の面から Fortran にしようかな？と考えましたが、Jupyter での インタラクティブなところが手軽で素人向き。結局、すべて Python に任せました。これでお客様の主目的は達成。ありがたい。

Pandas と NumPy で少し戸惑うところがありました。ルールが微妙に違うようで、まだ完全にわかっていません。ダメなら「ああダメなんだな」といって修正するレベル。いつか自在に使えるようになるのでしょうか？ま、プロになるつもりはないのですが、せめて使う道具のルールくらいは正しく覚えておかないと。

その合間に、来月参加するセミナーの事前学習。
ライブラリ等のインストールや機械学習の基本のあたりは飛ばして、使用予定の配布コードが動くか確認。大丈夫でした。
以前、コンペに出ていた課題「衛星画像から崩壊箇所の抽出」を研修でもトレースするようですが、そのコードを見ると自分のレベルがよくわかりました。課題だけ見た時はできると思ったのですが、マダマダ。うーん、技術者って終りがないね。
逆に、今後のノビシロととらえて少しづつ学びましょう。

Fortran とEXCEL

先輩が Fortran で SCE-UA を改変されていました。

ちょうど EXCEL で作成したタンクモデルの最適化シートのチェックができると思い、お手伝い。RMSE にペナルティを与える箇所だけ修正し、返しました。

Fortran の SCE-UA と EXCEL のソルバーを比較すると、RMSE ベースでは似たようなもの。見た目はどちらもそこそあっていますが、昔の方が見られるとおそらく嘆かれるような出来（RMSE を選択する時点で嘆かれるかもしれませんが）。やはり、データを見て半減期を考えて1段目から合わせていく方が良いように思われます。先輩曰く「データは見たもの勝ち」。よくわかります。

1時間単位で2年間のデータがあったのですが、計算時間は SCE-UA の圧勝。数十秒対数時間のオーダーです。グラフ化まで考えても、長期のデータに対しては EXCEL に勝ち目がありません。短期では手軽でグラフまで描いてくれる EXCEL ソルバー、長期では SCE-UA を選択するのが現状では BEST でしょう。

まだまだ Fortran を捨てられません。

Win10 + Ubuntu + Fortran

windows10 で Fortaran コードを編集・コンパイルしたいとのこと。

少し古い方に相談されていたみたいで、Cygwin + gfortran を進められていました。が、Cygwin がうまく入らないとのこと。
それなら、ということで Windows Subsystem for Linux をお勧め。Windows10 に Ubuntu を入れ、gfortran を使えるように。

フォルダ・ファイル等の permition の変更、ディレクトリの表現に気を付ける必要はありますが、Win とのファイルのやり取りは容易。Win からファイルを Ubuntu の home/ユーザーフォルダ内に移動して、コンパイル。そのまま計算して結果を Win ＋EXCELへ。

ま、ちょっとした計算ならコンパイラーを買うまでもないですし、デュアルブート を構築することもないでしょう。
Win10では、ずいぶん手軽になりました。

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