ulirgs @ ウィキ

LaTeX TIPS

2018-03-22T13:57:57+09:00

LaTeX TIPS：論文を書く際に役立つメモ・天体座標の書き方天体座標を記述する際に、 ~.s~とか~."~という感じで小数点を挟む場合、小数点の真上に"やsなどを記述するのが正式な形。この表式は、専用のコマンドが用意されていて、 ~.s~の場合、$\fs$ ~."~の場合、$\farcs$ で表記できる。 #よく使う表現なのに意外とこの手の情報がネット上を含め出回っていない様子…。・ある論文に載ってる表現と同じ表現をしたい…！でも、やり方がわからない… たいていの論文ではarXiv (astro-ph)に最終版ちょっと前くらいのバージョンが投稿されている。 ADSの該当論文のページでarXiv e-printを押してarXivに飛び、同じ表現があることをチェック。そのあと、Downloadでother format→Sourceで元texファイルが手に入る。ここから該当の表現を調べればOK! #このソースファイルの中身に時々コメントアウトしかしていなくて消されていない筆者の叫びがあってなかなか面白い…。

他の方が作ってくださったスクリプトがこけるときに注意すること

2018-01-05T21:13:03+09:00

他の方が作ってくれたスクリプトをダウンロードしてきて動かそうとして、こけることは結構ある。特にログインシェルの設定をいじっていることで失敗するケースの対応メモ。 1. noclobberしてない? 僕の場合、ログインシェルのスクリプトを編集して使っているため、時々起こる事象。 set noclobber を設定していると、リダイレクトで既存ファイルを上書きすることができなくなる。つまり、 $ touch hoge.txt $ echo yaemugura > hoge.txt なんてやろうとしても hoge.txt: File exists. で失敗する。これは自分で書いたスクリプトなら中身がわかっているので間違いづらいけど、他の方が作ったスクリプトでは細部を把握していないので、場合によっては致命的になることがある。この場合、>の代わりに>|を使ってあげることでリダイレクトが可能になる(bashなどでも同様)。 sed -i.bak -e 's/ > / >| /g' fuga.sh とかでスクリプトの中身をガッツリ書き換える (僕はやらかしが非常に多いので、こんな感じで、fuga.sh.bak名のバックアップを作るようにしている)。或いは、スクリプトを一時的な用途でのみ使うのであればコンソールで unset noclobber としてあげても回避可能(こっちの方がいろいろミスが少なくて良いかもしれない)。

clump同定(clumpfindほか編)

2018-01-26T12:50:00+09:00

