事前学習

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

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

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

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

PC の補強

どうも、新しいPCではスペック不足ということが判明。

計算を回すと、1回で数TBのデータが作成され、数十GBのメモリが消費されるようでした。で、あわててメモリーと内蔵HDDを増設。

後輩君に指示をして増設してもらいましたが、初めてだったようですね。周辺のオジサマ達が寄ってきて、あれに気をつけろ、これはこうするんだ、などと言ってました。この年代の人達は車とか機械いじり好きですからね。

相性問題もなく、無事完了。
これで、次から任せられます。

Android

先週、iPhone を破損。

10年で延べ4台。2台を画面破損。簡単に割れます。
で、買い替え。

10年くらい前でしょうか、当時の Android は酷い仕上がり。そのイメージもだんだん薄れてきた頃でしたし、耐衝撃を試してみたくて Android 機種を選択。

使ってみると、案外 Android 頑張っているな、という印象。

相変わらずフリーズは時々発生するものの、気になるほどではなくなっています。それよりも、iPhoneより良いなと感じる点がいくつかあり、ひとまず安堵。複数画面にウィジェットを配置できる機能は、良いと思います。

これまで以上にデータを Google に提供することになりましたが、5G インフラ展開までの間、大事に使いましょう。

NVIDIA driver のインストール (Ubuntu18.04)

NVIDIA-driver-410 入れた時のメモ。

root権限
suでパスを入れるとエラー
sudo -i

Install drivers
$ sudo add-apt-repository ppa:graphics-drivers/ppa
$ sudo apt update
$ sudo apt install nvidia-driver-410

*************************************
20190206追記
Ver.415が出ていました。

$ ubuntu-drivers devices
$ sudo ubuntu-drivers autoinstall
$ sudo reboot
$ nvidia-smi

不要パッケージ削除
sudo apt autoremove

リポジトリ削除
$ sudo add-apt-repository --remove ppa:graphics-drivers/ppa

DeepWater (Docker)

少し古いですが、DeepWater を入れた時のメモ。

必要条件
・Ubuntu 16.04 LTS
・NVIDIA Display driver at least 367
・CUDA 8.0.44 or later (we recommend the latest version) in /usr/local/cuda
・CUDNN 5.1 (placed inside of lib and include directories in /usr/local/cuda/)

環境書き込み
$ export CUDA_PATH=/usr/local/cuda
$ export LD_LIBRARY_PATH=$CUDA_PATH/lib64:$LD_LIBRARY_PATH

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

$ nvidia-docker run -it --rm --net host -v $PWD:/host opsh2oai/h2o-deepwater

java -Xmx18g -jar /opt/h2o.jar
java -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xmx18g -jar /opt/h2o.jar

admin Shut Down
exit

Docker コマンド

Docker でよく使うコマンドのメモ。

稼働コンテナ確認
docker ps -a

コンテナ停止
docker stop <CONTAINER ID>

コンテナ操作
docker container
  prune       Remove all stopped containers
  restart     Restart one or more containers
  update      Update configuration of one or more containers

コンテナの一括停止
$ docker stop $(docker ps -aq)

コンテナの一括削除
$ docker rm $(docker ps -aq)

イメージの表示
$ docker images

イメージの一括削除
$ docker rmi $(docker images -aq)

conda update

来月のTellus のセミナーに参加できそう。
https://tsbc-tokyo0209.peatix.com/

会社では応募3名中、私だけが当たり。ま、その前の大阪会場が外れたので、倍率2~3倍といったところでしょうか？

下準備で色々求められていますが、大体入っているので問題ないでしょう。
ひとまず、アップデートをかけておきましょう。

Anacondaのアップデート
$ conda update -n base -c defaults conda

パッケージのアップデート
$ conda update --all

古いパッケージの削除
$ conda clean --packages

SAR+機械学習、楽しみです。

FFT

先週、表面波探査を実施。

静かな平地で好条件と思いきや、近くの工場からと推察される 5Hz のノイズを取り切れませんでした。解析は未実施ですが、深部にどの程度影響したのか興味を惹かれているところです。

表面波探査では波動を扱いますが、他の探査や分析でもその知識は必要となります。微動はもちろん、XRD、SAR、電磁探査、土砂災害の検知など。これだけ使うなら、もっと性根を入れて勉強しておけばよかったと思うのですが、後悔先に立たず。
よく使う FFT もモジュール化されていますので、実際に手を動かすどころか表に出てくることすらありません。が、重要ですのでキーワードくらいは書き残しておきましょう。


「新・地震動のスペクトル解析」4章が主体です。

有限（離散）フーリエ近似
・波形を離散化し、N個の標本値（例えば時間=mΔtにおける加速度xm）を通過する関数として近似により表現。
・選点直行性の利用。
・もともとの波形をN/2種類（k次数、モード）の波に分解。
・標本の個数が有限なので、振動数の検出限界が生じる。これがナイキスト振動数(fN/2=1/2Δt)。
・N/2個の成分を持つフーリエ振幅スペクトル（分解して並べたもの）、フーリエ位相スペクトルとして表現可（時間領域を周波数領域に変換）。
・振幅・位相を表現するには、複素表現が便利。
・有限フーリエ変換では波形が周期的であることを仮定するため、リンク効果が発生。

