dynamicsoar's log

主に研究関係のメモ

Fortranで出力したデータを、call system() とシェルスクリプトを使ってその場ですぐに xz で圧縮し、元データは削除する

fortran programming linux

まえがき

前にも書いたかもだけど忘れそうなのでメモしとく。

まず Fortran 側で FV_00001.xyz, ...（グリッド）とか FV_00001.func, ...（流れ場）とか FV_00001.q, ...（時刻）といったファイルを出力している。これらは流れの可視化用のデータで、そのままだとでかい。計算機からローカルへの転送時間を短縮したいというのもあるけど、それ以上に、計算機自体の/homeディレクトリの節約のために、計算を続けながら、その場ですぐに圧縮したい。圧縮には xz を使ってるけど、お好みで gzip なり bzip2 なりにしてください。

前に書いた
システムコールとシェルスクリプトを利用して、Fortranのコードから「ディレクトリがなければ作る」を実行 - dynamicsoarの日記
と
natures flyers: Fortran で call system() するときに変数 (variable) を渡す方法
も参照。

注意点

Fotran 側でやるのは「シェルスクリプトのコール」までであって、圧縮作業は別のプロセス（ジョブ）になる。なので、特に OpenMP（というか並列計算）してるときは、圧縮のためにスレッドを使うので、ファイルサイズによっては流れ場計算の方が多少遅くなる可能性がある。なので、/home のサイズに余裕があるならこんなことしないで、計算終わってから一気に圧縮した方が流れ場計算は速い気がする（計算が全部終わってから、全部のファイルを圧縮するスクリプトをコールすればよい）。

Fortran側のコード

変数の意味

n_file_FV
ファイルの番号（連番）で、保存するごとに増えてくやつ
if_compress_FV_grid, if_compress_FV_flow, if_compress_FV_q
いずれも設定ファイルから読み込むパラメタ (integer) で、0, 1, 2 のいずれかを取る。意味は、0=圧縮しない, 1=圧縮してオリジナルデータは残す, 2=圧縮してオリジナルデータは削除。本来の目的からいって、僕は基本的には 2 を使ってるけど、グリッドの位置調整とかには 0 が便利だし、容量節約よりも計算機上での可視化＆後でのデータ転送高速化を目的として 1 を使うこともある。

グリッド保存用サブルーチン

  !! ファイル名（パスを含む）を設定
  write(out_grid,"('./output/FV_grid/FV_',i5.5,'.xyz')") n_file_FV
  ＜実際の出力作業は省略＞

  !! 圧縮
  write(command,"('sh ./src/compress_output_file.sh ',i1,1x,'grid',1x,i5.5)") if_compress_FV_grid, n_file_FV
  call system(command)

流れ場保存用サブルーチン

function ファイルなんだけど僕らは伝統的に q ファイルでなくこっちに流れ場を書いてるので。

  !! ファイル名（パスを含む）を設定
  write(out_func,"('./output/FV_func/FV_',i5.5,'.func')") n_file_FV
  ＜実際の出力作業は省略＞

  !! 圧縮
  write(command,"('sh ./src/compress_output_file.sh ',i1,1x,'func',1x,i5.5)") if_compress_FV_func, n_file_FV
  call system(command)

その他データ（自分の場合は時刻のみ）保存用サブルーチン

  !! ファイル名（パスを含む）を設定
  write(out_q,"('./output/FV_q/FV_',i5.5,'.q')") n_file_FV
  ＜実際の出力作業は省略＞

  !! 圧縮
  write(command,"('sh ./src/compress_output_file.sh ',i1,1x,'q',1x,i5.5)") if_compress_FV_q, n_file_FV
  call system(command)

いま考えたらこれら3つのサブルーチンはまとめるべきだな…ほとんど同じなんだから。まぁとりあえずこのまま書いておく。

シェルスクリプト側のコード

シェルスクリプト（bash以外は知らないが）ではイコールの前後に半角スペースを入れたらダメなので注意。参考：bashの変数代入の=の前後にスペースを入れてはいけない理由 - mollifier delta blog

compress_output_file.sh

これが Fortran の call system() で呼ばれる。引数を3つ取る。if_compress_FV_grid/func/q と、ファイルの種類と、n_file_FV の3つ。
そのまま functions.sh という別のファイルにある compress_output_file という関数に全部横流しする（だけ）。

#!/bin/bash

## 関数の読み込み
. ./src/functions.sh

compress_output_file $1 $2 $3

