dynamicsoar's log

主に研究関係のメモ

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

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-なんとか、に変える。

読んだ本の感想：『植物の形には意味がある』

book biomechanics

本の情報

全体を通しての感想

縦書きソフトカヴァの一般向け図書。「ティンバーゲンの4つのなぜ (ja.wikipedia)」でいうと、主に植物の形状がもつ機能的意義、つまり究極要因にまつわる話だ。必然的に、メカニズム（至近要因）についての話や進化の話もある。僕が苦手とする、どの蛋白がどうなって、とかどの遺伝子が発現して、みたいな ontogeny（発生）の話は少ない。ガチガチの植物バイオメカニクスではないが、バイオメカニクスにちょっとだけ踏み込んだような内容。専門用語は少ないか、あってもかならずフォローされていて、非常に読みやすい。なお、こういう形態と機能の話はマクロ生物学（少なくとも動物学）の人々の間では form & function とか functional morphology などと呼ばれるようだ。

著者の専門は光合成のようで、力学的な話は誤解と思われる内容や、推測もちらほら見られた。ただし全体としてはなっとくできた。また本書では随所で「〜はなぜあるのだろうか？」という疑問の提示の直後に空白とダイヤのマークが置かれていて、「自分で考えてみよう」と促している。その後に著者自身の考えが述べられるのだが、多くの場合に「こうである」ではなくて「こうかもしれない」とか「実はよくわからない/わかっていない」という open questions のかたちで終わっている。ある意味では投げっぱなしではあり、著者のリサーチ不足では？という面もあるが（もし著者が修士1年生だったらみんなそういうツッコミするのでは？）、これはこれで読者に考えさせるのでよいな、とも思う。少なくとも、「バイオメカニクスが専門ではないが植物の専門家ではある研究者」が常識的には知らないようなことである、ということがわかるだけでも価値のある情報だ。どうやら、力学的にはまだまだ調べられることは多いのだな、という印象。

そういえば、読んでいて思い出したのだが、僕が初めてバイオメカニクスに興味を持ったのも植物からで、『エンジニアから見た植物のしくみ』というブルーバックスを中学生か高校生の時に読んだのが最初だった。大学に入ってからはすっかり植物に対する興味は失っていたのだが、今になってみると、やっぱり面白そうだな、という感想を抱く。実は昆虫飛行、とくの翅の形状などのバイオメカニクス的な側面について1990年代に大きな貢献をした Roland Ennos という研究者が、その後で植物の力学にフィールドを移している（ようだ）： http://www2.hull.ac.uk/science/bbes/ourstaff/academicstaff/profrolandennos.aspx。 そしていまでは、僕自身も、植物バイオメカニクス関係の研究は将来やってみたいな、という思いが少し前からある（今すぐには難しいが）。

個別の点

