dynamicsoar's log

主に研究関係のメモ

メモ：Fluent case & data files --> EnSight format --> read in ParaView

CFD software troubleshooting ANSYS

前置き

ハマったところを中心にメモ。

状況としては、既に結果ファイルの cas & dat （時系列データ）があるが ParaView で開きたい、そしてどうやら EnSight 形式じゃないとまともに読めないっぽい、なんとかしたい、という感じ。

環境

  • Windows 10, 64 bit
  • Fluent 18.1
  • ParaView 5.4.0-RC2 64bit

手順

Fluent データの下準備

準備が必要。まず、gzip 圧縮されたデータファイルはなぜか変換してくれないので、全部解凍しておく必要がある。面倒だが仕方がない。次に、ファイル名について、詳しくはマニュアル（https://www.sharcnet.ca/Software/Ansys/16.2.3/en-us/help/flu_ug/flu_ug_file_export_esight.html でも多分大丈夫）を読めばいいのだが、簡単に書いておく。

「メッシュの変形や移動がなく、case ファイルが一つだけの場合」を考える。このとき、case ファイルは[一つ目の data ファイルと同じ名前].cas」にしておく。具体例をあげると、

  • test-001.cas
  • test-001.dat
  • test-002.dat
  • test-003.dat
  • test-004.dat

という感じにリネームしておくとTUI上での作業が楽。

Fluent 上

まず適当な workbench（新規でもいい）を開いて、新たに fluent モジュールを適当なところにおいて、Solution の方をダブルクリックして起動。というか直接 fluent 起動してもいいのかな。おそらくここで、たぶん case ファイルを読み込んだほうがいいが、読み込まなくてもなんとかなった。まぁどうせコマンド入力してる途中で読むんだけど。

TUIウィンドウをクリックしてコマンド入力モードに移る。

ここでまずつまずいたのだが、実はこいつ、pwd で現在のディレクトリ確認できる。すると、なんか変なところにいるはず（いつもの作業フォルダの dp0/FLU みたいなとこね。WBで確認できる場所）。じゃあ pwd ができるんなら cd もできるよね、とやるとできなくて死にたくなる。 Change current working directory with a text command? -- CFD Online Discussion Forums によると正しいコマンドは sync-chdir [path] だという。知るかよ…。とにかくそれで所望のファイルがあるディレクトリへ移動する。

あとは https://www.sharcnet.ca/Software/Ansys/16.2.3/en-us/help/flu_ug/flu_ug_file_export_esight.html などにあるとおりに、コマンドを入力していけばよい。

具体的には、まず

file/transient-export/ensight-gold-from-existing-files

を入力する。すると、色々ときかれるので答えていく。

たとえば以下のようにする：

  • EnSight Case Gold file name test_ensight
  • Case / Data file selection by base name? [yes]
  • Case / Data file base name test
  • Specify Skip Value [0]（黙ってEnter）
  • Cell-Centered? [no]（黙ってEnter）
  • Write separate file for each time step for each variable? [no]（黙ってEnter）
  • Write in binary format? [yes]（黙ってEnter）
  • Specify Data File Frequency [1]（黙ってEnter）
  • Separate case file for each time step? [yes] no（今は case ファイルが１つしか無いので）
  • Read the case file? [yes]（黙ってEnter）
  • Case file name ["test-0-001.cas"] test-001.cas（違うファイル名をサジェストされたので変更）

ここで一度ケースファイルが読まれて、グリッドが読まれる。

  • cell zone id/name(1) [*]（黙ってEnter...よくわからんけど行けた）
  • cell zone id/name(2) [()] （黙ってEnter...よくわからんけど行けた）

  • Interior Zone Surfaces(1) [()] （黙ってEnter...よくわからんけど行けた）

  • Select the variables to be exported

  • EnSight Case Gold scalar(1) else q to continue>

これは「どの変数を export するか」ということ。何も書かずに Enter したらリストが出るのでそこから選ぶ。pressure とか x-velocity, y-velocity, z-velocity とかすればいいんじゃないかな。選択が終わったら q と書いて Enter すれば変換が始まる。

UPDATE 2018-01-05

TUI を使う処理は journal file で自動化できるはず。あとでやってみるかも。

ParaView

出てきたファイルのうち、.encas というのが ParaView で読むべきケースファイル、なのだが、このままでは ParaView の reader が認識しないので、拡張子を .cas に変える。実は、いちおう、選択肢の一番下にある All files を表示させ、.encas を開いてから、reader として EnSight を選べば同じことはできるが、単に時間がかかるので、もう変えちゃったほうが早いと思う。

ParaView で開いたら、そのままでは流体領域が全部見えていて（というか外側境界だけ見えているはず）全然使えないので、 Recovering Fluent surfaces in ParaView -- CFD Online Discussion Forums にあるとおり、Extract Block フィルタをかましてやると、Multi-block Dataset という認識になって、壁面とかを選択できるようになる。

Docker で jupyter notebook から Caffe を試した

mac programming python software research

前提

Caffe を試したくなったが環境構築に苦労したのでメモ。

なので CPU モードしか試していない。

最初はふつうにビルドしようとしたのだが、依存関係が多すぎたり、python 2 なのか 3 なのか OpenCV も 3 なのかなんなのか、conda がいいのか悪いのか、などなど色々と困って、Makefile.config を何度書き換えても失敗し、しんどくなったので、Docker を試してみた。自分は Docker も機械学習も全くの素人でこれが初めての試み。

手順

まず Docker for Mac をふつうにダウンロードしてきてGUIでインストール。起動。