functions.sh

compress_output_file の部分のみ抜粋。他にもいろいろな関数をまとめておいている。

#!/bin/bash

#// if_compress: 0=no compress; 1=compress only; 2=compress & delete original file
#// kind: either one of: "grid", "func", or "q"
#// FVnum: FV number（Fortran側でいう n_file_FV）
#// option: xz のオプション。要は -k を使うかどうか
#//  参考： http://shellscript.sunone.me/case.html
compress_output_file()
{
  # 引数を変数にセット
  if_compress=$1
  kind=$2
  FVnum=$3
  
  ## if_compress に応じて、圧縮の際の option をセット
  case ${if_compress} in
    0 ) return ;; ## 何もしないで関数を抜ける
    1 ) option="-f -k" ;; ## 圧縮。元ファイルは残す
    2 ) option="-f" ;;   ## 圧縮 & 元ファイル削除
    * ) "Something's wrong. Check [compress_output_file] in ./src/functions.sh" ;; ## * は case default の意味
  esac
  
  ## ファイルの種類に応じた圧縮作業
  case ${kind} in
    "grid" )          xz ${option} ./output/FV_${kind}/FV_${FVnum}.xyz & ;; # {kind}はgridなんだけど拡張子はxyzなので場合分けしてる。
    "func" | "q" )    xz ${option} ./output/FV_${kind}/FV_${FVnum}.${kind} & ;; # | は or の意味
    * ) "Something's wrong. Check [compress_output_file] in ./src/functions.sh" ;;
  esac
}

「ハチドリは一秒間に80回も羽ばたく」は本当か → たぶん本当だけど一般的な速さではなく、上限付近

research bird biomechanics

ちょくちょく出典なしで出てくる表現なので、気になったので調べてる。まだ途中だけどたぶんいまメモっとかないと永遠に書かないので書いとく。

羽ばたき回数の計測例

自分の Mendeley に入ってた論文のうち、ハチドリの「ホバリング（前進速度0）」について軽く調べたところ、

  • 7種（6研究グループ程度）
  • 体重 3-5 g 程度
  • 翼長（片翼）50-70 mm程度
  • 羽ばたき周波数（1秒間の羽ばたき回数）は 30-50 Hz 程度

だった。ただし主に北米のハチドリ （ruby-throated, rufous, Anna's が多い）である点には注意が必要かもしれない。

References（順番はランダム）

  • Hedrick, T. L., Cheng, B., & Deng, X. (2009). Wingbeat Time and the Scaling of Passive Rotational Damping in Flapping Flight. Science, 324(5924), 252–255. 

    http://doi.org/10.1126/science.1168431

  • Altshuler, D. L., Quicazán-Rubio, E. M., Segre, P. S., & Middleton, K. M. (2012). Wingbeat kinematics and motor control of yaw turns in Anna’s hummingbirds (Calypte anna). Journal of Experimental Biology, 215(Pt 23), 4070–4084. 

    http://doi.org/10.1242/jeb.075044

  • Tobalske, B. W., Warrick, D. R., Clark, C. J., Powers, D. R., Hedrick, T. L., Hyder, G. A., & Biewener, A. A. (2007). Three-dimensional kinematics of hummingbird flight. Journal of Experimental Biology, 210, 2368–2382. 

    http://doi.org/10.1242/jeb.005686

  • Chai, P., & Dudley, R. (1995). Limits to vertebrate locomotor energetics suggested by hummingbirds hovering in heliox. Nature. 

    http://doi.org/10.1038/377722a0

  • Personal observation
  • あと他にも多少はありそうだけどあんまり違いが期待できないのでやめた

じゃあ 80 Hz って何よ

ググったところ、80 Hz というのはどうやら Greenewalt という有名なアマチュア研究者による Hummingbirds という本（1960 年）にあるらしく、これは最小のハチドリである bee hummingbird（Mellisuga helenae, マメハチドリ）についてらしい。残念ながらこの本はまだ読めてない。体重は 1.6-2 g とのこと（英語版 Wikipedia 情報）。

傾向として、体重が小さい（軽い）ほど周波数が大きいのはわかるし、翼長も短くなるのだから、80 Hz が異常に高速とは言えない。

というわけで、日本語版ウィキペディアの ハチドリ に今現在書いてあるように 80 Hzは「最大で」なのではないかというのが一応の結論。