以下では自分が疑問に思ったことなどを箇条書きで書いてみる*1。

  • page 66: 『植物にとっては、「暗闇」＝「土の中」』だというが、本当か？他の植生に覆われている可能性もあるのでは？もし、植物がこれらを識別できているのだとしたら、そのメカニズムはなんだろうか？
  • page 70あたり： なぜ、二酸化炭素は葉の表面から取り込むのだろう。管で輸送しない理由は？←というメモをしていたが、いま思うと、どちらかというと話が逆だ。「なぜ、二酸化炭素以外の物（要は水だ）を葉の表面から取り込まずに、根から取り込み、輸送するのか？」だ。結局、空気と水の比重の違いによって、空気は土よりも上、水は土よりも下になるから、というのが基本的な答えになるのだろうか？
  • page 118: 「タンポポも茎がほとんど見えません」とあるのだが、これは一体…？タンポポに茎はあるでしょ？？いまいちわからなかったのだが、どうやらロゼットと呼ばれるタイプの植物で、葉っぱが地面から出て（正確には地下茎から出る根出葉？）、それと茎の長さが同じくらいだから「遠くからは」見えづらい、ということだろうか。タンポポの茎はむしろ結構目立つと思っていたので、いまいちしっくりこないが…。
  • page 121からの「茎の高さは何によって決まるのか」の話。特に気になったのは高さの限界についての話。水を吸い上げるというという内部流れの話があり、これ自体は面白いのだが、それ以外の話がなかったのがとても残念。僕でなくても思いつくであろう「上空は地表よりも風が強いはずで、その影響は？」とか「上に行くほど軽くしたいところだと思うが、幹自体がテーパーかかるのか？それともテーパーにはせず枝の本数が減るだけなのか？種によって違うのか？」みたいな議論が、なかった。聴きたかった…。
  • page 222: タネをバネの力で弾き飛ばすタイプの植物（筆者は「カタパルト形式」と命名）について、『おそらくは、空気抵抗が少ないことが要求されるので、丸い種子になるはずです』とある。しかし、Reによって違うけれど、空気抵抗は丸よりも流れ方向に引き伸ばした形の方が小さい可能性がある。したがって、「種子の形にはそれほど多様性が生じないでしょう」という結論にも本当だろうか？という疑問が残った。直径を代表長さとしたReがとても小さくて (Re~1)、摩擦抗力に比べて圧力抗力が無視できるほど小さい、というのならわかるが、Re~100とかもっとあるのならば、そうとは言い切れないのではないだろうか。
  • page 234: 形ではなく、機能で収斂が起きているのだ、という話。とても面白い。同様の事例をもっと沢山知りたい。
  • page 244: サワグルミ。葉が風を利用して回転？これは知らなかった。
  • page 249: ヒマワリが太陽を追いかけて回転する意味について。→ ひまわりの屈光性について | みんなのひろば | 日本植物生理学会 などで、メカニズム（至近要因）についてはオーキシンがどうのこうの、とあるのだが、意外と（ググり方が悪くて）、機能的意義についてはよくわからなかった。やはり光合成速度と関係あるんじゃないの？という気がするんだけど違うのか…
  • page 252: 葉が南を向かない理由。そもそも、日本限定でいいのか？←とメモにあったが、おそらく南半球ではどうなのか、とか赤道直下ではどうなのか、というのを知りたかったのだと思う。

拡散と対流について

僕は構造力学には弱いので、「そんなものかぁ」と読めるのだが、流体力学はどちらかというと専門なので、記述がいちいち気になる。

二酸化炭素

光合成には光・水・二酸化炭素 (CO2) が必要、ということで何度かCO2の話が出てくる。が、ほとんど拡散のことしか書いていない。葉の内部での輸送ならそうなのだろう、という想像はつくのだが、まずここに関してやっぱり Reynolds 数みたいなもの（実際には別の無次元数かも）が欲しかった…。まぁたぶん一般書だから、この本としては無い方がいいという判断だろう。

風と蒸散

page 89 から、対流が出てくる。ここの論理展開がちょっと他の部分と比べるとちょっと（かなり）雑に感じられた。もっというと、自分がよくわかる部分について雑ということは、他の部分も雑なのでは？という不安が滲んでしまった。

まず p. 91 で「風の吹く方向と垂直に何か大きな平面体があると、風速はぐっと落ちます」とある。けれど、次の段落および図4.2 ではどう見ても風の吹く方向と 平行に 壁がある状況を考えている。まずここがよくわからない。後者、特に図4.2 は明らかに境界層の話をしている。また『当然ですが、空気が動かなくなった領域では拡散しか頼るものがありませんから』とあるが、当然ではない。いや、空気が本当に動かなければそうだが、まずそもそも「動かなくなる」というのが誇張だ。境界層はたしかに速度は小さいが葉の表面からわずかでも離れれば当然速度はゼロよりも大きい。さらに、境界層が層流でなく乱流であれば、拡散でしか物質輸送がなされないというのも事実ではない。つまり、ここでは境界層についてもっと踏み込んだ話を避けることはできないはずだ。ところが本文では以下のような論理展開がなされる：

  • 物体（葉）が大きいと『空気が動かない』ので、拡散でしか物質輸送がなされない
  • 『風速が大きければ大きいほど、物体の近くまで空気が撹拌』される
  • 『物体が大きければ大きいほど、空気が撹拌されない範囲が大きく』なる
  • したがって、葉の表面に『二酸化炭素が効率的に届くためには、風速が大きいか、葉が小さいか、少なくともどちらかが必要であることに』なる

