dynamicsoar's log

主に研究関係のメモ

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

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 とかいうやつよりはマシか…。

モモンガ (flying squirrel) の飛行に関する記事への感想

aerodynamics biomechanics research

ソースと概要

http://biographic.com/posts/sto/moonlight-gliders

ざっくり言うと、「モモンガの滑空ってあんまり制御してないっぽいイメージだったけど、すげーしてるよ！前縁フラップ・ウィングレット・VGが全部載せですごいし、さらに翼面を波打たせて揚抗比増大してるね、間違いない」という話。個人的には制御についてはまぁしてるでしょというイメージだったので、そこは「お、おう」感があって、後半では出典がまったくないのにどんどん novel mechanism 出ちゃうもんだから「えー…」ってなりますよね。なので通常ならスルーしたいところなんだけど、風洞実験してると言ってるし results は信じておく。ただし解釈には色々と疑問があって、簡単に言うと、「このひとが言う能動的な制御 (active control) のうち一部は本当は受動的な変形 (passive deformation) なのでは？」って感じですかね。ラボページみるとどうも遺伝とか神経・生理寄りっぽいので、もしかしたら in flight で EMG やっててガッチリ証拠掴んでるぜ、ってことなのかもしれないけども。でもそれだけでは流体構造連成の否定にはなってないわけで、そこらへんどうなの？と思えど、Results を見ずに Discussion だけ読まされてるようなもんで、どうしようもない。ただまぁ、随分と内容を喋っているので、普通に考えると論文投稿済みかアクセプト済みなのだろう。でないとしたら理学屋さん特有のオープンネスだろうから、それはそれでリスペクトする。あ、写真は素晴らしいと思います、はい*1。

ツッコミ

実験的に、ツイート → ツッコミというふうにやってみるテスト。

まずこの受動的 (passive) とは何かだけど、ここでは「自分の筋肉を使って翼を動かさない」くらいの意味合いのようだ。通常、動物の飛行は「羽ばたき飛行 (powered flight, flapping flight)」と「滑空 (gliding)」に大別されるが、ここでいう受動的・能動的というのはそれとは別の軸。

『翼間の仰角…記録されている』のところを訂正。原文は

For example, the squirrels were frequently recorded moving through the air with extraordinarily high “angles of attack,” which is the angle between the wing—in this case the patagium—and the direction of oncoming airflow.

ここで angle of attack は迎角（げいかく）ないし迎え角（むかえかく）→ 迎角 - Wikipedia。で、この定義を「翼（今の場合は飛膜）と、気流が来る方向との、なす角」というふうに書いている。これは不親切/不正確で、正確には翼弦 (chord) とのなす角、とすべきなのだが…まぁ一般向けの記述だしな…。

リフト (lift) これはふつう「揚力」と訳しますね…。

要するに「航空機の翼では60度みたいな大迎え角では失速するよね（というか20度くらいでするよね）、それに対してモモンガすげー」と。まぁ羽ばたき屋からすると「はい。」っていう…。もちろん興味深いんだけどそんな「メッチャ感動！！まさか失速しないとは！！！」ではなくて「うんまぁそうだろうね。ところで…」っていう感じですかね。わからんか…

んー、いちおう間接的な回答はあると思う。つまり、「滑空中に、能動的に翼形状をガンガン変えるという制御をしているから、安定して飛べるよ」ということと、「飛膜を波打たせて空気力増強してると思うよ」という2点だろう。個人的には後者には懐疑的だけども。

『操作性』 → 原文は "Increased speed enhances maneuverability," なので、直訳すると「上昇したスピードは機動性を増す」くらい。

ところでまずこのステートメントは真だろうか？機動性とはなんだろうか？一般的には、旋回率・旋回半径・ロールレートのような回転に関わる値で判断されるのではないだろうか。とすると単に速度を増せばいいというものではない。マッハ 3.5 で飛ぶ SR-71 の旋回半径は 100 km を超えるが、機動性が高いとは誰も言わないだろう。マッハ 0.8 で飛ぶ戦闘機の方が「高機動」と感じるだろう。もちろん逆におそすぎると、操舵に使う空気力が小さすぎるということはあるのかもしれないが…。

次に後半だが… 確かにそう書いてある。けど、正直この時点では何言ってるのか意味不明だった。後半を読むと、飛膜を波打たせることで空気力増強云々、という話が出てくる。しかし出典がないので、これが PIV をしたのか、とか、波打ちのない場合との空気力の比較実験をしたのか、とかが全然わからない。「湖を超えるほどの滑空比は異常」というのが根拠のようだが、普通はそういう場合まず追い風の影響を考えるべきだろう。原文中に追い風への言及はない。論文でもなかったら査読者が突っ込んでくれるだろう…。