ただ、既述したように今回調べられたのは北米の種が多くて、実際には南米の方が種としては（個体数も？）たくさんいることを考えると、「30-50 Hzが一般的」と言い切るにはまだ早いかもしれない。でも「80 Hz が一般的」というのはちょっと誤解に近いのではないかと。まぁ30 Hzでも肉眼で動きは見えないけどね…

200 Hz !?

あと、Handbook of the Birds of the World - Volume 5 という本には 200 Hz という記述があるらしい。しかも、 bee hummingbird ではなく北米でよく研究されているはずの rufous hummingbird（ふつうの論文は 40 Hz程度）でそれとか…ちょっと信じがたい。

というか200 Hzってハチ（ミツバチが190-230 Hz程度）とかハエ（ショウジョウバエで220 Hz程度）の領域で、筋肉の出力の限界から厳しいのでは？という気がする。少なくとも継続的には。翼端の平均速度は周波数に比例して、抗力が速度の2乗に比例するから、80 Hz の時に比べても抗力が4倍以上にもなるわけだ。更にパワー（仕事率）は速度の3乗に比例…。しかもおそらく rufous の方が bee より翼が多少は長いし重いはずで…。うーん……。一瞬なら出せるのかなぁ…？

余談：翼端速度は音速より十分小さい

なお、

  • 翼長（片翼） 50 mm
  • 羽ばたき振幅 140 deg（やや控えめ。max は 180 度超える）
  • 羽ばたき周波数 200 Hz

の場合でも、羽ばたき運動にサイン波を仮定すると翼端の速度は平均で 50 m/s 程度、最大の瞬間でも 80 m/s 程度なので、音速よりは十分に小さく（海面上標準大気くらいの状況で、それぞれ M = 0.14, 0.24 程度）、圧縮性の影響は考慮しなくて良さそう。アンデスの高地だと音速ちょっと低いけどまぁ大丈夫でしょう…。

ホバリングできる羽ばたき周波数の下限は？

じゃあ逆に一番ゆっくり羽ばたいてホバリングできるのは？というのが気になるところ。最大のハチドリである giant hummingbird（Patagona gigas, オオハチドリ）は 15 Hz とのこと（英語版 Wikipedia 経由だけど論文があった→ http://dx.doi.org/10.1016/0010-406X(67)90342-8 ）。

これが下限なのかはハッキリわからないけど、たとえばトンボで 35 Hz程度、スズメガが25 Hz程度、チョウ*1で10-15 Hz程度（いずれも種によって違うが）、ということですでにこれらよりも低い。体重も 19.1 g とツバメくらいある。とんでもねーな。研究してみたい感はあるけど南米行かなきゃか。

 

*1:butterfly frequency で google scholar すると人間の遊泳ばっかりヒットした… "stroke frequency" でもダメ（←これたぶん両者とも困る）。"wingbeat freqeuency" ならいける。

Win 7 (Enterprise) が夜中に勝手にリスタートされてた → Group Policy で No auto-restart を Enabled してみた

troubleshooting windows

今回だけならいいのだが、最近どうも頻繁すぎて、毎回フォルダとかアプリを色々立ち上げ直しになるので、困る。普段は Windows+L で画面ロックだけして帰宅するので。

 

環境は、Windows 7 Enterprise 64 bit.

 

まず Event Viewer で Windows Logs > System 内を見たところ、

Level: Information

Date: 今日の朝ごろ

Source: USER32

Event ID: 1074

Task Category: None

として、

The process C:\windows\system32\svchost.exe (myPC) has initiated the restart of computer myPC on behalf of user NT AUTHORITY\SYSTEM for the following reason: Operating System: Recovery (Planned)
Reason Code: 0x80020002
Shutdown Type: restart
Comment:  

 というのがあった。これでググると、

www.windows-noob.com

てのが見つかった。エラーではないので止められるということか。ほんとにこれで直るかわからんけどやってみるか。しかし Group Policy というのが admin でないと見ることしかできない。場所がわからん。

Control Panel\All Control Panel Items\Administrative Tools

にもエイリアスないし。ちょっとググったら、

C:\windows\SysWOW64\gpedit.msc

というのが本体と判明。これを右クリックから Run as admin して実行。あとはリンク先の画像の通り、

Computer Configuration > Administrative Templates > Windows Components > Windows Update

と下って行き、

No auto-restart with logged on users for scheduled automatic updates installations

をダブルクリック、左上の方にあるラジオボタンを Enabled に変えた。これで解決するといいんだが。まぁといってもたまには再起動しないとまずいんだけども。

 