FITS cubeからクランプを同定したい時には複数のアルゴリズムがあり、 clumpfind(Williams et al., 1994, ApJ 428, 693)やcpropsなどが使われている。ここではclumpfindなどを導入、利用する方法を記載する。 IDLなど幾つかの形式でプログラムが配布されている。また、miriadにも標準で入っているらしい(、が試してないし確認もしていない)。 1. starlinkの環境整備ここでは、[[starlink>http://starlink.eao.hawaii.edu/starlink/]]というUKで開発、 Joint Astronomy Centre→East Asian Observatoryで維持されている解析ツールセットを試してみる。リンク先の最新版(この文章記載時[2015/06/16]で2015A版)を手順通りにインストール。何故かちょこちょこリンクが切れているところがあるが、丁寧に追えば必要なものは残っているようである。 linuxに入れる場合、IMPORTANT NOTEにもあるとおり、 pathが衝突を起こすようなので、回避方法を考えなければならない。とりあえず、自分としては(tcsh環境下。bashの場合は適宜文法を読み替え).cshrcの中で alias starlink1 'setenv STARLINK_DIR /home/HOGE/starlink/star-2015A' alias starlink2 'source $STARLINK_DIR/etc/login' alias starlink3 'source $STARLINK_DIR/etc/cshrc' とか無茶をした(user名をHOGEとした場合)。これで実際に使いたい時にstarlink[1, 2, 3]を次々入力する。もっとスマートにやるなら専用シェルを作ってsourceしたほうがいいかも。 2. FITSデータについて starlinkではFITSファイルではなく、NDFという専用の形式でデータを扱う。もちろんFITSファイルを変換するツールは用意されている。 [[NDF形式について>http://starlink.eao.ha

CASAにNOSTAR経由のFITSを読ませる方法

2018-01-05T21:19:06+09:00

CASA(v4.6まで確認)ではNOSTARで生成されたFITSファイルを読むことができない. 精確には、読み込むためには速度軸+静止周波数のセットが必要らしいが静止周波数のデータが無いことが原因。 [追記2016/05/23] それ以外にも複数のFITSキーワードがNOSTAR出力FITSヘッダーにはないので、ついでに入れておくとよい。具体的には、ビーム情報(BMAJ, BMIN, BPA)、周波数軸単位CUNIT3。あと、BLANKは整数が最近のFITSの標準なので、どうせならBLANKの値を-1とか-99999のような値に書き換えておくのがベターっぽい。回りくどいが一応できるようになったのでメモ。まずmiriadをインストールしてあること。例えば、天文台のデータセンターアカウントがあればそこで利用可能。データセンターではいくつかの[[望遠鏡]]に合わせたmiriadが用意されている. 今回はATCAのバージョンで試して成功した。もちろんヘッダー情報を書き換えられるなら、他のツール(python+astropyなど)使いやすいものを使えばよい。最近はもっぱらpython派なのでastropy.io.fitsで読み込んでheaderをそのままいじくることが増えてます。ここでは、 infile.fits:NOSTARから出力したFITS nostar:上記FITSをmiriadに読み込んだ時の保存名(ディレクトリ) out.fits:miriad経由で再出力したFITS と書くと... 1.FITSファイルをmiriadに読み込む fits in=infile.fits op=xyin out=nostar 2.静止周波数を新たに設定 puthd in=nostar/restfreq value=115.2710 type=double restfreq valueは単位がGHz (additional) 周波数軸をfreqで出力した場合、 puthd in=nostar/cunit3 value=Hz type=ascii 周波数軸をvelで出力した場合、 puthd in=nostar/cunit3 value=m s-1 type=ascii ビーム情報

ライブラリが無い！その２(nostar導入編)

2014-05-19T21:56:37+09:00

色々あってOracle VM VirtualBoxでCent OS 6に変更した。その過程でリダクションツールnostarがうまく動かないトラブルに見舞われたのでメモ(2014/05)。 IDLはVirtual Machineを導入(折角お高いIDLを卒業してpythonユーザーになろうとしていたのに…) ->これはIDLの販売元であるExelis http://www.exelisvis.co.jp の登録を済ませて、my accountからIDLの製品版をダウンロードすればよい。作業時(2014/05)でバージョン8.1が出回っている。これを入れた。コンパイル済みのnostar.savはバージョン7.1用のものを入れてみたが、少なくともこのIDLバージョンでは問題なかった。バーチャルマシンを使う時は idl -vm=~~.sav といった感じで使う。 (NROのページにもきちんと書いてある) またIDLのインストール場所がデフォルトでも nostarのマニュアルとは違う場所に設定されるので、起動スクリプトのIDL_DIR部分は対応するように書き換えておく。 (この前の段階でいくつか[[ライブラリ]]が無いと怒られた[何だったかは忘れた]が yum install (ライブラリ)で何とかなった。) まず適当な作業ディレクトリを作って試してみる。 ~/(作業ディレクトリ)/otfdata/raw ~/(作業ディレクトリ)/otfdata/map を作っておいてnostarと打ち、プロジェクト名に作業ディレクトリ名を入れる。で、適当なOTFデータをsplitしたところで baselineやflagタスクをやってもコケる。 #厳密に言うとコケないがスペクトルの描写がされない。これはnostarが開発されてから時間が経ったことで、 linuxではlibg2c.so.0というライブラリがデフォルトでは入らないことによる。このライブラリはそもそもfortranのソフトウェアであるg77に組み込まれていたもので、現在はすでに開発終了、gfortranがデフォルトになっているためである。つまり、このライブラリをちゃんと入れてやれば動くはず。ということで探してみる。以下のサイ

ライブラリ

2013-08-30T19:28:25+09:00

*ライブラリが無い。。。 ubuntuではどうやら近年ライブラリ格納箇所を変更されたらしく、普通にプログラムは知らせようとして引っかかることも少なくない。そんな時は apt-file を使って探すのが楽っぽい。 apt-get install apt-file で導入。 apt-file search 探してるライブラリファイルとかやるといい感じに探してくれる。ファイルが入ってなければそれを入れればよいみたいだ。便利！

LINUX

2018-01-05T21:13:50+09:00

*LINUX関係のメモ **[[必要なライブラリが無い!>ライブラリ]] **[[必要なライブラリが無い!その2(nostar導入編)>ライブラリが無い！その２(nostar導入編)]] **[[他の方が作ってくださったスクリプトがこけるときに注意すること>他の方が作ってくださったスクリプトがこけるときに注意すること]]

AIPSでクリーン済みマップのように見せかける方法

2013-06-18T18:41:09+09:00

AIPSではconvolutionをかける際にdirtyマップかclean済みマップかで動作が異なってくる。 (詳細はexplain convとかで) そのため、単一鏡データや他波長データでconvolutionをかけようとする際にヘッダーを弄る必要がある。 (他のツールを使えという突込みは無しで…) そもそもビームサイズ(光赤外で言うところのPoint Spread Function[PSF])がヘッダーに書いてないことがあるので、その場合にはputheadタスクで長軸分解能bmajと短軸分解能bminを設定してやる。やり方は task 'puthead keyword 'bmaj keyval [空間分解能を度で入力。普通秒でわかっているので、分解能[arcsec]/3600と入力しておけば勝手に計算してくれる] puthead 以下、bminも同じ。そうすると、 Map type=DIRTY Number of iteration = 0 でdirty mapとなってしまう。これだと困る。 FITSファイルのヘッダーを見てみると HISTORY AIPS CLEAN NITER= 0 PRODUCT= 0 / DIRTY MAP となっている。 'PRODUCT ' Clean product code: 1 - 4 => normal, components, residual, points (integer*2) なので、PRODUCTの方をいじればよいような気がするがそれだと実は何も起こらない。実はNITER (Cleanを何回繰り返すか、number of iterationのようである)こそが dirty mapかどうかを決めているようである。ということで、これに適当な数字を入れてやれば万事解決。これもputheadでヘッダーを書き換えてやればよくて、例えば、 keyword 'niter keyvalue 100 puthead とかやればよい。 imhで見ると Map type=NORMAL Number of iteration = 100 となり、AIPSをだますことに成功できた。

APLpyの導入

2013-06-03T17:01:01+09:00

時代がpythonになってきてるのと、IDLだと資金的に無理なので、python解析を始めることにした。その際に天体の座標を入れたりするのにつかうパッケージAPLpy(http://aplpy.github.io/)のインストールでこけるという現象にあたったのでそれについてのメモ。環境 OS:Windows 7 (64-bit) APLpyのバージョン：0.9.9 pythonのバージョン：3.3 まず、一般的な導入法であるpipを使った。コマンドプロンプト(pipの入っている場所やpython.exeの入ってる場所にはパスを切ってある。) pip install aplpy →コケる。同様に(中身がpipなのでほぼpipと同義だが)easy_installを使ってみた。 easy_install aplpy →コケる。ソースコードから入れてみる。 http://aplpy.github.io/ からソースコードを落としてきて展開後、ディレクトリに入ってから python setup.py install →コケる。いずれもコード自体は流れきって、installに成功したとメッセージが出るが、実体はインストールディレクトリであるLib\site-package以下に入っていない。しかも、インストールやバージョン状況などの情報がある APLpy-0.9.9-py3.3.eggディレクトリ以下は生成されている。これがあるままだとどの形式でも追加インストールされないので一回試すごとに消した。よくよく流れたメッセージを見てみると、 build\lib というディレクトリができてない、と言って途中でエラーを吐いていた。該当ディレクトリをソースコード展開後のbuildディレクトリ以下に作ってみる。 →エラーメッセージは流れなくなるがそれ以外は同じ現象。更によくよくディレクトリ構成を見てみるとbuildの下には先ほど作ったlibのほかに、bdist.win-amd64とlib.win-amd64-3.3というディレクトリがあり、そっちの方にはインストールに必要な各種ファイルが入っているようだ。ディレクトリ名から察するにlib.win-amd64-3.3という

Cの導入(Ubuntu12.04 with VMware)

2013-06-03T16:38:42+09:00

Cのコンパイルについて。 (Cを書けない、読めない人間が他人様のプログラムをコンパイルする際にぶち当たった問題に対するメモ) なお環境としては、ubuntu 12.04。 math.hに含まれる関数(要するによく使う数学の関数)を使おうとすると（つまり、 #include が入っていると）、コンパイル時にコケるという現象に直面。コンパイルはhoge.cというプログラムだとすると gcc -lm hoge.c -o hoge.o とやった。上のコマンドのように-lmをオプションで指定すると、前半部分の -l は[[ライブラリ]]のパスを明示的に与えることを意味し、最後のmは libm.a (math.hが使っている。すべてライブラリはlib*.aという名前なのでmとしただけでlibm.aとわかるという仕組みらしい)というライブラリを探せ、という指令、なので、gcc内でパスの切ってある場所でlibm.aを探せ、という意味になる。普通、これでうまくいくそうである。これがうまくいかなかったということは、パスがおかしいのか?と思い gcc -print-search-dirs とやってgccがライブラリを探す参照パスを表示させたうえで、 libm.aの実体を色々探した。最終的に /usr/lib/i384-linux-gnu にあることが分かったが、ここはすでに参照パスが切ってある場所…。ちなみにubuntu 11.04以降ではCのライブラリの位置関係が大幅に移動を食らっている模様。 /usr/libなどではなく、/usr/lib/i386-linux-gnuなどに移動されている。(32bitの場合) 恐らくこれまでにもたくさんの人がこれに引っかかったのだろう(実際ぐーぐる先生にお伺いを立てるといっぱい引っかかる。)、今(2013年1月現在)ではインストール時に正しいパスを切ってあるということのようである。じゃー、なんでコンパイル通らないんだーと思ってさらに調べてみると、 http://askubuntu.com/questions/130373/ubuntu-12-04-compiling-a-c-program こんなページが引っかかった。