ここの forward acceleration って要するに推力のことなんだよね。要するに、前縁フラップ/スラット状に前にせり出した前縁部分に低圧部（言ってないがたぶん前縁渦）ができて、それによる空気力ベクトルが上方かつやや前方を向くということだろう。ただしこの状態では抗力も大きくなるので、高速時には折りたたんで抗力最小化したり、長距離飛行時には真っ直ぐ伸ばして揚抗比を上げたり、ということ。

この辺はだいたいそうなんじゃないでしょうかという感じ（訳じゃなくて内容ね）。僕が神経・生理に詳しくないこともあるけど。あ、control はふつう「制御」って訳してしまいますね。

ただ一点、何度も言うようだけど、『うねり』（原文では billowing）が能動的ってのはちゃんとエビデンス示してくれ、と。一般向けに言うと、ファミレスの前に立ってるのぼり、風でバタバタしてるよね。あれを見て「素晴らしい！能動的な制御だ」とか思わんでしょふつう、ということね。つまりバタバタしてたら普通はまず「うわー風であおられてるなー」って思うはずでしょう。その場合後流域が広がって圧力抗力が増大するのがふつうのはず。そうじゃないというなら、もちろん興味深いのだが、こんな言葉だけで言われてもなぁ、ということ。おわかりいただけるだろうか…（わからんか）。

後半がセンセーショナル。すでに言及した『うねり』みたいな話の他に、たしかに長い毛が局所的な乱流（アカデミックな文脈では乱気流よりも乱流が一般的）を生むとかある。これはフクロウの風切羽（翼前縁を構成するもの）の前縁にある serration を意識してるのかもしれないが、いずれにせよ、現在形だし、妄想とは思えないので、これはきっと風洞実験をしているのだろう。僕の予想では、

  1. 生きたモモンガを使った風洞実験 → やってるとあるのでやってるんだろうが、この「毛」については別の実験だと思う。もしやってたらスゴイ。
  2. 剥製での風洞実験 → これがありそうだが、そうなると「毛」単体はいいとしてうねり的なものとの合わせ技（←というようなことを言っているのだ…）をどうやって調べるのだろう？毛をカットするのは簡単だろうが、死体ではうねりは再現できないだろう。
  3. 模型での風洞実験 or 数値シミュレーション → 形状計測 ＆ 作成が大変だろうから、もしやってたらスゴイ。数値計算なら、原理的には毛の有無やうねりの有無も再現できるっちゃできる、んだけど、そんな超大規模マルチスケールやるの？というのはある。また、微細構造だけでなく材料の剛性まで再現するのは模型・計算とも大変に過ぎるだろう。まぁ、やってないと思う…。

フィールドだけじゃなくて

As more and more squirrels flew through wind tunnels and along blocked-off biology department corridors

と言ってるんだよなぁ…。フィールドだけだったら「なにこのおっさん妄想言ってんだ」で終了だったんだけど、これがあるので、どこか飛行バイオメカニクスやってるところとの共同研究なんだろう。ていうかぶっちゃけ UCB の Robert Dudley だと思う。ずっと滑空やってるので。

といったところでツッコミ終了。

ところで

flying squirrels are so overbuilt for flight that simple laboratory challenges of gliding from perch to perch, or up and down flights of stairs at the prodding of research assistants, were not enough to reveal their complete flight repertoire.

これには完全に同意。

*1:ただ、ステレオ撮影ならいいけどまたカメラ1台で「確実に」とか「間違いなく」みたいに言ってるとしたら…と思ってしまうのはどうしようもない。

Symantec Endpoint Protection (SEP) のアプデができなくなった (behind proxy) → proxy 設定を default から customize に変えたらいけた

troubleshooting windows network software

タイトルのとおりなのだが、手順をメモしておく。

環境

  • Win 10 Pro 64 bit
  • 大学で behind proxy でネットに接続している

現象

なぜか1週間ほど前から LiveUpdate が失敗していた、ようだ。試しに Windows の設定で proxy を殺して VPN とかしてもダメだった（← NVIDIA とか Adobe など、これで行ける場合が多いのだが）。

対応手順