実際には、境界層が乱流に遷移すれば平板（葉）に対する垂直方向の物質輸送は促進される。境界層が乱流に遷移するかどうかはサイズだけでは決まらないものの、仮にサイズだけでいえば、葉が大きい方が乱流に遷移しやすい。したがって『風が吹いていないときには、葉を小さくしないと二酸化炭素を取り込めない可能性がある』という結論は、早計で、境界層が層流か乱流に遷移するかどうかを検討した方がよい。

というか、こんなのはおそらく瑣末な事項…とも言いきれないが、もっと他に大きな問題があって、そもそも論として、風向きおよび葉の3次元形状の検討が決定的に不足していると思う。まず、「風と葉の平面が平行」という仮定にだいぶ無理があるのではないか。これは別に流体力学の専門家でもなんでもなくても思いつくことだろう。実際には、葉が平板の翼だとしたら、迎え角（風と葉のなす角）をだんだん大きくしていくと、どこかで流れが前縁（風が吹いてくる側のふち）から剥がれて（剥離して）、葉の上面には渦ができるはずだ。そのような状況ではたとえ境界層が乱流になっていなくても、物質輸送は促進されるはずだ。また、ここまでは葉が平板であるという仮定をしてきたが、実際には葉は平板ではなく、かつ、葉の周りのふちもギザギザしたりとさまざまな形をしている。したがって、たとえ迎え角が小さくて概ね平行のような流れがあったとしても、「ふち」で流れが乱されたり、剥がれたりして、やはり渦ができて、物質輸送が促進されることはありえるだろう。

というような議論がなされていなかったのが残念だった。もちろんこの本の全体を通して貫かれている注意深さをもって『自然環境を二酸化炭素と風速だけで考えるのは乱暴で、実際には、光の明るさや温度などの要因も絡み合って、葉の大きさの多様性が生み出されているのでしょう』とあって、こういうのはとてもよいと思うのだが。

一方で、そのあとの pp. 94-95 のコラムはとてもおもしろい。葉に当たった日光で葉の表面が暖められ、これによる上昇気流で二酸化炭素の輸送が促進されるのでは、というようなことが書かれている。要するに風がある時というここまでの話は強制対流だったが、自然対流もあるよね、ということだ（これらの用語が使われていないのが、一般向けだからなのか、著者が知らないからなのかはわからない。前者だとしたら、読者が further readings をできるように、使ったほうがよいと思うのだが…）。

おまけ

ところで、 p. 90 あたりで、水を下ではなく上から温めたらどうなるかという思考実験をしていて、表面付近で沸騰することで撹拌されるだろうという予想をしているが、実際には沸騰する前に表面張力駆動のマランゴニ対流が起きるのではないだろうか。加熱の程度によるのかもしれないが。

我々はいろいろな性能を比較するとき、何を指標とすべきだろうか？*2

最後にちょっと抽象的な話。この本では光合成の効率を「単位面積あたりの光合成速度」あるいは「単位重量あたりの光合成速度」としている。そして「何で比較するか」には色々ありえるので、気をつけよう、というような姿勢が見られる。これには大いに同意する。

具体的に気になっている例がいくつかあるので挙げてみる。

