ラズパイの時刻設定

Raspberry Pi 3B/4 にて定期的な時計合わせを行いたいと、GPT 君に教えを請いました。

• 現在はインターネットにつながっており、chronyを使用中
• ネットにつながらない時は GPS モジュールと gpsd + chrony を使う予定
• RTCを組み込んで、起動時にRTCから本体の時刻を修正、定期的にRTCの時刻を修正
• GPIOは他のモジュールに占用されており、RTC、GPSはUSB接続

このような条件です。

※RTC：東京デバイセズ TDPC0205

※WinSCP
ログイン画面の[設定]
[環境]->[シェル]
「シェル」が[デフォルト]から[sudo su -]に変更

1. GPS

1-1. update_time.sh のコピー

• script フォルダをデスクトップに作成、書き込みパーミッションを与える
• update_time.sh（及び test.sh）をコピー、実行パーミッションを与える
• update_time.sh には、起動時に RTC からシステム時刻に書き込む設定、11分毎にシステム時刻をRTCへ書き込む設定(Chronyのrtcsyncに対応していないRTCの場合)を記載

1-2. gpsd および gpsd-clients の導入

• USB 接続の GPS モジュール使用のため、以下の関連パッケージをインストール

sudo apt install gpsd gpsd-clients

1-3. gpsd の設定

• VID/PIDの調査

lsusb→”aaaa:bbbb”

• /etc/udev/rules.d/100-usb-GPS_RTC.rules ファイルを作成し、次の内容を記載

SUBSYSTEM=="tty", ATTRS{idVendor}=="aaaa", ATTRS{idProduct}=="bbbb", SYMLINK+="gps0"

• 再起動後、NMEA 文（$GPGGA, $GPRMC 等）が表示されるか確認

sudo cat /dev/gps0

• GPS モジュールの接続先に合わせ、設定ファイルを編集
  /etc/default/gpsd の例

START_DAEMON="true"
GPSD_OPTIONS="-b -n"
DEVICES="/dev/gps0"
USBAUTO="false"

• 設定後、サービスを再起動。

sudo systemctl restart gpsd

1-4. SHMから読み取る設定を追加（gpsdから取得）

• /etc/chrony/chrony.confに追記

# SHM(shared memory)から読み取る設定
refclock SHM 0 refid GPS

• 設定後、サービスの再起動を行う

sudo systemctl restart chrony chronyd

2.RTC

2-1. 東京デバイセズ制御プログラムのインストール

• https://github.com/tokyodevices/td-usb/blob/master/README_ja.md

sudo apt install libusb-dev

• scriptフォルダからターミナルを起動

git clone https://github.com/tokyodevices/td-usb
cd td-usb
make

2-2. 100-usb-GPS_RTC.rulesに追記

• VID/PIDの調査

dmesg | grep TDPC0205

もしくは lsusb→”cccc:dddd”

• /etc/udev/rules.d/100-usb-GPS_RTC.rules ファイル

SUBSYSTEM=="usb", ATTRS{idVendor}=="cccc", ATTRS{idProduct}=="dddd", MODE="0666"

2-3. 起動時：RTCから時刻設定

• /etc/systemd/system/time_sync_RTC.serviceファイルを作成し、次の内容を記載

[Unit]
Description=起動時にRTCの時刻をシステム時刻に反映するサービス
After=network.target

[Service]
Type=oneshot
ExecStartPre=/bin/sleep 20
ExecStart=/home/pi/Desktop/script/update_time.sh boot

[Install]
WantedBy=multi-user.target

2-4. 有効化＆起動

sudo systemctl daemon-reload
sudo systemctl enable time_sync_RTC.service

3. systemd タイマーによる定期実行

• 11 分毎に時刻同期を行う場合、systemd の service と timer を利用して自動実行する

3-1. /etc/systemd/system/time_sync.service を作成

[Unit]
Description=時刻同期サービス

[Service]
Type=oneshot
ExecStart=/home/pi/Desktop/script/update_time.sh

3-2. /etc/systemd/system/time_sync.timer を作成

[Unit]
Description=11分ごとに時刻同期を実施するタイマー

[Timer]
OnBootSec=1min
OnUnitActiveSec=11min

[Install]
WantedBy=timers.target

3-3. タイマーを有効化＆起動

sudo systemctl daemon-reload
sudo systemctl restart time_sync.service
sudo systemctl status time_sync.service

• time_sync.timerの起動状況確認

sudo systemctl status time_sync.timer

※時刻関連の確認

• Chrony は ntpd のような「fudge」コマンドによる時刻オフセット補正をサポートしていない
• GPS が UTC で提供する時刻とシステム時刻（内部は通常 UTC）の整合性をシステムタイムゾーン設定で管理
• システムのタイムゾーン確認

timedatectl

• タイムゾーンを設定

sudo timedatectl set-timezone Asia/Tokyo

• 設定変更後は、Chrony デーモンを再起動して反映

sudo systemctl restart chronyd

• 接続確認

chronyc sources -v

***********************************************
20250326 RTC部分を追加、全体を修正

core MP135

