読者です 読者をやめる 読者になる 読者になる

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

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

何か質問があればここか 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)

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 だった気がする)。

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

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

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

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

ソースと概要

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 に変えたらいけた

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

環境

  • 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)

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言語が日本語だと「ネットワーク環境」らしい。

【本読み】『そして恐竜は鳥になった』

これもとりあえず公開しちゃう。

対象の本

土屋健(著)、小林快次(監修)『そして恐竜は鳥になった』、誠文堂新光社、2013. ISBN 978-4-416-11365-3.

感想など

図書館で借りて読んだ。薄いけど新しいし「嘘っぽくない(フェドゥーシア的な意味で(?))」かなぁと思って借りたら、当たりだった。僕のような初心者にとって、このような変化の激しい業界の内容は、新しいこととわかりやすいことが重要だけれど、どちらも満足いった。もちろん、正確性を判定できるわけではないのだけれど。出典も一般向けにしてはそこそこあったような気がする(そうでもなかったかも)。

読みながら書いていたメモがあったはずだが、大半がどっかにいってしまった…。ツイッターにちょっと残ってるのと、一点だけ、

多くの昆虫は2対四枚の翅をもち、細かく羽ばたかせることで飛翔している。

「細かく羽ばたかせる」とはどういうことだろうか。ここから受ける印象は、「羽ばたき振幅が小さい」ということだが、実際には様々である。ハチなどは確かに割りと小さいが…

あ、あと、覚えているうちでは、風切り羽がなぜできたかというところが僕にとってはハイライトで、いろいろな説を「たぶん違う」と破棄していくのはなかなか面白かったのだけれど、最終的に選んだ(残った)のが「卵を覆うため」みたいなのだった気がするんだけど、あれは、どうなんだろ…。なお、卵が洋梨型なのは転がりにくくするため云々、については Shorebird さんの書評が非常に面白かった→ 書評 「The Most Perfect Thing」 - shorebird 進化心理学中心の書評など