たとえば、最近知った研究で「動物（アリとか魚とか）の活動の度合いを調べる」というようなものがある。この「活動の度合い」はどう定義するのが妥当だろうか？それがどうやら「ある距離を動いたこと」だとか「速度」とか「加速度」なんかで評価されていることがあるようなのだ。僕からすると、ある時間におけるエネルギ消費量か、エネルギを時間で割ったパワ（仕事率）で定義する方が適切であるように思える。あるいはせめて、質量（つまり個体による体重の違い）を考慮すべきではないのか？と思う*3。

類似した話として、ハトの飛行に関する研究で、帰巣する際に、「直線に近い方が性能がよい」という定義をしているものがあった。しかしこうしたルート選択の際にも、このように「かかる時間を減らす（平均速度を上げる）」という指標の他に、たとえば「消費エネルギを減らす」とか、「ある一定以上のパワを使わないようにする」というような視点などもありえるのではないか。あるいは、場合によってはこれは質量（体重）の違いが交絡となっている、という見方もできるのかもしれない。

そういえば、人に指摘しているだけではなくて、自分たちもよく、鳥の飛行において、横軸に「飛行速度」、縦軸にパワをとった「パワーカーブ」というものを描くのだが、これも体重あるいは翼面荷重で正規化する必要があるのではないのか？というのを思ったことがあり、同僚に話したのだが、「なるほど確かにそうかもしれんな」という反応だった（が、複雑になりすぎるためか一緒に書いている論文ではそういう処理はしていない）。これに関しては他の研究者の意見も聞いてみたいなぁ。

話を戻して、この本に関して言えば、著者はバイオメカニクスの専門家ではないため、ベネフィット/コストで評価するときのコストについて、力学からの視点がややピンぼけかなぁということがあったりする。残念ながら僕自身も材料力学・構造力学はあまり強くないので気持はよく分かるのだが…。

*1:それにしても、紙の本というのは、検索できないためいちいちページ数を書かなければいけなくて、とても不便だ。

*2:最近、森博嗣の小説を久々に読んでいたので、あまりにも森博嗣的なセクションタイトルになったことにはご理解をいただきたい。

*3:これは、アリの研究者には既にコメントとして伝えた。

論文の英文校閲サービスで直されたもの

writing research

初めて論文原稿の英文校閲サービスを使ってみた。このようなものが直されたよ、というのを共有するのはそれなりに有益と考えるので列挙してみる。

何か質問があればここか twitter の @dynamicsoar にきいてくれれば答えます。

前提

  • 英文校閲サービスは American Journal Experts というもの→ http://www.aje.com/
  • 対象は research article で、letter ではなく full paper.
  • 投稿先はイギリスの journal で、British English が preferred. したがって英文校閲サービスでも British English を選んだ。いま思うと、American Journal という名前についたサービスなのにこれは間違ってたのかもしれない。つまり、他に British の方が得意な業者（おそらくイギリスの）があったのかもしれない。
    • なお、このサービスの場合、料金と納期は words 数で変動し、かつ、納期は毎日変動していた。Standard と Premium を選べたが、予算の関係で時間がなかったため、Standard でかつ高速オプションを付けた。分量が多かった（11000 words程度）ため、6-7万円くらいだった。納期は通常で1週間程度、高速にしたら数日（今回は2日）。Elsevier の English Language Editing というのも金額的には似ていたようだった。
    • 修正対象はお金を追加で払えば増やせるが、今回は main text のみとし、journal のスタイルに合わせる修正も依頼しなかった。ファイルとしては、急いでいたので、図などを全部コメントアウトした .tex のソースと、参考のために図なども入った PDF をアップロードした。
  • 分野は工学と生物学の学際領域（バイオメカニクス）なのだけれど、いちおう biology の bioenginnering だったか biotechnology だったかを選んだ。

修正箇所のパタン

直された箇所は4パタン程度にカテゴライズできると思われる。つまり、

  1. 英文法のミスや typo (e.g. a/the/plural, do/does)
  2. 文法というより意味的におかしい点
  3. American English としてはよいが、British English としてはおかしい点 (e.g. minimize –> minimise)
  4. 口語的に過ぎて、academic writing に適していない点 (e.g. but –> however, around –> approximately)

