国立国会図書館インターネット資料収集保存事業 (WARP) で保存された、気象庁
ホームページ 2014年11月1日現在のスナップショットが公開されました。
http://warp.da.ndl.go.jp/waid/3566
このところ毎月更新だったのに、10月だけ14日だったから、これからは保存間隔
を長くしようとしているのかと心配しましたが、どうもそういうこ とでもない
ようです。
配信資料に関する技術情報でいうと、第４０３号までがpermalinkを獲得したこ
とになります。
http://warp.da.ndl.go.jp/info:ndljp/pid/8801546/www.data.jma.go.jp/add/suishin/cgi-bin/jyouhou/jyouhou.cgi
2014-12-17
技術情報第408号：平成27 年６月の３か月、暖・寒候期予報関連の配信資料変更について
17日付で
配信資料に関する技術情報第408号：平成27 年６月の３か月、暖・寒候期予報関連の配信資料変更について（配信資料に関する技術情報（気象編） 第301 号 関連）http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/408.pdf
配信資料に関する技術情報第408号：平成27 年６月の３か月、暖・寒候期予報関連の配信資料変更について（配信資料に関する技術情報（気象編） 第301 号 関連）http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/408.pdf
というのが出ています。
2014-12-08
配信資料に関する技術情報第４０７号 積雪域解析の改良に伴うメソモデルの冬季の地上気温予測の改善について
11月25日付け技術資料、27日００UTC初期値から実施されたものです。
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/407.pdf
メソモデルの積雪の有無は、従来は全球モデル用の解析を用いていました。
その説明はちょっと古いですが技術資料６４号にあります。
http://warp.da.ndl.go.jp/info:ndljp/pid/8783345/www.data.jma.go.jp/add/suishin/jyouhou/pdf/64.pdf
SYNOP 通報に含まれる積雪深を同化するわけですけれど、積雪深は必須項目では
ありませんし、電文の構造上も「積雪がないことを観測した」と「積雪深は観
測・通報 しないことになっている」が区別できないようになっているので、
積雪域の境界から外に広がりやすいバイアスがあるわけですね。
それをなんとか対策しようという努力の一つです。
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/407.pdf
メソモデルの積雪の有無は、従来は全球モデル用の解析を用いていました。
その説明はちょっと古いですが技術資料６４号にあります。
http://warp.da.ndl.go.jp/info:ndljp/pid/8783345/www.data.jma.go.jp/add/suishin/jyouhou/pdf/64.pdf
SYNOP 通報に含まれる積雪深を同化するわけですけれど、積雪深は必須項目では
ありませんし、電文の構造上も「積雪がないことを観測した」と「積雪深は観
測・通報 しないことになっている」が区別できないようになっているので、
積雪域の境界から外に広がりやすいバイアスがあるわけですね。
それをなんとか対策しようという努力の一つです。
2014-12-07
天気図の図郭を調べる
ちょっと AUPQ78 と AUAS50 の図郭を調べたいと思ったわけです。
まずは AUPQ78.
http://www.jma.go.jp/jp/metcht/kosou.html にPDF がありますから落としてきて、PDF の上で位置を調べるのは簡単ではないのでラスタ化しちゃいましょう。解像度はなんでもいいのでエイヤっときめて
$ convert -density 288 -monochrome aupq78_00.pdf aupq78_00.png
とかしてラスタ化してドローツールで経緯線交点の座標を調べることにしましょう。
地図投影は、自分で計算してもいいのですが、いまどきは proj とかいうツールがあって、
$
というようなことをして標準入力から経緯度対を食わせると投影された空間での座標値（メートル単位がでてきます）。で、これと経緯線交点のピクセル番号の線形回帰をかければよいわけです。
一つ面倒くさいのが、ピクセル番号は北から南に数えるのに、地図投影面のY座標は南から北に測ることで、しかたがないので標準経度を 90 度西に移して XY 軸をいれかえています。
ついで AUAS50 はラスタ画像が http://www.jma.go.jp/jmh/umiinfo.html
にありますから取ってきて、同じようなことをすればいいです。
Rubyやっつけコードと入出力などつづきはこちら
https://gist.github.com/etoyoda/ffb5a8df48e0fa71862d
まずは AUPQ78.
http://www.jma.go.jp/jp/metcht/kosou.html にPDF がありますから落としてきて、PDF の上で位置を調べるのは簡単ではないのでラスタ化しちゃいましょう。解像度はなんでもいいのでエイヤっときめて
$ convert -density 288 -monochrome aupq78_00.pdf aupq78_00.png
とかしてラスタ化してドローツールで経緯線交点の座標を調べることにしましょう。
地図投影は、自分で計算してもいいのですが、いまどきは proj とかいうツールがあって、
$
proj +proj=stere +lat_ts=60 +lat_0=90 +lon_0=50 +k_0=1.0 +x_0=0 +y_0=0というようなことをして標準入力から経緯度対を食わせると投影された空間での座標値（メートル単位がでてきます）。で、これと経緯線交点のピクセル番号の線形回帰をかければよいわけです。
一つ面倒くさいのが、ピクセル番号は北から南に数えるのに、地図投影面のY座標は南から北に測ることで、しかたがないので標準経度を 90 度西に移して XY 軸をいれかえています。
ついで AUAS50 はラスタ画像が http://www.jma.go.jp/jmh/umiinfo.html
にありますから取ってきて、同じようなことをすればいいです。
Rubyやっつけコードと入出力などつづきはこちら
https://gist.github.com/etoyoda/ffb5a8df48e0fa71862d
結論
(1) AUPQ78
proj: +proj=stere +lat_ts=60 +lat_0=90 +lon_0=50 +k_0=1.0 +x_0=-1962800 +y_0=7405800 +ellps=GRS80
x pixel size: 3782 m
y pixel size: 3785 m
x range: 173 to 2043
y range: 78 to 2822
(2) AUAS50
proj: +proj=stere +lat_ts=60 +lat_0=90 +lon_0=50 +k_0=1.0 +x_0=-1696000 +y_0=7268100 +ellps=GRS80
x pixel size: 5265 m
y pixel size: 5282 m
x range: 8 to 1723
y range: 18 to 2111
proj: +proj=stere +lat_ts=60 +lat_0=90 +lon_0=50 +k_0=1.0 +x_0=-1962800 +y_0=7405800 +ellps=GRS80
x pixel size: 3782 m
y pixel size: 3785 m
x range: 173 to 2043
y range: 78 to 2822
(2) AUAS50
proj: +proj=stere +lat_ts=60 +lat_0=90 +lon_0=50 +k_0=1.0 +x_0=-1696000 +y_0=7268100 +ellps=GRS80
x pixel size: 5265 m
y pixel size: 5282 m
x range: 8 to 1723
y range: 18 to 2111
2014-12-01
2014-11-26
ssh を通じてパイプから読む tar にはなぜ -B が必要か
説明を書くことがあったので、なくさないように保存。間違いがあったら教えてください。
テープは全然ちがいます：
ファイルというものは、種類によって特性がいろいろあります。
特性とは、いいかえると、できることと、できないことです。
- メディア容量いっぱいまで無制限に伸ばせる有限のバイト列が、1つのプロセスにつながっている
- lseek(2) によって任意バイト目のに位置づけすることができて（後退も可能）、
- その現在位置から任意個バイトを read(2) することができ、
- ファイル終端で read するとゼロが返ることで、「読めるわけではないがエラーでもない状態」が通知され、
- あるいは現在位置から任意個バイトを write(2) することもできてその後は破壊されず、
- 要すれば現在位置から後の全データを truncate(2) によって破棄することもできる。
- バイトストリーム（遡れない流れのイメージ）の両側がプロセスにつながっており、
write する側と read する側が決まっている - write したバイト数だけパイプに入って、それ以下の数だけ read したときはその内容が得られる
パイプに入っているバイト数を超えた数を read すると、入っているバイト数だけしか読めない - パイプに入るバイト数が決まっている（512バイトとか、Linuxだと4096バイトとか、そんなにデカくない）。
満杯のパイプに書き込むと write がブロック（吸い出してもらえるまで止まる）し、
空のパイプから読み出すと read がブロック（書き込んでもらえるまで停止）する - lseek(2) は常にエラーになり、つまり後退はできない
- 書き込み側プロセスが先にパイプを閉じたとき、ファイルの終端と同じ状態になり、読み側 read() に 0 が返される
逆に、読み込み側プロセスが先にパイプを閉じたとき、書き込み側が write(2) すると、シグナル SIGPIPE を受ける (ふつう13番だから exit code 141 に見える)
TCPソケットもパイプに似た特徴を持ちますが、書き込み側プロセスが書いたバイト列が一気にすぐ読み出し側プロセスに届くわけでなく（なにせ別ホストですからね）、read で何バイト取れるかはもっと予想がつきません。
- ファイルはバイトではなくブロックの列
- ブロックは「1回 write したバイト列」、昔は固定長だったみたいだが、いまどきは可変長、つまり書き込み側が指定できる（512バイトの倍数限定かも）
- ブロックはテープに書かれていて、read はブロック単位でしか行えない。
ブロック長以下の read はブロック先頭だけが読み出され、ブロック長を超える read はブロック長だけしか読み出せない - ファイル内の read 以外での前後移動はできないとおもったほうがよい。
- テープ上のファイルの終わりは書き込みプロセスが close したら勝手にできる
テープに書き込む際は、メディア上の後続のファイルは必ず破壊されるので、ftruncate にあたる別操作はない（必ず行われる） - テープ上のファイルの終わりでは read(2) が 0 を返すことはディスクファイルと同じ
- 巻き戻しをしないテープデバイスでは、ファイルの終わりを読み出して close した直後に、次のファイルに移動している
このような特性は Linux なら st(7) や pipe(7) で説明されている、はずなのですが、あの文章では一見さんお断りですわね。
ともあれそれをふまえると、-B やら SIGPIPE の問題もよくわかると思います。
- tar は、固定のブロック長で read/write を行う、つまり、1ブロックが1回で読めることを前提にしている
- ブロック長は 512 バイトかける -b オプションの数
- tar アーカイブに入れるファイル長がブロック長の倍数でないときは、末尾にゼロが埋められる（パディング）
- テープから tar が読む場合、書き込んだときのブロック長が読み出されるので、自動的にブロック長を判定できる
- パイプから tar が読む場合（特にネットワーク越しならなおさら）は、書き込んだときのブロック長はわからないし、1ブロックが1回で read できるとも限らない。
1ブロック(と思い込んでいるバイト数）が1回で読めない場合、続きの読み出しをリトライさせるのが -B オプション。 - また、パイプから読む tar はブロック長がわからないので、必要なファイルを解読したら終了してしまうようになっていると（gtar はそうではないと思う）、
書き込み側はパディングを続けている間に読み出し側が終了して、SIGPIPE を受けて爆死、ということになるのでしょう。
2014-11-21
ソフトウェアデザイン12月号にコンテナ型仮想化環境 Docker の記事がある
正直これまでどんなもんだかまったく分からなかったのだが、ハイパーバイザと
比べると、 chroot(2) の進化の系列にあるという説明は腑に落ちた。
セマンティクスが普段と違って使い方が覚えられないものは普及しない、という
のは、まあ他にもあるかもしれないが SELinux のことをいっているのだろう。
http://gihyo.jp/magazine/SD/archive/2014/201412
比べると、 chroot(2) の進化の系列にあるという説明は腑に落ちた。
セマンティクスが普段と違って使い方が覚えられないものは普及しない、という
のは、まあ他にもあるかもしれないが SELinux のことをいっているのだろう。
http://gihyo.jp/magazine/SD/archive/2014/201412
平成26年度 数値予報研修テキスト
平成26年度 数値予報研修テキスト が気象業務支援センター http://www.jmbsc.or.jp/ から発売になったそうです。
そのうち、気象庁ホームページ http://www.jma.go.jp/jma/kishou/books/nwptext/nwptext.html にも掲載されるはずですが、このボリュームだと印刷物をみたいという方もあると思いますので、上記ご参考まで。
そのうち、気象庁ホームページ http://www.jma.go.jp/jma/kishou/books/nwptext/nwptext.html にも掲載されるはずですが、このボリュームだと印刷物をみたいという方もあると思いますので、上記ご参考まで。
2014-11-13
配信資料に関する技術情報 第４０６号 地方海上分布予報の提供開始について
11月12日づけで発出された、標記資料が気象庁ホームページに掲載されました。
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/406.pdf
画像（PNG）形式とGRIB2形式の両方で提供があります。GRIB2マニア的には、
PDT4.0なのは普通ですが、ビットマップが使われてい るのが特徴的でしょうか。
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/406.pdf
画像（PNG）形式とGRIB2形式の両方で提供があります。GRIB2マニア的には、
PDT4.0なのは普通ですが、ビットマップが使われてい るのが特徴的でしょうか。
「東京」の気象観測地点の移転について（お知らせ出ました）
お問い合わせは、このお知らせに書かれている東京管区気象台の窓口にお願いいたします。
http://www.jma-net.go.jp/tokyo/sub_index/tokyo/kitanomaru/kitanomaru.html
2014-11-11
世界の自然災害の犠牲者数は20世紀前半とそれ以後でみれば大きく減っているらしい
ちょっと興味があってぐぐってみたらこんなページがみつかった。
http://www.ourworldindata.org/data/environmental-change/natural-catastrophes/
このデータの信憑性についてはよくわからないが、20世紀前半までは10万人ちか
い犠牲者を伴うような疫病・水害・旱魃があって、それはここ数十年はみられな いというこ
とはそれなりに説得力はある。
どうやって人類はそれを乗り越えたかというと衛生、治水、灌漑、いろいろあろうが、それをひとま
とめで呼ぶなら文明と言ってもいいんじゃないかと思う。一定の文明があたり まえに
なった後だけを論じれば、気候変動で文明が脆弱になってきているという論はできるのかも
しれないが、それなら文明開化以前まで視野に入れないと、ものをよく見 た気がしない。
2014-11-10
気象庁平年値（1981～2010）第4版
支援センター http://www.jmbsc.or.jp/ 曰く、
「気象庁平年値（1981～2010）第4版」が10月30日に発売になったそうです。
「気象庁平年値（1981～2010）第4版」が10月30日に発売になったそうです。
観測値はいろいろの理由であとから訂正されます。何年も経ってからも訂正は多数あるんだそうで、それをとりまとめて平年値が更新されます。
2014-11-05
配信資料に関する技術情報（気象編）第404号「黄砂予測モデルの改良について」出てます
平成26年10月29日付 配信資料に関する技術情報（気象編）第404号「黄砂予測モ
デルの改良について」が気象庁ホームページに掲載されました。
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/404.pdf
モデル開発としては、陸面モデルが置き換わったのが傍目からみても画期的なこ
とです。「そんなによいなら他のモデルにもなぜすぐ採用しない」と聞 かれそ
うですが、黄砂モデルは目的がシャープに絞られていますから、短期予報である
にもかかわらずユーラシアの春先積雪有無の予測がクリティカル という特別な
力点があります。他になんの影響もなく積雪だけが当たるようになるならば、何
も考えないでいいのですが、そう甘くはありません。融雪 速度は日射のうちど
の割合を大気との熱交換に使うかですから、さまざまなところが変わってきま
す。他モデルに使うには、それぞれの観点で評価して 現行以上の精度を確認し
なければならないわけです。
積雲対流モデルについては、よく知らないと申し上げておくのが正直でしょう。
デルの改良について」が気象庁ホームページに掲載されました。
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/404.pdf
モデル開発としては、陸面モデルが置き換わったのが傍目からみても画期的なこ
とです。「そんなによいなら他のモデルにもなぜすぐ採用しない」と聞 かれそ
うですが、黄砂モデルは目的がシャープに絞られていますから、短期予報である
にもかかわらずユーラシアの春先積雪有無の予測がクリティカル という特別な
力点があります。他になんの影響もなく積雪だけが当たるようになるならば、何
も考えないでいいのですが、そう甘くはありません。融雪 速度は日射のうちど
の割合を大気との熱交換に使うかですから、さまざまなところが変わってきま
す。他モデルに使うには、それぞれの観点で評価して 現行以上の精度を確認し
なければならないわけです。
積雲対流モデルについては、よく知らないと申し上げておくのが正直でしょう。
2014-11-04
libecbufr を読んでみる（反復・次元に関するデータ構造はどうやって作られているか）
TEMP BUFR を bufr_decoder -dump していると
007007 {R=1}{5002=52.419998,6002=-4,4025=30} 1685
みたいな出力にでくわすことがある。
この中括弧はなんだろう。
0.8.5 のソースコード、 API/Sources/bufr_meta.c の
bufr_print_rtmd_data(char *outstr, BufrRTMD *rtmd) あたりでやっているよ
うだ。
まず、 rtmd == NULL ならば、この中括弧群は一切生成しないで関数を抜ける。
{R=1} というのが反復記述子による反復数であることはだいたい察しがつくけれ
ど、それは bufr_print_rtmd_repl() でやっている。
rtmd->nesting が真の場合に "R=" が表示され、 rtmd->nb_nesting が2以上の
場合は R=1.1.1 のようにピリオド区切りで数が表示される。
被表示数は rtmd->nesting[i] である。
（つまり rtmd->nesting が偽の場合は "{}" が表示されるロジックなんだが、
それでいいの？ おそらくそれは起こらない想定だろうけど）
第2の括弧ブロックは、 rtmd->nb_tlc が真である場合に表示され、
rtmd->nb_tlc 個だけコンマ区切りの記述子・値ペアが表示される。
記述子は rtmd->tlc[i].descriptor, 値は rtmd->tlc[i].value である。
まあ、どうせ、次元記述子の修飾関係を明示するというつもりなのはわかるのだ
が、出現条件が知りたい。
ここらでコールツリーの上方へ探索。
bufr_print_rtmd_data() を読んでいるのは API/Sources/bufr_dataset.c の
bufr_fdump_dataset(BUFR_Dataset *dts, FILE *fp) である。
それを呼んでいるのは同じソースの bufr_dump_dataset(BUFR_Dataset *dts,
const char *filename) である。
それを呼んでいるのは Utilities/bufr_decoder.c の run_decoder(void) <=
main() である。
まあ、なんというか、 main を見つけると安心するよね。
さて、 run_decoder から下方探索はしんどいので後回しにして、
BufrRTMD::nb_nesting を設定しているのは bufr_meta.c:
bufr_create_rtmd(int count) である。
これは単純に反復記述子を数えているようである。
BufrRTMD::nb_tlc を設定しているのは bufr_ddo.c:
bufr_assoc_location(BufrDescriptor *bc, BufrDDOp *ddo) である。
これは ddo->current_location の各要素から記述子と値をとっている。
これを呼んでいるのは bufr_sequence.c: bufr_apply_Tables(BufrDDOp *ddoi,
BUFR_Sequence *bsq, BUFR_Template *tmplt, ListNode *current, int
*errcode) である。
これは多数回呼ばれるので上方探索が難しい。
あきらめて dts に戻る。
bufr_print_rtmd_data に食わされる BufrRTMD は bufr_fdump_dataset() 内で
は bcv->meta と呼ばれている。
これは bcv = bufr_datasubset_get_descriptor(subset, j) といって抽出される。
subset は bufr_get_datasubset(dts, i) といって dts->datasubsets から抽出
される。
BUFR_Dataset::datasubsets は DataSubsetArray 型でありそれは ArrayPtr 型
のエイリアスである。
ArrayPtr 型は名目上は char * と定義されているけれど、それは実際には
Array 構造体をさしている。
管理ルーチン arr_create(), arr_add() など以外が内部を操作しないようにオ
ペーク化しているのである。
Array の構造は Array::grow の値によって大きく異なる。
Array::grow が零または負であれば固定長配列で、 Array::eles が指す配列は
Array そのものと一体的に malloc される。
Array::size が1要素の大きさ、Array::total = [arr_create() の引数 len] が
要素数である。
Array::grow が正であれば可変長配列で、 初期には Array そのものとは別に
Array::total 個の要素が確保され、
不足時には Array::grow 個増やして realloc(3) される。
さて run_decoder() 内で dts の構築は bufr_decode_message(BUFR_Message
*msg, BUFR_Tables *tables) がしている。
その中で dts->datasubsets は ...
今日はちょっとここらでおしまい。たぶん続きは書かれない。
007007 {R=1}{5002=52.419998,6002=-4,4025=30} 1685
みたいな出力にでくわすことがある。
この中括弧はなんだろう。
0.8.5 のソースコード、 API/Sources/bufr_meta.c の
bufr_print_rtmd_data(char *outstr, BufrRTMD *rtmd) あたりでやっているよ
うだ。
まず、 rtmd == NULL ならば、この中括弧群は一切生成しないで関数を抜ける。
{R=1} というのが反復記述子による反復数であることはだいたい察しがつくけれ
ど、それは bufr_print_rtmd_repl() でやっている。
rtmd->nesting が真の場合に "R=" が表示され、 rtmd->nb_nesting が2以上の
場合は R=1.1.1 のようにピリオド区切りで数が表示される。
被表示数は rtmd->nesting[i] である。
（つまり rtmd->nesting が偽の場合は "{}" が表示されるロジックなんだが、
それでいいの？ おそらくそれは起こらない想定だろうけど）
第2の括弧ブロックは、 rtmd->nb_tlc が真である場合に表示され、
rtmd->nb_tlc 個だけコンマ区切りの記述子・値ペアが表示される。
記述子は rtmd->tlc[i].descriptor, 値は rtmd->tlc[i].value である。
まあ、どうせ、次元記述子の修飾関係を明示するというつもりなのはわかるのだ
が、出現条件が知りたい。
ここらでコールツリーの上方へ探索。
bufr_print_rtmd_data() を読んでいるのは API/Sources/bufr_dataset.c の
bufr_fdump_dataset(BUFR_Dataset *dts, FILE *fp) である。
それを呼んでいるのは同じソースの bufr_dump_dataset(BUFR_Dataset *dts,
const char *filename) である。
それを呼んでいるのは Utilities/bufr_decoder.c の run_decoder(void) <=
main() である。
まあ、なんというか、 main を見つけると安心するよね。
さて、 run_decoder から下方探索はしんどいので後回しにして、
BufrRTMD::nb_nesting を設定しているのは bufr_meta.c:
bufr_create_rtmd(int count) である。
これは単純に反復記述子を数えているようである。
BufrRTMD::nb_tlc を設定しているのは bufr_ddo.c:
bufr_assoc_location(BufrDescriptor *bc, BufrDDOp *ddo) である。
これは ddo->current_location の各要素から記述子と値をとっている。
これを呼んでいるのは bufr_sequence.c: bufr_apply_Tables(BufrDDOp *ddoi,
BUFR_Sequence *bsq, BUFR_Template *tmplt, ListNode *current, int
*errcode) である。
これは多数回呼ばれるので上方探索が難しい。
あきらめて dts に戻る。
bufr_print_rtmd_data に食わされる BufrRTMD は bufr_fdump_dataset() 内で
は bcv->meta と呼ばれている。
これは bcv = bufr_datasubset_get_descriptor(subset, j) といって抽出される。
subset は bufr_get_datasubset(dts, i) といって dts->datasubsets から抽出
される。
BUFR_Dataset::datasubsets は DataSubsetArray 型でありそれは ArrayPtr 型
のエイリアスである。
ArrayPtr 型は名目上は char * と定義されているけれど、それは実際には
Array 構造体をさしている。
管理ルーチン arr_create(), arr_add() など以外が内部を操作しないようにオ
ペーク化しているのである。
Array の構造は Array::grow の値によって大きく異なる。
Array::grow が零または負であれば固定長配列で、 Array::eles が指す配列は
Array そのものと一体的に malloc される。
Array::size が1要素の大きさ、Array::total = [arr_create() の引数 len] が
要素数である。
Array::grow が正であれば可変長配列で、 初期には Array そのものとは別に
Array::total 個の要素が確保され、
不足時には Array::grow 個増やして realloc(3) される。
さて run_decoder() 内で dts の構築は bufr_decode_message(BUFR_Message
*msg, BUFR_Tables *tables) がしている。
その中で dts->datasubsets は ...
今日はちょっとここらでおしまい。たぶん続きは書かれない。
2014-11-02
2014年11月3日、英国・オランダが文字形式の地上気象実況報（FM 12 SYNOP）の発信を停止します。今後はBUFRをお使いください
明日です。とうとうこの日がやって参りました。
世界気象機関（WMO）では全球気象監視計画（World Weather Watch Programme） の一環である Regional Basic Synoptic Network <URL:http://www.wmo.int/pages/prog/www/ois/rbsn-rbcn/rbsn-rbcn-home.htm> として加盟各国の地上・高層観測結果をリアルタイムに通報することとしています。
データを送るわけですから形式についても決まりがあり、WMO Manual on Codes <URL:https://www.wmo.int/pages/prog/www/WMOCodes.html> というものにまとめられています。そのうちこれまで実際に使われてきたものは、伝統的文字形式通報式（TAC: traditional alphanumeric codes）という、テキストというか電報を使うことを前提にして文字列でデータを表現するものでした。地上ならば地上気象実況報 FM 12 SYNOP です（具体は非公式ながら <URL:http://www.megakastro.gr/weather_agro/SYNOP_format%28FM-12%29.htm> がわかりやすいと思います）。
しかしTACにはいろいろ問題があり、WMOでは表参照型通報式（TDCF: table driven code form）というものへの移行を進めています。FM 94 BUFR （二進形式汎用気象通報式) と FM 95 CREX (文字形式) の2つがありますが、本則は BUFR であって CREX は通信システムの都合上テキストしか流せない場合ということになっています。
さてずいぶん昔に作られた移行計画というのがありまして、SYNOPを含む主要な通報については2014年11月をもってTAC-TDCFの平行配信を終了、ということになっています。つまり11月からは、各国の判断次第でTACの送信を止めることができる、というわけです。かわりに使ってほしいという BUFR については、気象庁から配信資料に関する技術情報第３３４号というのがでています（国立国会図書館蔵だからこのURLは変わらないよ）。
さて各国判断次第、というその先頭を切って11月3日に英国・オランダが、11月4日にはアイルランドがそれぞれ FM 12 SYNOP の配信停止を予告しています。
準備はできているはずなのですが、明日、どうなるか、 ちょっと緊張しています。
世界気象機関（WMO）では全球気象監視計画（World Weather Watch Programme） の一環である Regional Basic Synoptic Network <URL:http://www.wmo.int/pages/prog/www/ois/rbsn-rbcn/rbsn-rbcn-home.htm> として加盟各国の地上・高層観測結果をリアルタイムに通報することとしています。
データを送るわけですから形式についても決まりがあり、WMO Manual on Codes <URL:https://www.wmo.int/pages/prog/www/WMOCodes.html> というものにまとめられています。そのうちこれまで実際に使われてきたものは、伝統的文字形式通報式（TAC: traditional alphanumeric codes）という、テキストというか電報を使うことを前提にして文字列でデータを表現するものでした。地上ならば地上気象実況報 FM 12 SYNOP です（具体は非公式ながら <URL:http://www.megakastro.gr/weather_agro/SYNOP_format%28FM-12%29.htm> がわかりやすいと思います）。
しかしTACにはいろいろ問題があり、WMOでは表参照型通報式（TDCF: table driven code form）というものへの移行を進めています。FM 94 BUFR （二進形式汎用気象通報式) と FM 95 CREX (文字形式) の2つがありますが、本則は BUFR であって CREX は通信システムの都合上テキストしか流せない場合ということになっています。
さてずいぶん昔に作られた移行計画というのがありまして、SYNOPを含む主要な通報については2014年11月をもってTAC-TDCFの平行配信を終了、ということになっています。つまり11月からは、各国の判断次第でTACの送信を止めることができる、というわけです。かわりに使ってほしいという BUFR については、気象庁から配信資料に関する技術情報第３３４号というのがでています（国立国会図書館蔵だからこのURLは変わらないよ）。
さて各国判断次第、というその先頭を切って11月3日に英国・オランダが、11月4日にはアイルランドがそれぞれ FM 12 SYNOP の配信停止を予告しています。
準備はできているはずなのですが、明日、どうなるか、 ちょっと緊張しています。
2014-10-30
2014-10-23
積読を処理していたら流体力学会誌「ながれ」２０１０年12月号だけがぽろりとでてきたから読んでみる
当然ここ数ヶ月のがたくさん机につまれているのですけど、流体力学会は発行後半年たたないとウェブ公開されないからそっちの会誌読みはまた後日。そうやって忘れちゃうんですけどね。
で、紙の山を片付けていたら、どういうわけだか２０１０年12月号だけ出てきた。なぜ読まないで保存していたのかわからないけど、開いてみると、年会特集号ということでちょっと現場の人間にもとっつきやすいです。
http://www.nagare.or.jp/publication/nagare/archive/2010/6.html
小野寺直幸・青木尊之・小林宏充 GPUによるラージエディ・シミュレーションの高速化
http://www.nagare.or.jp/download/noauth.html?dd=assets/files/download/noauth/nagare/29-6/29-6tokushu7.pdf
主題じゃなくて申し訳ないけれど、緒言の「LESとは」がとてもよい。いままで勘違いしていたけれど、第一原理計算（DNSという）ではないのですね。小スケールの乱流を気象で言うところのパラメタリゼーションしているので、固定境界付近で問題が生じるのだという。そんなことも知らないのかと言われるとえへへというしかないですが。
最適化についてはカーネル対通信時間の比が問題という、わかりやすいお話。よく知らないけど。
田井 明・齋田倫範・矢野真一郎・小松利光 潮汐振幅の全球的な長期変化
http://www.nagare.or.jp/download/noauth.html?dd=assets/files/download/noauth/nagare/29-6/29-6tokushu8.pdf
M２潮の振幅を数十年スケールで追うと有意に変動しているのだといいます。はじめに、で地球温暖化に起因する海水準変動について語ってしまっているので、せめて振幅の増減が海水準の上昇と整合的か否かについて一言ほしいと思ってしまいますが、まあ、それはこれからというのでしょう。
竹原幸生・江藤剛治 風波砕波下における渦運動のPTV計測
http://www.nagare.or.jp/download/noauth.html?dd=assets/files/download/noauth/nagare/29-6/29-6tokushu10.pdf
空気が水中に取り込まれることに感心を持っているようです。物質交換への関心かな。
足立高弘・新井晶大 回転円すいの外表面を上昇する液膜流れ
http://www.nagare.or.jp/download/noauth.html?dd=assets/files/download/noauth/nagare/29-6/29-6tokushu13.pdf
こんな方法で効率の良い噴霧器が作れるとは思いませんでした
2014-10-21
気象モデルを真に回転楕円体に対応させる研究と座標参照系
発端は WIS データカタログで座標系をどう書くか、というか、GRIB データで地球が平均半径 6371.229 km の球となっているのに対して、地理情報メタデータではどういうCRS（座標参照系て訳すのかな）を与えたらいいのかと聞かれたのですよ。
CBS-IPET-MDRD フォーラムの次のスレッドご参照：
https://groups.google.com/a/wmo.int/forum/#!topic/cbs-ipet-mdrd/bYa0kl9Kp3w
ちなみに上記地球半径については過去記事ご参照：
http://toyoda-eizi.blogspot.jp/2012/09/mean-radius-of-earth.html
で、気象モデルというのはたしかに地球を真球と仮定して方程式系を構成するわけですが、だからといって真球ベースのCRSを作って与えなきゃいけないというのは飛躍が過ぎます。いつも言っていることですが、
・データは何に使うかを詰めなければまともに検討できない
・事物の本質を記述すれば万事に応用できるというような発想は百害あって一利なし
なのであります。だからセマンティックウェ…と脱線するのはおいといて、で、突き詰めていえば
・CRSは地図がずれないようにデータにつけた注
なのですから、気象モデルに流し込む観測が持っている経緯度は実のところWGS84である（2006年CBS臨時会合勧告1）ことを思い出すと、ここはモデルの方程式系が何であろうが知ったことではなく、すべてのモデル出力は WGS84 による経緯度座標 geographical coordinate system と言っておけばいいのです。間違って球ベースのCRSなんか定義してしまったら、そこでいう緯度は地心緯度だということになって、最悪 21 km とかずれてしまいます。
地心緯度と地理緯度の図：
http://upload.wikimedia.org/wikipedia/commons/0/06/Two-types-of-latitude.png
（もちろんモデル出力が経緯度格子ではなく、地図投影された座標系上の等間隔格子に出されるのであれば、その地図投影の記述はなされるべきですがそれは別の話だし、いまどきそれが WGS 84 ベースでない例はUK National Grid みたいに極めて限られるはず。）
…と断言してしまってからその筋の人に聞いてみると、気象モデルで回転楕円体の効果を考慮しようという研究も最近はあるようです。
P. Bénard (2014, QJRMS): An assessment of global forecast errors due to the spherical geopotential approximation in the shallow‐water case
http://www.readcube.com/articles/10.1002/qj.2349
なんだかロスビー波の位相速度が地球離心率εのオーダーで変わるというので、2週間予報にとってはたしかに馬鹿にならないような気もしますが、まあいずれにしても今のところの現業気象界ではそこまでは考えていません。
ちなみに今のモデルでも地理緯度で観測と合わせるので、コリオリの力はあっているんですよね。だからジオポテンシャルとメトリックの誤差という言い方になるんだと思います。
で、元のスレッドの話はそれでは終わらなくて、INSPIRE では指定してもよい CRS が厳しく限定されているというんですね。
（ http://inspire-geoportal.ec.europa.eu/documentation/legal-and-tgs/ds/INSPIRE_DataSpecification_AD_v3.1/
の§6.1.2 あたり）
気圧座標はICAO標準大気で高度に換算せよ、と言われても、航空気象用でなければ異様ですし、さもなくば ISO 19111-2 で座標系を記述しろ、といわれてもエンコーディングの標準たとえば WKT2 (ISO 19162) は公刊されていません。UML だけ渡されてコンセプチュアルには表現できる、といわれても、あまりに無責任じゃないでしょうかINSPIREさんよ。まあそこまで怒ってもしょうがないので、とりあえず単に気圧ってかいとけば、といって様子見をしています。
なんで欧州の地理屋さんが欧州ローカルルールで気象機関の心配をしてくれない世話まで焼かなきゃいけないのか、と思わなくもないですが、まあ、WMO の専門家チームの共同議長だから仕方がありません。こういうことをやって初めて先進地の具体が教えてもらえるということもありますしね。
CBS-IPET-MDRD フォーラムの次のスレッドご参照：
https://groups.google.com/a/wmo.int/forum/#!topic/cbs-ipet-mdrd/bYa0kl9Kp3w
ちなみに上記地球半径については過去記事ご参照：
http://toyoda-eizi.blogspot.jp/2012/09/mean-radius-of-earth.html
で、気象モデルというのはたしかに地球を真球と仮定して方程式系を構成するわけですが、だからといって真球ベースのCRSを作って与えなきゃいけないというのは飛躍が過ぎます。いつも言っていることですが、
・データは何に使うかを詰めなければまともに検討できない
・事物の本質を記述すれば万事に応用できるというような発想は百害あって一利なし
なのであります。だからセマンティックウェ…と脱線するのはおいといて、で、突き詰めていえば
・CRSは地図がずれないようにデータにつけた注
なのですから、気象モデルに流し込む観測が持っている経緯度は実のところWGS84である（2006年CBS臨時会合勧告1）ことを思い出すと、ここはモデルの方程式系が何であろうが知ったことではなく、すべてのモデル出力は WGS84 による経緯度座標 geographical coordinate system と言っておけばいいのです。間違って球ベースのCRSなんか定義してしまったら、そこでいう緯度は地心緯度だということになって、最悪 21 km とかずれてしまいます。
地心緯度と地理緯度の図：
http://upload.wikimedia.org/wikipedia/commons/0/06/Two-types-of-latitude.png
（もちろんモデル出力が経緯度格子ではなく、地図投影された座標系上の等間隔格子に出されるのであれば、その地図投影の記述はなされるべきですがそれは別の話だし、いまどきそれが WGS 84 ベースでない例はUK National Grid みたいに極めて限られるはず。）
…と断言してしまってからその筋の人に聞いてみると、気象モデルで回転楕円体の効果を考慮しようという研究も最近はあるようです。
P. Bénard (2014, QJRMS): An assessment of global forecast errors due to the spherical geopotential approximation in the shallow‐water case
http://www.readcube.com/articles/10.1002/qj.2349
なんだかロスビー波の位相速度が地球離心率εのオーダーで変わるというので、2週間予報にとってはたしかに馬鹿にならないような気もしますが、まあいずれにしても今のところの現業気象界ではそこまでは考えていません。
ちなみに今のモデルでも地理緯度で観測と合わせるので、コリオリの力はあっているんですよね。だからジオポテンシャルとメトリックの誤差という言い方になるんだと思います。
で、元のスレッドの話はそれでは終わらなくて、INSPIRE では指定してもよい CRS が厳しく限定されているというんですね。
（ http://inspire-geoportal.ec.europa.eu/documentation/legal-and-tgs/ds/INSPIRE_DataSpecification_AD_v3.1/
の§6.1.2 あたり）
気圧座標はICAO標準大気で高度に換算せよ、と言われても、航空気象用でなければ異様ですし、さもなくば ISO 19111-2 で座標系を記述しろ、といわれてもエンコーディングの標準たとえば WKT2 (ISO 19162) は公刊されていません。UML だけ渡されてコンセプチュアルには表現できる、といわれても、あまりに無責任じゃないでしょうかINSPIREさんよ。まあそこまで怒ってもしょうがないので、とりあえず単に気圧ってかいとけば、といって様子見をしています。
なんで欧州の地理屋さんが欧州ローカルルールで気象機関の心配をしてくれない世話まで焼かなきゃいけないのか、と思わなくもないですが、まあ、WMO の専門家チームの共同議長だから仕方がありません。こういうことをやって初めて先進地の具体が教えてもらえるということもありますしね。
2014-10-17
回転楕円体からのポーラーステレオ図法
まず、半径 \(R\) の地球からのステレオ図法の順投影 \(f: \varphi, \lambda \to E, N\) は、
緯度を \(\varphi\) とすると
\[ r = 2 R \tan\left(\frac{\pi}{4} - \frac{\varphi}{2}\right) \]
\[ E = r \sin\left(\lambda - \lambda_0\right) \]
\[ N = -r \cos\left(\lambda - \lambda_0\right) \]
と表わされる。
ステレオ図法は正角図法であるから、その性質を壊さないためには、
なんらかの回転楕円体から球への等角写像 \(g: \varphi', \lambda' \to \varphi, \lambda\) の後に \(f\) を適用すればよい。
ステレオ図法は方位図法であるから、経度方向の伸縮があると図に裂け目ができてしまうし、両極は両極に写像されないといけない。
その条件を満たすありがたい等角写像があって
\[ \lambda = \lambda' \]
\[ \tan\left(\frac{\pi}{4} + \frac{\varphi}{2}\right) =
\tan\left(\frac{\pi}{4} + \frac{\varphi'}{2}\right)
\cdot \left(\frac{1 - e\sin\varphi'}{1 + e\sin\varphi'}\right)^{e/2} \]
というのである。ここで \(\cot x = 1/\tan x = \tan(\pi/2 - x)\) であることを思い出すと
\[ \tan\left(\frac{\pi}{4} - \frac{\varphi}{2}\right) =
\tan\left(\frac{\pi}{4} - \frac{\varphi'}{2}\right)
\cdot \left(\frac{1 + e\sin\varphi'}{1 - e\sin\varphi'}\right)^{e/2} \]
\[ r = 2 R \tan\left(\frac{\pi}{4} - \frac{\varphi'}{2}\right)
\cdot \left(\frac{1 + e\sin\varphi'}{1 - e\sin\varphi'}\right)^{e/2} \]
ということになる。
あとは \(R\) をどうやって評価するかであるが、ふつう標準緯度における縮尺が与えられるので、その緯度円の地図上の円周と、回転楕円体上の緯度円の円周が等しくなるようにすれば地球赤道半径 \(a\) を用いた形にすることができる。
EPSG 9830 http://epsg.io/9830-method なんかはそうやっている。
緯度を \(\varphi\) とすると
\[ r = 2 R \tan\left(\frac{\pi}{4} - \frac{\varphi}{2}\right) \]
\[ E = r \sin\left(\lambda - \lambda_0\right) \]
\[ N = -r \cos\left(\lambda - \lambda_0\right) \]
と表わされる。
ステレオ図法は正角図法であるから、その性質を壊さないためには、
なんらかの回転楕円体から球への等角写像 \(g: \varphi', \lambda' \to \varphi, \lambda\) の後に \(f\) を適用すればよい。
ステレオ図法は方位図法であるから、経度方向の伸縮があると図に裂け目ができてしまうし、両極は両極に写像されないといけない。
その条件を満たすありがたい等角写像があって
\[ \lambda = \lambda' \]
\[ \tan\left(\frac{\pi}{4} + \frac{\varphi}{2}\right) =
\tan\left(\frac{\pi}{4} + \frac{\varphi'}{2}\right)
\cdot \left(\frac{1 - e\sin\varphi'}{1 + e\sin\varphi'}\right)^{e/2} \]
というのである。ここで \(\cot x = 1/\tan x = \tan(\pi/2 - x)\) であることを思い出すと
\[ \tan\left(\frac{\pi}{4} - \frac{\varphi}{2}\right) =
\tan\left(\frac{\pi}{4} - \frac{\varphi'}{2}\right)
\cdot \left(\frac{1 + e\sin\varphi'}{1 - e\sin\varphi'}\right)^{e/2} \]
\[ r = 2 R \tan\left(\frac{\pi}{4} - \frac{\varphi'}{2}\right)
\cdot \left(\frac{1 + e\sin\varphi'}{1 - e\sin\varphi'}\right)^{e/2} \]
ということになる。
あとは \(R\) をどうやって評価するかであるが、ふつう標準緯度における縮尺が与えられるので、その緯度円の地図上の円周と、回転楕円体上の緯度円の円周が等しくなるようにすれば地球赤道半径 \(a\) を用いた形にすることができる。
EPSG 9830 http://epsg.io/9830-method なんかはそうやっている。
回転楕円体からのステレオ図法（MathJaxの練習）
EPSG 9829 とか EPSG:9830 にでてくる投影式はなんですかというメモ。
ステレオ図法というのを北半球天気図なんかでよく使う。
地球を球だと思えばその投影式はこんなである。
\[ E = a\sin\left(\lambda - \lambda_0\right) \]
\[ N = -a\cos\left(\lambda - \lambda_0\right) \]
\[ r = \tan \left( \frac{\pi}{4} - \frac{\varphi}{2} \right) \]
が、しかし、回転楕円体であることを意識するならば、そうはいかない。回転楕円体から球面への等角写像をして、さらに球面から上記の投影をおこなうことになる。
等角写像の選択に任意性がないわけでもない。しかし、実際には経度を保存する写像をつかわないと緯度円を円に投影しないことになって、方位図法では大変具合が悪い。楕円体上の緯度 \(\varphi\) を球面上の緯度 \(\chi\) にうつしてから投影することになる・
\[
\tan\left(\frac{\chi}{2} + \frac{\pi}{4}\right)
= \tan\left(\frac{\varphi}{2} + \frac{\pi}{4}\right)
\left( \frac{1 - e\sin\varphi}{1 + e\sin\varphi} \right)^{e/2}
\]
ステレオ図法というのを北半球天気図なんかでよく使う。
地球を球だと思えばその投影式はこんなである。
\[ E = a\sin\left(\lambda - \lambda_0\right) \]
\[ N = -a\cos\left(\lambda - \lambda_0\right) \]
\[ r = \tan \left( \frac{\pi}{4} - \frac{\varphi}{2} \right) \]
が、しかし、回転楕円体であることを意識するならば、そうはいかない。回転楕円体から球面への等角写像をして、さらに球面から上記の投影をおこなうことになる。
等角写像の選択に任意性がないわけでもない。しかし、実際には経度を保存する写像をつかわないと緯度円を円に投影しないことになって、方位図法では大変具合が悪い。楕円体上の緯度 \(\varphi\) を球面上の緯度 \(\chi\) にうつしてから投影することになる・
\[
\tan\left(\frac{\chi}{2} + \frac{\pi}{4}\right)
= \tan\left(\frac{\varphi}{2} + \frac{\pi}{4}\right)
\left( \frac{1 - e\sin\varphi}{1 + e\sin\varphi} \right)^{e/2}
\]
2014-10-01
最近の飛行機はUSB給電をしてくれるのでありがたい
今月はたてつづけに海外出張をしてのべ地球一周半しております。
成田→アトランタ→サンパウロ→シウダーデルエステ経由アスンシオン、アスンシオン７泊、同左逆向き、松戸６泊、成田→仁川→ヒースロー、レディング３泊、同左逆向き、というワールドツアーで、３０代のころは俺にタイムゾーンなんかないと豪語していたのはどこへやら、ちょっと限界への挑戦の様相を呈しております。
長い航空便というと、寝るんでなければ映画か本が相場でありましたが、昨今の飛行機はUSB給電をしてくれるものが増えているようで、電子機器利用大幅緩和もあって、電子書籍という手ができてきましたですね。映画はわりと苦手なんですよ。もともと数分を超える動画というのが苦手というか、２時間コミットできるか定かでないし、途中で寝ちゃうとなんかすごくもったいない気がするとかいう貧乏性かもしれません。
Kobo touch ならば12時間くらいフル稼働してもぜんぜん電池がもつのですが、読書灯の建付けしだいでは遠慮しちゃうこともあります。が、USB給電があれば、Nexus7 2012 みたいなふつうのタブレットで使い続けられます。タブレットならばPDFやワードの文書を読み込むといった仕事もできるし、ずいぶんありがたいことです。
米国高解像度モデルHRRRの情報
9月23日からHRRRが本運用されているらしいのですが、関連情報
NOAAプレスリリース
http://www.noaanews.noaa.gov/stories2014/20140930_hrrr.html
（次２つがリンクされています）
ESRLによるモデル説明
http://ruc.noaa.gov/hrrr/
（スペックですね。まあ、日本のLFMや降水短時間予報の立ち位置ですわね）
NWS Technical Implementation Notice 14-32
http://www.nws.noaa.gov/os/notification/tin14-32hrrr_oper.htm
（日本で言うと支援センターに相当するFOSと、衛星データ放送NOAAPORTに配信す
ると言っています）
Unidata LDM メーリングリスト
http://www.unidata.ucar.edu/mailing_lists/archives/ldm-users/2014/msg00207.html
NOAAPORT に出てくれば配信するのだけど、実際にはまだ
出てきていないと言っています。
2014-09-30
第5回 気象学におけるGIS/OGC標準ワークショップ ラストコール
私がやってるわけじゃないんですけど、英仏独気象局とECMWFが共同でこういう
ワークショップをやっています。毎年輪番で場所がかわります。
第5回の参加お申し込みは12日まで、だそうです。
http://goo.gl/68jw0r
わたしは第2回に行ったのですが、さて最近の雰囲気はどうでしょうね。
第4回は ECMWF で開かれたようです。
http://old.ecmwf.int/newsevents/meetings/workshops/2013/GIS-OGC_standards/
ワークショップをやっています。毎年輪番で場所がかわります。
第5回の参加お申し込みは12日まで、だそうです。
http://goo.gl/68jw0r
わたしは第2回に行ったのですが、さて最近の雰囲気はどうでしょうね。
第4回は ECMWF で開かれたようです。
http://old.ecmwf.int/newsevents/meetings/workshops/2013/GIS-OGC_standards/
2014-09-24
[旧EMobile] データ通信を使わないときはTMO 3G UK とか決め打ちしないほうがいいかも
Yモバの説明によると
http://www.ymobile.jp/service/global_roaming/area/data1day.html
ネットワーク名称が
EE/T-Mobile/T-Mobile UK/TMO UK/one2one/234 30/Virgin
といった塩梅で場所によってバラバラなんだそうです。
いまレディングにいるわけですが、TMO 2G UK とか TMO 3G UK が見えたりします。
で、2G ならどこでも使えるだろうと指定したら、なんだか猛烈に電池を消耗します。
データ通信を使わないで緊急連絡のために電話番号を維持したいだけなら、ネットワークを固定しないほうがいいのかなと思いました。
2014-09-16
海風前線ですかね
今日のDL295で帰国しました。
網走付近から内陸寄りの航路（アリューシャン低気圧を避けて北寄り66N付近を通った続きでしょうか）で筑波山11000ft→銚子沖→つくば市付近5000ft→南風運用着陸、となったのですが、何やらつくば付近にTCUがモコモコしていたようで2度入る度にライトタービュレンスでございました。まあ安全がどうとかいう水準では全くないのですが結構な機上観測でした。
午後に九十九里・東京湾方面からずっっと南東風が入って雲が立つのは海風前線ですかね。雲があるなら行かなきゃいいのですが、成田のように滑走路が事実上1方向しかないと、どうしたって風下に入らざるを得ません。
2014-09-13
カナダ気象局の試験的AMQPデータサービス
気象機関では歴史的に FTP PUT がものすごく好まれるのですが、いつまでも FTP じゃないよねという話のひとつ。
カナダ気象局では anonymous FTP がそのまま置き換えられた HTTP データダウンロードサービス MSC Datamartを長年やっているわけですが、こういうことをするとポーリング重爆撃をくらうわけですね。
で、更新通知だけプッシュでやりたいという発想がでてきます。で、カナダは AMQP を使うことにしたんだそうです。
http://lists.ec.gc.ca/pipermail/dd_info/2014-January/000104.html
技術的展開としては、防災XMLの PubSubHubbub での提供と非常に似ています。
ちなみに、MSC Datamart は唯一のデータサービスでは無いです。24時間監視・ライブサポートの必要な利用者のために、その名もズバリ Cost Recovered Data Service という SFTP Push があります。
2014-08-28
スウェーデンの地上気象観測報（SYNOP）がエッセンシャルデータ（利用制約なし）に指定替えとなります
とつぜんそんなことを言っても説明が要りますかな。
世界の気象機関は世界気象機関（WMO）の調整のもとで観測網を構成し、観測データをリアルタイム交換しています。そのデータの扱いについては第12回総会決議40が定めるところです。データを発信する国が、エッセンシャル（利用制約なし）とアディショナル（商用再輸出を禁止できる）の２類型から１つに選べるのです。
WMO Resolution 40 (Cg-XII)
http://www.wmo.int/pages/about/Resolution40_en.html
なぜそんなものができたのか、というあたりはこのへんみてください。
佐伯理郎(1995): 気象データ・プロダクトの国際交換をめぐって, 天気, 42.10, pp.695-793.
http://www.metsoc.jp/tenki/pdf/1995/1995_10_0695.pdf
さて、欧州の結構な数の国が高頻度または高密度の地上気象観測報（FM12 SYNOP という電報形式で通報されるので SYNOP報とよばれる）をアディショナルに指定しました。高頻度または高密度、というのは、RBSN観測網の６時間毎の観測はエッセンシャルにしなければならないと決められているのでそれ以外、ということですね。
スウェーデンもその一部であったわけで、多数の電文がアディショナルに指定されていました（電文カタログ http://toyoda-eizi.net/wmo9/volc1/cccc/ESWI/ ）。それが今回エッセンシャルに指定替えとなります。
Sourece: WMO Operational Newsletter
http://www.wmo.int/pages/prog/www/ois/Operational_Information/Newsletters/current_news_en.html
2014-08-27
PowerShell で wget みたいなことをする例
Windowsはコマンドラインツールがしょぼいが、その代わりに .NET だか COM だ
かのクラスライブラリを使って PowerShell プログラミングするべきものである
らしい。
@IT: PowerShellを使って指定したファイルをインターネットからダウンロードする
http://www.atmarkit.co.jp/fwin2k/win2ktips/995dlfile/dlfile.html
かのクラスライブラリを使って PowerShell プログラミングするべきものである
らしい。
@IT: PowerShellを使って指定したファイルをインターネットからダウンロードする
http://www.atmarkit.co.jp/fwin2k/win2ktips/995dlfile/dlfile.html
2014-08-26
最近の技術情報・お知らせから（目撃情報を活用した竜巻注意情報、オゾンGPV高解像度化、ハイパースペクトル赤外サウンダ同化開始）
●技術情報第400号 気象庁防災情報XML形式の電文配信に用いるデータ種類コード
について（その７）
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/400.pdf
竜巻注意情報の改善に伴って従前のデータ種類コード VPHW50 に加えて VPHW51
を新設するというのです。
データ種類コードと英字官署名（WMO電文ヘッダの TTAAii と CCCC に相当）の
リストがあります。
内容については既出の技術情報第397号にあります。VPHW51 は「目撃情報を活用
した竜巻注意情報であることを機械的に判別できるようにした」ものだそうです。
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/397.pdf
●技術情報第401号 平成26年10月からの紫外線情報に用いる化学輸送モデルの変
更及びオゾン全量データの高解像度化について
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/401.pdf
オゾン全量データGPVが2.5度格子から1.25度格子になるそうです。他人事のよう
にいっていますが、いや、まあ、他所の主管ですからね。
●技術情報第402号 ハイパースペクトル赤外サウンダデータの利用開始について
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/402.pdf
NASAの衛星Aqua搭載のサウンダAIRS, EUMETSATの衛星METOP-AおよびMETOP-B搭載
のサウンダIASIのデータをGSMで同化開始します。
この変更により、GSMの初期値の精度が改善し予測精度が向上します。
AIRS http://www.wmo-sat.info/oscar/instruments/view/16 は2002年から、
IASI http://www.wmo-sat.info/oscar/instruments/view/207 は2006年からあって、
これを使いこなすことは長年の課題だったので、けっこう画期的なことです。
データフォーマットは変わりません。
●お知らせ（目撃情報を活用した竜巻注意情報は9月2日13時から）
気象振興協議会HP http://www.w-shinkou.org/ によりますと、26日付で、竜巻
注意情報の改善の実施時期についての第2回めのお知らせがでているそうです。
このお知らせそのものは未見ですが、内容的に 報道発表に書いてあることに尽
きると思います。
平成２６年８月２６日 報道発表資料 目撃情報を活用した竜巻注意情報の提供
を開始します
http://www.jma.go.jp/jma/press/1408/26a/tornado_140826.html
について（その７）
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/400.pdf
竜巻注意情報の改善に伴って従前のデータ種類コード VPHW50 に加えて VPHW51
を新設するというのです。
データ種類コードと英字官署名（WMO電文ヘッダの TTAAii と CCCC に相当）の
リストがあります。
内容については既出の技術情報第397号にあります。VPHW51 は「目撃情報を活用
した竜巻注意情報であることを機械的に判別できるようにした」ものだそうです。
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/397.pdf
●技術情報第401号 平成26年10月からの紫外線情報に用いる化学輸送モデルの変
更及びオゾン全量データの高解像度化について
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/401.pdf
オゾン全量データGPVが2.5度格子から1.25度格子になるそうです。他人事のよう
にいっていますが、いや、まあ、他所の主管ですからね。
●技術情報第402号 ハイパースペクトル赤外サウンダデータの利用開始について
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/402.pdf
NASAの衛星Aqua搭載のサウンダAIRS, EUMETSATの衛星METOP-AおよびMETOP-B搭載
のサウンダIASIのデータをGSMで同化開始します。
この変更により、GSMの初期値の精度が改善し予測精度が向上します。
AIRS http://www.wmo-sat.info/oscar/instruments/view/16 は2002年から、
IASI http://www.wmo-sat.info/oscar/instruments/view/207 は2006年からあって、
これを使いこなすことは長年の課題だったので、けっこう画期的なことです。
データフォーマットは変わりません。
●お知らせ（目撃情報を活用した竜巻注意情報は9月2日13時から）
気象振興協議会HP http://www.w-shinkou.org/ によりますと、26日付で、竜巻
注意情報の改善の実施時期についての第2回めのお知らせがでているそうです。
このお知らせそのものは未見ですが、内容的に 報道発表に書いてあることに尽
きると思います。
平成２６年８月２６日 報道発表資料 目撃情報を活用した竜巻注意情報の提供
を開始します
http://www.jma.go.jp/jma/press/1408/26a/tornado_140826.html
2014-08-20
OASIS ODF のスキーマは RELAX NG なんだそうな
Source: 村田真のXMLブログ
XAdESとODF/OOXML/EPUBとRELAX NG
http://www.xmlmaster.org/murata/xmlblog/xb140423.html
某UMLモデラーが RELAX NG is dead とか言っていたが、ポジショントークに騙
されてはいけない。
XAdESとODF/OOXML/EPUBとRELAX NG
http://www.xmlmaster.org/murata/xmlblog/xb140423.html
某UMLモデラーが RELAX NG is dead とか言っていたが、ポジショントークに騙
されてはいけない。
2014-08-13
NCAR Graphics は現在は NCL の一部
なんだそうです。
http://ngwww.ucar.edu/
↓
Download
http://ngwww.ucar.edu/download.html
と行くと、 NCL Download Page に案内されます。
http://www.ncl.ucar.edu/Download/
http://ngwww.ucar.edu/
↓
Download
http://ngwww.ucar.edu/download.html
と行くと、 NCL Download Page に案内されます。
http://www.ncl.ucar.edu/Download/
2014-08-10
気圧の海面更正の方式について
{おことわり：完結した調査ではありません。もうすこし調べるといろいろひっくり返るかもしれません。}
地上気象観測では、 現地気圧に加えて海面更正気圧というものを通報することになっています。その方式が諸国まちまちであるという話です。
地上気象観測では、 現地気圧に加えて海面更正気圧というものを通報することになっています。その方式が諸国まちまちであるという話です。
2014-08-08
国際保健規則の位置づけ
保健方面の人には常識なのだろうけれど。
Kotobank: 国際的に懸念される公衆衛生上の緊急事態
http://kotobank.jp/word/%E5%9B%BD%E9%9A%9B%E7%9A%84%E3%81%AB%E6%87%B8%E5%BF%B5%E3%81%95%E3%82%8C%E3%82%8B%E5%85%AC%E8%A1%86%E8%A1%9B%E7%94%9F%E4%B8%8A%E3%81%AE%E7%B7%8A%E6%80%A5%E4%BA%8B%E6%85%8B
国際保健規則によって国際法上の根拠が与えられるらしいです。
厚生労働省：国際保健規則 日本語（仮訳）
http://www.mhlw.go.jp/bunya/kokusaigyomu/kokusaihoken_j.html
世界保健機関憲章に根拠があるらしいです。
外務省：世界保健機関憲章
http://www.mofa.go.jp/mofaj/files/000026609.pdf#page=15
※ ぐぐって拾ったので最新かどうかはわかりません
第21条 (a) によって保健総会（health assmbly) が保健規則を定める権限を
持っているのだそうです。
世界気象機関条約第8条(a) に相当するのはWHO憲章第22条なのでしょう。
http://library.wmo.int/pmb_ged/wmo_15-2012_en.pdf#page=17
Kotobank: 国際的に懸念される公衆衛生上の緊急事態
http://kotobank.jp/word/%E5%9B%BD%E9%9A%9B%E7%9A%84%E3%81%AB%E6%87%B8%E5%BF%B5%E3%81%95%E3%82%8C%E3%82%8B%E5%85%AC%E8%A1%86%E8%A1%9B%E7%94%9F%E4%B8%8A%E3%81%AE%E7%B7%8A%E6%80%A5%E4%BA%8B%E6%85%8B
国際保健規則によって国際法上の根拠が与えられるらしいです。
厚生労働省：国際保健規則 日本語（仮訳）
http://www.mhlw.go.jp/bunya/kokusaigyomu/kokusaihoken_j.html
世界保健機関憲章に根拠があるらしいです。
外務省：世界保健機関憲章
http://www.mofa.go.jp/mofaj/files/000026609.pdf#page=15
※ ぐぐって拾ったので最新かどうかはわかりません
第21条 (a) によって保健総会（health assmbly) が保健規則を定める権限を
持っているのだそうです。
世界気象機関条約第8条(a) に相当するのはWHO憲章第22条なのでしょう。
http://library.wmo.int/pmb_ged/wmo_15-2012_en.pdf#page=17
2014-07-31
2014-07-28
配信資料に関する技術情報第３９９号「海水温・海流予報格子点資料の提供について」の訂正
気象振興協議会HPトップページ http://www.w-shinkou.org/ によりますと、技
術情報第３９９号の訂正が28日づけで 出ているそうです。
気象庁HPのファイル
http://www.data.jma.go.jp/add/suishin/jyouhou/pdf/399.pdf はわかりにくいですが差し替わったものになっています。配信開始が8月7日に迫っていますので、ここ数日にお持ちになった方はご注意ください。
訂正点は、8ページの表※４、塩分の GRIB2 パラメータ番号が 3 であったところが 192
になるというもののはずです。単位は PSU でかわりありません。
WMO 標準 FM92 GRIB のパラメータ番号 10-4-3 は単位 kg/kg ですが、海洋モデ
ルでは塩分濃度を PSU 単位で予報しています。
PSU という単位も公式ではないらしいのですが、このへんをごらんください。
http://en.wikipedia.org/wiki/Salinity#Seawater
質量比ではないことくらいはわかります。
Ruby 1.8/1.9 移植：ファイルの文字コードは面倒だがバイナリファイルならとりあえず話は簡単
めんどくさいですねー移植は。
Ruby 1.9 から String に文字コードが属性としてもたれるようになりました。
それは、まあ、いいことなのでしょうが、文字コードとして正しくないバイト列
を String にしようとすると例外が飛びます。
入出力というか、 IO#read は、まさしくバイト列から String を作る処理なの
で、悪いバイト列を読むとアプリが爆死します。
もちろん例外を rescue で受け止めればいいのですが、受け止めて見たところで
バイト列は失われていて分析も復旧もできません。
どうしろというのでしょう。
答は、たぶん、文字コード ASCII-8BIT としてファイルを開くことなのです。い
や、ぼくはバイナリがみたいんだから。
やりかたですが、File オブジェクトが遠くから渡ってくるならば、 IO#binmode
指令を打ち込むというのが手です。
STDIN はそうするしかないと思います。
もういっこ、簡単で、Ruby 1.8 コンパチブルな方法は、 b オプションつまり
File.open(filename, "rb") で開くことです。
もともと、そうすべきだったんです。
改行コードのことはあきらめましょう。もう、 CR 改行のファイルはないはずです。
Ruby 1.9 から String に文字コードが属性としてもたれるようになりました。
それは、まあ、いいことなのでしょうが、文字コードとして正しくないバイト列
を String にしようとすると例外が飛びます。
入出力というか、 IO#read は、まさしくバイト列から String を作る処理なの
で、悪いバイト列を読むとアプリが爆死します。
もちろん例外を rescue で受け止めればいいのですが、受け止めて見たところで
バイト列は失われていて分析も復旧もできません。
どうしろというのでしょう。
答は、たぶん、文字コード ASCII-8BIT としてファイルを開くことなのです。い
や、ぼくはバイナリがみたいんだから。
やりかたですが、File オブジェクトが遠くから渡ってくるならば、 IO#binmode
指令を打ち込むというのが手です。
STDIN はそうするしかないと思います。
もういっこ、簡単で、Ruby 1.8 コンパチブルな方法は、 b オプションつまり
File.open(filename, "rb") で開くことです。
もともと、そうすべきだったんです。
改行コードのことはあきらめましょう。もう、 CR 改行のファイルはないはずです。
2014-07-24
XMLを吐くBUFRデコーダ
前回BUFRデコーダについて調査・紹介したが、XMLに変換しようと考えているのだ。
新しいBUFRデータの評価をする仕事がいっぱいあるんだけど、XMLのバリデーションとか使えないかなと思うわけ。
libecbufr をつかって作ろうかとおもったのだけど、その前に車輪の再発明度の調査。
（車輪の再発明は嫌いじゃないというか、むしろ好きなんだが、人生は短すぎるので）
= python-bufr - Google code
https://code.google.com/p/python-bufr/
Pythonによる実装か、しかもGPLと色めき立ったが、事もあろうにECMWFのFortranデコーダのラッパーだというので萎えた。あと、XMLで検索されたのは、XMLRPCだけみたいだ。何がしたいかはわからない。
= Steve Sullivan の wmobufr
http://www.unidata.ucar.edu/mailing_lists/archives/bufrtables/2010/msg00000.html
これはずばりやりたいことをやりそう。
BSDライセンスも、まあ、いいでしょう。
ただ、Javaなんだよね。うーん。
新しいBUFRデータの評価をする仕事がいっぱいあるんだけど、XMLのバリデーションとか使えないかなと思うわけ。
libecbufr をつかって作ろうかとおもったのだけど、その前に車輪の再発明度の調査。
（車輪の再発明は嫌いじゃないというか、むしろ好きなんだが、人生は短すぎるので）
= python-bufr - Google code
https://code.google.com/p/python-bufr/
Pythonによる実装か、しかもGPLと色めき立ったが、事もあろうにECMWFのFortranデコーダのラッパーだというので萎えた。あと、XMLで検索されたのは、XMLRPCだけみたいだ。何がしたいかはわからない。
= Steve Sullivan の wmobufr
http://www.unidata.ucar.edu/mailing_lists/archives/bufrtables/2010/msg00000.html
これはずばりやりたいことをやりそう。
BSDライセンスも、まあ、いいでしょう。
ただ、Javaなんだよね。うーん。
2014-07-18
オープンソースの BUFR デコーダ
ちょっと調べてみるですよ。
= John Caron のページ
http://www.unidata.ucar.edu/staff/caron/bufr/
いろんな情報源をよくまとめています。
== NCEP BUFRLIB
http://www.nco.ncep.noaa.gov/sib/decoders/BUFRLIB/
tar ファイルを開くとカレントディレクトリにボロボロっと *.c *.f *.F ファイルが出てきます。 preproc.sh
というのを呼ぶとエンディアン判定をして *.F をどうにかしてくれます。あとは、Makefile はないので、
$ f77 -c *.f
$ cc -c *.c
と豪快にいって欲しいらしいです。ただし、アンダースコア関係をホゲるひつようがあります。
いや、まあ、そうまでして Fortran ですからね。ウェブのドキュメントは充実してるんですけどね。またね。
== ECMWF BUFRDC
http://www.ecmwf.int/products/data/software/bufr.html
これも Fortran です。数年前の経験ではいちおう Makefile があって、色々ホゲる必要がありましたが、まあまあさくりと通ったような気がします。
が、install スクリプトの出来が微妙で、定数データがビルドディレクトリを参照し続けてしまうんだったような... 使い方が悪いだけかもしれませんが。
それで Fortran ですからねえ。
== Canadian libECBUFR
https://launchpad.net/libecbufr
ソフトウェアの綺麗さでは定評のあるカナダ気象局です。
なんか launchpad で LGPL なので、よさそうなんですが、 Debian のバイナリパッケージしかないんですよね。なんか bzr
とかいうのでソースを落としてこないといけないんですが、それはどうしたらいいんでしょう。
= 他
SF.net に bufr-info というのがあります
http://sourceforge.net/projects/bufr-info/
これは L じゃない GPL2 ですが、 C++ なのはちょっと私にはついていけないです。
ギリシャ気象局が作っているようです。
= John Caron のページ
http://www.unidata.ucar.edu/staff/caron/bufr/
いろんな情報源をよくまとめています。
== NCEP BUFRLIB
http://www.nco.ncep.noaa.gov/sib/decoders/BUFRLIB/
tar ファイルを開くとカレントディレクトリにボロボロっと *.c *.f *.F ファイルが出てきます。 preproc.sh
というのを呼ぶとエンディアン判定をして *.F をどうにかしてくれます。あとは、Makefile はないので、
$ f77 -c *.f
$ cc -c *.c
と豪快にいって欲しいらしいです。ただし、アンダースコア関係をホゲるひつようがあります。
いや、まあ、そうまでして Fortran ですからね。ウェブのドキュメントは充実してるんですけどね。またね。
== ECMWF BUFRDC
http://www.ecmwf.int/products/data/software/bufr.html
これも Fortran です。数年前の経験ではいちおう Makefile があって、色々ホゲる必要がありましたが、まあまあさくりと通ったような気がします。
が、install スクリプトの出来が微妙で、定数データがビルドディレクトリを参照し続けてしまうんだったような... 使い方が悪いだけかもしれませんが。
それで Fortran ですからねえ。
== Canadian libECBUFR
https://launchpad.net/libecbufr
ソフトウェアの綺麗さでは定評のあるカナダ気象局です。
なんか launchpad で LGPL なので、よさそうなんですが、 Debian のバイナリパッケージしかないんですよね。なんか bzr
とかいうのでソースを落としてこないといけないんですが、それはどうしたらいいんでしょう。
= 他
SF.net に bufr-info というのがあります
http://sourceforge.net/projects/bufr-info/
これは L じゃない GPL2 ですが、 C++ なのはちょっと私にはついていけないです。
ギリシャ気象局が作っているようです。
2014-06-22
XPath で名前空間を指定しないと欲しいノードがみつからないとか
結論から言うと *[name()='タグ名'] の一つ覚えでいいわけですが、なんでそうなるかとか。（コードはテストしてないです。typoご容赦）
2014-06-17
RGB から簡易に色相を得る（HSV色空間）
RGBから簡易に色相を得たいという話があった。
それならば、HSV色空間の考え方を使うのがいいと思う。
http://ja.wikipedia.org/wiki/HSV%E8%89%B2%E7%A9%BA%E9%96%93#RGB.E3.81.8B.E3.82.89HSV.E3.81.B8.E3.81.AE.E5.A4.89.E6.8F.9B
の H 値が使えるだろう。
ここのロジックをざっくり全円周6分割にするならば次のようになるだろう。
１．RGB 値のうちで最大 MAX と最小 MIN を求める。
２．MIN = MAX ならば、無彩色つまりグレイスケールである。
３．MIN = B ならば、
（１） G < R ならば、オレンジ色
（２） G ≒ R ならば、黄色
（2） さもなくば（G > R）、黄緑
4. MIN = R ならば、
（１） B < G ならば、緑
（2） さもなくば（G >= R）、淡青
5. MIN = G ならば、
（1） R < B ならば、青紫
（2） さもなくば（R >= B）、赤紫
三色視の人は黄色付近に敏感（いいかえればRGBがあまり一様でない）と思われ
るので、黄色まわりは分割を細かくした。
でも、MAX で書き換えたほうが綺麗になりそうだなあ。とりあえず。
それならば、HSV色空間の考え方を使うのがいいと思う。
http://ja.wikipedia.org/wiki/HSV%E8%89%B2%E7%A9%BA%E9%96%93#RGB.E3.81.8B.E3.82.89HSV.E3.81.B8.E3.81.AE.E5.A4.89.E6.8F.9B
の H 値が使えるだろう。
ここのロジックをざっくり全円周6分割にするならば次のようになるだろう。
１．RGB 値のうちで最大 MAX と最小 MIN を求める。
２．MIN = MAX ならば、無彩色つまりグレイスケールである。
３．MIN = B ならば、
（１） G < R ならば、オレンジ色
（２） G ≒ R ならば、黄色
（2） さもなくば（G > R）、黄緑
4. MIN = R ならば、
（１） B < G ならば、緑
（2） さもなくば（G >= R）、淡青
5. MIN = G ならば、
（1） R < B ならば、青紫
（2） さもなくば（R >= B）、赤紫
三色視の人は黄色付近に敏感（いいかえればRGBがあまり一様でない）と思われ
るので、黄色まわりは分割を細かくした。
でも、MAX で書き換えたほうが綺麗になりそうだなあ。とりあえず。
2014-06-16
[Fortran] Optional引数がある外部サブルーチンを呼ぶにはinterfaceブロックが必要
FORTRAN77 までは、サブルーチンの呼び出しというのは、名前さえあっていれば
よかったのですが、
Optional引数のような非伝統的な機能（※）を使うときは、そのことを教えてや
らなければなりません。
※ Fortran 95 §12.3.1.1 参照。
* 呼び方（まあわかる）
* 引数キーワードを使って引用（使わなければいい）
* 総称名、利用者定義代入文、利用者定義演算子による引用
* 純粋手続きが必要な文脈での使用
（要は純粋手続き内部であって、それ自体が非伝統的）
* 呼ばれる物自体
* オプショナル引数がある
* 形状引継ぎ配列の引数（上下限のかわりにコロンを書いて、長さは呼び出し元
次第にする機能）がある
* ポインタの引数がある
* TARGET属性を持った引数がある
* （関数が）配列値の結果を返す
* （関数が）ポインタの結果を返す
* （文字型関数が）返す結果の文字長パラメタ値が定数でも引継ぎでもない
呼ばれる側に由来する制約は、呼ぶ側では必ずしも承知していないので、落とし
穴となりえます。
モジュール、他のサブルーチンまたは関数、あるいは主プログラムの中に入って
いるサブルーチンは、
どこかしらに「非伝統的な機能を使っているよ」ということを伝えることができ
ます。
しかし、外部サブルーチン（ソースファイルの先頭が subroutine 文になってい
るもの）を呼び出すときは、
コンパイラは誰にもそのことを教えてもらうことができません。
呼ばれる方のサブルーチンをモジュールに入れるように変えて、モジュールを
use するのが綺麗ですが、
名前を考えたり、 .mod ファイルが生じたり、面倒です。
てっとりばやい救済は、呼び側で interface ブロックを使うことです。
subroutine super
INTERFACE
subroutine sub(a, b, c)
integer, intent(inout):: a, b
integer, intent(in), OPTIONAL:: c
end subroutine
END INTERFACE
call sub(1, 2)
end subroutine
subroutine sub(a, b, c)
integer, intent(inout):: a, b
integer, intent(in), OPTIONAL:: c
end subroutine
よかったのですが、
Optional引数のような非伝統的な機能（※）を使うときは、そのことを教えてや
らなければなりません。
※ Fortran 95 §12.3.1.1 参照。
* 呼び方（まあわかる）
* 引数キーワードを使って引用（使わなければいい）
* 総称名、利用者定義代入文、利用者定義演算子による引用
* 純粋手続きが必要な文脈での使用
（要は純粋手続き内部であって、それ自体が非伝統的）
* 呼ばれる物自体
* オプショナル引数がある
* 形状引継ぎ配列の引数（上下限のかわりにコロンを書いて、長さは呼び出し元
次第にする機能）がある
* ポインタの引数がある
* TARGET属性を持った引数がある
* （関数が）配列値の結果を返す
* （関数が）ポインタの結果を返す
* （文字型関数が）返す結果の文字長パラメタ値が定数でも引継ぎでもない
呼ばれる側に由来する制約は、呼ぶ側では必ずしも承知していないので、落とし
穴となりえます。
モジュール、他のサブルーチンまたは関数、あるいは主プログラムの中に入って
いるサブルーチンは、
どこかしらに「非伝統的な機能を使っているよ」ということを伝えることができ
ます。
しかし、外部サブルーチン（ソースファイルの先頭が subroutine 文になってい
るもの）を呼び出すときは、
コンパイラは誰にもそのことを教えてもらうことができません。
呼ばれる方のサブルーチンをモジュールに入れるように変えて、モジュールを
use するのが綺麗ですが、
名前を考えたり、 .mod ファイルが生じたり、面倒です。
てっとりばやい救済は、呼び側で interface ブロックを使うことです。
subroutine super
INTERFACE
subroutine sub(a, b, c)
integer, intent(inout):: a, b
integer, intent(in), OPTIONAL:: c
end subroutine
END INTERFACE
call sub(1, 2)
end subroutine
subroutine sub(a, b, c)
integer, intent(inout):: a, b
integer, intent(in), OPTIONAL:: c
end subroutine
2014-06-13
Subversionの使い方（レポジトリ作成、とりあえずインポート、強引に上書きチェックアウト）
Subversion の使い方もすぐに忘れてしまう。
前提
* /foo/bar に常用するファイル（ソースコードとか）があるとする。
* レポジトリは /var/svn に作る。
* ひとりしか使わない。（まだパーミッション絡みの問題は信用していない）
レポジトリの作成
$ sudo mkdir /var/svn
$ chown `id -un`:`id -gn` /var/svn
$ svnadmin create /var/svn
リモートアクセスを受けるなら、何か設定をほげるらしい。
http://queens.db.toronto.edu/~nilesh/linux/subversion-howto/
レポジトリに登録
$ cd /foo/bar
$ svn import . file:///var/svn/foo/bar
CVS みたいにベンダータグ・リリースタグなど意味不明なものを求めてこない
のは結構なことである。
レポジトリに登録（1ファイルだけ）
$ svn import quux.c file:///var/svn/foo/bar/quux.c
常用作業ディレクトリに巨大バイナリなど管理したくないものが混ざっている
ときは、1ファイルだけ入れて、あとで add する。
期待通りにできたか確認
$ svntree list /var/svn
これは svn ls と違って、作業コピーがまだないときにも使える。
元のファイルを強引に管理下に置く
$ cd /foo/bar
$ svn co --force file://var/svn/foo/bar .
あとはまあ CVS と同じ（add/commit/update)
* svn add したら update しないとローカルファイルは管理下に入らない
前提
* /foo/bar に常用するファイル（ソースコードとか）があるとする。
* レポジトリは /var/svn に作る。
* ひとりしか使わない。（まだパーミッション絡みの問題は信用していない）
レポジトリの作成
$ sudo mkdir /var/svn
$ chown `id -un`:`id -gn` /var/svn
$ svnadmin create /var/svn
リモートアクセスを受けるなら、何か設定をほげるらしい。
http://queens.db.toronto.edu/~nilesh/linux/subversion-howto/
レポジトリに登録
$ cd /foo/bar
$ svn import . file:///var/svn/foo/bar
CVS みたいにベンダータグ・リリースタグなど意味不明なものを求めてこない
のは結構なことである。
レポジトリに登録（1ファイルだけ）
$ svn import quux.c file:///var/svn/foo/bar/quux.c
常用作業ディレクトリに巨大バイナリなど管理したくないものが混ざっている
ときは、1ファイルだけ入れて、あとで add する。
期待通りにできたか確認
$ svntree list /var/svn
これは svn ls と違って、作業コピーがまだないときにも使える。
元のファイルを強引に管理下に置く
$ cd /foo/bar
$ svn co --force file://var/svn/foo/bar .
あとはまあ CVS と同じ（add/commit/update)
* svn add したら update しないとローカルファイルは管理下に入らない
2014-06-10
（おもに計算尺で）相対湿度を求める近似式
おことわり：
（１）今日的な意義はほとんどありません。
（２）あくまで近似です。正確な値を得るためには「気象観測の手引き」などをご覧ください。
http://www.jma.go.jp/jma/kishou/know/kansoku_guide/tebiki.pdf
先日お話ししたように計算尺を買ってみたのです。何に使えるだろうかと思って、乾湿計の読み取り値から相対湿度を与える極めて簡単な近似式があるのを思い出しました。
RH ≒ [(湿球温度/℃ + 10) ÷ (気温/℃ + 10)] ^ 3（１）今日的な意義はほとんどありません。
（２）あくまで近似です。正確な値を得るためには「気象観測の手引き」などをご覧ください。
http://www.jma.go.jp/jma/kishou/know/kansoku_guide/tebiki.pdf
先日お話ししたように計算尺を買ってみたのです。何に使えるだろうかと思って、乾湿計の読み取り値から相対湿度を与える極めて簡単な近似式があるのを思い出しました。
【注意: 特に10℃以下の低温時の精度が悪いです】
この式には個人名がついていたと思いますが忘れてしまいました。子供のころの記憶ですから定かでありませんが、気賀康夫「電卓に強くなるーすぐに役立つ公式と実例集」（ブルーバックス B327）で読んだのだと思います。
http://www.amazon.co.jp/dp/4061179276
ともあれ、この式は、電卓よりむしろ計算尺に向いていて、1回内輪を回して1回カーソルを合わせるだけで計算できてしまうのです。おそらく歴史的には計算尺のためにこのような公式が多数作られたのだろうな、と思いました。
(1) 湿球温度と気温にそれぞれ１０を加算する（暗算でできるよね）。
気温20℃、湿球15℃であったなら、それぞれ30と25。
(2) 除算をする。外輪の3.0を内輪の2.5に合わせる。
(3) このとき、外輪の1.0に対応する位置にカーソルを合わせる。
内輪は1～10の目盛で、8.3強 という数字が出ている。(Tw+10)/(T+10) = 0.83強 ということ。
(3) このとき、外輪の1.0に対応する位置にカーソルを合わせる。
内輪は1～10の目盛で、8.3強 という数字が出ている。(Tw+10)/(T+10) = 0.83強 ということ。
(4) 内輪の内側に3乗の目盛があれば、そこを読むと3乗まで計算できる。
1～1000の目盛で580 くらいだったら、湿度は 58% ということ。
同じ条件で理科年表の非通風乾湿計の表をみると 56% とあります。まあまあその程度の精度です。気温が低くなるほどあてはめの精度が悪くなって、概ね5℃以下のときは使い物になりませんが、それにしてもよくこんな近似式を考えたものだと思いました。
同じ伝で露点温度も考えてみました。こちらは常温で±1％程度の精度はあります。
1～1000の目盛で580 くらいだったら、湿度は 58% ということ。
同じ条件で理科年表の非通風乾湿計の表をみると 56% とあります。まあまあその程度の精度です。気温が低くなるほどあてはめの精度が悪くなって、概ね5℃以下のときは使い物になりませんが、それにしてもよくこんな近似式を考えたものだと思いました。
同じ伝で露点温度も考えてみました。こちらは常温で±1％程度の精度はあります。
RH ≒ [(露点/℃ + 125) ÷ (気温/℃ + 125)] ^ 9
9乗は、3乗を読み取ったあとで、カーソルを動かして更に3乗を求めるという流れになります。一手間かかりますが、3乗で似たような近似をしても、なかなか使い物にはなりませんでした。
2014-05-16
GML (ISO 19136) 対応の libxml2 は Ubuntu 13 以降orz
５月中旬に書いて投稿を忘れていた:
---
さるところで12.04LTS を使っているわけですが、今日なんか更新が来たんだけ
ど、見たら libxml2 2.7.8 なんですわ。
Ubuntu全体ではこうなっています。
http://packages.ubuntu.com/search?keywords=libxml2
GML (ISO 19136) の XSD を使おうとすると libxml2 2.8.0 以降または豊田パッ
チ野良インストールが必要なわけですが、それは Ubuntu 13 以降を使いなさい
というわけですね。
http://toyoda-eizi.blogspot.jp/2013/08/libxml2-version-280-or-later.html
2014-05-14
NCEPにおける観測データ処理（BUFRはこんなふうに使うもの）
ちょっと調べ物の途中でのめっけもの。
Com-GSI （http://www.dtcenter.org/com-GSI/users/index.php; たぶん米国
NOAA/AWFA/UCARが共同で変分同化コードを開発するコミュニティプロジェクト）
がチュートリアルセミナーをやっていて、その 2013 年の回
http://www.dtcenter.org/com-GSI/users/docs/tutorial_presentations_2013.php
に "Observation data processing" という NCEP の発表があるんですね。
４ページ目の図がデータの流れをよくあらわしています。
http://www.dtcenter.org/com-GSI/users/docs/presentations/2013_tutorial/Tue_L1_Keyser_ObsProcessing.pdf#page=4
次の3段階のデータがすべてBUFR形式だというんですね
・BUFR Tanks: 形式をすべてBUFRに整えただけ（*1）、
QCはデコード処理に組み込みの原始的なものしかない
・dump files: 時空間を目的に応じて選択し、重複（*2）を除去し、
QC（purge/keep, reject list, marine flags などのフラグを付与、まあ要する
に品質が悪い観測プラットフォーム識別子をマークするわけですね）
・PrepBUFR files
conventional data にだけ作られるもので、ゲス（予報値）を使った何らかのQC
をするそうです
で、これが解析に入るんだといいます。
*1 たとえBUFR SYNOPであっても内容構造（記述子列）は一様ではありません。
次のような報告があります
https://groups.google.com/a/wmo.int/forum/#!searchin/cbs-ipet-drmm/synop$20weiqing/cbs-ipet-drmm/7wnx0Zwy0go/czuIKqTw1GYJ
*2 特にGTSで顕著ですが、重複したデータが多数入電するということがままあり
ます。分散管理、低遅延、高可用性、訂正可能性、歴史的互換性など全部ひっく
るめるとしょうがないんです。
いろいろ使い方的なことも参考になります。たとえば NCEP の BUFR 表 B がこ
こにあるとか。
http://www.emc.ncep.noaa.gov/mmb/data_processing/bufrtab_tableb.htm
ちなみに、気象庁でいうと、だいたい dump files に対応するのがデコードデー
タと呼ばれるもので、気象業務支援センターから提供されています。
http://www.jmbsc.or.jp/hp/offline/cd0430.html
Com-GSI （http://www.dtcenter.org/com-GSI/users/index.php; たぶん米国
NOAA/AWFA/UCARが共同で変分同化コードを開発するコミュニティプロジェクト）
がチュートリアルセミナーをやっていて、その 2013 年の回
http://www.dtcenter.org/com-GSI/users/docs/tutorial_presentations_2013.php
に "Observation data processing" という NCEP の発表があるんですね。
４ページ目の図がデータの流れをよくあらわしています。
http://www.dtcenter.org/com-GSI/users/docs/presentations/2013_tutorial/Tue_L1_Keyser_ObsProcessing.pdf#page=4
次の3段階のデータがすべてBUFR形式だというんですね
・BUFR Tanks: 形式をすべてBUFRに整えただけ（*1）、
QCはデコード処理に組み込みの原始的なものしかない
・dump files: 時空間を目的に応じて選択し、重複（*2）を除去し、
QC（purge/keep, reject list, marine flags などのフラグを付与、まあ要する
に品質が悪い観測プラットフォーム識別子をマークするわけですね）
・PrepBUFR files
conventional data にだけ作られるもので、ゲス（予報値）を使った何らかのQC
をするそうです
で、これが解析に入るんだといいます。
*1 たとえBUFR SYNOPであっても内容構造（記述子列）は一様ではありません。
次のような報告があります
https://groups.google.com/a/wmo.int/forum/#!searchin/cbs-ipet-drmm/synop$20weiqing/cbs-ipet-drmm/7wnx0Zwy0go/czuIKqTw1GYJ
*2 特にGTSで顕著ですが、重複したデータが多数入電するということがままあり
ます。分散管理、低遅延、高可用性、訂正可能性、歴史的互換性など全部ひっく
るめるとしょうがないんです。
いろいろ使い方的なことも参考になります。たとえば NCEP の BUFR 表 B がこ
こにあるとか。
http://www.emc.ncep.noaa.gov/mmb/data_processing/bufrtab_tableb.htm
ちなみに、気象庁でいうと、だいたい dump files に対応するのがデコードデー
タと呼ばれるもので、気象業務支援センターから提供されています。
http://www.jmbsc.or.jp/hp/offline/cd0430.html
2014-05-13
閏八月のある年は残暑が厳しい？
「閏八月のある年は残暑が厳しい」ということを昔は言ったらしく、さるところで質問に答えた。流れ去るのはもったいないので再録しておく。
----
旧暦が気象を制御するということは荒唐無稽というのはいうとおりだと思いますが、見かけの残暑ということはあるかもしれません。
閏月は、旧暦の月が次第に季節より早く進みすぎてしまうので調整に入れるものです。八月が閏月になるということは、閏じゃない本物の八月は限度一杯まで早く到来するということです。
限度とは何かというと、八月とは秋分（今で言う９月２３日頃）がある月と定義されているのです。八月が遅く来る年は、秋分の直前の朔が八月一日となります。こういう年の八月は（今で言う１０月に近いですから）寒いです。一方、八月が早く来る年は、秋分の直後に九月一日となります。こういう年の八月は（今で言う９月に近いですから）残暑そのものです。
旧暦で残暑を占った人は旧暦で生活していた時代の人でありませんでしょうか。そういう人にとって見れば、名目上の八月が同じ月なのですから、同じ月が閏月の入り具合で暑かったり寒かったりするように思えたことでしょう。
まあ、要は「暑さ寒さも彼岸まで」を別の形で言っただけではないかと思うのです。
2014-05-07
星になった沼口さん
調べ物をしていたら発見。小惑星になったんでしたね。
http://ssd.jpl.nasa.gov/sbdb.cgi?sstr=10155+Numaguti
沼口敦さんについては天気の追悼記事を引くのがいいかな。
http://ci.nii.ac.jp/naid/110001814499
気象庁情報カタログ（平成26年4月1日付け）がホームページ上で公開されています
かつて情報総覧ともいわれていたものです。
http://www.jma-net.go.jp/common/177jmh/catalogue.html
支援センター、ホームページ、無線FAX放送などさまざまな提供手段がありますが、それらについてはひとつ上のページをご覧ください。
http://www.jma-net.go.jp/common/177jmh/index.html
http://www.jma-net.go.jp/common/177jmh/catalogue.html
支援センター、ホームページ、無線FAX放送などさまざまな提供手段がありますが、それらについてはひとつ上のページをご覧ください。
http://www.jma-net.go.jp/common/177jmh/index.html
2014-05-05
[作業ログ] mikutter に画像投稿用プラグインを入れる
mikutter という ruby で書かれた twitter クライアントがあります。通知音用に「みくっ」とかいった音声ファイルがついててお好きな方には…もとい、ruby/gtk アプリケーションとして、また最近のソフトウェア共有のありかたについてたいへん勉強になりそうなので使っています。
で、一応 twitter クライアントとして使う場合には画像を張り込みたいということもありますわね。
プラグインをインストールしてみることにしました。
1.概論
まずはプラグインの説明のページでインストール法を見ます。なんか git clone するっていいますね。
2. penguin2716さんの（挫折）
(1) 序
それからプラグイン一覧のページにいくと、 一番シンプルなのはmikutter_update_with_mediaのようです。
まずは、プラグインの指示に従い依存ライブラリをインストールします。
$ sudo gem install twitter
(出力略)
なんかいろいろ言いますが基本的にエラーじゃなさそうなのでよしとします。
ついでインストール法を試してみましょう。
$ mkdir -p ~/.mikutter/plugin
$ git clone git://github.com/penguin2716/mikutter_update_with_media.git ~/.mikutter/plugin/mikutter_update_with_media
(出力略)
これも何やらファイルを落としてきたくさいことがわかりますのでよしとします。
(2)破
ここで起動すると、 twitter という gem が無いから bundle install しろとかいって mikutter が落ちます。
bundle というのは mikutter のインストールのときにやったあれですね。 何をするものか知りませんが、もういちどやれというのでしょう。気を取り直して mikutter インストールのときに作ったディレクトリに行って
$ bundle install --path=vendor/bundle
とします。これでは新しいプラグインを関知しないのではないだろうか、と心配していると、どういうわけだか http だの twitter だのといった gem をインストールします。
もういいんじゃないかと思うので mikutter を起動すると今度は動きます。プラグインの指示に従ってショートカット設定を開くと、「画像付きで投稿する」が現れたのでひとまず成功でしょう。
ショートカットを設定したら、mikutter を再起動する必要があるのかもしれないけど、実験しないで再起動しちゃったのでわかりません。
(3) 休す
で、ショートカットキーを押してしばらくまつと、gtkのファイル選択ウィンドウが出るんです、が、選択しても何も起こりません。本当はデバグするべきなんでしょうがとりあえず挫折。（後述バグによるものか？ だとすれば根深いかも）
3. mogunoさんの（成功）
気を取り直してもういちどプラグイン一覧のページにいくと、https://github.com/moguno/mikutter-uwm-hommageというのがあるようです。
しかも、説明を読むと、twitter gem とか不要だ（しかも日本語がらみのバグがあるらしい）というんですね。つまり上述2.(2)は不要だったようです。が、やってしまったものは仕方がありません。まあいいでしょう。うちのmikutterは太ったままで運用します。
$ git clone git://github.com/moguno/mikutter-uwm-hommage.git ~/.mikutter/plugin/mikutter-uwm-hommage
こんどはGUI版なんで、ショートカット設定も必要なく、投稿ボタン右に画像付投稿ボタンが現れます。めでたしめでたし。
で、一応 twitter クライアントとして使う場合には画像を張り込みたいということもありますわね。
プラグインをインストールしてみることにしました。
1.概論
まずはプラグインの説明のページでインストール法を見ます。なんか git clone するっていいますね。
2. penguin2716さんの（挫折）
(1) 序
それからプラグイン一覧のページにいくと、 一番シンプルなのはmikutter_update_with_mediaのようです。
まずは、プラグインの指示に従い依存ライブラリをインストールします。
$ sudo gem install twitter
(出力略)
なんかいろいろ言いますが基本的にエラーじゃなさそうなのでよしとします。
ついでインストール法を試してみましょう。
$ mkdir -p ~/.mikutter/plugin
$ git clone git://github.com/penguin2716/mikutter_update_with_media.git ~/.mikutter/plugin/mikutter_update_with_media
(出力略)
これも何やらファイルを落としてきたくさいことがわかりますのでよしとします。
(2)破
ここで起動すると、 twitter という gem が無いから bundle install しろとかいって mikutter が落ちます。
bundle というのは mikutter のインストールのときにやったあれですね。 何をするものか知りませんが、もういちどやれというのでしょう。気を取り直して mikutter インストールのときに作ったディレクトリに行って
$ bundle install --path=vendor/bundle
とします。これでは新しいプラグインを関知しないのではないだろうか、と心配していると、どういうわけだか http だの twitter だのといった gem をインストールします。
もういいんじゃないかと思うので mikutter を起動すると今度は動きます。プラグインの指示に従ってショートカット設定を開くと、「画像付きで投稿する」が現れたのでひとまず成功でしょう。
ショートカットを設定したら、mikutter を再起動する必要があるのかもしれないけど、実験しないで再起動しちゃったのでわかりません。
(3) 休す
で、ショートカットキーを押してしばらくまつと、gtkのファイル選択ウィンドウが出るんです、が、選択しても何も起こりません。本当はデバグするべきなんでしょうがとりあえず挫折。（後述バグによるものか？ だとすれば根深いかも）
3. mogunoさんの（成功）
気を取り直してもういちどプラグイン一覧のページにいくと、https://github.com/moguno/mikutter-uwm-hommageというのがあるようです。
しかも、説明を読むと、twitter gem とか不要だ（しかも日本語がらみのバグがあるらしい）というんですね。つまり上述2.(2)は不要だったようです。が、やってしまったものは仕方がありません。まあいいでしょう。うちのmikutterは太ったままで運用します。
$ git clone git://github.com/moguno/mikutter-uwm-hommage.git ~/.mikutter/plugin/mikutter-uwm-hommage
こんどはGUI版なんで、ショートカット設定も必要なく、投稿ボタン右に画像付投稿ボタンが現れます。めでたしめでたし。
2014-04-24
Pythonメモ その4
引き続いて Swaroop "A Byte of Python" 読んでいます
・引数デフォルト値。まあ今どきFortranでも出来る。
・キーワード引数。まあ、やっぱり :key=>val より key=val のほうがいい。
・可変長引数。複数の引数をタプル（イミュータブルなリスト）またはディクショナリとして受ける機能。Rubyで言うと配列とハッシュだわね。
・関数が値を返すにはreturnが必要。Rubyのメソッドでネストしたcaseが最終文の時、一体どこの行がreturn相当か考えるのもしんどいので、まあ悪いことで無いと思う。
・returnのない関数は None という値を返す。nil相当だろうね。
2014-04-22
pythonメモ その３
引き続いて Swaroop "A Byte of Python" 読んでいます
・関数を def で始めることは Ruby と同じ
・関数にかっこが必須なこと（定義、引用とも）
→関数名そのものは関数オブジェクトを指す。一見さん向きではないが綺麗な文法だろう
・何もしないpass文（制御構造をインデントするために必要）… FortranのCONTINUE文ですね。素敵な変態加減。
・docStrings: 関数冒頭に文字列だけを一文として置くと、関数オブジェクトの __doc__ メソッドとなり、help 文はそれを問うている
・関数内で使い始めた変数はローカル。明示的にglobal宣言をすると変えられる
2014-04-20
システム間で流通するデータ形式の標準にプログラム言語のバインディングを与えること
先日ね、上司が「yamlのいいところは、一発で読めてパーザがいらないところだ」っていうわけです。
もちろんそうなんだろうけど、あれっとも思ったんです。UMLモデラーが自動プログラミングを喧伝することに常日頃から私が不快感を示しているわけだけれども、データ形式とプログラム言語のバインディングという意味では同じじゃないのかと。
結論から言うと、配列とハッシュという万能データ型コンビが、カスタムの構造型とくらべて「他人から押し付けられる場合の嫌」が少ないんでないかなと思うわけです。ダックタイピング的には拡張しても別物にならないほうがいいですしね。
2014-04-18
nm(1) の出力の読みかた、あるいはFortranやCの分割コンパイルとリンクとは
なんか最近こういうのを書いておかないといけないと思うんです。どっかに良いテキストがあるんでしょうが、探すより書いちゃったほうが速いかなと。
まずもって実用的なところから。nm コマンドはオブジェクトファイルまたはライブラリを引数にとってオブジェクト内のシンボルを表示するものです。出力の各行はアドレス（あれば）、シンボルの種類、名前です。
まあちょっと例を見せたほうがいいですね：
$ cat a.c
#include <stdio.h>
int x;
int main()
{
static int s;
int r;
r = printf("%d\n", x);
return r;
}
$ cc -c a.c
$ nm a.o
00000000 T main
U printf
00000000 b s.1780
00000004 C x
プログラム中の名前がいくつか nm の出力に現れています。種別はこんなところですね：
b: BSS領域（小文字はリンク対象ではないことを示す）
C: コモン領域
D: データ領域（上にはないけどついでに）
T: テキスト領域
U: 未定義シンボル
で、なんたら領域と言われてもわからんという人が多いと思うわけです。
ノイマン型コンピュータではメモリは命令列とデータ（演算対象）のふたとおりに使われると教えると思います。ちょっと古いです。CやFortran（90以降）の実用上は、命令列・データ・スタックの３通りに使うと理解したほうがいいと思います。
（スタックというのは、手続（Cの関数、Fortranのサブルーチンや関数）に入る時に戻り先アドレスを保存したり、手続の中だけで使う変数を確保しておく場所で、手続の呼び出し階層が深くなると一方向に伸びていくものです。これによって、手続が同じ手続を呼び出すこと（再帰呼び出し）が可能になります。いいかえると、FORTRAN77が再帰呼び出しを禁止していたのは、かつてメインフレームにスタックがなかったからです。）
データのメモリを動的に確保して開放のタイミングを自分で制御（手続が終わった後も残したり、手続の途中で開放したり）したいことがあります（Cのmalloc(3)やFortranのポインタに対するALLOCATE）が、これはヒープと呼ばれます。都合4種類になりますね：
メモリの用途
└┬命令列（静的＝位置固定）
├スタック（動的、手続終了時に開放）
└データ
├ 固定アドレスのデータ（静的）
└ヒープ（動的、明示的に開放）
さて、大抵のOSではプログラムはファイル（executable file = 実行ファイル。メインフレーム方言ではロードモジュールという）に格納されます。そのファイルには何が書かれるかというと、だいたいは静的な（プログラム開始時にアドレスが確定する）ものです。どこに何という名前で何バイトとっておいて何を書いておけ、というようなことが並んでいるわけです。動的なものは大きさくらいしか書いてないです。
CやFortranでは分割コンパイルができます。ソースコードひとつひとつをコンパイルしたもの（オブジェクトファイル）をリンクして実行ファイルができるわけです。実のところ実行ファイルとオブジェクトファイルは共通のフォーマットになっています。リンクという操作は、オブジェクトファイル内の名前を全部調べて、仮のアドレスをつけかえてアドレスを種類別に連続して並ぶようにしたり、未定義シンボルとなっていたところを他のオブジェクトファイルの同名のシンボルのアドレスで埋めてやるというような操作です。
で、ようやく最初の nm に戻るわけですが、命令列をテキストというのはいいとして（何故ですかね。私も知りません）、固定アドレスのデータにはいくつか種類があります。おもに初期値の与え方によって分かれるわけです：
シンボルの主な種類
└┬ U 未定義シンボル
├ T テキスト（命令列）
└固定アドレスのデータ
├ D 非零の初期値があるもの（データ領域）
├ B 初期値がゼロなもの（BSS領域）
└ C 初期値が他のファイルにあるかもしれないもの（コモン領域）
まずいちばん基礎的なのがデータ領域ですわね。初期値があってゼロとか決め打ちできないわけですから、それをファイルに書いておかねばなりません。同じ名前が複数あったらリンカが duplicated symbol というエラーを吐いて教えてくれます。
次はBSS領域。これは初期値がゼロなものです。初期値がゼロな変数はしばしばあるものだし、初期値をファイルに書いておかなくてもいいですわね（あれ、昔はBSS領域を使いすぎるとファイルがでかくなるからだめだと言われたような気がするんだけどなあ…今実験してみてもそんなことはありません）。こいつも外部リンケージを持つなら重複してはいけません。
さっきの関数外 static 変数の例では nm が小文字 "b" を表示しているので、別のソースコードに同じ変数 s があったとしてもかまいません（別物としてアドレスが確保されます）。なんか gcc の場合は単なる s じゃなくて s.1780 とかいう名前になっていますが、デバッガの都合かなんかでしょうかね。よくわかりません。
最後のコモン領域というのは、特色として複数のオブジェクトファイルで同名のシンボルがあってもエラーにならず、一本化されます。初期値は指定できません（どれを選んだらいいかわかりませんね）が、同名のデータ領域のシンボルが１つだけならまとめて一本化されます。
これはC言語としては初期値のない関数外の「int x;」みたいなのでできるものですね。宣言（名前に型を指定するだけでメモリは割り付けない）なのか定義（メモリを割り付ける＝大抵は同名が重複してはいけない）なのかよくわからない文で、複数のソースコードで同じ 「int x;」とやってもエラーにならない（宣言みたいだ）けれど、最終的にメモリなしになってしまうのでなく1箇所のメモリが割り当てられるわけですが、そういう性質はコモン領域のものです。
関数内の static じゃない変数 int r; は nm の出力にあらわれていないことにも注意しておきましょう。こういった変数はスタック上にとられます。関数冒頭にスタックを伸ばして r のぶんのメモリを書く命令と、関数の脱出時にスタックを同量縮める命令が入るわけですが、r そのものは固定したアドレスをもたず、関数外から参照することもできない＝リンカがリンクすることもないわけです。
ところで、コモンというと Fortran の悪名高きコモンブロックが思い出されますが、実際そうです。モジュールなんかを使わない古典的な（77的な）例を下に示しますが、コモンブロックがコモン領域に、サブルーチン内のSAVEがついた変数がBSS領域に割り当てられます。
$ cat b.f
SUBROUTINE MAIN(L)
COMMON /BLK/ I
INTEGER J, K
SAVE K
J = K
K = L
L = J
PRINT *, I
END SUBROUTINE
$ gfortran -c b.f
$ nm b.o
U _gfortran_st_write
U _gfortran_st_write_done
U _gfortran_transfer_integer
00000004 C blk_
00000000 b k.695
00000000 T main_
【補遺2014-04-20】
フォロワーさんから次の本を勧められました。未見ですが挙げておきます。
CQ出版 リンカ・ローダ実践開発テクニック
JANコード：JAN9784789838078
2010年9月1日発行
坂井 弘亮 ／ 著
http://shop.cqpub.co.jp/hanbai/books/38/38071.html
2014-04-15
[Fortran] 書式なし順番探査ファイルの形式（2GB超では互換性を欠くみたい）
Fortran では書式なし順番探査ファイルはレコード内容の前後にバイナリのレ
コード長がつきます。
最近の gfortran ではレコード長が 4 オクテット（デフォルト）または8オク
テットで選択できて、 -frecord-marker=8 オプションで変更できます。
http://gcc.gnu.org/onlinedocs/gfortran/Runtime-Options.html
インストール時のデフォルトで8オクテットに設定する事もできるようですが、
どうやるのか知りません。
対して Intel Fortran ではレコード長は常に４オクテットで、2ギガバイトを越
えると分割出力されます。レコード長が負の場合は分割を意味するようです。
https://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/fortran-mac/GUID-E36C2463-1514-4E4E-B88A-769AB0326C57.htm
コード長がつきます。
最近の gfortran ではレコード長が 4 オクテット（デフォルト）または8オク
テットで選択できて、 -frecord-marker=8 オプションで変更できます。
http://gcc.gnu.org/onlinedocs/gfortran/Runtime-Options.html
インストール時のデフォルトで8オクテットに設定する事もできるようですが、
どうやるのか知りません。
対して Intel Fortran ではレコード長は常に４オクテットで、2ギガバイトを越
えると分割出力されます。レコード長が負の場合は分割を意味するようです。
https://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/fortran-mac/GUID-E36C2463-1514-4E4E-B88A-769AB0326C57.htm
2014-04-07
Pythonメモ その２
引続き A Byte of Python を読みながら（前回文献書いてなかったごめん）。
●シングルクォートとダブルクォートの中では等しくバックスラッシュエスケープが処理される。文字列に r を前置するとバックスラッシュエスケープが抑止される。正規表現に勧められるという。つまり正規表現リテラルは無いのかな。まあ、思い切りが良いとは言えるかな。
●真偽値定数は True and False
●while/for ループの else: ブロックはループ脱出時に呼ばれる。確かに脱出時処理を書きたいことはあるね。
●range() の結果は配列ではない。要すれば list() に食わせてリストにする。
●range（0, 10）は10を含まない。Rubyの .. と ... えーと、どっちだっけ。忘れるくらいだから別の文法でもいい。
2014-04-02
ruby でトップレベルにコードを書かないスタイルを「インスタンスって何」と思ってしまう Fortran 使いに説明するの巻
毎年4月になるとなんかこういうことをしているので、なんとか経験を洗練したいものです。
要はこう言うと楽なのではと思いましたよ。
なんでトップレベルで書かないかというとその心は、複数メソッドが現れるならば、最初からその間で共有されるデータのスコープ管理をしておかない といけないということであって、それってFortranのモジュールでできたことと同じなんですよね。だからモジュールでたとえてしまえばいいの ではないかと。
要はこう言うと楽なのではと思いましたよ。
- クラスというのはFortranのモジュールみたいなものです。使い始めに任意のサブルーチンじゃなくてnewを呼ばなければいけな いので、変数の初期化を普通はinitialize内でやります。
- インスタンス変数（@name）というのはFortranのモジュール変数です。
- インスタンスとは何かというのは、今はわからなくてもいいです。１クラスを同時に複数個newできて、その時インスタンスが複数ある という言い方をします。クラスにはコードが所属しますが、インスタンスにはデータが所属します。
- クラス変数（@@name）というのは複数インスタンスがあるときに共有される変数です。私はほとんど使いません。
- グローバル変数（$name）というのはFortranのコモンブロックです。覚悟をもって使用してください。
class App
def initialize argv
# 初期値設定
@files = []
for arg in argv
case arg
when /\A-d\z/ then $DEBUG = true
# その他オプション処理
else @files.push arg
end
end
end
def run
for file in @files
File.open(file, 'r') {|fp| fp.each{|line| ... }}
end
end
end
App.new(ARGV).run if $0 == __FILE__
で、Ruby初めてでトップレベルで Hello World から入った人がこれをいきなり見ると「うっ」となるわけですね。悩んだ挙句「インスタンス（変数）ってなんですか」みたいに聞かれて、素直にインスタンスから説明すると時間を無駄にするんですわ。この2014年にもなってOOPを全く知らないなんて、と読者諸兄は思われるかもしれないけど、気象界は世間と隔絶したところなんで、プログラミングセンスがあってもOOPを全く知らないなんてことが平気で起こるのです。何か方便が必要で しょうと。
なんでトップレベルで書かないかというとその心は、複数メソッドが現れるならば、最初からその間で共有されるデータのスコープ管理をしておかない といけないということであって、それってFortranのモジュールでできたことと同じなんですよね。だからモジュールでたとえてしまえばいいの ではないかと。
rubyist からみた python メモ
Swaroop "A Byte of Python" 読んでいる。
まあ順不同である。
- レキシカルな部分はあまり驚くようなことはない。
- しいていえばヒアドキュメントの代わりに三連引用符が用いられることくらいか。これ、どっかでみたな。RELAX NGだっけ。
- 前にも書いたが文字列が変更不可である。これはけっこうすごいことだ。
- 文字列リテラル内の式展開（Rubyの "#{expr}"）はないみたいだ。かわりに "{0}".format(expr) あるいは "{key}".format(key=...) のようにする。これはやや冗長ではあるが、評価タイミングが明確になって好ましいのではないか。
- 演算子もむちゃくちゃ驚くものではない。整除（floor）が // で実数商が / のようだ。
- 代入は文であって式ではないらしい。これは if a = b のような誤りを防げるからわるい話ではない。ちょっとFortranを思い出す。
- if のあとは elif である。elsif ではない。あと、case 構文はないようだ
2014-03-30
CVSROOT=:ext:略 cvs co にあたることは github にあるリソースに対してはどうやるの（開発者になれなかった俺はしぶしぶgitをインストールしましたみたいな）
なんか github にあるソフトウェアをレビューしなきゃならんのだよ。
いぜんこういうことを言っていたのだけれど、天罰覿面。
なんか言ってる人がいますが、せめてSubversionくらい使えるようになろうと一念発起してCVS使うのやめたんです。で、レポジトリの構造忘れてlsみたいコマンドもわからないので、日常的な作業ではRCSです。バックアップは、諦めました。
— TOYODA Eizi (@e_toyoda) 2014, 2月 11自作の開発なら必要もないのに新しい VCS なんか使わない、というだけで完結して10年以上 CVS だけ使って生きて来ちゃったのだが、仕事の質が変わったので話はそうはいかない。
なお、適当に独学しただけなので、無保証注意喚起。読者諸兄が真似してなにかマズいことをやらかしてしまったとしても当局は一切感知しない。
2014-03-21
ＵＭＬの矢印たちをＸＭＬエンコードするときに順番の決まりがあるわけではないらしい
まあ、表題で尽きるわけですが、フォーマルに書こうとすると「俺無知だった」視点の試行錯誤が抜けて意味がわからなくなる文化ギャップ系の話。
ＵＭＬモデリング（本当は論理モデリングっていうのかな）で作られた標準ありますでしょ。ＩＳＯ１９１１５（地理情報メタデータ）なんかが念頭にあるわけですが、大抵ＵＭＬが本則（authoritativeとかいう）でデータ辞書とか（あれば）ＸＳＤが参考だって位置づけにされるんですよね。
で、実際問題としてはＸＳＤで記述されるＸＭＬが使われて、子要素の順番が問われるエンコーディング（ＵＭＬの構造をどうやって具体構造に対応付けるか）が行われるわけですから、順番を知らなきゃ話になりません。しかしＵＭＬを見ても箱からいっぱい線がでていて、どの順番でＸＭＬの子要素にするのかは自明ではありません。
で、ＩＷＸＸＭで同じことをやるので聞いてみたわけです。せんせー、上から右回りとかジグザクとか規則あるんですか。
答は、「そんなものはない」でした。
ＵＭＬモデリングツールであの図を作っているときは、線にタグという見えないデータが貼り付けることができて、それを使って線に１，２，３，…て順番をつけておくと、ＧＭＬエキスポートツールがその順番に xs:element を書いてくれるんだそうです。
ＵＭＬは図形言語なはずなんですが、実際問題としては図形表示に見えてこないことが大事なんですね。まあ、１９１１５の場合はＸＭＬ表現はあくまで表現の一例なので、あくまで順番は決まっていないから、ＵＭＬが本則になっているのだ、というべきかもしれません。実際問題としては１９１１５−１の今次改正でデータ辞書の順番を変えないように気をつけたとかいうくらいで、強烈に意識されてはいるんですが。で、ＩＷＸＸＭでは特定のＸＭＬ表現を必ず使うことになるので、ＵＭＬではなくＸＳＤが本則になるのは、そういうわけだそうです。
そういえば、ＵＭＬをＸＳＤに翻訳することをシリアリゼーションと呼んでいました。普通は、アプリケーション内の個別のインスタンスをメモリ内構造からファイルなりＨＴＴＰ応答のオクテット列に変換することをシリアリゼーションというんだと思いますが、メモリ内構造→ＵＭＬ、ファイル→ＸＳＤという塩梅でそれぞれメタなものに置き換えた操作もシリアリゼーションではあるのでしょう。でもって、直列化イコール順番の導入ですから、順番が問われたのも当然のなりゆきではあります。
それにしてもなあ、順番を手入力するとなると、モデルというものの本質が線条的なもんだと言っちゃってもいいような気がするんですよね。じっさいＵＭＬはモデルの表現にすぎないって意見も出てたし。結局、ＢＮＦみたいな線条的な言語で書いちゃったほうがよっぽどわかりやすいし、ツール（今はAltovaじゃなくてEnterprise Architectが使われている）のサスてナビリティが高い気がするんですが、それはＦｏｒｔｒａｎのＢＮＦとかｙａｃｃとか読みすぎなんですかね。まあ、事務処理だってMSWordやめてTeXでやるかといってるようなものかもしれません。
登録:
投稿 (Atom)