core MP135 を購入。
Python コードを動かすまでの手順です。

balena-eacharを管理者モードで起動
ｍicroSDにイメージを焼く

USBケーブル接続後、シリアル通信
ID: root
Pass: root
$ passwd root

ユーザー追加
$ adduser "user name"
sudo group に追加
$ gpasswd -a "user name" sudo

root パーティション拡張
$ cd /usr/local/m5stack
$ bash resize_mmc.sh 

LANに接続後、SSH接続
IP確認
$ ifconfig

・自動起動させるプログラムをWinSCPでコピー。
・python3 で稼働確認。
・vimでrc.local を変更し、自動起動設定。

システム修復

片道４時間、日帰りで、観測システムを修復してきました。

Linuxに不慣れだった後輩君が設定していたため細部の設定に漏れがあったこと、私の管理ミスでこれを見逃していたこと、夏場の高温でハードの一部に不具合が発生していたこと、最終的には停電がトリガーとなったこと等、いくつかの要因が重なり問題となりました。で、現場まで赴くことに。

原因を突き止めてしまえばその場で対応できる、比較的簡単なソフト側の対策で済んだのですが、熱だけはハード対策が必要そうでした。が、これは高価な製品を購入しないと対応できません。うーん。

システム修復後、ついでに DNS を設定。GUIからなぜか反映されていなかったので、コマンドで変更。

$ sudo vi /etc/systemd/resolved.conf

[Resolve]
DNS=8.8.8.8

$ sudo systemctl restart systemd-resolved.service

apt update は成功しますが、upgrade で失敗します。古いリストが残ったままなのでしょう。リストを全消ししてから再度 update & upgrade。upgrade には時間がかかりました。