高速フーリエ変換（FFT）
・有限（離散）フーリエ変換を効率的に計算するアルゴリズム。
・標本数を2の累乗とすることで計算時間を短縮。
・標本数の不足分には「後続のゼロ」をつけ、2の累乗個とし計算。リンク効果を断ち切るため、現実の波のスペクトルに近いとも言える。
https://phreeqc.blogspot.com/2016/07/blog-post_30.html

パーセバルの定理
・標本値xmの2乗平均は、平均パワと呼ばれる（単位時間当たりの電力（電圧の2乗に比例）の式と似ているため）。
・「パワスペクトル」の「パワ」はココからきている。エネルギーを表現する物理的「パワ」と同義でない。
・各モードの成分が受け持つパワを表現。

表層崩壊の現地実験映像

昨晩、NHK で人工降雨？による表層崩壊の実験映像を流していました。

すごいよ出川さん！本物の火事＆土砂崩れ！衝撃映像満載のメガ実験バラエティー
「土砂崩れに予兆はないのか？」

これ、地すべり学会にも映像がアップされており、ダウンロードもできます。
https://japan.landslide-soc.org/for_general_index.html

テレビでは 180mm/h の解説がありました。なかなか崩れないため徐々に降雨強度を上げ、最終的には過去最高程度に至ったようです。何時間続けたか？観測機器の動きは？など細かい話はありませんでした。

崩壊形状は平坦で薄く、違和感のある映像でした。人工降雨が短期間で地盤内に浸透できなかったためでしょうね。一方、それ故の流動性に対しては納得。豪雨に起因する崩壊では、対岸まで土砂が駆け上る例もあります。このような挙動を示す場合もあるのでしょう。
驚いたのは土堤の範囲。ばっちりでしたね。どのように設定されたのでしょう？感覚でしょうか？
私ならもっと広く作って、下流側に駐車させませんが。あの程度の高さの土堤は気休めであり、役に立たないことを知っていますので。万が一、もっと大きな崩壊が発生したら、などと考えてしまいます。地下は見えないですからね。

観測データが開示されるかどうかわかりませんが、もしかすると映像を掲載している地すべり学会から「報告」が出てくるのかもしれません。その場合は見てみましょう。

128GB メモリ

制限緩和後、あらためて EC2 の H2O を起動。

メモリは 120GB 確保。
java -Xmx120g -jar h2o.jar

split は相変わらずダメでしたが、XGBoost 、Deep Learning ともに、最後まで走りました。ただ、データの質が良くなく、結果はボロボロ。
1試行20分程度でしたので、グリッドサーチを考えるとやはり GPU が欲しいところ。XGBoost は GPU 対応でしたので、次に必要に迫られた場合には試行してみましょう。

データを動かしてみて、見つかった不都合個所を改善し、再度計算へ。大規模データでもこのループを回せるようになりました。が、まだまだ終わりがなさそうです。

なお、今回の課金は$40弱。初年度無料枠に加え、昨年の SageMaker 講習会で $25 のクーポンをいただいていましたので、最終的には数百円の出費になるようです。安く済ませることができました。

インスタンスタイプの変更

EC2 の H2O を起動。

メモリは56GB確保。
java -Xmx56g -jar h2o.jar

11GB の csv 読み込みは OK。
splitはダメ。うーん、メモリ？ H2O？ Java? の限界。

Jupyter 経由で CSV を分割し、再度 H2O へ。
今度はモデリングまで到達しましたが、ここにきてメモリエラー。より大きなインスタンスが必要でした。見誤りました。
Java heap space', caused by java.lang.OutOfMemoryError: Java heap space
#e Thread WARN: Swapping!  GC CALLBACK, (K/V:29.58 GB + POJO:23.09 GB + FREE:3.33 GB == MEM_MAX:56.00 GB), desiredKV=9.82 GB OOM!


SagerMaker に移行。
が、こちらも、データクレンジング時にメモリーエラー。EC2同様、メモリ64GBでは不足でした。うーん。失敗。

Machine Learning ではどうか？
こちらはOK。データ量に応じてスケールアップしてくれるようです。
が、Machine Learning では細かい調整ができません。EC2, SageMaker にて、より多くのメモリを積んでいるインスタンスで動かすしかなさそうですね。

まずは 既存のインスタンスを右クリックから「インスタンスの設定」-「インスタンスタイプの変更」で メモリ128GB の r5d.4xlarge に変更。これはすぐ反映されました。簡単！

で、開始。
が、始まりません。
You have requested more instances (1) than your current instance limit of 0 allows for the specified instance type. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit.

制限緩和のリクエストが必要とのこと。そういえば、以前実施したことがありますね。左の「制限」から該当インスタンスを見ると以下の通り示されています。
実行中のオンデマンドインスタンスの数: r5d.4xlarge 0

