日本語練習帳

つらみのラプソディを歌います

複数のファイル間でデータ平均を取るtips

数値計算による研究をしていると,

  1. 何らかの方法でデータを拾い,無加工で出力する
  2. 出力されたデータを処方箋に則って加工する
  3. 加工されたデータを視覚化し,考察する

というサイクルに耽溺することが多いかと思います.そればかりやるのが良いか悪いかは置いておいても.

そして,多くの場合は出力加工は自動化することが出来て,何も考えなくてもプロセスが進むため,研究している側は他のことに時間を費やすことが出来ます.

しかし,比率で言って出力よりも加工の方が圧倒的に時間が掛かるなと思ったら,何かを疑ったほうが良いでしょう.もしそのような事態に陥ったら,原因として

という可能性を探ってみて下さい.このような組み合わせは,端的に言ってバランスが悪いです.

そこで,思い切ってなるべくスクリプト言語を使わないという方法を提案し,データセットが十分に大きい場合にはこの考えが役立つことを示していこうと思います.


※本記事では実データの例時間計測の結果を示すには時間の都合上至りませんでした.また後日にでも続きを書こうと思います.


始めに

以下のような2つのテキストファイルがあるとします.

1 1.0 1.0
2 1.2 0.9
3 1.4 0.89
4 1.6 0.899
5 1.8 0.8999
1 2.0 2.0
2 2.2 1.9
3 2.4 1.89
4 2.6 1.899
5 2.8 1.8999

そして,それぞれをdata1.datdata2.datと名付け,併せて一つのデータセットだと考えます.

つまり,data{1,2}.datの1-3列目をそれぞれ $$ \begin{align*} t,\quad \{f_{i}(t)\}_{i=1,2},\quad \{g_{i}(t)\}_{i=1,2} \end{align*} $$ とおいて,$f(t)$,$g(t)$という2種類の時間依存データが2つ存在すると見做します1

さて,これらの2つのデータの2列目と3列目の平均を取って,

1 1.5 1.5
2 1.7 1.4
3 1.9 1.49
4 2.1 1.499
5 2.3 1.4999

という新しい1つのデータに統合することを考えます.即ち,数式で表現すると $$ \begin{align*} \tilde{f}^{(N)}(t):=&\frac{1}{N}\sum_{i=1}^{N}f_{i}(t)\\ \tilde{g}^{(N)}(t):=&\frac{1}{N}\sum_{i=1}^{N}g_{i}(t) \end{align*} $$ という新しい量を定義し,それらのデータを $$ \begin{align*} t,\quad \tilde{f}^{(2)}(t),\quad \tilde{g}^{(2)}(t) \end{align*} $$ という形で吐き出すことを目標に据えます.

一般にこういう作業を「クローンデータの平均化」と読んだりします2

こうやって書くと比較的シンプルな課題なので,シェルスクリプトとか単体のawkスクリプトによってさっくりと解決できそうなものです.

実際,データセットのサイズが十分に小規模のものについては,幾つかのブログで紹介されています.自分は,特に『複数ファイルの列データを1ファイルにまとめる』を参考にしたので,挙げておきます.

masa-cbl.hatenadiary.jp

短く言えば,「スクリプト言語の範囲で簡単に出来ますよ」という内容です.


スクリプト言語からの逸脱

ところが,上に挙げたようなデータセットのサイズを遥かに超えるような巨大なものについては,何が起きるかわからないのがスクリプト言語というものです.つまり処理速度の点では「向かない」と言えます.例えば,一般に $$ \begin{align*} t,\quad \tilde{f}^{(N)}(t),\quad \tilde{g}^{(N)}(t) \end{align*} $$ と書いて,$N$が$1000$とか$10000$のオーダーで,$t$方向にも$1000$行~$10000$行程度のデータが並ぶような場合を考えます.そのようなサイズのデータに対して,同様の処理をスクリプト言語でやろうとすると,(データ構造にも依りますが)よっぽど気を使って最適化しない限り1日や2日の規模の時間を消費します3.そして,普通は1日をかけるような贅沢は言っていられないわけです.