ということ。ただし、今回のサービスでは、単に直された原稿のみが返されて、それとは別のコメントというものはなかった（おそらく別料金）。したがって、直された箇所それぞれが、上記のうちのどれだったのかは正確にはわからないことが多かった。

具体例

単語・熟語

順番は適当。

  • a/the/複数形の修正（死ぬほどたくさん直されていた。勉強になった）
  • figure 3A, C –> figures 3A, C（subfigure を指すときに複数形が正しいことがわかった。しかし、figures 3A, 3C とどちらが（あるいはどちらも）正しいのかはわからない。直されなかったので今のがダメではないのだろうが…）
  • minimize –> minimise（僕が British にし忘れてた）
  • especially –> particularly（British?）
  • merely, solely –> only（British?）
  • though –> although（British? though の方が British だと思ってたんだけど…）
  • but –> however（口語）
  • around, roughly –> approximately（口語。roughly は一箇所残ってたが、around は一括置換されたかもというほど全部直されていた。相当嫌われるのか？）
  • usually –> typically, generally（口語）
  • sometimes –> occasionally（口語）
  • much, a lot [of] –> considerably（口語）
  • see, find –> observe（口語。find の方は全部ではないが see はおそらく全部直されていた）
  • whole –> entire/entirely（口語？）
  • so that –> such that（口語？）
  • in general –> generally（理由よくわからず。全部ではないが、添削し忘れかも）
  • while –> whereas（理由よくわからず。全部ではない。添削し忘れではなさそうなので違いがあるのかも）
  • wingbeat cycle averaged force –> wingbeat cycle average force（「羽ばたき1周期で平均した力」の意味で、受け身っぽく ed 付けたらよくね？と思ってたが間違いだった）

接続詞の that は省略しない

修正頻度はこれが一番多かったかもしれない。直す方も精神的に辛かったのでは（いや、仕事か）。どうやら僕は癖なのかほとんどすべての接続詞の that を省略していたようで、それらが全て追加されていた。

therefore/thus の前後でのカンマとセミコロンの使い方

たとえば

A is defined as foo, therefore B can be written as bar.

のように書いていた部分が、次のようにセミコロンを使って直されていた。

A is defined as foo; therefore, B can be written as bar.

therefore のところが thus でも同様だった*1。

while/whereas の前には必ずカンマを入れるようだ

これはそのまま。おそらく全部直されていた。

ハイフンの使い方

非常に多くの語のハイフネーションが解除されていた。最初は「なんだよ、これがこの分野の慣習なんだよ」くらいに思っていたのだが、あまりにも何度も直されているのでパタンがわかった。どうやら、名詞を単に2つつなげるだけならハイフネーションしてはいけないようだ。じゃあどういうときにいいのかというと、その2つ（以上の）つなげた名詞を、さらに別の名詞に対する形容詞的に使いたい時だ。

実は考えてみると、これは思い当たる節があった。飛行機などの翼で、飛行方向側の縁（ふち）を「前縁（ぜんえん）」と呼ぶ。英語では leading edge だ。ところが「前縁の近くにできる渦」を意味する「前縁渦」は leading-edge vortex と書かれる。このことは知っていたのだが、これが一般的なルールだと気づいていなかった。ん？そういえば “15-year-old boy” とかなんとか、文法の授業でやったか…？あのへん、正直に言って、興味なくて聞き流していたのだよな…。

よく見ると形容詞的用法でなくても mid-foobar というのだけは解除されていなかった。なるほど、これは mid foobar にはできないもんな。なるほど…

キャピタルレターの使い方

固有名詞扱いにしたくて、わざと頭文字を大文字にしていたものが全て解除されていた。これについては反映するか無視するかを考え中。

そのほか

  • 現在進行形・過去進行形 –> 現在形・過去形（結構たくさん直されていた）

*1:この2者の使い分けをハッキリわかっていないが、それはまた別の問題。