$ sudo rm -r /var/lib/apt/lists/*

ひとまず周辺環境を含め目についた問題は全てつぶしておきました。今回は停電により、隠れていた問題も同時に顕在化しました。最初に見逃さないようにしないと、このように不要な対応が発生します。気を付けましょう。

Linux ファイル移動、コピー

a.txtをb.txtにリネーム
$ mv a.txt b.txt

*.txtをdir1の下位に移動
$ mv *.txt dir1/

dir1をdir0の下位に移動
$ mv dir1/ dir0/

-vで経過表示
$ mv −v dir1/ dir0/

ftp サイトからカレントディレクトリにコピー
$ wget ftp://ID:PASS@address/a/b/c/*

表面波の伝播 その2

先日の文献で紹介されていたツールです。

Computer Programs in Seismology 3.30
http://www.eas.slu.edu/eqc/eqccps.html

MFT が提供されていましたので、試しに使ってみました。

Cygwin 環境を作るのはイマサラなので、Linux 環境を選択。SSH や WSL2 だと GUI がダメなので、手元の laptop を Win10 との dual boot に変更（途中、BIOS を触って Win の boot loader が立ち上がるようになってしまいましたが、grub を選択して F10 で書き込めばOKでした（機種によって書き込み方が違うので、また迷わないように( ..)φ））。

これで Ubuntu 20.04 が入ったので、次はCPS。インストール手順は以下の通り。

$ sudo apt install make gcc gfortran

隠しファイル表示
/home/.profile にパス追加
PATH=$PATH:/home/CPS/PROGRAMS.330/bin
export PATH

このまま make すると ヘッダーファイルがないといわれます。追加。
Xlib.hの追加
$ sudo apt install libx11-dev
curses.hの追加
$ sudo apt-get install libncurses5-dev

$ ./Setup LINUX6440
$ ./C

これでOK。で、起動。
MFT は GUI を備えていましたので、まずこれから触ってみました（do_mft）。
残念ながら、Hi-net は読み込めず。F-net は読めました。同じ防災科研さんのツールで SAC 形式に変換していたのですが、前者についてはヘッダーを読めなかったようです。gsac では Hi-net も読み込み & プロット可能でしたので、do_mft の問題でしょうか。

続いて同じく GUI の do_pom。こちらは以下が出典。
Analysis of dispersive waves by wave field transformation
https://pubs.geoscienceworld.org/geophysics/article-abstract/46/6/869/68551/analysis-of-dispersive-by-wave-field
相変わらず理屈はついていけないのですが、結果は MFT よりマシ。先日の位相速度と同程度でした。うーん。

なかなか前に進みません。やはり、素人がすぐに結果を出せるほど甘くない内容です。

**************************************
20210511追記 その１

追加すべきライブラリは TOP ページに書かれていました。
http://www.eas.slu.edu/eqc/eqccps.html

Ubuntu Linux

You can use the program download page, or open a terminal window and enter the following commands:

sudo apt-get install make
sudo apt-get install gcc
sudo apt-get install gfortran
sudo apt-get install xorg-dev
sudo apt-get install libncurses5-dev
sudo apt-get install gawk

the following programs are useful:

sudo apt-get install gv
sudo apt-get install ImageMagick

追記 その2
F-net も読めないモノがありました。長いと読めないのでしょうか？

20210514追記
do_mft のバックで動いている sacmft96 などでは読めました。do_mft、do_pom のファイル認識に不具合があるようです。

 
20210626追記
Kimiyuki Asano et al.(2017)Surface wave group velocity in the Osaka sedimentary basin, Japan, estimated using ambient noise cross-correlation functions

The group delay time of the surface wave at each period was estimated using the multiple flter analysis technique (Dziewonski et al. 1969). 

MFTから求められる群速度。まだ理論は理解できていません。
http://www.eas.slu.edu/eqc/eqc_cps/TUTORIAL/LessonA/index.html
http://www.eas.slu.edu/eqc/eqc_cps/TUTORIAL/EMPIRICAL_GREEN/MFT.pdf

10. まとめ（Ubuntu + Docker + nvidia-docker + Deep Water）

目指していた Ubuntu + Docker + nvidia-docker + Deep Water を実装できました。

XGBoost を使えるようになったのは収穫です。

Deep Water で DNN を利用できないのは残念ですが、いずれ動くようになるでしょうし、それにこだわる必要もないでしょう。nvidia-docker により、他のフレームワーク等も容易に利用できるようになりましたし、以前の計算では、DNN より Random Forest の方が良い結果を出していましたので。データセット（数字）を扱う場合、機械学習の中の一つとして DNN があるという位置づけの方が妥当なように思われます。

さあ、環境は整いました。これで一安心。
あとはやってくる問題を解くだけです。

9. Driverless AI

Driverless AI のテストです。
https://www.h2o.ai/driverless-ai/

まずは、ホスト側の/home/<ユーザー>/　以下にディレクトリ作成。dataに学習・検証・テストデータを入れておきます。
$ mkdir data
$ mkdir log
$ mkdir tmp
$ mkdir license

NGC にログイン
$ docker login nvcr.io
user：$oauthtoken
Pass：<登録時に作成した Key>

環境を pull
$ docker pull nvcr.io/partners/h2oai-driverless:latest

Docker スタート。
（env NV_GPU="1" を入れないと、2枚目の GTX1060 を正しく認識しないのは Deep Water と一緒でした。）

$ env NV_GPU="1" nvidia-docker run \
    --rm \
    -u `id -u`:`id -g` \
    -p 12345:12345 \
    -p 54321:54321 \
    -p 8888:8888 \
    -v `pwd`/data:/data \
    -v `pwd`/log:/log \
    -v `pwd`/license:/license \
    -v `pwd`/tmp:/tmp \
    nvcr.io/partners/h2oai-driverless:latest

http://<IP>:12345
でアクセス。

ユーザー名を聞かれましたが、適当に入力して次の画面に。
お試し版として、30日のキーをいただいていましたので、それを入力。

動きました。

チューニング含め、ほぼ自動ですね。かっこ良い！

GPUも稼働しています。

データをそのまま使っているだけでなく、演算もして利用しているようですね。凄い。

が、自動過ぎてよくわかりませんね（楽ですけど）。

そもそも、アルゴリズムは何でしょうか？

調べてみると、FAQにありました。
http://docs.h2o.ai/driverless-ai/latest-stable/docs/userguide/faq.html#

Which algorithms are used in Driverless AI?
Features are engineered with a proprietary stack of statistical models including some of the most sophisticated target encoding and likelihood estimates, but we also employ linear models, neural nets, clustering and dimensionality reduction models and more. On top of the engineered features, XGBoost models (and ensembles thereof) are used to make predictions. More models such as linear models and neural nets are added currently and will be available shortly.

いずれは DNN も含まれるのでしょうね。
個人的には計算時に設定がわかったほうが良いかな？
非技術者の利用を想定されていますので、このスタイルで行くのでしょう。

7. Deep Water : XGBoost

XGBoost のテスト。

負荷をかけるという点で ntrees=1000に設定してみました（計算結果を見ると 100 で既に収束していました）。

ホスト側での GPU 稼働状況。

$ nvidia-smi pmon
# gpu        pid  type    sm   mem   enc   dec   command
# Idx          #   C/G     %     %     %     %   name
    1       2809     C     0     0     0     0   java         
    1       2809     C     0     0     0     0   java         
    1       2809     C     0     0     0     0   java         
    1       2809     C     0     0     0     0   java         
    1       2809     C     1     0     0     0   java         
    1       2809     C     2     0     0     0   java         
    1       2809     C     2     0     0     0   java         
    1       2809     C     2     0     0     0   java         
    1       2809     C    26     8     0     0   java         
    1       2809     C    63    21     0     0   java         
    1       2809     C    64    22     0     0   java         
    1       2809     C    63    21     0     0   java         
    1       2809     C    11     3     0     0   java         
    1       2809     C    39    13     0     0   java         
    1       2809     C    64    21     0     0   java         
    1       2809     C    64    21     0     0   java         
    1       2809     C    58    19     0     0   java         
    1       2809     C    63    21     0     0   java         
    1       2809     C    64    21     0     0   java         
    1       2809     C    63    21     0     0   java         
    1       2809     C    14     4     0     0   java         
    1       2809     C     0     0     0     0   java         
    1       2809     C     0     0     0     0   java 

$ nvidia-smi                                   
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0                    Not Supported                                       |
|    1      2809      C   java                                        1329MiB |
+-----------------------------------------------------------------------------+

本格的に稼働させるなら、VRAM は大きな方がよさそうですね。

速度は4倍。負荷が大きいほど威力を発揮しそうです。

GPU:3m27s
CPU（6core）：14m12s

結果（AUC）も良好。

Deep Water の XGBoost、良いと思います。

続く。

6. Deep Water : DeepWater

Deep Water を動かすための docker image を入れましょう。

https://www.h2o.ai/deep-water/
https://github.com/h2oai/deepwater#pre-release-docker-image

Optional Step. Make docker run without sudo. Instructions for Ubuntu 16.04:
    sudo groupadd docker
    sudo gpasswd -a ${USER} docker
    sudo service docker restart

入れなかったのでリブートして
$ nvidia-docker run -it --rm --net host -v $PWD:/host opsh2oai/h2o-deepwater

OK。動き初めました。
なるほど。毎回、環境を構築するわけですね。
先に言われていたように、メリットは
・使いたい環境（Ver.の組み合わせ等）を選択できる。
・複数の環境を共存させることが可能。
・動作する環境を組み合わせて提供してくれるので、悩まない。時間がかからない。
いろいろなフレームワークを試す場合にメリットが大きい！素晴らしいですね。

それでは、Deep Water を使いましょう。
$ java -jar /opt/h2o.jar

あとは H2O と一緒。指定されたアドレスを CTRL 押しながらクリック。
http://<IPアドレス>:54321/flow/index.html

Deep Water 入りの Flow が立ち上がりました。



＊＊＊＊＊＊＊＊＊ ここから、つまづきました。＊＊＊＊＊＊＊＊＊＊
＊＊＊＊＊＊＊＊＊飛ばしてOK。要点は最後。＊＊＊＊＊＊＊＊＊＊＊

が、import file　で検索してもデータファイルが表示されません。
リブートしてもダメ。
（今度は pull せずに即立ち上がりました。一度データをDLしとけば良いのね。優秀。）
pathを通してもダメ。
root権限でもダメ。
exit、 ctrl-d 効かない。
終わらない。リブート。

ふと思いついて Upload file　にすると、何事もなかったように動きます。こちらでした。
コンテナ内からホスト側のファイルを見に行くというのは、PC間を跨いで見に行くようなものでしょうから、何か設定がいるのでしょうね。

モデル（アルゴリズム）は Deep Water を選択。
設定はほぼ今までどおり。H2O と同様で迷いません。
Deep Learning Backend （MXNet、Caffe、TensorFlow ）を指定できますね。これは嬉しい。
GPU の device_id も指定できます。GTX1060は id1 でしたので1を入力。

で、計算開始！

が、error


MXNet の場合

Saving the model parameters.
[] /home/jenkins/slave_dir_from_mr-0xb1/workspace/deepwater-master/thirdparty/mxnet/dmlc-core/include/dmlc/logging.h:235: [] /home/jenkins/slave_dir_from_mr-0xb1/workspace/deepwater-master/thirdparty/mxnet/mshadow/mshadow/./stream_gpu-inl.h:125: Check failed: (err) == (CUDNN_STATUS_SUCCESS) CUDNN_STATUS_ARCH_MISMATCH
[] /home/jenkins/slave_dir_from_mr-0xb1/workspace/deepwater-master/thirdparty/mxnet/dmlc-core/include/dmlc/logging.h:235: [] /home/jenkins/slave_dir_from_mr-0xb1/workspace/deepwater-master/thirdparty/mxnet/mshadow/mshadow/./stream_gpu-inl.h:125: Check failed: (err) == (CUDNN_STATUS_SUCCESS) CUDNN_STATUS_ARCH_MISMATCH
terminate called after throwing an instance of 'dmlc::Error'
terminate called recursively
  what():  [] /home/jenkins/slave_dir_from_mr-0xb1/workspace/deepwater-master/thirdparty/mxnet/mshadow/mshadow/./stream_gpu-inl.h:125: Check failed: (err) == (CUDNN_STATUS_SUCCESS) CUDNN_STATUS_ARCH_MISMATCH
Aborted (core dumped)


googling では、cc で引っかかっているとのこと。あれ？GTX480 で計算しようとしている？


Caffeだと

・・・
Ignoring device_id
PYTHONPATH: /opt/caffe/python
Detected 2 GPUs
Started Caffe backend
・・・
54321      11     FJ-1-31   ERRR: java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: 0 <= 470341 < 273652
・・・


TensorFlow　では

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x00007fb022e3d92d, pid=11, tid=0x00007fb0b6eee700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_131-b11) (build 1.8.0_131-b11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libtensorflow_jni.so28445ce9-1982-4eea-b7cf-90bb2f0f6553+0x211992d]
#
# Core dump written. Default location: //core or core.11
#
# An error report file with more information is saved as:
# //hs_err_pid11.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted (core dumped)


MXNet で GPU Device id0 (GTX480)で計算してみると、 Cafe と似た以下のエラーを吐く。

No GPU found - not loading CUDA library.
・・・
04-03 00:41:21.783 10.11.56.1:54321      733    FJ-1-13   ERRR: java.lang.RuntimeException: java.lang.ArrayIndexOutOfBoundsException: 0 <= 500004 < 273725
・・・

試しにGTX480を抜いて、GTX1060の1枚刺しで計算してみました。
が、Cafe、TensorFlow 共に同じエラーを吐くので、GPU 2枚刺しで引っかかっているわけではない。

他のモデルではどうか？と XGBoost を試してみると、OK。問題なく走ります。AUC 0.9超えで、ちゃんと計算しています。

GPU：1分45秒
CPU：3分44秒

GPU使ってますね。

では、2枚刺しに戻してXGBoost。

NG。GPUの指定がまずいとErrorを吐きます。これか？

GPU backend (gpu_id: 1) is not functional. Check CUDA_PATH and/or GPU installation.

gpu_id: 0 だと、走ります。
ただし、ホスト側では id 1 の GTX1060 が動いています。

$ nvidia-smi pmon
# gpu        pid  type    sm   mem   enc   dec   command
# Idx          #   C/G     %     %     %     %   name
    1       5898     C     1     0     0     0   java         
    1       5898     C     2     0     0     0   java         
    1       5898     C     1     0     0     0   java         
    1       5898     C     1     0     0     0   java         
    1       5898     C    15     4     0     0   java         
    1       5898     C    14     4     0     0   java 

$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.48                 Driver Version: 390.48                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 480     Off  | 00000000:03:00.0 N/A |                  N/A |
| 44%   66C   P12    N/A /  N/A |    278MiB /  1469MiB |     N/A      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 27%   41C    P2    31W / 120W |    919MiB /  3019MiB |     57%      Default |
+-------------------------------+----------------------+----------------------+
                                                                             
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0                    Not Supported                                       |
|    1      5898      C   java                                         907MiB |
+-----------------------------------------------------------------------------+

XGBoostでは、gpu_id: 0 がGTX1060を指すようです。なぜでしょう？
このあたり、プロがいたらすぐに聞けるのでしょうけど。

再び、DeepWater。

今度はできるだけデフォルトに近い設定からテスト。gpu_id は 0 指定。

隠れ層2層だとOK。GTX1060 を使用しています。
以下、順次テスト。
3層 OK
Problem type:Dataset OK
balance_classes:on NG

これでしたか。balance_classes を使えないのは痛いですね。
balance_classes:off に戻して続けます。

score_each_iteration:on OK
backend：Caffe OK
backend：TensorFlow NG

TensorFlow はダメですか。残念。backend：mxnet に戻して続けます。

input_dropout_ratio:0.1 OK
mini_batch_size:100 OK


これで計算は進みますが、ほとんどGPUを使っていないようです。やはり gpu_id 周りを解決しないとダメでしょうか？

$ nvidia-smi pmon
# gpu        pid  type    sm   mem   enc   dec   command
# Idx          #   C/G     %     %     %     %   name
    1       7612     C     0     0     0     0   java         
    1       7612     C     0     0     0     0   java         
    1       7612     C     0     0     0     0   java         
    1       7612     C     1     0     0     0   java         
    1       7612     C     0     0     0     0   java         
    1       7612     C     0     0     0     0   java         
    1       7612     C     0     0     0     0   java         
    1       7612     C     0     0     0     0   java

$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.48                 Driver Version: 390.48                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 480     Off  | 00000000:03:00.0 N/A |                  N/A |
| 44%   59C   P12    N/A /  N/A |    278MiB /  1469MiB |     N/A      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 28%   46C    P2    30W / 120W |    199MiB /  3019MiB |      4%      Default |
+-------------------------------+----------------------+----------------------+
                                                                             
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0                    Not Supported                                       |
|    1      7612      C   java                                         187MiB |
+-----------------------------------------------------------------------------+


コンテナには GPU を1つだけ渡すように設定してみます。
env NV_GPU="1" nvidia-docker run -it --rm --net host -v $PWD:/host opsh2oai/h2o-deepwater

# nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.48                 Driver Version: 390.48                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 27%   34C    P8     7W / 120W |      2MiB /  3019MiB |      1%      Default |
+-------------------------------+----------------------+----------------------+
                                                                             
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

これで GPU 周りはスッキリ。


java -jar /opt/h2o.jar

#read-142 WARN: Swapping!  OOM, (K/V:1.03 GB + POJO:4.07 GB + FREE:131.5 MB == MEM_MAX:5.23 GB), desiredKV=762.3 MB OOM!

INFO: Java heap totalMemory: 362.5 MB
INFO: Java heap maxMemory: 5.23 GB
INFO: JVM launch parameters: []
INFO: Machine physical memory: 23.54 GB

javaアプリで エラーが出るので、最大メモリサイズを指定。

java -Xmx18g -jar /opt/h2o.jar

INFO: Java heap totalMemory: 362.5 MB
INFO: Java heap maxMemory: 16.00 GB
INFO: JVM launch parameters: [-Xmx18g]
INFO: Machine physical memory: 23.54 GB

GPUの稼働率は変わりませんね。
DeepWater 1.37h
H20 18m15s

DeepWater のAUC が0.6弱。使えません。

うまく走ったとしても、答えは当然異なるようです。
https://stackoverflow.com/questions/48274614/deeplearning-and-deepwater-models-give-very-different-logloss-0-4-vs-0-6

• h2o.deeplearning is H2O's built-in deep-learning algorithm. It parallelizes very well, works well with large data, but does not use GPUs.
• h2o.deepwater is a wrapper around (probably) Tensorflow, and (probably) using your GPU (but it can use the CPU, and it can use different back-ends).

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
＊＊＊＊＊＊＊＊＊＊ ここまで飛ばしてOK。＊＊＊＊＊＊＊＊＊＊＊＊＊＊
＊＊＊＊＊＊＊＊＊＊以下、Deep Water まとめ。 ＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊


Deep Water 内のモデル（アルゴリズム）として Deep Water を選択した場合、私の環境ではGPU関連に不具合が生じるようです。

残念ながら、当面は Deep Water 以外を選択する方が良さそうです。選択する場合の注意点は、以下の通り。

・docker image を読み込む際に、env NV_GPU="1"をつける。（Deep Water 全体）

＄ env NV_GPU="1" nvidia-docker run -it --rm --net host -v $PWD:/host opsh2oai/h2o-deepwater

・Upload file でデータ読み込み。（Deep Water 全体）
・gpu_id: 0 を使用。（Deep Water 全体）
・balance_classes は使えません。（Deep Water：DeepWater ）
・backend：TensorFlow は使えません。（Deep Water：DeepWater ）


H2Oとか、XGBoost（GPU）は優秀ですね。
XGBoost を使ってみましょうか？

続く。

4. Docker (Ubuntu16.04)

AWS や Azure　を視野に入れる場合、Docker は使えるようにしておきたい。
（今はぼやっとしかわからなくても、触っているうちに靄も取れるでしょう。）

まずは Docker のインストール
https://docs.docker.com/install/linux/docker-ce/ubuntu/#extra-steps-for-aufs
$ sudo apt-get update
$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo apt-key fingerprint 0EBFCD88
$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
$ sudo apt-get update
$ sudo apt-get install docker-ce
$ sudo docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

$ sudo docker version

Client:
 Version: 18.03.0-ce
 API version: 1.37
 Go version: go1.9.4
 Git commit: 0520e24
 Built: Wed Mar 21 23:10:01 2018
 OS/Arch: linux/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version: 18.03.0-ce
  API version: 1.37 (minimum version 1.12)
  Go version: go1.9.4
  Git commit: 0520e24
  Built: Wed Mar 21 23:08:31 2018
  OS/Arch: linux/amd64
  Experimental: false


OK。入りました。

コンテナ一覧の稼働状況と止め方。
$ docker ps -a
$ docker stop <CONTAINER ID>


次は nvidia-docker です。
続く。

3. GTX480・GTX1060（非SLI）Ubuntu16.04

Ubuntu 側で GPU 2枚挿し（非SLI）の確認。

$ nvidia-smi
   
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 384.111                Driver Version: 384.111                   |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 480     Off  | 00000000:03:00.0 N/A |                  N/A |
| 63%   86C    P0    N/A /  N/A |    275MiB /  1469MiB |     N/A      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 27%   30C    P8     7W / 120W |      1MiB /  3013MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                             
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0                    Not Supported                                       |
+-----------------------------------------------------------------------------+

GTX480とGTX1060の二枚を認識しています。何もしていないのに480 は熱いですね。

driver Version は384.111。これだと、CUDA8.0までしか対応していません。
https://github.com/NVIDIA/nvidia-docker/wiki/CUDA#requirements

Requirements
The machine running the CUDA container only requires the NVIDIA driver, the CUDA toolkit doesn't have to be installed.
NVIDIA drivers are backward-compatible with CUDA toolkits versions

CUDA toolkit version Driver version GPU architecture
6.5 >= 340.29 >= 2.0 (Fermi)
7.0 >= 346.46 >= 2.0 (Fermi)
7.5 >= 352.39 >= 2.0 (Fermi)
8.0 == 361.93 or >= 375.51 == 6.0 (P100)
8.0 >= 367.48 >= 2.0 (Fermi)
9.0 >= 384.81 >= 3.0 (Kepler)
9.1 >= 387.26 >= 3.0 (Kepler)

ドライバーを更新しましょう。

古いVer.を削除
$ sudo apt-get --purge remove nvidia-*

リポジトリ登録
$ sudo add-apt-repository ppa:graphics-drivers/ppa
$ sudo apt-get update

最新Ver.確認
https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa

Current official release: `nvidia-390` (390.48)
Current long-lived branch release: `nvidia-390` (390.48)
Old long-lived branch release: `nvidia-384` (384.130)

最新版インストール
$ sudo apt-get install nvidia-390
$ sudo reboot

$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.48                 Driver Version: 390.48                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 480     Off  | 00000000:03:00.0 N/A |                  N/A |
| 50%   75C   P12    N/A /  N/A |    199MiB /  1469MiB |     N/A      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 27%   31C    P8     7W / 120W |      2MiB /  3019MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                             
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0                    Not Supported                                       |
+-----------------------------------------------------------------------------+

これでOK。

次は Docker のインストールです。
続く。

1. Ubuntu・Windows 10 の dual boot

昨年度にGPU 使用の Deep Learning を断念していました。

ビッグデータを CPU のみで扱えるよう調整して計算していたのですが、これでは少し情けない。時代に追いつくべく、ひと段落したところで環境を整えることに。

といっても、クラウド使用ではなく、まずはローカルで（InfraWorks でも表示の改善を期待しています）。Ubuntu + Docker + nvidia-docker + Deep Water を目指します。Ubuntu は Win10 との dual boot を予定。

まずは Ubuntu 16.04 LTS のインストールから。
ドライブは別にします。余っていた mSATA SSD を 2.5インチに変換し、SATA接続（ケースに2.5インチ用ベイが余っていた。しかも Power ボタン付き。）
これに Ubuntu を入れます。

1. Win10 上でUbuntu 16.04 iso を DL
2. unetbootin-windows　でブートローダーつけて起動用 USB 作成
3. Ubuntu を USB から直接起動
4. IP等ネット周り設定
5. 動作確認後、mSATA SSD にブートローダー、OSインストール
6. BIOSで Ubuntu SSD の起動順位を Win10 SSD より上位に設定
7. 起動確認
   2.5インチ用Powerボタンonで、ローダー経由の Ubuntu 自動起動（Ubuntu ・ Windows 10 選択可）
   2.5インチ用Powerボタンoffで、ローダー経由せずに Windows 10 起動
8. 「Ubuntu ソフトウェア」「更新」「インストール」でOSを含め最新に更新―再起動

次に GPU を 認識させます。

1. 「システム設定」「ソフトウェアとアップデート」「追加のドライバー」より NVIDIA　GPU ドライバインストール
2. 再起動後にGPU確認 $ nvidia-smi

これで Ubuntu 上で 古い NVIDIA GeForce GTX480 を認識しました。

続く。


*******************************************
20180404追記

Win10に戻ると時間がズレます。
Ubuntu 側も local で合わせておきましょう。

$ sudo timedatectl set-local-rtc true

Docker

動画を見ていて、H2O4GPU のソルバーに deep learning が含まれていないことに気づきました。

https://www.youtube.com/watch?time_continue=2&v=pzxzFY9GBT8

ちゃんと説明読んでね！って。
https://github.com/h2oai/h2o4gpu/blob/master/README.md

deep learning で GPU に対応しているのは「Deep Water」
https://www.h2o.ai/deep-water/

でも、これ2つ入れると必要な環境が競合しないのでしょうか？（ま、他所のフレームワークを持ち込むわけではないので大丈夫でしょうけど）

その不安に対しては、コチラに明解な回答の一つが記載されていました。
https://qiita.com/DUxCA/items/7bf3862569cfca122d73

caffe, caffe2, tensorflow, theano, mxnet, chainer, pytorch, torch などの様々な CUDA 依存のライブラリやフレームワークがある。
しかしこれらは互いに依存するubuntuやpython、CUDA等のバージョンがそれぞれ異なる。
このような状況では以下のような問題が発生する。

• 共用 GPU マシンの場合 - ユーザがそれぞれ sudo 権限を持ち、好き勝手にライブラリをインストールしたりバージョンアップすると、すぐに環境が破綻する
• 研究での GPU 利用の場合 - その時その時のマシンの環境依存になってしまうため、再現性が担保できない
• クラウドサービス利用の場合 - 仮想マシンから GPU を利用するのが（不可能ではないが）面倒くさい、計算に使いたいのに仮想化によるオーバーヘッドがある

これらの問題は nvidia-docker を使うことで解決できる。

docker ですか。確かに、H2O4GPU、Deep Water でイメージが用意されています。使い方はわかりませんが、便利そうなのは理解できます。というか、1台のPCで複数の OS Ver.や、CUDA Ver. を共存させようとすると、このような方針が簡単なのかもしれませんね。

Azure や AWS に手を出せていないのに、次は docker。さらに、nvidia - docker。
うーん、速い。完全に置いて行かれています。
ま、遅いながらも前に進みましょう。

SNAPHU 動きません

SNAPHU で unwrapping しようと思い、DL。
http://nova.stanford.edu/sar_group/snaphu/

make して、
make install して、と思ったらできない。
手動で makefile に指示のあったディレクトリにコピーして準備完了。

ます唱える呪文は snaphu.conf に書かれています。

# snaphu -f snaphu.conf Phase_ifg_.snaphu.img

27 parameters input from file snaphu.conf (84 lines total)
Logging run-time parameters to file snaphu.log
Segmentation fault (コアダンプ)

いきなりのコアダンプ。
以下は調べながら通った道筋、備忘録です。

# ulimit -a

core file size (blocks, -c) 0

コアダンプの出力を有効化します。
# ulimit -c unlimited
# ulimit -a

core file size (blocks, -c) unlimited

core file の出力先を変更
#echo /core > /proc/sys/kernel/core_pattern
# cat /proc/sys/kernel/core_pattern
/core

core fileを端末を立ち上げたディレクトリにコピーして（CDが面倒なだけ）
# gdb snaphu core.11111

Program terminated with signal 11, Segmentation fault.
#0  0x00007fe5f0036694 in vfprintf () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-157.el7_3.5.x86_64

はい、インストールしましょう。gdb を quit で抜けて、
# debuginfo-install glibc-2.17-157.el7_3.5.x86_64

もう一度、
# gdb snaphu core.25555

#0  0x00007f5778318694 in _IO_vfprintf_internal (s=<optimized out>,
    format=<optimized out>, ap=ap@entry=0x7ffe286718b8) at vfprintf.c:1635
1635   process_string_arg (((struct printf_spec *) NULL));


いえ、わかりません。optimized されているのでわからないのですが、少なくともNULLがあるのでここなんでしょう。けど、どう直せばいいの？

ひとまずココまで。

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でした。

XP から Linux

XPのサポートが切れるので、新しいPCを選んでほしいと頼まれました。

Webと写真整理がメイン。たまにWord等。
タッチパネルが良いという事でしたので、Win8 ＋タッチ、i5 でメモリ 4GB 以上を見てみると、簡単に7万円越えでした。

もったいないので、今のPCでLinuxを入れることを提案。
運用できるようにするまで少し手をかけてやらないといけないか？と思いながら、最近の動向を知るべく本屋に行ってみました。すると、案外同じことを考える方がいらっしゃるようで、いくつかの雑誌が XP からの乗り換え特集を組んでいました。
1冊買って中を見てみましたが、ディストリビューションの多さに驚きました。人気なんですね。十数年は、Red Hat 一択だったように思いますが。

で、付録のUbuntu のライブ版を起動。
すると、32bit 版がすんなり起動！（1発で動くとは思っていませんでした）
次は Wi-fi 接続ですが、こちらもすんなりOK。Web閲覧も、Firefox が入っていたので OK。VPN の設定まであります。驚きです。ここまで進化していたんですね。
USB の外付け HD も、つなぐだけで認識。ファイルアクセスも全く問題ありません。
プリンターはメーカーHP にドライバーがなかったのでダメかと思いましたが、何と、こちらも手を加えなくても認識。驚きました。
結局、全く問題なく移行できそうでした。これだと、余っているHDにインストールしてしまえば、後からデータ移行も可能です。しかも、XPに比べて軽い。私にとっては申し分ないです。あとは使用者の慣れと好き嫌いだけですね。

軽量ディストリビューションも多数あるようです。古いPCも、用途によっては、まだまだ再生できそうですね。

HDDの認識

HDDの認識を2つ。

先日購入した 98用の IDE HDD を 9821AP へ、はめてみました。
が、通電するものの認識しなません。おかしいなあと思いつつ、時間が来たので現場へ。

帰ってきて、そういえばと思い、HELPボタンを押しながらDIP switch を確認。
やはり、HDDが切り離されていました。ま、当然です。設定を変えると一発で認識。フォーマットもOK。FDのシステムディスクが部分的に読み取れなくなっていたので転送で失敗しましたが、起動はしました。生きていますが、うーん、古い。


もう一つは Linux の HDD （らしい）。現場に付けていた観測機器の HD のフォーマットが Linux 用で Win から読めないとのこと。フォーマットの詳細は不明。USB 接続できるのかも不明。とりあえず、何か分かれば教えてほしいとのこと。

xfs の外付け HDD が手元にあったので、USB で接続。そして、いつぞやのKNOPPIX を起動。
http://phreeqc.blogspot.jp/2012/04/blog-post_17.html
こちらは問題なく認識し、NTFS へデータのコピーも可能でした。
あと、LANDISK に USB で接続しても認識しそうなので、伝えておきました。こちらは結果が知りたいですね。


今も昔も、悩むところは似ているようです。

プロファイルの修復

WinXP のユーザープロファイルが壊れました。

デフラグをかけようとしたところ、うまくスケジュールに組み込めなかったのか、立ち上がりません。何度やっても途中で止まるので、前回正常起動時の構成を使って起動しました。が、ユーザープロファイルが壊れてしまい、他のユーザーからしかログインできなくなりました。

しかし、アクセス権を設定していたのが裏目に出てしまい、他のユーザーからプロファイルが覗けません。セーフモードで覗こうとしてもダメ。

仕方ないのでAIST の KNOPPIX を DL し、CD に焼いて起動ディスクを作成しました。
http://www.rcis.aist.go.jp/project/knoppix/
起動してみますと、ちゃんと中身が見えます。Linux ベースなので Win のアクセス権やパスは無関係です。逆にいえば、データを守るには暗号化して保存しておくしかないようですね。
しかし、AISTはなぜこのようなOSを開発しているのでしょう？緊急用でないことは確かでしょう。目的がよく分かりませんが、まあ、ありがたいです。

ということで、NTUSER 関連ファイルを入れ直し、ほぼ以前の状態に戻すことができました。