Lion に Geant4 9.5 を入れた
(2012.12.5 追記) Mountain Lion でも同様にして install できます。
1. 環境変数の設定
以前は G4WORKDIR とか色々と設定していましたが、なんかそういうのはもう要らないっぽい。次の変数だけ ~/.zshrc に追加しましたが、別になくても OK です。
export G4INSTALL=/usr/local/geant4/geant4.9.5.p01
2. 落としてきて展開
$ wget http://geant4.cern.ch/support/source/geant4.9.5.p01.tar.gz $ cd /usr/local $ sudo mkdir geant4 $ cd geant4 $ sudo tar zxvf ~/geant4.9.5.p01.tar.gz $ mkdir geant4.9.5.p01-build $ cd geant4.9.5.p01-build
まあ、入れるところは好きな場所で良いのですが、今回は /usr/local/geant4/geant4.9.5.p01 に展開して、geant4.9.5.p01-build で build することにします。前者は G4INSTALL として設定済み。
4. Build する
ここが大きく 4.9.3 の頃とは変わっていました。CMake を使うのが標準になったようです。
$ pwd /usr/local/geant4/geant4.9.5.p01-build $ sudo cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DXERCESC_ROOT_DIR=/opt/local -DGEANT4_USE_OPENGL_X11=ON -DGEANT4_USE_RAYTRACER_X11=ON -DGEANT4_INSTALL_DATA=ON -DGEANT4_USE_GDML=ON $G4INSTALL
以前は Configure を走らせて色々と質問に答える形式で設定を行っていましたが、今は -D で色々やるようです。以下、自分が使った設定のみ解説。
- CMAKE_INSTALL_PREFIX Geant4 の library だとかを install するための path です。Default で /usr/local なのですが、念のため明示的に与えています。
- XERCESC_ROOT_DIR Xerces-C を入れた場所で、MacPorts からなので /opt/local を指定しています。
- GEANT4_USE_OPENGL_X11 OpenGL を ON に。
- GEANT4_USE_RAYTRACER_X11 Ray tracing を ON に。
- GEANT4_INSTALL_DATA 中性子などの追加データを install する。
- GEANT4_USE_GDML GDML を使う。
cmake が無事に完了したら、次は普通に make です。
$ sudo make -j4 $ sudo make install
5. geant4.sh を走らせる
これまた ~/.zshrc に以下を追加します。bash の場合は公式の manual に従って下さい。zsh だと /usr/local/bin に移動しないと駄目なようです。
cd /usr/local/bin source geant4.sh cd - > /dev/null
6. 例題を試す
これも 9.3p01 の頃と勝手が変わっていて、CMake を使います。
$ cd $ mkdir B1-build $ cd B1-build $ cmake -DGeant4_DIR=/usr/local/lib/Geant4-9.5.1 $G4INSTALL/examples/basic/B1 $ make -j4 $ ./exampleB1
cmake を使う場合には vis.mac などは一緒に build directory に持ってきてくれませんので、自分で examples/basic/B1 などから cp して下さい。
B1 の例だと make の target を指定しなくて良いのですが、例えば examples/extended/radioactivedecay/rdecay01 の場合だとあらわに target を指定する必要があるので注意です。まあ、今どき zsh 使うのが当然なので、勝手に target の一覧を展開してくれるはずですが。
$ cd $ mkdir rdecay01-build $ cd rdecay01-build $ cmake -DGeant4_DIR=/usr/local/lib/Geant4-9.5.1 $G4INSTALL/examples/extended/radioactivedecay/rdecay01 $ make -j4 rdecay01 $ ./rdecay01
7. Mac 用の VRML viewer を入れる
Geant4 の可視化に使われる VRML は、Windows や Linux で表示するためのソフトが豊富に存在します。Mac だとあまり無いようで、試しに MacPorts から OpenVRML を入れてみましたが、exampleB1 の吐く VRML を正しく表示できませんでした。
$ sudo port install openvrml +player $ openvrml-player
で、次に試したのが FreeWRL です。これは OS X 用に binary installer が用意されているのですが、少なくとも手元の Lion にはちゃんと install できませんでした。そこで、手動でゴニョゴニョと。
FreeWRL-1.22.13-pre1.dmg などを落としてきて、disk image を展開します。そうすると /Volumes/FreeWRL 1.22.13-Pre1 install という volume が mount されます。Installer が入っていますが、これは使わないで、手動で必要なものを移動します。
$ cd $ cp /Volumes/FreeWRL\ 1.22.13-Pre1\ install/FreeWRL-1.22.13-pre1.pkg/Contents/Archive.pax.gz . $ gunzip Archive.pax.gz $ open Archive.pax $ cd unidst $ cp -pr Applications/FreeWRL /Applications $ sudo cp -p usr/local/lib/lib* /usr/local/lib/ $ sudo cp -p usr/bin/* /usr/local/bin/
この状態だと /usr/local/lib/libfreetype* が置かれるのですが、これらがちょっと古いため、MacPorts で入れた /usr/local/lib/libfreetype* とぶつかる可能性があります。MacPorts で入れたものが動かなくなったら (Emacs 23 が起動しなくなることを確認済み)、/usr/local/lib/libfreetype* を消して、以下を実行しましょう。
$ cd /usr/local/lib $ sudo ln -s /opt/local/lib/libfreetype.6.dylib libfreetype.6.dylib
これで、freewrl という command を叩くと、Aqua で VRML が表示されます。X11 でやる方法もあるのですが、自分とこではうまく build ができませんでした。
$ freewrl
~/.zshrc で環境変数に以下を追加しておくと、VRML を表示する際に自動で freewrl が起動されます。
export G4VRMLFILE_VIEWER=freewrl
exampleB1 の場合、vis.mac に /vis/open OGL 600x600-0+0 という行があるので、これを comment out し、/vis/open VRML2FILE という行の comment を外します。そして exampleB1 を実行した最後に /vis/viewer/flush を実行すると、FreeWRL が起動します。ただし、prompt が返ってこないので、Ctrl-C で殺せば OK です。
$ ./exampleB1 (略) Idle> /vis/viewer/flush
横長の表を含む PDF のページを 90 度回転させる
LaTeX で横に長い表組みをするときに、landscape を使って 90 度回転させる場合があります。ただしこれだと、完成した PDF を眺める時にページごと回転させるか、もしくは首を傾げないと表を読めないので、LaTeX を書いている最中だと結構不便です。
ちと調べたところ、lscape package の代わりに pdflscape package を使えば自動で該当ページを 90 度回転させてくれるようです。
以下、.tex の例。pdflatex の場合は pdflscape を使うだけ、dvipdfmx を使う場合は、そのように明示する必要があります。
\documentclass[a5paper]{article} % for platex + dvipdfmx %\usepackage[dvipdfmx]{pdflscape} % for pdflatex \usepackage{pdflscape} \title{How to rotate a PDF page\\including a wide table?} \author{Akira Okumura} \begin{document} \maketitle \begin{abstract} We explain how to rotate a PDF page including a wide table. \end{abstract} \section{Introduction} Table~\ref{wide} is a wide table. \begin{landscape} \begin{table} \label{wide} \caption{This is a wide table created with the pdflscape package.} \begin{center} \begin{tabular}{|c||c|c|c|c|c|c|c|c|c|c|} \hline & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 & 10 \\ \hline \hline 1 & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 & 10 \\ \hline 2 & 2 & 4 & 6 & 8 & 10 & 12 & 14 & 16 & 18 & 20 \\ \hline 3 & 3 & 6 & 9 & 12 & 15 & 18 & 21 & 24 & 27 & 30 \\ \hline 4 & 4 & 8 & 12 & 16 & 20 & 24 & 28 & 32 & 36 & 40 \\ \hline 5 & 5 & 10 & 15 & 20 & 25 & 30 & 35 & 40 & 45 & 50 \\ \hline 6 & 6 & 12 & 18 & 24 & 30 & 36 & 42 & 48 & 54 & 60 \\ \hline 7 & 7 & 14 & 21 & 28 & 35 & 42 & 49 & 56 & 63 & 70 \\ \hline 8 & 8 & 16 & 24 & 32 & 40 & 48 & 54 & 64 & 72 & 80 \\ \hline 9 & 9 & 18 & 27 & 36 & 45 & 54 & 63 & 72 & 81 & 90 \\ \hline 10 & 10 & 20 & 30 & 40 & 50 & 60 & 70 & 80 & 90 &100 \\ \hline \end{tabular} \end{center} \end{table} \end{landscape} \end{document}
Unison を使って実現する大量データの双方向同期
1. 実現したい事
数百 GB から数 TB に及ぶ大量のデータを、複数の計算機環境で Dropbox のように同期したい。しかも無料で、かつ Dropbox よりは転送速度の速いものが良い。
実験データとか計算データとか解析データとか、職業柄いっぱいデータを扱う日常でして、しかもそれが手元の MacBook Pro の中にあったり、どっかの研究所の計算機 server にあったり、果ては昔の所属機関の RAID に詰まったりしているわけです。遠隔地にデータがあったとしても、計算させるだけだったら SSH で job を投げるだけで済みます。しかし X を飛ばしてちょっと解析したくなってくると、どうにも SSH じゃやっていられません。
そんな中、512 GB の SSD も値段がこなれてきて、また 1 TB の 2.5" HDD なんかも出てきました。僕の仕事用の MacBook Pro は OWC の Data Doubler というのを載せているため、SSD と HDD の二台載せが可能です。合計で 1.5 TB もあれば各地に散らばったデータを収容する能力があるわけで、是非ともこれらを集約したくなります。
2. rsync の問題点
しかし rsync で同期しちゃえば済むじゃないか、と単純には行きません。なぜなら rsync の同期は一方通行だからです。MacBook Pro 側でデータを部分的に変更して、遠隔地側でも変更してなんて作業をしてしまうと、両者の整合性を取るのが面倒になります。
また、不要な file を片方で消去した時に、rsync で同期してしまうとそれが復活するなんてことも発生します。.log を消したり、*~ を消したりした場合、こういうものは同期先 (or 同期元) でも同時に消えてもらいたいものです。
3. Dropbox の問題点
じゃあ、もっと便利な Dropbox を使えば良いじゃないか、となるわけです。rsync が古くから Un*x で使われてきたのにも関わらず、Un*x 使いの中でも Dropbox が人気なのは、双方向同期を気軽に、しかも background でやってくれるからでしょう。
しかし、最大の問題が発生する料金です。僕の場合は「Dropbox の容量を無料で 20GB まで増やす方法」などを使って、無料で 24.9 GB まで使えるようになっています。しかし、100 GB を Dropbox で確保するには年間 $40 が発生し、また 1 TB を使うには年間 $795 も必要です。これはちょっと研究費で賄う気にはなりません。
さらに、Dropbox は転送速度が遅いため、即座に大量のデータを同期させたい場合には向かないらしいと聞きます。
4. Unison を使おう
ということで、色々と悩んで Twitter で助言をいくつか頂いた結果、Unison を使うことにしました。先に Unison の長所と短所を書いておきます。
4.1 Unison の長所
5. Unison の導入
5.1 Mac の場合
MacPorts なりを使って簡単に導入しましょう。僕の Lion 環境では ver. 2.40.63 が入りました。
$ sudo port install unison $ unison -v unison version 2.40.63
5.2 Linux の場合
これは使っている環境にもよると思いますが、僕の場合は管理者権限のない計算機に導入したため、自分で build しました。prefix は $HOME/opt です。環境は RHEL 5 (64 bit) です。
まずは OCaml を落としてきて build します。3.12.1 を使いました。これがないと Unison の build ができません*1。
$ tar zxvf ocaml-3.12.1.tar.gz $ cd ocaml-3.12.1 $ ./configure -prefix $HOME/opt $ make world $ make opt $ make opt.opt $ make install
次に、Unison の build ですが、version 番号を全ての環境で統一する必要があります。Mac で導入した 2.40.63 を入れます。
$ tar zxvf unison-2.40.63.tar.gz $ cd unison-2.40.63 $ emacs Makefile #ここで$(HOME)/bin を $(HOME)/opt/bin に書き換えた (好みで) $ make $ make install
これだけです。unison -v で、Mac のものと同じ version 番号かを確認しましょう。
5.3 遊んでみる
この後は、Unison の基本的な使い方を学ぶために、manual を読んで動作確認をしてみましょう。英語の公式か、有志の方の日本語訳を参照して下さい。「Tutorial」のところを読んで基本的な動作を身に付けましょう。
5.4 自分が使っている引数
- -owner 所有者の情報を維持します。これをつけないと、UID が同一になるようになるのかな? login name が違う環境同士でやるとどうなるんでしょうね。試していません。
- -prefer newer 更新日時の新しいものを優先します。同時編集している場合などには注意してください。
- -times これをつけないと、file の time stamp がメチャクチャになるそうです。
- -batch 変更が衝突した場合に、"-prefer newer" に従って自動的に衝突を解決します。勝手にやられるのが嫌な場合は、-batch は外して手動で解決しましょう (衝突した file ごとに、ちゃんと確認が出ます)。
- -path 特定の下の階層だけを同期したい時に使います。
実際には、以下のような使い方をしています。
$ unison . ssh://YOUR_REMOTE_SERVER/THE_DIRECTORY_WHICH_YOU_SYNC -owner -prefer newer -times -batch
今のところ、名古屋で使用している MacBook Pro、アメリカ西海岸にある SLAC の計算機環境 (100 CPU 使える)、千葉県にある宇宙線研究所の計算機環境 (これも 100 CPU 使える) の三箇所で同期しています。同時に 200 CPU を使いきりたいときには、両方の計算機で並行して job を投入するため、両者の出力結果を同期させ、さらに手元の MacBook Pro に持ってくるという用途には、Unison は最善の解決方法だなと実感しています。
5.5 注意点
Unison は background で更新を調べてくれたりはしません。ユーザが unison を実行するたびに、同期元、同期先の directory 階層を調べに行って更新箇所を調べます。そのため、数十万や数百万の file を同期しようとすると時間がかかります。特に、接続先が NFS などを使っている場合は負荷がかかります。可能な限り、データを少ない数の file にまとめるようにしましょう。
海や大陸を跨いだ同期をする場合、「遅延時間」のせいで scp や rsync と同様に非常に時間がかかります。特に初回同期時には何十時間もかかってしまうでしょう。これを解決するためには、Unison でいきなり同期するのではなく、あらかじめ rsync や scp などで同期できる部分は同期しておきましょう。その際には「scp の複数同時接続」のような手法を使うことで、長距離でも 100 Mbps を超えるデータ転送が可能になります。Unison を使って同期するのは、初回同期が済んで、両者で更新をするようになってからでも問題ないでしょう。
Unison は実行時に、SSH を使って同期先の unison の version を調べます。僕は .zshrc の設定で login 時に色々と標準出力へ吐き出すようにしているのですが、これがあると version 番号が正しく出力されなかったと見なされてしまいます。unison への PATH を通すだけの .zshenv などを用意してやると、これを解決できます (参照)。
Lion + MacPorts + ptex の dvipdfmx がこける
Lion に移行してから、MacPorts で導入した ptex に含まれる dvipdfmx を使うと、PNG や JPEG を \includegraphics している場合に .dvi から .pdf に変換ができなくなりました。
2ch の Mac 板から http://anago.2ch.net/test/read.cgi/mac/1232248024/424-434 を見ると同じ問題と解決策があったので、これで解決。
431 :名称未設定:2011/10/10(月) 19:50:08.17 id:hMO31Ob70
Snow Leopard上で再構築したdvipdfmxだと大丈夫でした。
UpTeX.app/teTeX/binのなかのdvipdfmxを以下のものと
差し替えてください。http://www2.kumagaku.ac.jp/teacher/herogw/archive/uptexdiff111010.dmg
本体の方は、これから更新します。
小川さんのところから、dvipdfmx の入った .dmg を落としてきて、/opt/local/bin/dvipdfmx と置き換えてやるだけです。
BibTeX もしくは JBibTeX の Buffer Size を拡張する方法
BibTeX や JBibTeX の command である bibtex とjbibtex は、あまりに長い行の含まれる .bib を読み込むと死にます。なぜかというと、一度に読み込める行の長さが決めうちになっており、それを超えると処理できなくなるためです。
例えば MacPorts から入れた ptex @20110314 に含まれる JBibTeX 0.99c-j0.33 の場合、9000 文字を超えるような行を含む .bib を処理すると以下のような error で死んじゃいます。
This is JBibTeX, Version 0.99c-j0.33 (utf8.euc) (Web2C 7.5.4) The top-level auxiliary file: OkumuraCone.aux The style file: model1a-num-names.bst Database file #1: oxon.bib Sorry---you've exceeded BibTeX's buffer size 9000 zsh: segmentation fault jbibtex OkumuraCone
9000 文字を超えるほうが悪い気もするんですが、素粒子業界や宇宙業界だと author list がとんでもないことになっており、例えば今回の場合はこの論文の author list で死んだわけです。600 名以上います。
この 9000 という数字を自分で書き換えれば良いわけですが、ptex を自前で scratch から build するのも面倒なので、MacPorts を基本的には使ったまま対応します。以下、手順。
3. Build を中断する
依存関係のある package の install が済むと、ptex の build が開始されます。以下のように標準出力が出るはずです。
$ sudo port install ptex (中略) ---> Computing dependencies for ptex ---> Fetching archive for ptex ---> Attempting to fetch ptex-20110314_1+motif+utf8.darwin_11.x86_64.tbz2 from http://packages.macports.org/ptex ---> Fetching ptex ---> Verifying checksum(s) for ptex ---> Extracting ptex ---> Applying patches to ptex ---> Configuring ptex ---> Building ptex
これが出たら、すかさず Ctrl-Z で MacPorts を中断します。見逃さないようにしましょう。
4. bibtex.ch もしくは jbibtex.ch を修正する
MacPorts での ptex の build は、次の directory で実行されます。
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_tex_pTeX/
さらにこの下に、次の directory が作成され、build に必要な source code が展開されています。
ptex/work/temp/tetex-src-3.0/texk/web2c/ptex/
この中に bibtex.ch と jbibtex.ch が置かれているので、これを修正します。自分の場合は日本語の文献なども BibDesk で管理しているので、jbibtex を修正しました。ptex @20110314 の場合、jbibtex.ch の 180 行目と 219 行目の数字を好きな大きさに変更します。以下が diff の結果です*1。
$ diff jbibtex.ch\~ jbibtex.ch 180c180 180c180 < @!buf_size=9000; {maximum number of characters in an input line (or string)} --- > @!buf_size=100000; {maximum number of characters in an input line (or string)} 219c219 < @!glob_str_size=3000; {maximum size of a |str_global_var|; --- > @!glob_str_size=100000; {maximum size of a |str_global_var|;
5. Build を再開する
最後に、Ctrl-Z で中断していた MacPorts の処理を、fg で再開します。新たに install された /opt/local/bin/jbibtex を実行すれば、数千人の author list にも対応できるはずです。
追記
pTeX から TeXLive 2014 に変更したら、jbibtex が無くなり pbibtex というのを使うようです。pbibtex でも長い著者リストの場合に問題が発生したので、/opt/local/etc/texmf/texmf.cnf を sudo で変更しました。具体的には、以下のように glob_str_size の値を増やします。
glob_str_size = 200000
これを反映させるために、
$ sudo fmtutil-sys --all
を実行します。
*1:kakuto さんのご指摘を受けて、変更箇所を追加 (2012/4/13)。
Lion の SSH で "Write failed: Broken pipe" が出て接続が切れる
多分 Lion にしてから、SSH で接続していると "Write failed: Broken pipe" と表示されて接続が勝手に切れてしまうようになりました。こことかここを見ると同じ症状の人がたくさんいるので、Lion から SSH の default の設定が変わったのでしょう*1。
~/.ssh/config の中に、以下の一行を入れて解決するはずです。15 秒に一回 (他の数字でも問題ない) 接続先に信号を送り、接続が継続してるとアピールしてくれます。
ServerAliveInterval 15
*1:Snow Leopard でも出る人は出るようなので、本当に Lion のせいかは不明です。SSH の server/client の色々な組み合わせでは試していません。
Lion で X11 が死ぬ問題の解決法
Lion に移行してから、ROOT で script を複数回走らせると X11 が凍るというか死ぬ問題が発生するようになりました。RootTalk の情報では、これは ROOT の bug ではなく (Apple の) X11 の bug だそうです。同じ thread に解決方法も載っているので、Lion + ROOT を使っている人は回避策を実行しておいたほうが吉。
再現するのも簡単で、以下の通りやれば X11 が反応しなくなります (cmd + opt + esc をやると、"Not Responding" になる)。
void bugx11() { TCanvas *c1 = new TCanvas(); TCanvas *c2 = new TCanvas(); c2->Divide(1,2); TH1D * h1 = new TH1D("h1","h1",100,0,1); h1->Draw(); printf(">>> Before Update\n"); gPad->Update(); printf("<<< After Update\n"); }
$ root root [1] .x bugx11.C >>> Before Update <<< After Update\ root [2] .q $ root root [1] .x bugx11.C >>> Before Update [ここで固まる]
解決方法
XQuartz 2.7.0 以上を落としてきて、install する。次に以下の command を実行 (やらなくても良い気がするんだけど、うちの環境はやらないと駄目だった)。
$ launchctl load -w /Library/LaunchAgents/org.macosforge.xquartz.startx.plist
最後に login し直して ROOT を立ち上げると、X11.app ではなく XQuartz.app が立ち上がるはずです。