ところでこれとは別に、ロック画面で放置してたらスリープ→復帰→スリープってのを30分ごとくらいに繰り返していて、不穏だったのだが、Event Viewer で見たらどうも Ethernet が起こしてるようだ。うーむ。ていうか電源の設定で Never sleep に設定した気がしてたんだがなぁ…これもなんとかした方がいいか…

 

resync Photo Stream on iPhoto (9.5.1) @ Mac OS X Mavericks

apple troubleshooting

また iCloud の話。どうも iCloud ってのはなんかこう、dropbox や sugarsync に比べて同期で苦労することが多い気がするんだがなんとかならないのか。

症状

iPhone/iPad で撮った写真のうち、ランダムに（？）数枚が mac の iPhoto 内の Photo Stream に同期されず、抜けている。

対処

もちろん iOS デバイスを Mac に直接つなげて取り込めばいいんだけど、それ以外の方法ということで下記に。具体的には、家族間で Photo Stream を共有してるとかそういう。古い写真（1ヶ月くらい？）は諦めるしか無さそうだが、直近の写真なら下記の方法でいちおう再同期できた。

  1. まず現状の Photo Stream の backup。Mac の iPhoto を開き、左のバーの SHARED > iCloud > My Photo Stream（他にもあるなら全て）で、Command-A で全選択。左のバーの上の方の Photos あたりに drop. まぁ定期的にやってることとは思うけど…
  2. iPhoto を閉じて、System Preferences > iCloud > Photos > Options... > My Photo Stream のチェックを外して OK. 「消えるよ？いいの？」って言ってくるので Turn Off iCloud Photos をクリック。これやると Photo Stream の写真が一度全部消える。
  3. すぐに System Preferences > iCloud > Photos > Options... > My Photo Stream のチェックを入れなおして OK. iPhoto を開くと再同期が始まる。なぜか 1,000 枚全部ではなくて 180 枚くらい（1ヶ月ちょいくらい）の分だけが DL された。よくわからん…

なんかもっといい方法あるのかもしれないけど、うまくググれなかったので…

 

iCloud sync between Clear for mac & for iPhone がやっとできた

mac apple software

Clear for mac が出てから、iCloud 経由での iPhone との同期 (iCloud sync) にずっと失敗していた*1。それが、さっきちょっと調べたらようやくできたのでメモしておく。

環境

手順

まず、自分の場合 iPhone: Settings > iCloud > Documents & Data > Use Cellular Data がオフになってたのが基本的な問題*2。

それから、

Clear OSX app : iCloud Error - Realmac Community Forums

の iTibz のコメントのとおりに wipe した。ただし実はこのコメントが言葉足らずで、iPhone 側での wipe 手順というか、Advanced mode の表示手順が書いていない。それは別の FAQ ページにある。

Troubleshooting iCloud Sync in Clear – Realmac Software

要は一番上のレイヤで「iPhone を2回シェイクする」と Advanced メニューが出てくる。

その他

  • wipe は iCloud 上のデータが消えるだけなので、少なくともその時点では Clear アプリ内のリストのデータは消えない。なので、iTibz のコメントにあるように、 wipe するときはそれぞれの Clear 内での iCloud sync トグルボタンを ON にした状態でないと意味が無い。ただ、デバイスの reboot 後にアプリで iCloud を sync したときにどうなるかは…たぶん消えないで同じ名前のリストがあったら単純に足し算になるのじゃないかと思うが、わからない。心配ならバックアップ取っておいた方がいい
  • 実は wipe する前に、上記 FAQ ページにある refresh だけを先にやってみたが、改善しなかった
  • iCloud > Documents & Data にある Clear のトグルボタンは ON のままにするのが正しいようだ。この設定は Mac と iPhone で別々なので両方確認すること。これらは、アプリ内での iCloud sync トグル（こっちは wipe すると自動的に OFF になる）とは別なので注意。このへんの複雑さのせいでみんな混乱してるんじゃないですかね…いや悪いのは Apple なのかもしれないけど
  • あといま気づいたけど、iPhone の Settings 直下にも Clear の設定があって、ここでも Use Cellular Data と Background App Refresh のトグルボタンがあるね…これらも当然 ON でないといけないはず（自分は ON だった）。やっぱりこれ複雑すぎでしょ…
  • iCloud Drive を既に使っている場合はまた別の注意点がある: http://help.realmacsoftware.com/hc/en-us/articles/200737812-FAQ-iOS-8-iCloud-Drive 要は mac が Yosemite じゃないとだめということかも。自分が Mavericks だし iCloud Drive 使ってないので検証してない

