【本読み】『凹凸形の殻に隠された謎』
内容が忘却の彼方に行きそうなので、ここで一旦公開する。
対象の本
椎野勇太『凹凸形の殻に隠された謎 腕足動物の化石探訪(シリーズ:フィールドの生物学)』、東海大学出版部(発行当時は「東海大学出版会」かも)、2013. ISBN 978-4-486-01849-0
- 公式: 東海大学出版部|書籍詳細>凹凸形の殻に隠された謎
- Shorebird さんによる書評: 書評 「凹凸形の殻に隠された謎」 - shorebird 進化心理学中心の書評など
- 本人のウェブページ: 【腕足動物】 凹凸形の殻に隠された謎 - 椎野 勇太 Yuta SHIINO
感想
率直に言ってメッチャ面白かった。学術的な内容というか、地球科学・地質学・古生物方面の面白さってのが伝わってきた。研究者人生云々、みたいなところはそれほどでもない…というか、面白いというよりは共感した、かな。僕はCFD→生物と逆方向に入った人間で、また、スウェーデンでポスドクやったりもしたので、その辺も親近感がある。
疑問点
このへん、本当は論文を読めば概ね解決するはずなのだけれど、メモとして残しておく。
- そもそも腕足動物の殻とは?ヤドカリみたいに拾ってくるんじゃなくて、自分で作る?気になるのは2点で、固さがどれほどか(流れでは変形しないのか?)と、生体組織なのか(ゆっくりとでも能動的に変形できるものなのか?
- 「だだっ広い水底にぽつんと置いてある」モデルで良いの?(←ブーメランではある)
- 変えた変数は、形状以外では、流入方向という yaw と流速の2つだけ?ピッチ角やロール角は変えていない?もしそうなら、どうしてその角度を選んだ?ロールは対称性からわかるとして、ピッチ角はどうやって決めた?
- 内部構造について。実際には生体部分があるはずで、実際に触手冠について熱く語っている(その重要性がよくわからないのだが…表面積が大きいほど捕食効率が良いとかいうこと?そうであればハッキリそのように書くべきだった)。しかしCFDの形状モデルは、殻のみで中は空洞なのだろうか?おそらくそうだと思う。だとしたら、その妥当性はどう評価するのか?つまり、中に物が詰まっていたら当然流れは変わるはずでは?憶測でもいいから、何かしら中身を詰め込んで計算してみたりしたのだろうか?していないのなら、なぜしなくてよいと言えるのだろうか?もっと言ってしまうと、こういうモデル化しにくいことこそ実験でやるべきであって、CFDと全く同じことを実験で再度やるのはあまり意味がないと思う。というわけで、質問はむしろ「そういう、中身を詰め込んだ実験はしたのですか?してないなら、なぜですか?」ということになる。
- 触手冠と殻のトレードオフ(?)のところ、気になる。「どちらでもよい」ような書き方だけれど、生成・維持・捕食効率(?)・etc. のようなもので、トータルの比較をした場合に、たとえばより後の種の方がエネルギ消費が少ないみたいな違いがあるのでは?
- 水の物性(などの物性値・物理定数など)はどうしたのだろう?現代のきれいな海水を想定?別の値に変えてみたりしたのだろうか?
- 表面粗さ…は、付着生物やってるか。
【論文読み】世界一大きな(重い)ハチドリのエネルギ消費は他のハチドリのスケーリングから外れてはいない
対象論文
Fernández, M. J., Dudley, R. & Bozinovic, F. 2011 Comparative energetics of the giant hummingbird (Patagona gigas). Physiol. Biochem. Zool. 84, 333–340. (doi:10.1086/660084)
概要
対象動物
- giant hummingbird(オオハチドリ、学名 Patagona gigas).
- 現状、世界一重いハチドリ。ハチドリ全体としては、ほとんどが6 g以下で、それ以上も 6-12 g である。Giant hummingbird は質量が20 gもあり、二番目に重いハチドリの2倍近くと非常に重い。
- にも関わらず、giant hummingbird は飛行のつらい*1高地を含む 0-4500 m に分布する。
先行研究と仮説
- 先行研究によると、DEE*2/BMR*3 > 7 は生理学的に維持不能と考えられる。
- giant hummingbird はこの限界に近いのではないかという仮設を立てた。もしそうなら、体重の増加につれて、DEEはBMRよりも速く増加するはずだ。
手法
- giant hummingbird と他の3種を南米のチリで捕獲し、BMR, DEE, HMR*4を調べた。
- DEE は DLW (doubly labeled water) で調べた。日本語では二重標識水と呼ぶようだ。これは大まかにこういうことのようだ:運動前に水素と酸素の同位体を注射する。このときの同位体の量は known であり、これと、運動後の同位体の比率から酸素消費量がわかり、そこからエネルギ消費を推測できる。そしてこれを時間(今の場合は1日*5)で割れば代謝率が得られる。
- BMR は、鳥を夜間チャンバの中に入れて、そのチャンバに流入・流出する空気から酸素消費率を計測した*6。
- HMR は酸素マスクを使って計測した。具体的な方法が読んでもいまいちよくわからない。やはりこれもチャンバ内で酸素マスクから酸素を供給し、出て行くところでどれだけ減ったかを見ている、ということかな。
- BMRを基準として、2つの比率を定義した*7:
- 自分たちで実験した他に、文献から13の種の DEE, BMR, HMR を探し出した。これらの値は、スケーリング(体重の大小に伴う代謝率の大小の関係)を調べるのに使った。
- また、phylogenetic*9 な考慮も行った。これには McGuire et al. (2007) のデータ、McGuire からの personal communication による branch length, および Mesquite というソフトと、このソフト用の PDAPモジュールを用いた。
結果
- giant hummingbird は他のハチドリの allometric scaling から外れていなかった。
- giant hummingbird の sustanined metabolic scope は 5.6 であり、これは他のハチドリの値(= 3-4程度)よりは高いが、理論的に提唱されている endotherms(恒温動物)の最大値 (= 7) よりは低かった。
議論
- 実は計測した DEE が、野生での DEE よりも低く出ている可能性がある。なぜなら、野生と違って計測が行われた aviary ではハチドリは単一であり、ネクターも自由にいくらでも手に入ったため。また、Stiles (1971) によると、captivity*10 の Anna's hummingbird は野生下に比べて半分の時間しか飛行していなかったという(DEE は「飛行した時間」ではなく単純に「1日」で割っているので、これは単純に DEE の低下として現れる)。同じことが giant hummingbird でも起こっていたのかもしれない。
- 一方で、captivity という環境自体がストレスとなり、DEE を増やす方向に働いている可能性もある(これも Stiles (1971) の指摘)。
- ホバリングよりも他の行動の方が実は本当の瞬間的な代謝率は大きい。つまり、4,500 mで暮らすような giant hummingbird はさすがに生理学的な上限に近いだろう。したがって、ホバリング以外の行動をする事も考えると、これ以上の大型化をしようとすると低地に移行せざるを得ないのではないか。
感想
- まず2番目に重いやつよりも2倍以上も重いというのが非常に不思議。間のやつは、淘汰されたのか?だとしたらなぜ?それには、この論文では答えていない(そもそもそういう question ではない)。
- 一方で、そんなにも違うのに metablism としてはスケーリングに乗っていることもやや意外。さらには酸素濃度・空気密度ともに低い4000 m級の高地でも問題ないと。そうするとバイメカだけなら、もう少し大型まで行けるのかもしれない。いけるといっても、総合的には不利になって、このサイズが限界なのかもしれない。← ていうかこれ、Discussion に書いてた…
- というより、やっぱり、実際に現実的なのは2番目に大きな種までで、giant hummingbird には何かしら環境特異性というのか、特殊化というのか、そういうのがありそうなのだが…。当然、彼女らも(彼女らこそ)このあたりは気になっているはずだから、既にそういうことも調べているかもしれないが。
- 2番目に重い種ってどれなんだよ!気になる… ← Sword-billed が 12 g くらい行くみたいなので、こいつかもしれない Sword-billed Hummingbirds, Ensifera ensifera
- DEE, BMR, HMR でそれぞれ異なる手法を用いて代謝率を計測しているが、相互の validation は大丈夫なのか?たとえば、同じ手法を使って同じ値を出せるか、という検証は過去にされているのだろうか?(たぶんされているのだろうが)
- Phylogenetic treatment のところはやっぱりまだ全然わからない。勉強しなきゃいけない。
- だいぶ前に読んだので内容忘れてる…(なのでとりあえず書いたとこまでUPしようと)
*1:酸素濃度と空気密度が低い。特につらいのは後者。Dudley や Chai が 1990 年代後半に詳しく調べている。
*2:daily energy expenditure, 一日平均のエネルギ消費利率。
*3:basal metabolic rate, 運動していないときの基礎代謝率。
*4:hovering metabolic rate, ホバリング時の代謝率
*5:普通はもっと長くするようだ。ハチドリは代謝率が高いので短くてもよいのだろう。
*6:この装置、僕がLundにいたときに他の人達がよく使っていた。BMRは安静状態の値でなければいけないので、建物を夜に出入りするときは静かにやれと言われた。うるさくすると鳥が起きてしまい、計測値が振動してしまうとのこと。
*7:BMRで無次元化・正規化した、と言ったほうがいいのかもしれない。
*8:実際にはホバリング中の代謝率が最大ではない。上昇や急旋回などの方が大きくなるはずで、これは論文にも書かれていた。Dudley なので抜かりはない。
*9:日本語だと…系統発生学?
*10:日本語だとなんだろ…飼育?捕獲?
Adobe Creative Cloud を某工大でインストールするには(Win 10)
ひとことで言うと: VPNしろ。
前提
前提として、プロキシの設定は次のようにしておけば良い:
- 設定を自動的に検出する → OFF
- セットアップ スクリプトを使う → OFF
- プロキシ サーバーを使う → ON. プロキシはいつものやつ。
- 次のエントリで<略>のところのボックス → 何も書かなくて良い
- ローカル(イントラネット)のアドレスにはプロキシ サーバーを使わない → チェックする
ただし、下記に示すように Win 10 で VPN する場合、直前にはこのプロキシを切る必要がある、ようだ。
手順
- まずは手順書にあるとおりにインストーラでCCアプリをインストールする。が、このままだとサーバに繋がらず、個別アプリのインストールに進めない。
- Windows の場合、ポータルから VPN のページを開いて、「Network-Access__なんちゃら」というボタンを押す直前までいく
- ここで、スタートメニューの設定アプリ(Win 10を想定)> ネットワークとインターネット を開き、今まで使っていたプロキシを切る。このタイミングで切っておかないと、うまいこと VPN 接続できない。
- 上記のようにプロキシを切った状態で「Network-Access__なんちゃら」ボタンを押せば、VPN 接続が開始されるはず。
- VPN接続した状態で、CCデスクトップアプリを起動する。これでサーバに接続できるはず。
なお、VPN接続した状態では逆にポータルの他の機能は使えない。したがって、インストールが終わったら VPN を切ること。
Adobe ID について
また、Adobe ID はすでに持っているものがあっても、サブスクリプションの関係でややこしいので、別に作ったほうが良さそう。自分の場合は、イラレを他の2台のPCにインストール済みだったため、自分のIDでやろうとすると「これ以上インストールできません」みたいに言われたので、新しく大学用のIDを作った。
NVIDIA GeForce Experience
【論文読み】The comparative hydrodynamics of rapid rotation by predatory appendages
だいたい書けたけどまとまらない…
対象
McHenry, M. J., Anderson, P. S. L., Van Wassenbergh, S., Matthews, D. G., Summers, A. P. & Patek, S. N. 2016 The comparative hydrodynamics of rapid rotation by predatory appendages. J. Exp. Biol. 219, 3399–3411. (doi:10.1242/jeb.140590)
何をしたのかまとめ
目的
- シャコパンチにおいて、パンチ運動と腕形状の種による違いが流体力にどのように影響するかを調べること。
- これには、本来はCFD*1がよいのだが*2、全てのパタンをCFDで計算するのは計算リソース的に大変なので、簡易的な流体計算であるBEM*3を使いたい、というか、使う。しかし、BEMは簡易版なので、正確性を検証しなければならない。そこで、流体力(抗力)によるトルクを評価指標として、BEMがCFDと比較して十分に使えるかどうかをテストすることも実質的には大きな目的となっている。
手法
書いてある順序ではなく、自分なりに整理すると次のようなこと。
- シャコパンチの運動を文献から求める(4種)。さらに中型のスピアラー1種を自分で撮影して追加。運動は、どうやら carpus の根本を pivot とした2次元平面内の1自由度の回転運動として近似し、その角度を文献のスピアラー種からフィッティングで求めている。Phylogenetics を考慮した比較もしているようだが、意図がいまいちわからないので詳細は割愛。
- 実物を元にしたシャコの腕形状・パンチ運動*4を使って、パンチのCFDを行い、抗力によるトルクを求める。このときのパンチ運動が、文献値なのか、上で求めたフィッティングの値なのかは不明瞭(おそらく前者)。
上記の腕形状の作成時に用いた20程度の腕断面それぞれの位置を使って、BEMで計算を行い、その結果をCFDでの結果(トータルおよび断面ごと)と比較したい。そのためには、BEM に用いる抗力係数 Cd (eq. 5) が必要となる。これは次の方法で求める。
- 楕円柱の shape factor k = 0.015 を使って、eq. 6 から求める。
- 一様流CFDから:形状モデルはパンチ運動と同一。流速はパンチ運動での最大値(?)である 20 m/s として、定常・一様流のCFDを行う。計算結果から、20断面それぞれについての (Cd),i を出してそのままBEMの各ブレード要素に叩き込むのが一つの方法、もう一つは、楕円柱の式 eq. 6 で k = 0 とし、全体の抗力 Fd がCFD結果のものと等しくなるように、各ブレード要素の (Cd),i を決める方法。
水路実験:ずっと勘違いしていたが、どうやら水路実験の結果はBEMに直接使われていない(!)。一応やっていることは以下の通り。3Dプリンタで作成したリアリスティックな腕形状モデル*5、および楕円柱を水路内に設置して、抗力を計測する。このとき、腕の先の方 (dactyl) を閉じた状態と開いた状態の2パタンを調べる*6。ここから shape factor k を求めるようだが…どうやって求めたのかがわからない。腕模型との抗力の差が小さくなるように、楕円の短軸・長軸を変えていったときの楕円柱の k ということだろうか? ("range of long elliptical cylinders with different aspect ratios" はここにも適用されているのかも)いずれにしても、この結果がBEMには使われていない。また、なぜか BEM で使っている種である G. smithii の k は 0.1 程度であり (Table S3)、BEMの楕円柱仮定の 0.015 とは一桁も違う。どういうことなの…。結果のところでは、むしろ「7倍も違うのにBEMの結果はこんなに合ってるぜ!」みたいに書いているが、え、それは、どうなんだ…
トルク以外にエネルギでも評価している。
BEM を使って、3種のシャコのパンチ運動について、3つのパラメタを振って sensitivity analysis をしている。
結果
やってることが多く、それぞれのブランチで結果がいろいろある。しかし、このうちCFDやBEMに持っていく結果は一部だけ(水路実験の結果は使ってないし)。しかも、手法に書いてある順番とは異なる順番で結果が羅列されており、読みづらい。
- 水路実験では、閉じた状態での腕形状が長手方向 (spanwise) に一葉に近いスピアラーでは、腕の先の方を開いても抗力がほとんど変わらなかった*7。一方、閉じた状態で腕の先の方が(流れの前後方向に)膨らんでいるスマッシャーでは、腕を開くと抗力が増加した。それぞれの種のshape coefficient k を求めた。スピアラーの C. scolopendra は楕円柱と似た 0.015 だった。
- 一様流とリアリスティックなパンチ運動のCFD結果は全然違う(当然)。
- BEMとCFDの結果の比較
- ただの楕円柱ベースの抗力係数を使ったBEMでは、パンチ後半の時間帯でトルクがCFDと大きくずれる。
- 一様流CFDを使って抗力係数を求めた2つのBEMでは、時間的にはトルクがCFDとよく合った。しかし、各要素について比較すると、いずれのケースでもかなり…全然合ってない。とくにspanwise location 80%くらいのところで、CFDでは正のトルク(腕を加速する方向)がわずかにみられる*8のに、BEMでは大きな負のトルクが生じている。つまり、定性的にすら合っていない。が、結論としては「トータルがあっているからよかったよかった」というような論調…。そして要素ごとのずれについては色々と説明しているのだが、突然迎え角の話が出てきて、よくわからないのが正直なところ。消化不良で終わってしまった。
- sensitivity analysis では、「上腕部分の長さがトルクに一番効くよ」というようなお話。
Comments
Major points
なぜカメラ1台だけの撮影で2次元平面内(1軸まわり回転)の運動と言える?
仮にそれが言えたとして、取り付け角*9は全ての断面で0度、つまり「ねじりなし」なのかどうかが明確でない。→ いまいちハッキリしないが、ESM Fig. S2 によると翼型は対称かつ「ねじりなし」のようだ。
Note that the model assumes mirror symmetry about the sagittal plane through the long axis of the appendage.
⇒ http://dx.doi.org/10.1242/jeb.061465 の Fig. 5B の micro-CT を見ると、確かにこの一断面については対称でも良さそうだ。ただし、元論文に戻って ESM の Fig. S2B を見ると、左側の要素軸の平板的な図では断面が(翼型的に言うと上下が)場所によっては若干非対称なのに*10、右の3Dっぽい図では対称にしている。これがどれほどの影響を与えるか…。微妙なところだろう。単純化して一般化したいのはわかるのだが、この非対称性が negligible であるとか、なにかしらの justification ができれば欲しかった。たとえば、航空機と違って、このRe域において、この程度の非対称性は小さな違いしか生まない、ということを示すと良かった。
「BEMをCFDと比較して、十分使えることを示す」要素ごとのトルク全然合ってない問題」(Fig. 6G-I) について、色々と言い訳をしているが、結局なぜこれでよいのかはよくわからなかった。
General comments
- 色々とやっていて、ぜんぶ入れたくなるのはわかるのだが、やったこと同士の関係がわかりづらい。
- たとえば自分ならどうするか考えてみると、一案として、3Dプリントモデルでの水路実験と20 m/s での一様流CFDは「一様流」という扱いでまとめる。その結果の詳細はESMに押し込め、本文には概要のみを記し、「これによってBEMに用いる Cd を決定した」という話の流れを明確にする。その上で、CFDのモデルと結果、BEMの手法・結果、そしてこれらの比較、という主題に集中する。
とはいえ、そもそも「BEMをvalidationしたい」が主題というのは、どうなのだ?と思った、が、←これは僕の勘違いだった。実際には種による違いの比較(が、少なくとも建前)。イントロの最後で3つの副題的な questions を挙げていた。これは素直によいと思う。- 揚力についての言及が一切ない。これは後でわかったが、おそらく流れに対して翼厚方向に完全に上下が対称な断面形であるとし、かつどのspanwise位置でもAoA*11=0度としているからだろう。しかし、この対称性についての説明は、 ESM で形状についてあるのみで、AoA が本当に0度なのかどうかは結局不明確だった。シャコパンチ業界では常識なのでいちいち言及されないのかもしれないが、書くべきだ。
- 書いてなかったと思うのだが、dactyl が strike の最中に closed → open に変動する、ということはないのだろうか?おそらくそれはなくて、stroke の最中は既に open or closed どちらかだけなのだろうが…。
水路実験
- Fig. 4: 細かいことだが、Aはモーメントアームの関係を使って求めるのならアームの長さも書くべきだろう。Bは流れの方向がわからない。腕の上腕側 (propodus) の長手方向が流れに垂直になるようにしている、のか?そして角度はその1パタンしかやっていないのか?
Kinematics
We approximated the strike kinematics of each species using one average strike from L. maculata
として eq. 3 を算出して、他のシャコパンチ運動を決定しておきながら、
Calculations of the mean-squared error (MSE) for the fit ... indicated that the spearer, L. maculata, exhibited substantial variation not represented by Eqn 3.
っていいのか…?統計の話がわからないので、なにか騙されてるような感じがするのだが…
- assuming pure 2D but how realistic is it?
CFD
- 回転中心は実物でのどこ?よくわからない
- pivot を中心にした単純な回転のようだが、本当にそうなのか??(加賀谷さんも気にしてた点)
- 根元側(回転中心側)が突然裁ち落とされているように見えるのだが (Fig. 6) 実際には当然まだ体のどこかが続いているはずだ。つまり根元側の速度が十分に小さいという前提が必須になるのでそれは明確に述べておかないと。「胴体がなくても流れ場に影響しないの?」というのは羽ばたきでは定番のツッコミのひとつ。返しとしては、ホバリングでは wing proximal sections の速度は小さいから、まぁそんなに影響しないんじゃない、という感じ。経験上は、たしかに流体力にはあまり影響しないが、流れ場の見た目は結構違う、つまり、proximal sections の「要素に注目した」議論はあまり信頼できない可能性がある。たとえば Fig. 6A の下にある要素ごとの C_d のプロット、Position < 4 で2D楕円と全然違うが、これは root vortex の影響かも。Tip 側で合ってないのも同様に tip vortex の影響かも。
- というか、Fig. 6H, 6I, CFDと全然あっていないが、大丈夫なのか?特に spanwise location で70-90%程度の、回転体の流体力で一番大事なところが全然あっていない。spanwise方向に積分した(要するに全部を足した)トルクである Fig. 6E, 6F では合っているが。6F が合うのは、合うようにしているから合っているように見えるのだが、なぜ 6E が合うのかがよくわからない…偶然ではないの?これだけ要素レベルで合っていないものが本当に汎用性があると自信を持っているのか?
- よく見たらここの言い訳に相当な紙幅を費やしていた。local AoA とか唐突にいい出しているが、そもそも AoA が定義されてすらいないし、CFD用モデルの各要素での AoA も全然わからないし(ゼロじゃないの?)、非常に読みづらい。
- これが「wing root or wing tip ですごくずれちゃってます」なら良かったんですよ、別に。プロペラで一番大事な60-80% spanwise locationでこんなに違うってのは…
- たとえば「いくつか条件を変えてCFDしてみよう」とはならなかったのだろうか…計算リソースの問題かな。具体的には、Fig. 8 でパラメタを変えてBEMで simulate しているが、この中から数点だけでもCFDやってみて、BEMの結果と比較して、「やはり要素レベルでは合わないが、total (sum) では合ってる」といえば、だいぶ説得力は上がると思うのだが。
ミス・typoなど
- Fig. 8 のシンボルの説明、キャプションでは closed circle が dactyl closed, open square が dactyl open とあるが、8A内のレジェンドは逆になっている。UI的に考えてキャプションが正しいだろう、たぶん。
*1:Computational fluid dynamics.
*2:実験的に、形状と運動の両方が正確なパンチをするのは大変だからだろう。また、そこでさらにPIVするのもつらそうだ。
*3:Blade element method.
*4:1種。スマッシャー。
*5:5種。CFDと同じスマッシャーを含むスマッシャー2種・スピアラー2種・どっちでもないやつ(?)1種。
*6:スマッシャーは閉じた状態、スピアラーは開いた状態が自然らしい?
*7:と、言っているが、本当だろうか。よくわからない。が、一様流の結果にそんなにツッコんでもしょうがない気もする。
*8:1つの位置のみ。ほかは全部値は異なれど負の値。
*9:angle of incidence, AoI; 今の場合は迎え角 angle of attack, AoA と同じ値になる
*10:pivot も図で中央よりやや右寄りにある。しかし運動が完全に2Dだと言うのならこの位置は問題にはならない。
*11:angle of attack
pandas で各要素の有効数字を揃える(「小数点以下何桁」ではなく)
Introduction
df.round(n) だと「小数点以下n桁」で四捨五入される丸められるだけで、有効数字を揃えたい場合はちょっと違う、ということがあった。
たとえば df という DataFrame の中身として
- 12.345
- 9.8760
があったとき、df.round(2) すると、
- 12.34
- 9.88
になる*1。
ところが今やりたいのが「有効数字3桁であらわしたい」であって、単に「小数点以下2桁で丸めたい」ではない、とするとどうか。つまり、
- 12.3
- 9.88
となってほしい場合。
Methods
まず
import numpy as np from math import log10, floor def round_sig(x, sig=2): return np.around(x, sig-int(floor(log10(abs(x))))-1)
という関数を作る。これはstackoverflowの回答の indgar 氏のコードをコピペし、x を abs(x) にしたもの。また、python デフォルトの round よりも numpy の around の方が良いようなので、そちらにした。
使うときは、まだこの辺がよくわかってないのだが、Series にしか直接は適用できないっぽい?ので、
df_orig = pd.Series([12.345, 9.8760]) # 適当な元データを用意する sig_digit = 3 # 有効桁数を指定する s_orig = df_orig[:] # DataFrame --> Series s_round = s_orig.apply(round_sig, args=(sig_digit,)) # ここで apply df_round = s_round.to_frame() # Series --> DataFrame df_round # 結果の表示
みたいな感じで。あ、Series への変換と逆変換のところも関数に入れればいいのか…
参考にしたページ
mac (w/ Python 3 & PyQt5) で ocXgag
Introduction
鳥人間な制御屋さんが公開してくれた ocXgag という翼型の調整ソフトがちょっと面白そうだった:
- 失速特性を考慮した翼型設計ocXgag その1 背景 - A Plane On The Sand
- 失速特性を考慮した翼型設計ocXgag その2 公開と使い方 - A Plane On The Sand
が、Windows にしか対応してないとのことだったので mac で使えないかとやってみた。ただ mac 固有の問題というよりは PyQt のバージョン違いの問題なのかも。Qt に触れるのが初めてなのでよくわからない。いずれにせよ、結論としては、コードを少しいじって Xfoil をインストールしたら動くようになった。
なお起動方法は単純に、コマンドライン(自分は iTerm 2)でスクリプトのあるディレクトリまで移動し、
$ python ocXgag.py
とするだけ。
検証環境
Methods & Results
スクリプトの書き換え
PyQt のバージョンがスクリプトに書かれている 4 でなく 5 であることが原因で、書き換えが必要になった。したがって、ocXgag.py をエディタで開いて、以下のことをした。
- 冒頭付近、from PyQt4 import QtGui, QtCore を from PyQt5 import QtGui, QtCore, QtWidgets に差し替え
- backend_qt4agg を backend_qt5agg へ置換
- QtGui.QFont() 以外の QtGui という文字列を全て QtWidgets という文字列へ置換
- GetFoilName の self.foilname = というところを、self.foilname, _ = に差し替え。これを調べるのにだいぶ時間がかかった*1。 参考。
以上で、アプリの起動および翼型データの読み込みまではできるようになった。
Xfoil のインストールと PATH の設定
このあとは Xfoil が必要になるので、Xfoil4Mac をインストールした。このとき XQuartz が必要と言われたので、それも入れた。あとはコマンドラインから xfoil を開けるように、パスを通す。具体的には、
$ PATH=$PATH:/Applications/Xfoil.app/Contents/Resources/
とした。確認は
$ echo $PATH
で。以上で使えるようになった。
1password extension for Chrome (on Mac) で 1password (for Mac) が見つからないやつ → プロキシが怪しい
もうちょっと具体的に言うと、ブラウザエクステンションをインストールしたあとで初めて Chrome 右上の 1password アイコンをクリックした時の話。すでに 1password for Mac をインストールしてあるのに、「見つかりません」とか言われる。説明文のバージョンが4だったり怪しい上に何度やっても Try again とか言われてイライラする。
これ、これまでは Chrome extension を何度か uninstall --> install してれば直った。あとはまれに mini の立ち上げ忘れということもあった。が、今回はなんどインストールしても直らない。そこで色々検索していたところ、次のページを発見した:
Configuring a firewall or proxy on your Mac - 1Password Support
確かに、これまでと変わった点として「大学の研究室からプロキシ経由でアクセスしている」ということがあった。で、結果としてはこの 127.0.0.1 を bypass のとこに追加したら worked like a charm だった。
意外と同じところでハマってる人がいそうなので…というか、自分でも忘れそうっていうか一度見つけたのにすぐ忘れてしまっていたので、メモしておく。
ちょっとわからないのが、Safari だとなぜかプロキシの設定をする前でもブラウザエクステンションが使えたこと。理由は不明。あと、Windows でプロキシ使ってる場合にどうかはわからない。