次に、jupyter と Caffe などの色々なパッケージが入った Docker 用イメージファイルを公開してくれている人がいた ( https://github.com/floydhub/dl-docker ) ので、

$ git clone https://github.com/floydhub/dl-docker

としてダウンロード。

しかしこのあとマニュアルにあるとおりのコマンドで jupyter を起動すると kernel が起動しなかった。対処法は、フォーラムにあるものを微妙に改変して、

$ docker run -it -p 8888:8888 -p 6006:6006 floydhub/dl-docker:cpu sh -c 'jupyter notebook --ip=0.0.0.0 --no-browser'

でいけた（フォーラムのコマンドは floydhub/ がない）。

これで docker 内の仮想マシンみたいなものに入るので、その中の /opt/caffe/example （だったかな？）へ辿っていき、そこにあるサンプルの notebook を開いていつものように実行する。というところまでやった。

チュートリアルの0番と1番は、GPUのところをちょこっとCPUに書き換えたら問題なし。具体的には、

caffe.set_device(0)
caffe.set_mode_gpu()

というところが何箇所か出てくるので、これら2行をコメントアウトし、

caffe.set_mode_cpu()

に変える。

しかしチュートリアルの2番は画像をDLした後あたりでクラッシュする…。これはまだ解決していない。

参考

今回使わせてもらった Docker は、

Installing all the deep learning frameworks to coexist and function correctly is an exercise in dependency hell.

とあるので複数の deep learning フレームワーク環境を共存させるのが大変、というモチベーションだったようだ。

読んだ：A general scaling law reveals why the largest animals are not the fastest

journal club biomechanics swimming flight

論文の情報

前書き

僕は動物の飛行の力学（主に流体力学）が専門で、最近は遊泳にも手を出し始めた程度で、歩行・走行は専門ではない。

統計については、最近ようやく勉強を始めたところだけれども、全くの素人であり、この論文の統計手法に関する評価をすることはできない*1。

それから、筋肉の話がでてくるけど、生理学についても素人なので、以下では正確性を欠く記述をしている可能性がある。

内容まとめ

概要

いろいろな動物について、水平移動の最大ダッシュ速度（≠巡航速度）を縦軸、体重（質量）を横軸にとった散布図を描く。そうすると、だいたい、小さいほど遅くて、大きいほど速い傾向がある*2。この傾向を、うまく表すような、シンプルな曲線（を表す数式）は、従来の理論では、power law（べき乗則？）といって、「大きければ大きいほど速い」ような数式が提案されていたようだ (第1式; Bejan & Marden, 2006, J. Exp. Biol., 未読)。本研究では、よりよいフィッティングとして、「最大の動物よりもちょっと小さいあたりの動物が一番速い」ような、形としては ∩ のようになる曲線（を表す数式）を提案している。実際に、複数のモデルを比較したところ、提案している新しいモデルが一番よいフィットになった。また、歩行・遊泳・飛行という3つの運動（移動）方法の全てについてこのモデルはフィットした。さらに、いまの世の中にいる生物だけでなくて、化石になった生物、たとえば恐竜の速度をも予測できるはずだとしている。実例として、いくつかの恐竜について、形態学をもとにした推測値と、モデルによる推測値がわりとよく合っていることを確認している。

もうちょっと踏み込んだ内容

当然だけど以下は僕の理解。生理学的な部分などで間違いがあるかもしれない。

速度に「小さいほど遅くて、大きいほど速い傾向」があるのはなぜだろうか。この論文では以下のように説明してる。運動には無酸素運動 (anaerobic) と有酸素運動 (aerobic) の2種類があり、それぞれ筋肉の速筋と遅筋に対応している。速筋は素早い運動を可能にするけれど継続時間が短い；遅筋は逆に遅いけれど継続時間が長い。いま注目しているのはダッシュ速度なので、無酸素運動・速筋が関係していそうだ。ポイントは、速筋は継続時間が短いということ。この影響を考慮したのが今回提案するモデル。

要点は Figure 1 にまとめられている*3。これは上段の左右 (a, b) と下段の左右 (c, d) がペアになっている。まず、上段は（従来の）理論的な予測で「無限に加速できるとしたら、速度は体重の順番になる」ということ。ここでもう一つのポイントは、最大速度に到達するのは体重が大きいほど遅いという点。これは一種の2乗3乗則ということでいいのだと思う。力は筋肉の断面積つまり長さの2乗に比例するが、質量（体重）は3乗に比例する。したがって、加速度 = 力/質量 は長さの1乗に反比例する…つまり、大きいほど加速が遅い。まぁ、直感的にも、小型飛行機と大型ジェット機の離陸とか見てればわかるんじゃないかと思う。

ところが実際には、速筋が蓄えられるエネルギ (ATP) には限界があるので、有限の、けっこう短い時間しか加速することはできない。この影響を考慮すると、体重がとても大きな（重い）動物は、加速度が小さいために、速筋のエネルギを使い切った時点ではまだ十分に加速しきれていない、ということになるようだ（下段）。逆に、これはハッキリとは書いていないのだけれど、あまりにも小さい（軽い）動物だと、速筋のエネルギを使い切るよりも前に加速しきってしまうようだ。こうしたことから、結果として「実現できる最大ダッシュ速度」は、体重の順番にはならず、「ちょうど速筋のエネルギを使い切る頃に十分に加速しきる動物」すなわち「一番重いやつよりもちょっと軽いやつ」が最速、ということになる。

このように、提案している新モデルでは筋肉のことを考慮しているけれど、地面から受ける反力とか水流や風の影響は全く考慮していない。個人的にはこのあたりが気になるのだけれども。

手法

  • 文献を調査して、622データ（474種）の最大（ダッシュ）速度と質量の情報を取得。
  • 提案モデルを含む、複数のモデル（数式）をこの速度-質量の関係にフィッティング（Rを使用）。
  • フィット具合は Bayesian information criterion (BIC) で評価。
  • Residual variation analysis → ここは僕の知識不足でよくわからず。内温性・外温性の比較もやっている (figure 3) ようだがいまいちわからなかった。

感想

たまには時系列で感想を綴ってみるのもいいかもしれないと思うのでやってみる。

twitter で存在を知り、AFPBB のニュース記事を読み、論文のアブストと図をチラッと見た時点では「おっすごそうじゃん」という印象だった。「歩行・遊泳・飛行という複数の移動様式における最大速度」がひとつのモデル（数式群）で表現できるという売り込み。どうやら、筋肉の収縮かなにか、生理学的な発想がもとになっているようだ。「あぁ、そっち系なのかな。流体力学はどれくらい考慮されているのだろう？」僕は力学屋なので、このモデルというのが力学をどれほど考慮しているのか、あるいはデータに合うようにフィッティングしただけで力学的メカニズムは考慮していないのか、という点がまず気になる。歩行では地面との接触による地面反力 (ground reaction force, GRF) だけを考慮して流体力学的な考慮はしなくていいのかもしれないが、遊泳では水の抵抗（抗力）を受けるし、飛行では抵抗に加えて重力に対抗するだけの揚力を生み出す必要がある。そしてこれら流体力学的な力というものは、物体のサイズによって影響を受ける。そこでまず、論文本文をダウンロードして、いくつかのキーワード（やその断片）で全文を検索した。具体的には、drag（抗力）, lift（揚力）, force（力）, fluid（流体）, aero*4, hydro*5 あたりで検索した。すると force は多少ヒットするが3/5が muscle force であり、aero はヒットした9つ全てが aerobic か anaerobic, hydro は参照文献のタイトルで1ヒットのみ。よって「あぁ、やはり筋肉の生理学は考慮しているようだが、流体力学は考慮していないようだな」という事がわかった。この時点で熱狂は少し落ち着き、「うーん、深く読むのは後でいいかな」となった。僕が興味あるのは、流体力学的な考慮がなされたモデルだからだ。

ところがアブストをよく読むと、このモデルは「474種 (species)」ものデータで支持されているという。これがひっかかった。少なくとも飛行に関して、正確な最大速度というのはそんなに多くは計測されていないという印象が僕にはあった。「このうち飛行ってどれくらいあるんだろう？」という疑問がわいた。そこで、イントロダクションも結果もすっ飛ばして手法 (Methods) を見に行った。ここで最大速度は具体的には文献から “maximum speed”（最大速度）、“escape speed”（逃避速度）、“sprint speed”（スプリント速度…おそらく短距離ダッシュのことだろう）のキーワードで検索したとある。さらに以下の2つの速度を除外している：

  1. 垂直方向の速度。主に鳥の文献に多い。要は急降下で最速になるということだろう。重力加速度により速度を得てしまうが、これは今回のモデルに入っていないため除外するとのこと。
  2. 通常速度のうちの最大値。これは「including also dispersal and migration（分散や渡りを含む）」とあるので、要は、長時間に渡って維持が可能な最大巡航速度のことだろう。

本文をすっ飛ばしていたので、ここで初めて最大速度というものが実際には「水平方向の」「ダッシュ速度」だとわかった。前者はなんとなくそうかなと思っていたが、後者が意外で、僕はここを読むまでは maximum speed とは「最大の巡航速度」のことだと思っていた*6。

続けて、"622 data points for 474 species (see Supplementary Table 1 for an overview)" とある。どうやら本文中にはデータ数の内訳がなく、supplementary material を見ろということのようだ。

…なんか時系列で書くのに疲れてきたので、ここからはまた要点のみの記述にします…

出典について

本文中で使用されたデータセットの出典は supplementary information*7 に明記されている。しかし、

  • データ数の少なさ
  • 出典調査のずさんさ

の2つの問題があると思う。

追記：出典の表をPDFでのみ提供していることも大きな問題だわ…。CSVにすべきだ。

遊泳と飛行のデータ数

走行（歩行）に比べて遊泳と、とくに飛行のデータ数が少ない。具体的には、

  • 走行：458データ（節足動物50・鳥類3・哺乳類261・爬虫類144）
  • 遊泳：109データ（節足動物1・鳥類5・魚類81・哺乳類16・軟体動物5・爬虫類1）
  • 飛行：55データ（節足動物19・鳥類29・哺乳類9）

となっている (Supplementary Table 1)。統計学的にどうなのかはわからないけど、まぁ、当然、多いほうがよりよいフィッティングになるんだろうってことくらいは想像できる。

個別に見ると、たとえば遊泳する節足動物と爬虫類のデータが1ずつしかなくて、これらはモデル生成に使っていない、といったことも disputable かもしれない（ないものはないのでしょうがないが）。

出典調査のずさんさ

孫引きやひ孫引き（？）が多く、出典調査がずさんである（手間を惜しみすぎている）。したがって出典の信頼性に対する配慮が充分なされているかが疑わしい。

オンライン・ウェブページを出典とすること

出典 96 から 103 はオンラインのウェブサイトとウェブページである。基本事項として、ウェブページの情報は永続性に乏しく、ほとんどの場合は自らの研究ではなく他人の情報の転記や引用であり、査読を経てもいない。当然、扱いには注意が必要だ。

たとえば出典101は www.speedofanimals.com というサイトで、おおもとの出典はなんだろうと思うと、一番下の方に "Animal descriptions are from Wikipedia" と書いてある。英語版ウィキペディアは比較的出典がきちんと整備されている印象があるので、値としては間違っていないのかもしれない、と思いたくはなる。ところが、speedofanimals.com のリンク先URLは www.wikipedia.org とだけなっており、個別の動物についてのリンクではない。英語版であるという保証もない。いつ時点という情報もない。Wikipedia は誰でも書き換えられる wiki なので、「いつの時点の版（バージョン）」という「版指定」がないと、出典としての正確性が劣ることになる*8。

しかしそもそも、研究者として、ウィキペディアから転記したサイトをさらに孫引きするというのは正直にいって驚愕した。これはつまり、ウィキペディアにある情報を自分たちでチェックすることを怠り、このサイトに丸投げしているということだ。正しい態度は、ウィキペディアへは当然あたり、さらにそのウィキペディア記事が論拠としている原著論文へあたることだろう。こんなのは基本中の基本で、研究室なら学部生がゼミで指摘されるくらいのことではないだろうか。それを、データをフィッティングしている、データに強く依存した論文で、そのデータをきちんと遡っていない、なんていうのは、本当に、ちょっと、どういうことだ…。しかも、Nature 関連ジャーナルに載るような論文で*9。

「そうはいっても、そういう疑わしいデータは、450とかあるデータ点のうちの、ごくごくわずかなんでしょ？」と思うだろうから、速度だけについて、いくつあるかを数えてみた*10：

  • 走行：27/458 (5.9%). 内訳は、哺乳類23/261*11, 鳥類2/3, 爬虫類2/144.
  • 遊泳：17/109 (15.6%). 内訳は、鳥類3/5, 魚類9/81, 哺乳類4/16, 軟体動物1/5.
  • 飛行：10/55 (18.2%). 内訳は、全て鳥類10/29.

となっていた。特に飛行では20%近い。だから直ちにダメだというわけではないが、もともと少ないデータのうちの2割をきちんと原典まで遡って確認していない、というのは、信頼性を損ねる行為だと思う。

書籍を出典とすること

これ自体は批判されるような行為ではないのだけれど、やはり査読を経ていない（だろう）し、孫引きなので、もっと sharper な引用の仕方をして欲しいところだ。つまり、多くの本というのは自分で独自に計測したデータを載せることはなくて、さらなる出典があるだろうから、そちらの方を引用すべきではないか、ということ。たまにそうやって調べていると伝言ゲームの過程でデータの転記ミスに気づくこともあるし。

なお、飛行では10/55（節足動物2/19, 鳥類8/29）が出典11番の本に依存している (http://press.princeton.edu/titles/162.html)。出典11番のところには2015年発行とあるが、実際には初版1965年の本の復刻であり、データとしてはかなり古い。他の分野は知らないが、動物飛行のデータで1965年というのは、計測方法などの面から不安が残る。さらにこの本のタイトル "An Essay on" というのがまた不安を掻き立てるが、中身は確認していない。鳥類については、ウィキペディアとこの本とで18/29=62%のデータを占めることになるのだが、僕なら怖くて原典を徹底的に確認しないとフィッティングなんてする気になれない。

あとは書籍じゃなくて査読済み論文だけど孫引き、ってのもあって、それはさすがに（原典の年代や手法などを一度確認しておけば）いいかなぁ、と思います。走行の出典44番と80番がかなり多い模様。

twitter でのツッコミ

以下のようなツッコミが見られた（他にあったら追加するかも）。

ハヤブサ

うーむ。まぁニュース記事はしょせんニュースなので、「論文をよく読んでなかったんですねー」で終わるかもしれないけれど、ちょっとそれだけじゃないんだよなぁ…。このハヤブサの出典は AllAbout からの孫引き： www.allaboutbirds.org/guide/Peregrine_Falcon/lifehistory ←このページには出典が5つ挙げられていて、このどれかが原典だろうとは思うが…（そしてその本の中にまた本当に原典が…）。いやいや、待って待って、その前に、AllAbout には 110 km/h という数字はないぞ。引用すると、

reaching speeds up to 112 km/h (69 mph) in direct pursuit of prey

とある。これ自体がまずちょっと問題で、112 km/h = 約69.59 mph (miles per hour) または 69 mph = 約111.05 km/h だから、記述自体が不正確だ。ただ、いずれにしても 110 km/h にはならない。これが 110 km/h になった可能性は2つありそうで、ひとつは論文執筆者がアクセスした時点では 110 km/h と書かれていた可能性*12。もうひとつは、論文執筆者が勝手に1の位を丸めたか、69 * 1.6 = 110.4 -> 110 km/h というような雑な計算をしたか。なんにせよ、「雑だなぁ」という印象を受ける。

カジキ

これは気づいてなくて（遊泳ちゃんと追いかけてなかった）、「え！？桁違いじゃん」と思ったけど、これもまた孫引き問題でした。しかもけっこう根が深い。

  • 出典10番のその "Direct ... blue marlin" (Block et al., 1992, J. Exp. Biol.) は black marlin (Istiompax indica) = 130 km/h および blue marlin (Makaira nigricans) = 75 km/h の速度の出典として載っている。この論文はタイトルの通り blue marlin (Makaira nigricans) の計測をしている。そして指摘の通りこの論文における直接計測の最大は 8.1 km/h なのに、どうなっているのか。
  • 本文を「130」で検索すると Table 1 にある Walters (1962)。また、blue marlin の75 km/h は Walford (1937) とある。いずれも Estimate とある。実測値ではないようだ。しかし References を見ても Walters 1962 なんてものはない（たぶん載せ忘れ）。ググるしかない。こっからまた遡ります。
    • なお、この論文の本文で一番関連ありそうなところを抜き出すと、"The fact that they can strike a bait trolled at 800 cm s-1 leaves no doubt that they are capable of short bursts of high-speed swimming, but we saw no such rapid movements in 160 h of speed observations. High-speed swimming and agility must have a place in the repertoire of activities displayed by blue marlin but, during the summer near Hawaii, such behavior is rare. There were only infrequent 10 to 30 s bursts of speeds exceeding 200 cm s-1. Short periods of fast swimming are undoubtedly important for catching certain prey, and hence important in terms of survival, but the characteristic mode of swimming we observed for this species was quite slow." というわけで、800 cm s-1 (28.8 km/h) という値*13はあるものの、計測できたのは 200 cm s-1 程度だったということになっていて、どうも Walters らの estimation は怪しいのではという雰囲気…（ちゃんと読んでないので違うかも）。
  • おそらく Walters, 1962, Am. Zool. http://www.jstor.org/stable/3881203 がそれ。しかしこれもおおもとではない。 Nursall, 1962 が cite されている。しかも、"Nursall (this issue) questions the validity of the reported swimming speeds of 80 and 90 km/hr for tuna, 130 km/hr for marlin and swordfish and of 120 km/hr for sailfish" とある。Block et al., 1992 はこの記述を見ていたはずなのに、Nursall には言及すらしていない…。
  • Nursall, 1962 はこれ https://doi.org/10.1093/icb/2.2.127 *14 であり、ここには、barracuda（カマス）の計測値が異常ではないかという記述に続いて、"Also suspect then are unconfirmed figures for salmon (45 Km/hr = 28 mph), tuna (90 Km/hr = 56 mph) and martin and swordfish (130 Km/ hr = 81 mph) reported by Barsukov (1960)" とある。まだ遡るのか…。
  • ところが References を見ると、Barsukov, V. V. 1960. The speed of movement of fishes. [In Russian]; Priroda 3:103-104 とある。はい出ました、Russian. これはちょっと遡れないですね…。どうやらこれが原典っぽいけども。
  • というわけで、ようやく、この 130 km/h は "unconfirmed figures" である（っぽい）ことがわかりました。

えーっと、何の話だったっけ？あ、つまり 130 km/h が怪しい、と。たぶん 75 km/h も怪しい。そして今回の論文に戻って figure 2d を見ると、シルエットからしてもカジキっぽいやつがちょうどピーク付近にいる。フィッティングカーブの形に効いてるんじゃないの？という気がしてくる。遊泳も…大丈夫なのか…？

その他の感想

全体を通して

どうにも、全体を通しての僕の感想としては、「走行（歩行）だけにしとけばよかった（っぽい）のになぁ」ということになりそう。いや、走行もチェックしてないけども。そうとうに穿った見方をすると、「走行のデータから新モデルでーきたっと。でも『少なくとも哺乳類の少なくとも走行について成立する新モデルです』と言ってもなんかしょぼいし、ちょこちょこっと wikipedia とかオンラインサイトとかで飛行と遊泳のデータもサクッと集めてみるかー」→「おぉ、なんかよさげじゃん。すげぇ発見だよ！Nature（系列）だ！！」みたいな感じじゃないのかなぁ…って気もしてくる。うがちすぎかな。

ただ、流体力学的なものを入れたとしても、定量的に変わるだけで、定性的な曲線の形状自体はこんな感じなのかもしれない、とは思う。つまりフィッティングに使うパラメタが大きく変わるけど、一番の大枠は間違っていないのかもしれない。その「大枠」の提唱こそがすごく評価されることなのだ、そんな細かい出典のことやらなんやらにツッコんでいるからお前は万年ポスドクなのだ、とか言われたら死ぬ。

mechanistic ってなに？

これ連呼されてるんだけど、意味がよくわからなかった。Methods の Model fitting のところを読むと、どうやら「単なる数値へのフィッティングではなくて、生理学というメカニズムを考慮している」ということを言いたいようだ、たぶん（自信なし）。確かに、流体力学は考慮していないとしても、生理学は考慮しているのだから、一歩前進ということでいいのだろう。

恐竜

Table 1 と figure 4 がそれ。Figure 4 でグレーの円がモデル生成（フィッティング）に用いた現生動物のデータで、緑の塗りつぶし三角が別の人が計算した恐竜の速度と質量の関係（Table 5 でいう Morphological models の列の値）。出典は supplementary table 5 とその references にある3つの文献。これら恐竜の値は、今回新たに提案したモデル生成には使っていない、つまり独立に計算された値。その割にはずいぶんよく合ってるでしょ、ドヤ、ということ。一方、従来手法の power law を使うと、Table 1 の Power law の列にあるように、体重が小さいうちは Morphological models と合うけれど、体重の大きな種では全然合わない（過大に評価する）。なぜ figure 4 に power law の線を入れなかったのかはわからない。入れたほうがわかりやすいのに。両対数なので、要は右肩上がりの直線になるってことだろう。

*1:個々のデータ点の数値が公開されているので、統計の自習素材として使ってみるのはいいかもしれないなぁ…というのはちょっと思った。ただ、表がcsvとかではなくてPDFなのだよな…嫌がらせかよ… → あとで出典チェックする時にウンザリした…。

*2:速度を体長で正規化、とかは今は考えない。

*3:たぶんこの論文は open access (OA) じゃないと思うので、読めないって人も多いかもしれないけど、僕は非OA論文の図をネットにバシバシUPすることにはまだ抵抗があるので、図は載せません（おそらく多くの場合 fair use とみなされるのだろうという気はするが）。bioRxivにプレプリントがあるのでそちらをどうぞ→ https://doi.org/10.1101/095018 . パッと見で図はだいたい同じように見える。

*4:aerodynamics（空気力学）, aerodynamic force などにヒットする。

*5:hydrodynamics（水力学）, hydrodynamic force などにヒットする。

*6:僕だったら maximum dash speed とかなにか、定義を読まなくても maximum cruising speed とは明確に区別される用語を使ったかもしれない。

*7:紙の雑誌ではなくオンライン版のみに提供される付録という意味での Electronic Supplementary Material の頭文字から ESM とか呼ばれることもある。

*8:ある人が2071年に、2017年出版の論文の出典を確認しようとして、「ウィキペディアから」とだけ書かれていたらどう思うだろうか？「え、いつの情報だよこれ…」となるだろう。

*9:「査読者なにやってんの」というのはあるかもしれないが、基本的には supplementary material までは査読義務はないはずなので、責めるのは難しい（よくない）かもしれない。

*10:質量は速度に比べると計測が容易で、疑いの余地が相対的に小さいので、とりあえず置いておく。

*11:ただしこのサイトのデータのみに依存した種は5, 6程度で、それ以外は他の出典もある。

*12:AllAbout は wikiではないが、当然、記述は変わりうる。

*13:しかしこれも personal communication なのだが…。

*14:American Zoologist というジャーナルは2002年に名前が Integrative and Comparative Biology に変わっている。毎年1月に国際会議をアメリカのどこかで主催してるのがこの発行団体である Society for Integrative and Comparative Biology (SICB).

How to compile and load Fluent UDF on Linux

CFD linux programming troubleshooting

Corrections to the UDF manual (version 18.1)

Due to the following typographical errors, you cannot make the UDF. So you need to fix these:

  • Page 341-341: the path “path/ansys_inc/v181/fluent/fluent18.1.0/src/” is inccorect. In reality, it should be “path/ansys_inc/v181/fluent/fluent18.1.0/src/udf/”
  • Page 342: In procedure 5, the file of interest is NOT the makefile.udf2 but makefile.udf . -
  • AND rename the copied makefile.udf to makefile . The manual says Makefile but this doesn’t work.
  • Most importantly, it appears you need to copy the makefile into the each of the subdirectory under the architecture directory, e.g., /libudf/lnamd64/3ddp_host/ and /libudf/lnamd64/3ddp_node/ . This information is absent in the manual at all, which is really annoying. Could be environment dependent? but still…

Then, you should finally be able to do the

$ make "FLUENT_ARCH=lnamd64"

and finish compiling.

Prepare the case and data files

This step is important and should be done carefully. The general idea is to do minimum thing. Particularly, do not play with TUI before saving the case file, which could potentially harmful and might result in unexpected behaviour during the computation in the Linux server. In my case, I encountered a situation where the computation halts at the first dat file saving, which seemed to have been the result of changing the suffix or prefix for the auto-saved files (via TUI). When I discard the Fluent module in the Workbench and made a clean Fluent module, this problem disappeared. So be careful.

Unload the UDF

Don’t forget to “Unload” the UDF when you were checking e.g. the body motion in Windows' Fluent. For that, right-clicking the “User Defined Functions” (under the Tree view) and select “Manage…” then you will see the list of loaded UDFs.

Delete the Dynamic Mesh Zones

This may not be the mandatory (I haven’t checked yet) but probably preferable.

record (log) the actions for journal file

I recently found a very useful feature in Fluent, i.e. record (log) the journal actions. From the menu “File > Write > Start journal…” you can record the actions in a journal file.

Unfortunately, Fluent is not smart enough to convert the GUI actions to the TUI commands in the recorded journal file, i.e. they are simply “Click this button” “Click this tab” or such… So you must find the appropriate TUI commands by yourself… (sigh)

How to load the compiled files using a journal file?

Surprisingly, this fatal information is absent in the manual. The following command should work.

/define/user-defined/compiled-functions load "<NAME OF libudf DIRECTORY>"

How to enable Dynamic Mesh & Create Zone for rigid body motion using a journal file?

Note the following applies only for the dynamic mesh & rigid body motion.

For the simple dynamic mesh,

/define/dynamic-mesh/dynamic-mesh? yes no no no no

and for creating the dynamic zone for a simple rigid-body motion

/define/dynamic-mesh/zones/create <ZONE_NUMBER> rigid-body "<UDF_PROFILE>" no 0. 0. 0. 0. 0. 0. 0.

where you must specify the <ZONE_NUMBER> and <UDF_PROFILE>.

You can check the zone number in the Fluent’s Tree pane > Cell Zone Conditions.

And the udf profile is the one shown in the “Motion UDF/Profile” drop down list in the “Dynamic Mesh Zones” dialogue via GUI. (after loading the compiled UDF). It is something like “move_body::libudf” .

読んだ本：『すごい進化』

evolution book journal club

基本情報

General comments

進化の話、難しそうだなぁと思っていたがそんなことはなく、非常に読みやすかった。それになにより楽しく読めた。以下に感想・疑問点等を記す。

「適応度の最大化 == 生物の目的（という表現）」は揺るぎないのか？

まず適応度最大化を目的として設定（採用）します、というのはもっと explicit に書いておいて欲しかった。その上で、なぜそれを採用することが合理的なのか、というのを簡単にでも説明して欲しかった。

いまささっと読み返すと、p. 194 あたりに「暗黙の前提を疑う」というのがあって、内容に同意するかはともかく、うまい発想だなぁ、と思わされたのだけれど、だからこそ、根本であるっぽい「適応度の最大化」というあたりは陽に説明して欲しかったなぁ…。

あと、適応度という話がでてこなくて、記述上はどうも「個体数を最大化したいと思われます」みたいになっていたので、混乱したというのもある。

んー、でもまぁ、この本の scope ではないと言われればそれまでかな。ただここが明解でなかったので、読んでいる最中、ずーっと頭のなかにもやもや感が残っていた。

UPDATE 2017-06-22

これに関して、著者からコメントを頂いた（下記）

こうやって気軽に authors - readers がコミュニケートできるってのは本当にありがたい。

「制約」「適応」の定義とは？

この本は「一見すると制約に思えるような形質 (incl. 行動) でも、実は適応の考えで説明できるのではないか？」と知恵を絞って考えるというのが基本姿勢になっている。それ自体はとてもおもしろくて、「制約でしょ」とある意味で思考停止してしまわないことは大事だね、という教訓めいた読後感もある。

ただ…素人質問かつ根本的なことなんだけど、「制約」ってなんだ？？いや、なんとなくはわかるし、個別の例も理解はできるんだけど、定義がいまいちハッキリとわからなかった。同様のことが（対立する概念っぽい）「適応」の方にも言える。

あと、この二者って本当に対立する概念なのだろうか。なんか、観察者（我々）の見方によってどちらとも言えるのでは（どちらとも言える場合があるのでは）、という気がしたのだけれど、どうなんだろう。たとえば、p. 23の卵の数の例は、制約といってもいいし最適化といってもいいのでは？…と思ったら、p. 25では「突然変異がまだ起きてないこと」「祖先からの形質をまだ維持しているだけ」ことが制約だといっている。あれ、そうなん？つまり phylogenetic constraints のことだろうか。「水辺に住んでいたから」とかの環境も制約になるのではないかという気がするんだけど。

あと、上では便宜的な表現としての目的論てきな表現は別にいいでしょ、と言っといてなんだけど、なんかやっぱり「いやいや」というのはうーん…いや、まぁこれは感じ方の問題かもしれないから、いいか。

「性選択・性淘汰」という表現について

この本では「性選択」「性淘汰」という表現がたぶん一度も出てこない。それどころかハッキリと ornament も「自然淘汰」である、と書いてある。実は僕も性選択って自然選択のサブセットじゃないの？と思っていたので、「あ、やっぱりこういう考え方でいいのか」と思えて、それはよかったんだけども、やはり補足説明というか、スタンスの明示というか、何かしらの記述が欲しかった。

特に、ツバメの tail streamer のようにいわゆる自然選択と性選択の両方が働いているのではないか、という議論がずっとあるようなケースについても触れて欲しかったなぁ（←僕が詳しいということではなくむしろ逆）、というのは感じた。

Specific points

後半はメモをとらずに一気に読んでしまったので、コメントは前半に集中してしまった。

p. 13 カタツムリの巻き方について

左巻きのカタツムリは繁殖において不利だとしても

んー？左巻きの方が多い状況なら、それは不利ではないのでは。いや、当初島に渡ってきた個体群は全て右巻きだが、その後繁殖する過程で突然変異により左巻きの個体が複数現れる、ということか？むしろ天敵が乏しいなどの理由で左巻きでも交尾時間がかけられて不利でない、などの別の要因は？

→ これはあれか、フィールドの生物学『右利きのヘビ仮説』を読めってことか…

p. 14 イトヨの生息環境と体型について

湖に生息するタイプではより持続的に泳ぎ続けるのに適した細長い体型 川に生息するタイプでは瞬発力を発揮しやすいようなややずんぐりとした体型

という記述があった。だけど、これらはそんなに自明だろうか？というかまず、真なのだろうか。魚は不勉強で、僕は直感的にも論理的にもすぐにこれを判定できない。尾ビレだったら、マグロみたいに細長い方が誘導抗力が小さくて省エネで、コイのような団扇状の形状よりも高速遊泳に向いているというのは聞いたことがあるんだけど、横から見た時の体の形態（アスペクト比）についてもそういったものがあるのか。あるんだろうけど。

ただ…真であるとしたら、流体力学のことをあまり（ほとんど）知らない人でも直感的にそのように思うのであれば、それはどうしてなのだろう、というのもちょっと興味深い。

pp. 23, 25 制約について

Major comments を参照。

pp. 43-45 卵の形状について

とてもおもしろかった。のだが…卵がなぜそもそも球形なのか、という基本的なところの説明、および関連した掘り下げないのが残念だ。普通に考えると、構造的 and/or 熱的な理由で球形なのだろう。まぁその省略は別に（僕としては）いいのだが、ではそれの意味するところは、というさらなる思考が必然的になされるはずだ。

つまり、球形であることにはそもそも利点があるのだから、縦長化には限度があり、縦長化によって形態的制約は ある程度までは 緩和されうるものの、依然としてその制約は存在するし、不利な点も同時にあるかもしれない、と考えるべきではないか。

pp. 47-48 尾てい骨

形態ではなく、行動の側が淘汰されたのかもしれない、のでは？形態が淘汰された方が自明だ、というのがわからなかった。

もっというと、これって別に尾てい骨に限らず一般的な話ではないのか？

pp. 57-58 小さな卵を複数 vs. 大きな卵を少数

これだと逆に大きな卵がクリサキのように生き延びてる理由が不明。どんな利点がある？

→と思ったらちゃんと次の章でガッツリ解説していた。まさか章をまたいで伏線回収するとは思わなかった。

p. 92 捕まえやすさの計測方法

「捕まえやすさ」を捕まえた個数というインプットのみで計測すること。それにかかったエネルギや時間というコストも合わせて考えるべきかもしれない。

→これもあとで拾われていた。まぁむしろ生態学屋的には基本中の基本なのだろう、たぶん。

p. 94

生物の場合、基本的にはたくさんの子を残したいはずです

一番最初にも書いたんだけど、ここで僕は「そう？なんで？」と思ってしまった。たぶん単純な数ではなくて適応度のことを言ってるのかな、と勝手に脳内補完したけど、素人なので違うかもしれない。なのでやっぱりここはハッキリと書いておいて欲しかった（議論しておいて欲しかった）なと。

p. 122 雑種について

そもそも、雑種の何がいけないの？というか、雑種とは何？（自分で調べよう…）

p. 122 ハインリッヒの法則

ここでハインリッヒの法則を持ち出すのはちょっと脇が甘いというか、なぜその論理が使えるか、というのを飛ばしている。というか、たぶん使えるという根拠はないのでは？単に「似ている気がする」程度のことではないのかな？もしそうなら、それを生物の説明に援用するのは、発想としては全然いいのだけれど、論拠のような使い方をするのはちょっと危ないのではないかなと思った。

p. 144あたり、「オス殺しのバクテリア」について

ここの擬人化はちょっとやりすぎではないかなと感じた。オスに感染したバクテリアの個体群は子孫を残せないのだが、それはどう考えたらいいのだろう。血縁淘汰？

この辺で、進化の主体は誰だ？スコープは？「種」なのか？「個体」なのか？観察者の設定次第か？…みたいな疑問が湧いてきたようだ（メモにそうある）

p. 159 鳥の「羽」の話

ぼく「素人質問ですが…」

昆虫屋さんだからなのか、一般向けの本だからなのかわからないけど、「羽」は曖昧なのでやめた方がいいのでは…。一枚一枚の「羽根 feather」と、羽根や骨・筋肉等の集合体としての「翼 wing」は明確に区別して欲しいところ。まぁ、これは細かい表記の問題なのでよいとして、本題は以下。

本来、鳥の羽は効率よく飛び回るために機能しているはずです。季節の変わり目に何千キロメートルも飛ぶ渡り鳥と、花の蜜を吸うためにホバリングするハチドリとでは、羽に求められる性能は違うでしょうが、いずれにせよ飛ぶことを目的に羽を使っているのには違いありません。

と思うじゃん？ハチドリのうちの幾つかの種は北アメリカと南アメリカの間を渡るんだよなぁ…。

クジャクのオスのあまりにも長い羽は、飛ぶのにかえって邪魔になっています

[要出典]。…というのは半分冗談だけど、実はチョウの tail は飛行に役立っているかもしれないという研究もあったりするので（下記）、この辺も「自明でしょ？」と根拠なく断定するのは危険かもですよ、とは言っておかないといけない（いや、いけないってことはないんだけど）。

  • チョウの tail をなくすと揚力と縦安定が減少したという報告 http://dx.doi.org/10.1007/s11340-009-9330-x これと別に Physics of Fluids か Experiments in Fluids にも似たようなのがあったはずだけどちょっといま見つからない…
  • 関連して、ツバメの tail fork（切り込み）の深さは性選択ではなく空力性能による自然選択によるというような話（っぽい）→ http://dx.doi.org/10.1002/ece3.1949 およびこれが cite している論文。僕はまだ読み込めてない。

2倍のコスト関連

ここはすごくエキサイティングだったんだけど、どうにも疑ってしまう。確かに数理的には無性生殖に有性生殖が浸透していく、というのはスッキリとしていて「おぉ」なんだけど、なんかこう…ホントかなぁ？と。いや、たぶんこれは僕が疑うこと自体をとても楽しんでいる、というだけなんだろうけども。

で、一点気になったところは、「最初のオス」はどうやって誕生したの？ということ。「最初のオス達」かもしれない。オスが浸透していく説明にはなっていても、オスがなぜ最初に生まれたのかの説明はない。

あ、それからこれはまた別の話かもしれないけど、性が2つしかないのはなぜ？というのも。これはどこかで説明を見た気がするんだけど…なんだったかな？やっぱりコストだったかな。でも、本書に出てくる川津説だったら、たったの2でなくて種によっては3でも4でも「いやいや」なっちゃうんじゃないの？という気がするんだけどなぁ。まぁでも、コストが高すぎて2に落ち着くということなのかな。

p. 206 アブ

多くのアブはハチに模様や飛び方が似ています

純粋な疑問なんだけど、ここでいう飛び方ってなんのことだろう。

UPDATE 2017-06-22

ちょっとここ、前に書いたときは力尽きていたようだったので、補足。

昆虫飛行のバイオメカニクス業界（？）では、bumblebee（マルハナバチ）・honeybee（ミツバチ）・hoverfly（ハナアブ）というのは、モデル生物というほどではないかもしれないけど、そこそこよく扱われる種ではある。これらに共通するのは、羽ばたき周波数*1が高めであるということ。たとえば以下のようなデータがある：

これだけ高い周波数を出せるということは、いずれも非同期型の間接飛翔筋なのだろう。では他のハエはどうかというと、この業界でもやはりfurit fly（ショウジョウバエ）はモデル生物といっていいんじゃないかというくらいよく使われていて、羽ばたき周波数はだいたい 210-230 Hz 程度 (e.g., Fry et al., 2005)。他のハエは… blowfly（クロバエ？）が 145 Hz (Walker et al., 2013) というのがあった。

というわけで、何が言いたかったかというと、羽ばたき周波数は、特にハチを模倣していないであろうショウジョウバエでも似たようなものなので、これだけからは「（ハエたちの中でもアブだけが）ハチの飛び方を真似ている」とは言えない。なので、「羽ばたき周波数以外の他の要素（羽ばたき振幅・ストローク面角度・胴体角度・飛行速度・などなど）で、他のハエとは違って、特にアブがハチに似ているものがあるのだろうか？」ということをパッと思ったわけです。

ちなみに、他のモデル生物というか、よく使われる昆虫には hawkmoth（スズメガ）があり、こいつの羽ばたき周波数は 25 Hz くらいと遅い。これは同期型の間接飛翔筋だから、ということのよう（直接飛翔筋で有名なのはトンボ）。飛翔筋の直接・関節と同期・非同期の違いについては、昆虫飛行研究者 Andrew Mountcastle の個人ページが非常にわかりやすくてオススメ。

*1:1秒間あたりの羽ばたき回数。単位は Hz（ヘルツ）。

journal file を使った CUI での Fluent の実行について

CFD programming research software

前置き

マニュアルとしては、ANSYS Fluent Text Command List というものがある。あるが、辞書のようにコマンドが羅列されているだけで、実際の書き方がわからない。ひどいことに、Fluent の他のマニュアルを見てもごくごく簡単な例（単なる solve/iterate 100 みたいな）しかない。これはひどい。当然、ググりまくってちょっとずつ調べてみたりするしかない状況。しかしオンラインの情報もあまりない。自分用にメモすると同時に誰かの参考になればと思い、ここに記す。

基本的な事項

  • Fluent を開いたときに、右下の方に Console 画面というのがある。このウィンドウをマウスクリックしてキーボードで [Enter] すると、コマンド受付状態になる。実は Fluent のたぶんすべての操作はここから CUI で可能。というかむしろ、 GUI ではできない操作もある*1。この CUI 操作を羅列したスクリプトが journal file と呼ばれる。
  • たとえば、スパコンのようにジョブ管理ツールでジョブ投入するときは当然 GUI は使えないので、この journal file の利用が必須となる。
  • スクリプトなので、実態はただのテキストファイル。ファイル名はたぶんなんでもいい。
  • たとえば journal file を journal.jou というファイル名にした場合、呼び出し方は、コマンドラインから $ fluent 3ddp -g -i journal.jou のようにする。
  • Windows の場合、"C:\Users[ユーザ名]\AppData\Local\Temp\WorkbenchJournals" に実は普通に GUI 操作していたときの履歴が journal file として格納されている。じゃあこれを見れば参考になる！…と思うじゃん？実際には「GUI操作」が記録されていることが多すぎて、「ボタンクリック」とかそんなのがたくさんあって、非常にわかりづらい。おそらく参考になる部分はあるのだが、スパコンではGUIモードで起動してないので、コピペでは使えない。結局、マニュアルを見たりコンソールで調べたほうが早い。

Fluent のコンソールモードの使い方

  • なぜか Unix/Linux とは違って独特。やめてほしい…。
  • なにも入力せず [Enter] すると、今いる階層で可能なコマンドの一覧が表示される。これが ls 相当。
  • cd はない。コマンド一覧のうち、末尾にスラッシュ (/) が付いているものはディレクトリのようなものであり、さらに下の階層があるので、それを打ち込むと cd できる（スラッシュは不要）。末尾にスラッシュがないものは、コマンドそのものなので、打ち込むと実行されてしまうので注意。
    • 上の階層に戻る cd .. 相当のものは、 q とだけ打ち込めばよい。
  • マウスカーソルによる GUI 操作はいつでもできるので、コマンドモードは抜けなくてよい。exit と打ち込むと、Fluent が閉じてしまう。この仕様、かなりうざい。
  • tab 補完が効かなくてつらいが、コマンドは途中まで打ち込めば勝手に解釈してくれる。たとえば初期階層で solve でなく sol [Enter] で solve/ の階層に行ける。
    • 候補が複数あるときは、tab補完のように「どれ？」と親切にきいてはくれない。勝手にどれかが選ばれる。たとえば初期画面で d [Enter] すると、define/ ではなく display/ に移動する。謎だ。
  • ? [Enter] すると help-mode になって、入力したコマンドが実行される代わりにヘルプが表示される。あまりわかりやすくはないが、ないよりはマシか…。help-mode を抜けるのも、やはり q [Enter] でよい。

journal file の文法

  • コンソールでやったことの、ルートからコマンドまでをまとめて1行に書く。行頭のスラッシュはおそらくあってもなくてもよいと思われる。
  • 行のコメントアウトは行頭にセミコロンを置く。
  • 定常計算 (steady) は、 solve/iterate [iteration回数] でよい。
  • 非定常計算 (transient) は、 solve/dual-time-iterate [time steps] [iteration回数] とする（参考： https://www.cfd-online.com/Forums/fluent/70908-iterate-command-line.html）。
    • 信じがたいことだが、自分の調べた限りでは、この基本的で重要な情報が、マニュアルのどこにも載っていない。コマンド一覧には「dual-time-iterate は非定常計算に使います」とだけある。ハッキリ言ってこのマニュアル作ったやつは無能。
    • おそらく、solve/iterate [iteration回数] の次の行に solve/update-physical-time としてもよさそう。その場合、おそらく事前に solve/set/number-of-time-steps [time steps] コマンドで time step数の設定を先にしておく必要がありそう（未検証）。

具体的な手順

これが正しいという確証はないのだが、こんな感じでなんとか実行できている、という手順を示す。

ローカルでの準備

まずはローカルPCで Fluent の計算準備をする。Workbench からやっている場合は、Setup を開いて、色々な設定をして、流れ場の初期化 (initialization) もして、実行直前まで行く。この状態で case file を保存しておけば、あとはほとんど実行するだけ、のはず。

ところで、可視化などのために Run Calculation > Data File Quantities… で　Additional Quantities の Select All Shown は選択しておきたいところなのだが、「Data File Quantities… がグレーアウトしてクリックできない」という症状があると思う。これは、Intialization を先に一度しないとクリックできないようになっている、ようだ。

それから、普段、Fluent のケースファイルの実態がどこにあるかなんて気にしていないから見つからない、という事があるかもしれないので、念のためそれを説明する。ケースファイルは、[作業フォルダへのパス][プロジェクト名]_files\dp0\FLU-XXX あたりにあることが多い。より確実には、Workbench で Fluent の Setup を右クリック > Properties を開いて（右の方にペインが展開される）、Directory Name を確認するのがよい。Properties ペインは開きっぱなしにしておけば、右クリックでなく左クリックでよいので楽。

スパコン上での準備

case file名が test.cas, 時刻0でのデータファイル名が test-00000.dat だったとする。スパコン上の作業フォルダには、以下のものを入れておく。

なお、前までは .gz はダメだと思って手動で $ gzip -d していたが、さすがの Fluent も .gz のままで読み込めるようで、圧縮したままでよい。

シェルスクリプトで journal ファイルを呼び出し、そこからケースファイルとデータファイルを呼び出す。スパコン上で initialize するのなら、データファイルはいらないのかもしれないが、その場合上に示したように Data File Quantities も journal からセットしないとダメかも。

journal file の具体例

;; Read case file
file/read-case test.cas.gz
;
;; Read data file
file/read-data test-00000.dat.gz
;
;; Set dt (s) 不要かも。未検証
solve/set/time-step 0.001
;
;; Compute [time steps] [iteration steps]
solve/dual-time-iterate 2000 20
;
;; End
exit
y

*1:バージョンアップとともに減ってきてるかも。

atom のキーバインディングを Notepad++ (Npp) に近づける

programming software troubleshooting windows mac

前置き

Win と Mac でデフォルト自体が結構違うのでその都度どっちかを示していく方向で。適宜追加予定。

基本的な方法

Settings > Keybindings にある your keymap file という文字列をクリックすると keymap.cson というファイルが出てくるのでこれを編集する。文字列の書き方は、下の方にある適当な Keystroke の「クリップボードにコピー」アイコンをコピペすればなんとなくわかる。

move line up/down

Windows でのデフォルトは Ctrl-Up/-Down とシンプルなのだが、Npp で慣れ親しんでしまったので Ctrl-Shift-Up/-Down へと変更。

column select

column-select をインストールする。Win の場合、デフォルトのキーバインディングが Shift-Alt-なんとか、になってるので、Npp 風にするならこれを Ctrl-Shift-なんとか、に変える。