*1:iPod touch でできた事があった気もするが、iPhone 買ってから使わなくなったので無意味…

*2:昔の自分が電話代節約しようとしたんだろうな…

パンクチュエーションはググれなかった

essay

どうでもいいっちゃいい話だが、さっきふと、「昔のRPGでなんか『コマンド？』とかきいてくるやつあったなーなんだっけあれ」と思って「コマンド？」でググろうとしたが、できない。単に「コマンド」で検索されてしまう。

Punctuation, symbols & operators in search - Search Help

ここには

 >  Except for the examples below, most punctuation is ignored.

とあって、できないようだ。Google 以外は調べてないが、実質検索といえば google なわけで。あ、パンクチュエーションってのは句読点とか？とか！とか ” とかの記号のことね。

こんだけアイティーぎじゅつが進んだ2014年にもなってまだパンクチュエーション付き表現のウェブ検索すらできないなんて……意外だった。「C++」とか一部はできるみたいだけどさ。

自分の疑問は結局、適当にあたりをつけて「コマンド DQ1」で画像検索したら正解だったっぽい。まぁこんなのはどうでもいいんだが、もっと真面目な用途で検索に困っている人がきっといるはず、と思ったので。

「勝手に翻訳」ってどうなんだろ

essay

保護期間終了してたり、Public Domainだったり*1、CCなどでderivative OKなライセンスの場合はいいとしよう。そうでないコンテンツについて、勝手に翻訳して、ウェブに公表するという行為が、法的あるいはマナー的にどうなのか、前からちょっと気になってる。断っておくと自分は著作権法にはあまり詳しくないので見当違いかもしれない。

 

たぶん著作権法的には、国にもよるけど、グレーかアウトじゃないかな。ただ有料コンテンツじゃなければまず怒られることは無い、のだと思う。それとフェアユースとみなせる場合の翻訳がどうなるのかはよくわからない（参考）。ソフトウェアエンジニアのエッセイなんかは、商業誌でなくウェブに公表してあるものなら、たぶんフェアユース的な発想で翻訳しても大丈夫なんだろう。文化的にも。歌詞とか論文*2とか、本来有料なコンテンツの勝手翻訳は、ちょっとどうかなぁと思う。というか、いや、ダメでしょ。

 

どうも「勝手に翻訳」してる人たちって「みんなの役に立ってるんだからいいでしょ」感があるように思う。もっというと、「原著作者もオーディエンスが広まって嬉しいに違いない」みたいな発想もあるのではないか。たしかにそういう場合もあるだろうし、むしろ、そういう場合が多いかもしれない。だけど、ほんとうに原著作者に対する敬意があるなら、彼ら（あるいは著作権者）に確認・報告すべきじゃないか。最悪事後でもいいから。それをしり込みするってことは、やっぱりどこかに後ろめたさがあるんじゃないかな。

 

あとは「単純に英語の練習を兼ねてやってて、著作権とかそのへんはよくわかんないし全然考えてませんでした」というやつ。でもこのパタンは、大規模にはならないと思うんだよね。ブログのほとんど全エントリが翻訳記事、とかそういう規模になるころには嫌でも著作権とかその辺のことを考えるだろうと。考えてないとしたら、やっぱり「なんかやばいかも…」と思って調べるのを忌避してるってことじゃないかな。

 

あぁあともう一つ。ここまで「勝手翻訳」だと勝手に決めつけてきたけど、実はその翻訳が「勝手かどうか」って見た目じゃわからないんだよね。「これ、勝手に翻訳してます！」なんて書くわけ無いし（たまにあるけど…）。逆にちゃんと許可とってる場合でも、ふつうは元記事へリンクするくらいで、わざわざ「本人の許可とってます！！」なんて書かない。僕も書かないと思う。だけど、商業的にやってるならまぁ大丈夫なんだろうって思うけど、個人ブログなんかで見ると「これ、大丈夫？」って不安になる。どうしたらいいのか。たぶん、継続的に翻訳する場合（ブログに翻訳エントリが大量にある場合など）は、About 的なところに「このブログの翻訳エントリは著作権者に確認とってます」とか書いておくのがいいのかな。

 

 

*1:アメリカではPDでも日本では違う、とかはあるのかもだけど…。

*2:オープンアクセスでCCだったりするやつはどんどんやれってことなので違うと思うけど。