Radiative transfer は21世紀の相対論になるか
最近あまり気象・気候のエントリーを書いてない。というか、ブログすら更新していない。ちょっと公私ともにバタバタしていてね。出張先で時間ができたので、安宿で缶ビールでも飲みながら、気候のエントリーでも書いてみるよ。
CO2温室効果懐疑論
Onkimoさんのエントリー harusantafe さんが twitter で論争を - 「温暖化の気持ち」を書く気持ち
いつも愉快なonkimoさんのエントリーでCO2 15μm吸収による温室効果懐疑論について語られている。Onkimoさんによると、これは(1)飽和論と(2)無放射緩和過程論に分類できると言う。
飽和論
前者の飽和論は懐疑論の文脈で語られることが多い。15μmは光学的に厚い(optically thick)。だからこれ以上CO2濃度がふえても温室効果は増加しないという理屈だ。15μmのラインはたしかに光学的に厚い。地球大気のスペクトルを宇宙から観測すると、この吸収プロファイルが台形状になっているのがその証拠だ。また、温室効果はCO2濃度の対数で効くのもその証拠だ。ちなみに光学的に薄いと線形で効く。これを飽和と称するかどうかは別として、CO2の吸収線は光学的に厚い。
無放射緩和論
後者の無放射緩和論も懐疑論の文脈で語られることが多い。CO2分子が赤外線を吸収するとCO2は励起される。しかし窒素分子に衝突して励起されたエネルギーが窒素分子の熱エネルギーに変わるので、CO2の励起はなくなり赤外線を再放射できないだろうとう理屈だ。これもradiative transferの初学者が陥りやすい間違いだ。「局所熱平衡(LTE)」や「キルヒホッフの法則」でググれカスと言われても仕方がないだろう。このへんは僕も過去のエントリークライメイトゲート事件:いまさらホッケースティック論争? - 雑多な覚え書きで言及した。
簡単だけど複雑 ―相対論との類似性―
Onkimoさん曰く:
「飽和」論も「無放射緩和過程」論も、確かに、わかりにくい議論なんですよね。いえ、物理を学んだ方にはそんなに難しいものではないのではありますが。
僕個人としては、radiative transfer は物理学のなかでも難しい部類だと思う。でも、方程式系はとてもシンプルなのだ。radiative transferの方程式はボルツマン方程式から演繹的に導かれる完成した理論だ。しかも理論はシンプルで疑いの余地はない。でも難しいのだ。もっと正確に書くと、
Radiative transfer自体はとてもシンプルで疑う余地はない。しかしその方程式系から導かれる結果はとても複雑だ。
と書くべきだろう。
これは相対論とのパラレリズムがあると思う。すなわち、
アインシュタイン方程式はシンプルだ。しかしその結果はとても複雑だ。
Radiative transferと相対論が異なるのは、つぎの点だ。radiative transferがボルツマン方程式から導かれるのに対し、相対論は等価原理という原理としては自明ではないものから導かれる。
懐疑論についてもパラレリズムが見いだせる。20世紀は「相対論は間違っている」が隆盛していた。21世紀は「温暖化は間違っている」なのだろう。
王道のアプローチ
相対論も温室効果も「方程式はシンプルだけど、結果は複雑」という特徴がある。こういう問題にいどむとき、王道がある。それは
数値計算で解を求める。
これにつきる。複雑な問題について、数値計算を行わず、方程式の性質を頭の中であれやこれや、風が吹いたら桶屋が儲かるのような考えをめぐらせても、得るものは少ない。しかし、我々はコンピュータという20世紀最大の発明を享受しているのだ。コンピュータで数値計算を行って方程式系の性質を吟味するのが王道なのだ。
世の中には、コンピュータシミュレーションを軽視する人がいる。彼らはこう言うだろう:
「コンピュータに計算させたら、何故かわからないけど、こんな結果になりました。こんなのは思考停止だ」
僕に言わせれば、こういう発言こそが湯川秀樹や朝永振一郎の亡霊に取り憑かれていると思う。紙と鉛筆と難しい方程式で何かすごい知見が得られるという、そんな時代は終わったのだ。こういう人は過去の科学と現代の科学の流儀の違いを理解していない。ブルーバックスの読み過ぎだ。
忙しい合間に論文を書く方法
今年も残すところあと4日間となった。研究はボチボチ進んだ。ファーストオーサーの論文を複数本、共著論文も複数本書くことができた。雑用で忙しい割によくやっていると我ながら思う。同僚の中では一番かもしれない(笑)。
忙しい中でキチンと論文を仕上げる方法をメモしておく。現在でも試行錯誤だが、現段階での覚え書きだ。なお、ボクの研究スタイルは、シミュレーションを用いた研究だ。
- 研究進捗メモを作る
- 多くの研究者がやっていることだと思う。メモを電子ファイルで作り、計算に用いたパラメータを必ずメモする。複雑な式もちゃんと入力しておく。これらを論文執筆時にコピペをする。
- 論文を想定して図を作る
- 研究進捗メモに貼る図にも、論文に掲載する図を作ってしまう。また図のアップデートをコマンド一発でできるようにしておく。こうしておくと、論文執筆時にメモの図を流用することができる。
- 複数のプロジェクトを同時進行する
- 複数のプロジェクトを同時進行すると、時間の使い方の最適化が容易になる。プロジェクトAが論文執筆フェイズのときは、プロジェクトBは計算フェイズにするなど。プロジェクト間の頭の切り替えを容易にするため、研究進捗メモが重要になる。
- 雑用を後回しにする
- 研究優先で時間を作り、雑用を後回しにする。雑用は遅れても大丈夫なことが多い。また、雑用が遅いという実績をつくると、つぎからあまり雑用が降ってこなくなる(かもしれない。いまのところ、それはないが)。
- GTDを活用する
- これは言わずもがな。
- 人が休んでいるときに働く
- 休日や祝日には雑用が降ってこない。雑用を頼む人が休んでいるからだ。したがって、休日や祝日はまとまった時間が確保でき、大きな問題に取り組むことができる。しかし、これをあまり多用すると家庭崩壊につながるので、諸刃の剣だ。素人にはおすすめできない。
バッファローのポータブルHDD (1TB) は最悪だ
バッファローのHD-PXT1.0TU2という外付けのポータブルHDDを購入した。USB2.0接続の外付けHDDで、容量は1TBだ。大容量のわりにスリムで可搬性が良いと判断したからだ。
しかし、このHDDは最悪だった。
メーカーの商品紹介はここだ: HD-PXTU2 バッファローツールズ対応 耐衝撃/セキュリティー機能搭載 USB2.0用 ポータブルHDD : ポータブルHDD | バッファロー
なぜ最悪かというと、この外付けHDDをPCにUSBで接続すると、メインのHDD領域だけでなく、仮想CD-ROMのイメージもマウントする。Windowsの場合は、仮想CD-ROMにある怪しげな exe ファイルを自動実行しようとする。Mac の場合にも 仮想CD-ROMをマウントしてしまう。これはとってもウザイ。
Utility_HD-PXTU2 がその仮想CD-ROMだ。*1
出来の悪いメーカーアプリケーションを押し売りするのは辞めて欲しい。使わない選択肢も残して欲しいものだ。
おまけに、この仮想CD-ROMはなかなか消せない。
virtural CD-ROM 消す
とかググっても、有効な解決策は見つからない。もしかしたら、フラッシュメモリか何かに仕込まれているのだろうか。もしそうならお手上げだ。
Macにマウントして mount コマンドの結果を見ると、仮想CD-ROM領域はHDDのパーティションに分けたものではなく、別のデバイスとして認識されているようだ。fdiskコマンドも使えない。
普段は内蔵用のHDDを、裸で外付け用として使っている。たまに、”ちゃんとした”ケース付きの外付けHDDのパッケージを買うと、ハマってしまう。
やっぱ、外付けHDDは裸族に限る。
Macでニコニコ動画:H.264 MPEG4にエンコード
Macでニコニコ動画にアップするために、H.264のMPEG4に動画をエンコードする方法を紹介します。OS以外は全てフリーソフトを使います。手順はシンプルです。
MacPorts をインストール
The MacPorts Project -- Home から MacPorts をインストールします。
動画をエンコード
つぎのようなシェルコマンドを作ります。
#! /bin/sh TMPDIR=`dirname $1` FFMPEG=/opt/local/bin/ffmpeg LOG=$TMPDIR/passlog$$ export DYLD_BIND_AT_LAUNCH=1 FIN=$1 if [ ! -f $FIN ] ; then echo "No such a file: $FIN" ; fi FOUT="`echo $FIN | cut -f 1 -d .`.mp4" FPS= if [ $FPS ] ; then FPS="-r $FPS" ; fi # 映像のビットレート BPS=150k # オーディオのビットレート AUDIOBITRATE=80k # 画像サイズ RESOLUTION=512x384 #CROP="-cropleft 8 -cropright 8" # 音声ボリューム VOL= if [ $VOL ] ; then VOL="-vol $VOL" ; fi # 音声サンプルレート AR= if [ $AR ] ; then AR="-ar $AR" ; fi echo "encoding: $FIN ===> $FOUT" QOPT="-qcomp 0.7 -qmin 20 -qmax 41 -qdiff 10" $FFMPEG -y -i $FIN -pass 1 -passlogfile $LOG -vcodec libx264 -level 30 -b $BPS $FPS \ $QOPT -me_method umh -subq 7 -trellis 2 -coder ac -g 250 -bf 3 \ -b_strategy 1 -directpred 2 -partitions parti4x4+partp8x8+partb8x8 \ $CROP -sws_flags lanczos -s $RESOLUTION \ -me_range 32 -sc_threshold 50 -flags loop \ -cmp chroma -refs 5 -acodec libfaac -ab $AUDIOBITRATE $VOL $AR -async 100 \ -threads 0 $FOUT $FFMPEG -y -i $FIN -pass 2 -passlogfile $LOG -vcodec libx264 -level 30 -b $BPS \ $QOPT -me_method umh -subq 7 -trellis 2 -coder ac -g 250 -bf 3 \ -b_strategy 1 -directpred 2 -partitions parti4x4+partp8x8+partb8x8 \ $CROP -sws_flags lanczos -s $RESOLUTION \ -me_range 32 -sc_threshold 50 -flags loop \ -cmp chroma -refs 5 -acodec libfaac -ab $AUDIOBITRATE $VOL $AR -async 100 \ -threads 0 $FOUT /bin/rm -f ${LOG}* /bin/rm x264_2pass.log exit 0
この shell コマンドをたとえば h264encode.sh とすると、
./h264encode.sh movie.mov
とすると、movie.mp4 が吐き出されます。音声はAACになります。
ffmpeg は HE-AAC v2 のデコーダをサポートしていますが、エンコーダは未サポートのようです。まぁ、このあたりは時間が解決するでしょう。
中国からの越境大気汚染
先日、北海道の摩周湖の森が立ち枯れするニュースが報道ステーションで紹介されました。立ち枯れの原因のひとつが、中国からの越境大気汚染であるとう話でした。
そこで、昔作った古い動画を思い出し、再うpしました。
動画でも紹介していますが、工場からの排ガスには窒素酸化物(NOx)や揮発性有機化合物(VOC)が含まれています。これらの有害物質は、排出源である工場に公害対策を施せば排出を抑えることができます。しかし中国では垂れ流し状態のようです。
窒素酸化物や揮発性有機化合物は、紫外線を受けると酸素からオゾンが生成される反応過程の触媒になります。ここで生成されるオゾンが有害なのです。いわゆる光化学スモッグというヤツです。これが偏西風に流されて、中国から日本にやってきます。
成層圏にあるオゾン(オゾン層)は、紫外線を吸収するので、我々にとってはありがたい存在ですが、対流圏にあるオゾンは人体に有害な影響をおよぼします。
日本も昔は、国内の排出源が原因で光化学スモッグが発生していました。現在では国内の排出源に対策が施されて、一時期は光化学スモッグの発生が減っいました。しかし、最近はまた増加しはじめています。原因は、中国からの越境大気汚染と考えるのが妥当なようです。
講演資料を転載しても良いか
最近の研究会では、講演資料のパワーポイントやPDFファイルをウェブにアップロードして、収録代わりにすることが多い。昔は収録を紙で印刷して製本していたが(していたようだけど)、講演資料をそんまま見れるほが何かと便利だ。
たまに見かけるのが、講演資料の転載だ。調べ物をするためにググっていると、自分が作ったパワーポイントのスライドに出くわすことがある。どこかで見たことがあるスライドだなーと思っていると、実は自分が作ったスライドだったりするのだ。
無断で使う(1次作成者に了解を得ずに使うこと)のはべつに良い。いちいち許可を求められても、面倒なだけだ。しかし、せめて引用元や出典を明らかにしてほしい。
と思うのはボクだけだろうか?
転載されるスライドは、自分の研究成果の部分ではなくて、たいていは、イントロの包括的なレビューの部分だったりするんだよね。たくさんの文献を調べるのって結構大変なんだよ。。。
Windows で Emacs + tramp
Emacs がないと生きていけません。はい。Emacs がないと作業効率が半減してしまいます。Tramp があるとさらに便利。Tramp は ssh を使ってリモートマシンのファイルにシームレスにアクセスできる最強プログラムだ。
日本語が入力可能な Emacs
Windows で Emacs を使う場合、いくつかの選択肢がある。Windows 付属の MS-IME で日本語を入力する場合、選択肢はつぎの2つくらいだろうか:
- 本家 Emacs + NTEmacs_JP の IME パッチ
- gnupack の NTEmacs
- すでにビルドしてあるので楽です。ボクは横着なので、今回はこれを使う。
とうわけで、今回は後者の楽チンモードでいくことにする。
Plink
Windows で tramp を使うとき、ssh を plink で代替する。Cygwin 付属の ssh では tramp がうまく動作しないからだ。Plink は、PuTTY をインストールすると Program Files (x86)/PuTTY/plink.exe として入る。
ちなみに、本家 PuTTY は日本語が通るので、あえて PuTTYjp をインストールする必要はない。
Emacs の設定
日本語関係
日本語入力に関する設定はこちらを参考にした。
(prefer-coding-system 'utf-8-unix) ; 日本語入力のための設定 (set-default-font "MS ゴシック-10.5") (setq default-input-method "W32-IME") ;標準IMEの設定 (w32-ime-initialize) ;IMEの初期化 (set-cursor-color "red") ;IME OFF時の初期カーソルカラー (setq w32-ime-buffer-switch-p nil) ;バッファ切り替え時にIME状態を引き継ぐ ;IME ON/OFF時のカーソルカラー (add-hook 'input-method-activate-hook (lambda() (set-cursor-color "green"))) (add-hook 'input-method-inactivate-hook (lambda() (set-cursor-color "red")))
Plinkへのパスを設定
plink.exe にパスを通す。普通は
(setq exec-path (cons "c:/Program Files (x86)/PuTTY" exec-path))
としたいところだが、この方法では PATH は通るのだが、なぜか tramp から呼べない。
次のようにするとうまくいく*1。
(setenv "PATH" (concat "C:\\Program Files (x86)\\PuTTY" ";" "C:\\cygwin\\usr\\local\\bin" ";" "C:\\cygwin\\usr\\bin" ";" "C:\\cygwin\\bin" ";" (getenv "PATH")))
環境変数 PATH に直接設定するのだ。ググッてみるとみなさんこれに苦労している様子。この方法が一番簡便な方法だと思う。
Tramp の設定
tramp の設定は次のようにする:
(require 'tramp) (setq tramp-default-method "plink") (setq tramp-shell-prompt-pattern "^[ $]+")
とくに変わったところはない。