Changing the font sizes in ANSYS Fluent (for high DPI display)

CFD troubleshooting windows software

Solution

Assuming the version is 17.2, navigate to:

C:\Program Files\ANSYS Inc\v172\fluent\fluent17.2.0\cortex\resources

and open cxdisplay.qss with a text editor (e.g. Atom, Notepad++, or whatever). You may need the Admin right (I did).

It seems this is CSS, so just modify the font sizes under “QWidget” and “QDockWidget#RibbonDockWidget QGroupBox” (I’m assuming the latter is for the ribbon menu but I don’t know for sure).

Specifically, change the numbers before the “px” in:

QWidget{
        font: normal 20px;
}

and

QDockWidget#RibbonDockWidget QGroupBox {
    font-size: 18px;
}

(Note I already changed them and forgot what were the original sizes. Probably 14 px and 13 px, respectively)

Background

I’m using high DPI displays on Windows 10. The scaling worked for the Workbench but not for Fluent, which made me so unhappy. I tried the .manifest thing in vain. So I tried searching the Fluent help app, which led me to the file cxdisplay.qss!

UPDATE 2017-03-27

I noticed this only works for Fluent. 200% display scaling worked for Workbench but instead it introduced another problem in DesignModeler and Meshing, where the heights of the texts in menu bars are too small, i.e. only some top portion of the texts are visible in the menu bars. Maybe the real problem is not the font size but the height of each menu bar, which is apparently fixed and not scaled properly.

Unfortunately, I haven’t found the workaround for this. I could not find corresponding CSS yet. Therefore I am using 150% or 175% as a compromise. Another way is to go without the texts in menu bars and only the icons (except for the main menu bar). You can set this in the Workbench options. For this, from main menu in Workbench, Tool > Options > Appearance > uncheck “Text on Toolbars”. Tooltips are still available when you hover the mouse cursor on the buttons.

Hope ANSYS implement the support for the hi-DPI displays in the update…

日本語の説明（需要あるのか…？）

2Kだか4Kだかの高解像度ディスプレイで Fluent (17.2) を開くと文字が小さくて死ぬ。Workbench は Windows 10 のスケーリングでうまくいったのに Fluent はダメ。つらい。ググって出てくる .manifest ファイルとレジストリいじるやつをやってもダメだった。

ダメ元で Fluent 内のヘルプ検索したら「CSS いじれよ」みたいにあった。マジかよ…

C:\Program Files\ANSYS Inc\v172\fluent\fluent17.2.0\cortex\resources

にある cxdisplay.qss をテキストエディタで開いて（管理者権限必要かも）、

QWidget{
        font: normal 20px;
}

と

QDockWidget#RibbonDockWidget QGroupBox {
    font-size: 18px;
}

を好きなサイズに変えればよい（確か、もともとは 14 px と 13 px だった気がする）。

UPDATE 2017-05-09

I noticed that for workbench fonts to be enlarged you need to tick the “Disable display scaling on high DPI settings” for your launching shortcut icon of the workbench.

Workbench については、起動するためのショートカットアイコンを右クリックし、Properties > Compatibility の下の方、Settings 内の “Disable display scaling on high DPI settings” にチェックを入れることが必要だった。これは 18.0 をインストールしたときに気づいた。

オフラインで iTunes を起動して音楽を聴くと曲が変わるたびにポップアップ出て死ぬほどうざい→オンライン中に起動しておく

apple mac music troubleshooting software

タイトルの通り。一応環境： El Capitan, MBP 13-inch Late 2013.

https://discussions.apple.com/thread/7127579 ← ここで pranab127 氏が言っていたのがタイトルの workaround. オフライン状態でうっかり iTunes 閉じたり、mac を再起動したら詰むので、解決はしてない。2015 に出された報告なのに一切対処することなくどうでもいい UI いじりに精を出す Apple, 正直幻滅するわ…。まぁそれでも勝手に再起動する Windows 10 とかいうやつよりはマシか…。