自分は英語環境なのだが、日本語でもまぁだいたいわかるだろう…

  1. タスクバーで SEP (Symantec Endpoint Protection) のアイコンを右クリック → Open する。
  2. 左のバーのうち Change Settings をクリックする。
  3. 一番下の Client Management の Configure Settings ボタンをクリックする。
  4. 上のタブで、左から3番目の LiveUpdate をクリックする。一番左の General のタブ内にもプロキシの設定があるが、ここだけ変えてもダメだった。
  5. 一番下の Proxy Options の Configure Proxy Options… をクリックする。
  6. 左のタブ (HTTP or HTTPS) で、デフォルト状態は真ん中の I want to use my Windows… というやつになっているはず。これでいけるはずなのだが、なぜかいけないので、一番下の I want to customize my HTTP or HTTPS settings を選択。Host proxy: には proxy.foo.bar.jp みたいのを入れ、 HTTP Port: と HTTPS Port: にはいつものポート番号を入力。以上を終えて OK を押して閉じる。
  7. SEP のメイン画面まで戻り、左のバーから LiveUpdate… を押すと成功するはず。

なぜある時から default でいけなくなったのかは不明だが、まぁいいや…

参考ページ

Git と Atom 用、プロキシ環境（大学）と非プロキシ環境（自宅）を切り替える方法 (Mac OS X El Capitan)

troubleshooting mac software network

This entry illustrates how to automatically switch proxy settings between "behind-proxy" environment and "no-proxy" environment for Git and Atom editor on Mac OS X El Capitan.

↑ いちおう検索用に…

前提

想定する環境

  • 大学（プロキシ利用 behind proxy）： 「proxy.FOOBAR.ac.jp:NUMBER」を使ってね、と言われていることを想定。
  • 家（非プロキシ no proxy）： プロキシ設定使いたくない。

mac での設定

前提として、mac で Network Location*1 を複数作って切り替える、というところまではできているものとする。その上で、 git と atom（のパッケージのインストール・アプデ）を使うには、以下のような切り替えようスクリプトが必要になる。

以下のスクリプトは、 Macのネットワーク環境に合わせてHTTP_PROXYを切り替えるシェルスクリプト - Qiita をコピペ改変させてもらっただけ（多謝）。このページで git は問題ないが、atom はまた別の設定が必要だったのでそこを調べた。忘れそうなのでメモしておく。

やること

~/ に .switch_proxy というファイルを作る。その中身を以下のようにする。プロキシ情報と Location は自分の環境に合わせて書き換えること。

スクリプト

# 何度も出てくるので、プロキシ情報を proxy という変数に代入しておく
proxy=proxy.FOOBAR.ac.jp:NUMBER

# mac の Network Location をトリガにする
switch_trigger_location=University

# 大学用
function set_proxy() {
  export http_proxy=$proxy
  export ftp_proxy=$proxy
  export all_proxy=$proxy
  export https_proxy=$proxy

  ## for git
  git config --global http.proxy $proxy
  git config --global https.proxy $proxy
  git config --global url."https://".insteadOf git://

  ## for Atom editor
  apm config set proxy http://$proxy
  apm config set http-proxy http://$proxy
  apm config set https-proxy http://$proxy
  apm config set strict-ssl false
}

# 自宅用
function unset_proxy() {
  unset http_proxy
  unset ftp_proxy
  unset all_proxy
  unset https_proxy

  ## for git
  git config --global --unset http.proxy
  git config --global --unset https.proxy
  git config --global --unset url."https://".insteadOf

  ## for Atom editor
  apm config delete proxy
  apm config delete http-proxy
  apm config delete https-proxy
  apm config delete strict-ssl
}

# if [ "`networksetup -getcurrentlocation`" = "$switch_trigger_location" -a "`networksetup -getairportnetwork en0 | awk '{print $4}'`" = "$switch_trigger_network" ]; then
if [ "`networksetup -getcurrentlocation`" = "$switch_trigger_location" ]; then
  echo "Switch the settings for behind proxy network"
  set_proxy
else
  echo "Unset proxy settings"
  unset_proxy
fi

挙動

Atom に関しては、Network Location を切り替えるたびに、~/.atom/.apmrc ができたり消えたりする（プロキシセットすると生成され、アンセットすると消える）。なのでちょっと重い気がする。たぶんもっと頭いい方法ありそうなのだが、これで動いてるからいいや…

詰まったところ

http://$proxy というところ、これで正しいのだが、最初 http:// が必要だと思っていなくて、 $proxy だけにしていて、ダメだった。これだけで30分くらい無駄にした…

atom での unset のしかたは、ターミナルで $ apm config --help と打ったら set, get, delete, ... が使えるよ、と言ってたので、まぁ delete だろ、と思ってやっただけ。

参考にしたページ

*1:OS言語が日本語だと「ネットワーク環境」らしい。