取り急ぎリクエストしておきましょう。

S3-EC2 データコピー

S3 に上げた 18GB のファイルを Sagemaker のインスタンス (ml.m5.4xlarge) へコピー。

これ、爆速でした。
アップに数時間かかったのに、AWS内でのコピーは 数十秒。驚き。csv に変換できるかな？と試したところ、できました。64GB のメモリ選択で正解でした。
再度、作成した 11GB の csv を S3 へコピー。こちらは1分弱。ま、早いでしょう。

SageMaker でのファイルコピーは Jupyter 上から Python で行ったのですが、
EC2へはコマンドをたたきました。
・S3からローカルにファイルをコピー
$ aws s3 cp s3://バケット名/ディレクトリ名/ファイル名 ./ディレクトリ名/
・EC2からS3にファイルをコピー
$ aws s3 cp ディレクトリ名/ファイル名 s3://バケット名/ディレクトリ名/

こちらも速いなあ、と思ってみてますと、途中でエラーを吐きました。
download failed: [Errno 28] No space left on device

容量確認。
ubuntu@ip:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme1n1     259:0    0    50G  0 disk
└─nvme1n1p1 259:1    0     8G  0 part /

ボリュームを50GBに拡大していましたが、パーティションはそのままでした。50Gに拡大します。
ubuntu@ip:~$ sudo growpart /dev/nvme1n1 1

ubuntu@ip:~$ lsblk
nvme1n1     259:0    0    50G  0 disk
└─nvme1n1p1 259:1    0    50G  0 part /

OK。再度コピーしました。
が、エラーを吐きます。
ubuntu@ip:~$ aws s3 cp s3://
download failed: [Errno 28] No space left on device

容量は空いています。
ubuntu@ip:~$ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/nvme1n1p1 1024000 185280  838720   19% /

で、お決まりの reboot 。
すんなりコピーできました。

S3 の課金

元旦早々、「S3 で1か月の無料枠突破に近いよ」という趣旨のメールが届きました。
S3 への平均15GB×2回のアップロードで put request が1700回を超えた模様。2回ともエラーでアップロードできなかったのですが、カウントは進んでいる状況のようでした。

その後、18GBの h5 ファイルを WinSCP でアップできたのですが、現段階で以下の表示。
Amazon Simple Storage Service 2,000 Put Requests of Amazon S3
100.00%(2,000.00/2,000 Requests)

うーん。なんだか釈然としません。
当面、私の環境ではS3標準のアップロード機能を避けましょう。

EC2 ＋ H2O, Jupyter Notebook

SageMaker で XGBoost による Binary classification を整備。

ビルトインアルゴは Docker で展開。CPU のみでした。import は csv か LibSVM のみ。オンプレミスでの RAPIDS に比べ、メリットはあまりないですね。ま、両者とも H2O で使えるので大規模データの変換に使えるかもしれません。

次は、EC2 に H2O を投入。H2O は CPU 版なので、メモリ大きめの m4.4xlarge を選択。これは以前に実装したことがあったので、容易に進みました。

そしてAnaconda。同じくEC2 に実装しようとしたのですが、はまりました。
インストールして再起動。jupyter notebook でサーバーは立ち上がるのですが、クライアントから接続できません。ポートは解放済みですが。
調べてみると、設定ファイルを作らないとダメでした。最初から Deep Learning AMI でインスタンスを作っておけばよかったのですが。
https://docs.aws.amazon.com/ja_jp/dlami/latest/devguide/setup-jupyter-config.html

Jupyter サーバーの設定
SSL 証明書を作成します。
$ cd
$ mkdir ssl
$ cd ssl
$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout "cert.key" -out "cert.pem" -batch

パスワードを使用してクライアントから Jupyter ノートブックサーバーにログインすると、サーバー上のノートブックにアクセスできます。
iPython ターミナルを開きます。
$ ipython
iPythonPrompt> from IPython.lib import passwd
iPythonPrompt> passwd()
パスワードハッシュ (sha1:examplefc216:3a35a98ed... など) を記録します。
exit

ここでJupyter を一度起動させておいたほうが良いでしょう。
終了してから、

Jupyter 設定ファイルを編集します。
 ~/.jupyter/jupyter_notebook_config.py

c = get_config()  # Get the config object.
c.NotebookApp.certfile = u'/home/ubuntu/ssl/cert.pem'
c.NotebookApp.keyfile = u'/home/ubuntu/ssl/cert.key'
c.NotebookApp.ip = '*'
c.NotebookApp.open_browser = False
c.NotebookApp.password = 'sha1:fc216:3a35a98ed980b9...'  

私の環境では c.NotebookApp.ip = '*'  がダメでした。 c.NotebookApp.ip = '0.0.0.0' でサーバーが立ち上がりました。バージョン違いでしょうか。 ま、次からは大丈夫ですね。

クライアントから簡単な試算も行い、チェック終了。
いざ、本番ということで S3 に 18GB 近いファイルをアップロードしようとしたら、エラー。アップできません。弱りました。