やがては「いっその事スクリプト言語を辞めてC++Fortranなどのコンパイル式の言語に頼った方が良いんじゃないの?」という問に到達します.「パンがないならお菓子を食べればいいじゃない」ではないですが,時間との戦いが厳しくなってきたと思ったら,発想の転換を余儀なくされます4


Fortranによるデータセットの平均化

そこで,データ加工をFortran(=Fortran95)を使って行う方法を紹介します.

まず,ソースコードを以下に示します.以下のコードは

  • 加工したいデータセットの一つ一つがdata001.datdata002.dat,…という風にゼロパディングされた3桁の自然数によって番号付けられていて,実行ディレクトリ直下に存在すること
  • それらの個数(n)及び各データの行数(time)をユーザーが把握していること
  • 実行ディレクトリ直下にdata.datというファイルが存在しないこと

を前提として動きます5

PROGRAM analyze

  IMPLICIT NONE

  !変数宣言
  CHARACTER si*4
  INTEGER(kind = 4) :: i, it, dum_t, dum_d
  INTEGER(kind = 4) :: n, time
  DOUBLE PRECISION, ALLOCATABLE :: d(:)

  !標準エラー出力(装置番号0)でコンソール部分を分離する
  WRITE(0, *) "[Input] Number of Clones."
  READ(*, *) n !data*.datの個数を標準入力に読ませる
  WRITE(0, *) "[Input] Length of each Stream."
  READ(*, *) time !各data*.datの行数を標準入力に読ませる

  ALLOCATE(d(1:time)) !データを読むための配列を割付

  d(1:time) = 0d0 !配列を初期化

  !データを配列にスタック
  DO i = 1, n, 1
     WRITE(si, '(I0.3)') i !数値を文字列に変換
     OPEN(10, file="data"//si//".dat", status="old")
     DO it = 1, time, 1
        READ(10, *) dum_t, dum_d !ダミー変数に読み込ませる
        d(it) = d(it) + dum_d !配列に順次加算
     END DO
     CLOSE(10)

     OPEN(11, file="data.dat", status="new")
     DO it = 1, time, 1
        WRITE(11, *) it, d(it)/n !平均化されたデータを出力
     END DO
     CLOSE(11)
  END DO

  DEALLOCATE(d) !配列の割付を解除

END PROGRAM analyze

次に,プログラム内部の流れはコメントから明らかだと思うので割愛することにし,これを使ったり,改変して別の用途に用いたりするための普遍的な手順を紹介します.

  1. 処理したいデータの全てを実行ディレクトリ直下に配置する.
  2. 上記のソースをコンパイルして実行する.
  3. 標準入力からデータの数各データの行数を入力する.

多くの場合,そうやって出てきた加工済みデータ(data.dat)に対して更なる処理を加えたり,gnuplotで視覚化したりすることが想定されるため,加工処理が済んだら,加工前データ(data???.dat)を適当に退避させると良いでしょう.

例えばGNUコンパイラの場合だと

gfortran main.f90 -o main

などで実行ファイルを作ってから

echo "${numParam} ${numClone}" | ./main
mkdir clone
mv data???.dat clone/

を1セットで行うのもありです.…と思った矢先に

/bin/mv: Argument list too long

と怒られる事案が発生しました.こういう時は,まずmvの代わりにxargsを用いて

find . -name "data???.dat" | mv {} clone/

を試すのがお約束でしょう.しかし,それでも怒られることがあります.その時は,最終手段としてGNU Parallelを用いて全CPUを叩き起こせば何とかなると思います.

find . -name "data???.dat" | parallel --bar -a - mv {} clone/

何とかならなかった人は,ご愁傷様です.この優先順位でparallelに手を出した場合、それなりに時間がかかることが予想されるため、一応--barによって進捗を観察できるようにしています.

ひとまず,試してみたい方はお手持ちのコンパイラ6で上記のソースをコンパイルして,爆速のデータ処理を存分にご賞味あれ.


シェルスクリプトによるデータセットの平均化

比較対象と言ってはなんですが,自分で試行錯誤の末に作ったシェルスクリプトワンライナー版を以下に示します7

seq 1 1 $time | parallel -k --bar -a - "awk '\$1=={1} {d+=\$2} END{print {1}, d/NR}' data*.dat" >> data.dat

各々のシェル変数は,Fortranソースコードとの対応を考えて,同じ文字を使っています.nに対応するシェル変数は正規表現のお陰でどこかに飛んでいってくれました.

--barは,何となく「進捗が目に見えないと気が狂いそうだから」という理由で付けています。

これを使ってデータ処理を行うと,飽くまで記憶の範囲ですが,かなりの時間を取られました.「parallelの効果がCPUのコア数に依存するから」というのも考えられる一つの原因ですが,メモリアクセスの効率も一般にC++Fortranに比べて悪い可能性があります.

逆に言えば,そこを改善できれば,処理速度の問題は解決できると踏んでいます.


終わりに

本当は,例えばawkワンライナーC++とかFortranに匹敵するスピードでデータ処理を行うのが目標でした.

しかし,速度比にして10倍~100倍の悦びを知ってしまった今,思いつきの「(大きなデータを処理する時は)スクリプト言語を使うのをやめよう」という考えにシフトしつつあります.

ただ,スクリプト言語についてはとにかく勉強が浅いので,ちゃんとやれば任意のスクリプト言語で爆速データ処理が出来るという希望も捨てずに,色々な可能性を探っていこうと思います.

一方で,この記事の内容は「コマンドの起動時間とデータの参照時間の2つは飽くまで兼ね合いの関係にあるのだから,それはそう」と言われてしまえばお終いです.でも,それを自分の手で確かめることは大いに意義があると思われます.


(2017/02/16追記)

Mathjaxの調子がおかしくて何度も更新を繰り返してしまった.

近いうちに,はてブMarkdown記法で数式を記述する時に必要な手順についてまとめようと思います.


  1. ここでは,両者ともに1列目($1,2,3,4,5$)が共通しているのがポイントで,個々で言う「データ」には情報としては含まれません.逆に,これらが異なっている場合には,シェルスクリプトseqpasteを使って$1,2,\ldots$という縦のストリームを左側に付け加えれば,この記事の議論がそのまま適用できます.

  2. 勘の良い方はお気づきかも知れませんが,自分は物理のシミュレーションをする際に必要に迫られ,このテクニックを取り入れました.例えば,Ising模型における磁化やエネルギーなど,(一般に)MC時間に依存するような物理量の時間発展は,初期状態と乱数の種子によって決まります.つまり,初期状態を決めてシミュレーションを行っても,乱数の種子を入れ替える限り,無数の種類の(系の)時間発展が考えられます.一方,統計力学では,しばしば物理量を「圧倒的に多くの互いに無相関なサンプルの平均」によって決定します.この無相関なデータセットとして「ある初期状態を決めた時の,幾つかの乱数の種子($i=1,2,\ldots$)に対するある量$\hat{F}$の時間発展の組$\{F_{i}(t)\}_{i=1,2,\ldots}$」というものが妥当であれば,それを採用しない手はありません.そこで,これらのデータセットのそれぞれの種子に対するものを「クローン」と呼び,それらを全部平均したものを「クローン平均」と呼ぶことにします.名前の由来は忘れましたが,互いに異なるクローンは(量子力学的な場合を除いて)MCMCの範囲では同時に実現しないからこそ「クローン」なんだろうなと推測しています.もし詳しい方がいらっしゃったら,ご教示願いたいです.

  3. 勿論,こんな主張は要出典なわけで「データを参照する順序がおかしいから時間を消費するんだ」とか「parallelコマンドの使い方を間違えてるんじゃないの」とか,ツッコミの可能性はいくらでもあります.ただ,ここで取り扱いたいのはあまり何も考えずに爆速でデータ処理をするといういわば脳筋的なテーマなので,悪しからず.

  4. ポール・ジョンソンの『インテレクチュアルズ』にもあるように,この言葉にまつわるエピソードの言い出しっぺはルソーで,一方で彼自身は全く出典を示していないそうです.少なくとも,マリー・アントワネットの言葉ではないらみたいで,自分もこの前Twitterで知ったばかりです.

  5. これらの前提条件を崩したい場合には,牛島さんの『数値計算のためのFortran90/95プログラミング入門』などを参照しつつ上のコードを書き換えて下さい.

  6. 大概はGNUコンパイラのgfortranかIntelのParallel Studio XEに付属しているやつのいずれかでしょう.

  7. 無論,ちゃんとやればFortran版に匹敵するスクリプトを組める可能性はある.また,PerlとかRubyとかPythonについては不勉強故コードの書き方を知らなかったため,今回は試していない.案外,そういう所に落とし穴があるのかも知れない.何かアイデアがあれば,ご教示願いたいです.

バレンタインデーの呟き

日記

明け方まで採点バイトをしていたせいか,そのまま12時頃まで寝てしまった.

そして,今日は特に13時過ぎに研究室に居る必要があったため,一旦寮で洗濯物を回し,その足で研究室に行って事務作業を潰し,また帰って洗濯物を干して,昼食に行くという変なルーチンをこなすことになった.

昼食は分福茶寮という奇天烈爽快な喫茶店で頂くことにした(n回目).

retty.me

相変わらずの美味しいチーズ焼きカレーでした.

f:id:taro17:20170214190530j:plain

今日はコーヒーセットを(学生なのでサービスとして)頂いたが,アイスクリームセットとかいうのもあるらしいので,今度はそちらも頼んでみようかと思う.

ifortでコンパイルした実行ファイルがアレする件について

もう知らぬ.要は,状況として「シェバン行から1行1行読ませれば通るスクリプトが,それ自体に実行属性をつけて./hoge.shすると全く読めなくなる」という症状に全てが集約されるのだが,その原因探しに最悪1ヶ月も潰すくらいなら,GNUに魂を売る方がよっぽど良いというものだろう.

後,昨日の記事

tarotene.hatenablog.com

にも書いた「ちゃんとlibiomp5をリンクすれば通る」なんて内容も飽くまで環境依存の話で,研究室のMacProでやったらやっぱり駄目でした.

状況に整理がついたらまた記事を書き直そうと思います.

研究について

昨日からあれこれ悩んでいるのも,全ては研究に用いる数値計算プログラムの実行なり解析なりをまともにやりたいという一点に尽きるわけで,そろそろ結果が厳密化されましたとか良いアルゴリズムを提案しますとか私の論文がA○Sから出版される運びとなりましたみたいな投稿をやりたくなってきましたね(血涙)

一応学会では,極めて希少な分野の代表みたいな感じで細々とセッショントークに臨む予定でございます.

エラー処理に1日を溶かしました(n回目)

本日のエラー処理

既に「Intel製のFortranコンパイラがどのMacでもまともに動かない」という問題を抱えていた.

具体的には,並列化オプション付きで.f90なり何なりをコンパイルすると,

software.intel.com

にも報告されているように,コンパイル自体は普通にうまくいくのだが

dyld: Library not loaded: libiomp5.dylib
Referenced from: /Users/$USERNAME/hogehoge
Reason: image not found

と言った形のランタイムエラーを吐き続ける.直接的な原因としては,fortranコンパイラの機能である並列化オプションとして -qopenmpを付け加えて

gfortran main.f90 -o main -qopenmp

というリストをぶち込んだからなのだが,少なくともGNU製コンパイラではそんなことは起きなかったし,これは明らかに変な阻害要因がある.というわけで,いくつかのページを当たってみたところ,以下のようなサイトに出くわし,問題は解決した.

Mac用McMaille - Kanza-wiki

どうやら,岡山大の神崎さんという方の研究室で更新されているwikiらしく,いくつかの数値計算用プログラムが公開されていた.意外と興味を惹かれるものが沢山掲載されていたから,また今度じっくり時間をかけてサーフィンしてみたくなるサイトだったが,そこに書かれていたのは,ただ単純に

DYLD_LIBRARY_PATH="(libiomp5.dylibの在り処)"
export $DYLD_LIBRARY_PATH

をすれば良いという情報が簡潔に述べられていた.これは,パスを通すという概念が腑に落ちていなかった自分としては盲点で,つい先日とあるシェルスクリプトGNU Parallelを実装しようとした時の経験が一切生かされていないと実感した.その時は「複雑な処理だけど同じことを色んなパラメータについて回す」ということをGNU Parallelで行うために,実は生まれて初めてシェル関数というものを使ったのだが,どうも

parallel (シェル関数名) [...]

みたいな使い方をしようと思うと,export -f (シェル関数名)が必要になるらしく,それを関数名宣言の後に付け加えて

foo(){
hogehoge
}
export -f foo

とし,一種の構文みたいな形で貼り付けていた1

このことは,コンパイラがライブラリを呼び出す時にも同様で,パスが通っている筈のディレクトリにlibiomp5.dylibなるものが無かったからである.そして,それをexport $DYLD_LIBRARY_PATHによって任意のシェルに引き継ぐ必要があった.

解決の流れは次の通りである.

  1. まず,locate libiomp5.dylibIntelコンパイラのライブラリの箇所を突き止める.

  2. 次に,その箇所のディレクト$DYLD_LIBRARY_PATH=/opt/intel/lib環境変数に代入する.多くの場合は/opt/intel/libだと思ったが,違った場合は適宜修正を.

  3. 最後に,環境変数を引き継ぐためのお呪いとしてexport $DYLD_LIBRARY_PATHをかける.

これによって,いつでもlibiomp5.dylibの呼び出しが可能になり,コンパイラオプションとして-qopenmpをしてもランタイムエラーが出なくなる.これらのことは,.bash_profileに書いておいても損はないだろう.

DYLD_LIBRARY_PATH=/opt/intel/lib
export $DYLD_LIBRARY_PATH

また,locateがまともに通らない場合は,お呪いとして

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.locate.plist

をやってしばらく待ってから再挑戦するというのも手だろう.

今日は一方で,えらく不思議なエラーに見舞われた.ログインシェルがbashで1行1行読ませれば通るリストを,いざスクリプトファイルにして読ませると(standard_in) 1: parse errorを吐くのだ.流石にキレソー.

その他

エクセルソフトさんが主催するセミナーへの参加を決意した.

www.xlsoft.com

数値計算における二大巨頭である並列化ベクトル化のうち,ベクトル化だけは全然知らないし,単に研究をしているだけではちっとも学べそうになかったので,その辺の意味合いも込めて話を聞いてくることにした.題材は,大正義IntelParallel Studio XEだそう2だが,なんと,この高価な(コンパイラ付き)ソフトが学生が非商用で利用するうちはタダなのだそうだ.詳しくは

Qualify for Free Software - Student | Intel® Software

にも書かれているが,(例え国公立であっても安くはない大学の学費が)より大きな巨額の富に化ける例だろう.他にも例えば,Jetbrains社のIDE利用ライセンスでも,ちゃんと学生プログラムがある.

www.jetbrains.com

こういう機会はみすみす逃さないようにしていきたいし,贅沢に利用しつつ真の自己実現を果たしたいと思うばかりである.

https://software.intel.com/en-us/intel-parallel-universe-magazine

お引っ越し

とある事情で研究室が移転することになったので,引っ越しの手続き以外(転入先の確定)を済ませた.

何の事はない,某柏大学に,JR京都駅もどき千葉支部が統合されるそうだ3.そこに指導教員が常駐することになったそうである.


  1. この用法は恐らく正しくない.というか,筆者自身がシェルスクリプトについて不勉強であることがそもそもの未解決問題であるように思えてきた.

  2. Fortran使いからすれば,Intelさんはほぼ唯一と言ってもいい力強い味方である.

  3. 今,柏大学は半分ほど更地になっていて,工事でいくつかの建物が建設中になっているが,そのうちの一つが第2京都駅というわけである.

午後を犠牲にしました

数値計算

昨日くらいから数値計算用プログラムの書き直しを行なっている.

と言っても,リファクタリングではない.むしろ処理の流れと区切りを変えようという試みで, 単一の.sh(上流) - 単一.f90(下流) という従属関係にある集合体を分割し,複数の.shから同一の.f90を呼び出すような関係に変えているだけだ.

割と骨が折れる.

いま示したい一連の結果がちゃんと「有意差」であることを見るには,適切な箇所で大量のサンプルを取る必要があるが,その適切な箇所の測り方を含めて,ちゃんと動作する環境を作りたかった.それだけだ.

しかしコーディングをやっていると自動化したいことと手でやりたいことの配分がせめぎ合う感じになって,精神衛生上よろしくない.

ピアノ

今日は昼過ぎにピアノを少しだけ練習した.今年度の残りは少ないが,「今年」演奏する曲もそろそろ確定した方が良さそう.キャパシティ的に3曲も4曲も仕上げられることは,多分ないだろう.とりあえず,

あとは室内楽サークルで毎年やってる新歓演奏会のために一応仮のものとして

のいずれかのsoloを某氏に依頼しようと思っている.断られたらまた考え直す必要があるなぁ.

ラヴェルの楽譜について,とっさの時にIMSLP等でダウンロードしようと思うと大体Durand社以外のものはなく,原典版としては権威があるのかも知れないが,運指法の点でとことん使いにくい.実家に音楽之友社から出版されているペルルミュテール校訂版を忘れてきたのが痛い.

40分間の数値計算が無に帰しました.

40分なんて大規模量子系計算を日常的にやりつつ論文を書いている人たちからすれば大したことないタイムスケールだとは思うが,僕にとって今回のロスは由々しき事態だ.

一応述べておくと,何分,何時間,何日と無駄にしようとも「プログラムがまともに回っていて意味のある数値が吐き出されていれば,計算のモチベーションはともかく結果は無駄ではない」という考えに立っている.即ち,どういうことかというと,40分間真面目に計算するフリを続けていた.f90のプログラムが蓋を開けてみればひたすら0.000という数字を吐いていたのだ.それだけです.

計算機としては手元にあるMacBookProを使っていて,コードの構造としては.shに支配された.gpなり.awkなり.f90なりがひたすらクルクルと踊っては.datを投げて,またそれを別の役者が受け止めるような感じになっている.要は,パラメータの入力を.shが受け付け,それを.f90が引き継いでガンガン回すわけだ.そこで無効な数値を入れたりすると,.f90に渡った段階でSIGSEVなり何なりの致命的なエラーを初期段階で吐いてくれるため,基本的に「黙々と計算が回っている=計算結果も一応は非自明なものとして出てくる」という立場で物事を進めていた.しかし.f90のコードをよく見てみると,case文の選択で無効な数値を入れても何もされないというアホンダラなバグがあったため,そこで系は初期状態のconfigから何も時間発展していなかったのだ.今見ようとしているのは静的な物理ではなくて動的な物理なので,計算したい物理量も静的な量と量の間の「差」から出てくる.完全に失敗した模様.辛い.

何を言っているか分からないと思うが,数値計算で物理を見ようと思うと,長時間を投入してワーッとやる前にきちんとバグ取りをしましょうねという話.

(コード上の表面的なバグ取りなら猿でも出来るかも知れないが,自明な結果を防ぐためには,敢えて変な機構をちゃんと取り付ける必要がある.例えばcase文の分岐パラメータは,それ以外のパラメータがあった場合は事前にエラー終了を返すとか.ところで,孫請け状態の.f90が.shにエラー終了値を返すとかって出来るのだろうか…?)

2017年の実質的な年明けです

年が明けてから十n日が経過したが,研究やその他の活動は相も変わらずである.

何とか数日間の鬱屈を解消し終えたところで,の申請書のアウトラインは整ったように思う.学会の講演要旨も叩き台程度にはなったはず.

講義のレポートには結局手を付けられなかった.締め切りという点では,3つある講義のうち一番余裕があると言っても過言ではないが,内容的としてはそれなりに重たかったかも知れない.

しかし,分野を自分の適性に従って正しく選びつつ,問題提起そのものに独創性を発揮することがこれほどまでに難しいことだったとは.今後,研究の舵を切り直したり,新たに付加的なテーマを設定する場合には,「下手の考え休むに似たり」ということも踏まえつつよく考えた方が良さそう.

あと,研究で数値計算に使っているスクリプトを地味に公開するのも手かなと思ったり.よくあるgnuplot等のコード解説サイトが踏襲する用法・目的別のスタイルではなく,「今日はこのようなコードを必要に駆られて△△のサイトを参考にして作成したが,この部分は〇〇の解析結果を可視化するのにも役に立ちそう」みたいに自然発生したものを解剖するスタイルで作ると考えることが少なくて良さそう.

ところで,この演奏すごく良くないですか.


N. Kapustin - Manteca op.129, Yordanova & Kyurkchiev Piano Duo

この曲を今年(正確には来年度)とある知人と演奏することになりました.季節的には夏頃になると思いますが,時期が近づいたら告知していこうと思います.

最後に,宣伝に貢献しないと嬲り殺される勢いだったので,次の3月に乗る予定のオケも告知します.リンク先で勘違いをされませんように,関西のFREEではなく関東のFREE EASTの方に乗ります.どうぞよろしくお願い申し上げます.ご興味のある方は,メールにて名前だけお伝え下されば,当日のチケット取り置き等手配致します.

ensemblefree.jp

呟き

随分と日が空いてしまった.

研究に関しては,(その性質上,具体的な進捗は述べられないが)あるモデルのダイナミクスを変え,そして特徴的なある物理量の振る舞いがなんとスピン系の異方項(異方定数) Dが決めているというところまでは辿り着いた.ここのところ,関連論文を漁る時間を多めにとった甲斐もあり,微々たる実りはありそう.

本日のarXiv

(自分もそのうちのひとりであるが)世の中には物好きがたくさんいるもので,そういう人たちが集まると一つの歴史を作ってしまう.どんな歴史かというと「Helium film系の超流動臨界点とカシミール効果」に関する研究の歴史である.

[1611.09694] Tricritical Casimir forces and order parameter profiles in wetting films of $^3\text{He}$ -$^4\text{He}$ mixtures

人類は, {}^{3}\mathrm{He}-{}^{4}\mathrm{He}の合成系の相図を平均場で理解するところまで来ている.関連論文として,

Phys. Rev. Lett. 83, 1187 (1999) - Critical Fluctuation-Induced Thinning of ${}^{4}\mathrm{He}$ Films near the Superfluid Transition

Phys. Rev. Lett. 88, 086101 (2002) - Critical Casimir Effect near the $^{3}He\ensuremath{-}^{4}He$ Tricritical Point

Phys. Rev. Lett. 97, 075301 (2006) - Critical Casimir Force in $^{4}\mathrm{He}$ Films: Confirmation of Finite-Size Scaling

が挙げられる.いずれも,「擬2次元系のHeliumが持つ臨界点近傍の自由エネルギーの異常に起因して系の厚みが変化する」ということをカシミール効果と関連付けて述べている.この系におけるカシミール効果としては,引力的なものも斥力的なものも存在するというのが興味深い.

これらの理論的研究で,比較的古い時代のものは

Phys. Rev. B 34, 330 (1986) - Finite-size interaction amplitudes and their universality: Exact, mean-field, and renormalization-group results

Phys. Rev. B 35, 3560 (1987) - Critical surface free energies and universal finite-size scaling amplitudes of three-dimensional XY models by direct Monte Carlo sampling


[1611.09847] Dynamic zero modes of Dirac fermions and competing singlet phases of antiferromagnetic order

物性論においてはポピュラーなトピックである「強相関電子系における反強磁性相とスピン1重項の相の競合」をFermion多体系-非線形 \sigma模型の結合系で理解しようという理論的枠組み.勉強せねば.

室内楽

今週末にモーツァルトのフルート協奏曲ト長調(より第1楽章)とバッハの管弦楽組曲第2番(よりバディネリ)の伴奏とシューマンのピアノ四重奏曲(より第1楽章)のピアノをやることになりましたが,最近風邪っぽいのでどうなるかが分かりません.


Mozart - Concerto for Flute and Orchestra G-dur K 313 (285C) Emmanuel Pahud.


J.S. BACH Badinerie By James Galway


Schumann | Quartet with piano I. | Daishin Kashimoto - Lise Berthaud - François Salque