SHELXLとは
SHELXLは構造精密化を行うためのプログラムで、SHELX-97パッケージの中のひとつです。
SHELXLクックブック
重要コマンドの使用方法などをまとめてみます。
SHELXLのファイルがよく分からない
- 問題
- SHELXLではいろいろなファイルが出力されて何が何かよく分からない
- 解説
- 以下のファイルがあるようです。
拡張子 内容 解説 .ins インストラクションファイル 精密化に使う原子座標や命令(instruction)が含まれる .hkl 構造因子データ 構造因子データファイル .res 結果ファイル 精密化後の原子座標が含まれる .lst ログファイル 処理時の詳細ログ .fcf CIF反射ファイル 電子密度を描くときに必要 .pdb 出力PDB WPDB命令で出力内容は制御される
.fcfファイルのフォーマット
LIST 6 | |
---|---|
LIST 5 | H,K,L,Fo,Fc,PHIC フォーマットされたきれいなテキストができる |
081019現在、SHELXLを使った差フーリェマップ計算をCCP4でやるよい方法がわからず、.insファイル中、このパラメータを変えて
- SHELXL
- F2MTZ (.fcf -> .mtz)
- FFT+MAPMASK
== 御参考まで F2MTZ script ==== f2mtz HKLIN fff04_1.fcf HKLOUT fff04_fofc <<+ > f2mtz.log CELL 71.33 33.22 25.02 90.00 105.64 90.00 LABOUT H K L FO FC PHIC CTYPE H H H F F P FORMAT '(3I4,2F10.2,1F7.2)' # このフォーマットでSHELXLから出力されます SYMM C2 #空間群を入力 +
他にも、SHELXPROを使って、XTALVIEW/O/TURBOマップを計算する方法がありますが、CCP4に重みを持っていくよい方法があったら教えてください(くの)。
水素原子を含める/含めない
SHELXLで出力されるPDBファイルに含まれる情報をコントロール。
コマンド | 温度因子 | 内容 |
WPDB 1 | isotropic B-factor | 異方性温度因子を精密化してもPDB出力は等方性温度因子のみ |
---|---|---|
WPDB 2 | anisotropic B-factor | 異方性温度因子をPDB出力 |
WPDB -1 | isotropic B-factor with hydrogens | WPDB 1を水素原子込みで |
WPDB -2 | anisotropic B-factor with hydrogens | WPDB 2を水素原子込みで) |
水素原子を含めるためには.resファイル(前回のリファインメント結果)を参照し、REMでコメントとして扱われている以下のような行からREMを削除します
REM HFIX_??? 43 N
これを
HFIX_??? 43 N
など。???には3文字表記の残基種。これにより指定された残基に水素を入れる準備が整う。.resファイルを.insファイルとしてSHELXLを1サイクルでも流せば、出力ファイルにWPDBコマンドで指定された出力形式でPDBが出てきます。
水素原子の名前
4文字の名前が水素原子につくとややこしくなるから、3文字の名前にしなければいけない! 問題になる水素⇒ダブルコンホメーションの場合
例)Leu残基は水素原子がδ位に結合しているので出力されるPDBの水素原子に
- 一つ目のコンホメーション(A)⇒HD1A, HD1B, HD1C という名前がつく。
- 二つ目のコンホメーション(B)⇒HD2A, HD2B, HD2C という名前がつく。
これをモデル修正プログラムで見ようとするとできない!!ので、名前を例えば
- HD1A⇒HD1
- HD1B⇒HD2
- HD1C⇒HD3
- HD2A⇒HD4
- HD2B⇒HD5
- HD2C⇒HD6
などとする必要がある。
HFIXのこと
水素原子を入れるときはREMコマンドでコメントアウトされているREMを削除してやればよい。
この際、メチル基や水酸基はほうっておくと変なところに水素原子を発生させられるのでHFIXコマンドで
- 水素原子を電子密度が最大になるトーション角を選択して
- トーション角の精密化を含める
という作業が必要。この際にアサインするコマンドとして
メチル基 | HFIX 33 ⇒ HFIX 137 |
水酸基 | HFIX 83 ⇒ HFIX 147 |
にする必要がある(した方が良い)。
N末のNについては HFIX 137 N_1001 などとする
(N末の残基種による; チェーンが切れているところなども同じ処理)
CONN コマンド
SHELXLは距離の近い原子座標に自動的に結合を生成してくれる。が、結合ができると温度因子にリストレインがかかる(これもパラメータ DELUでコントロール可能)ので注意が必要。特に水!!; 他にはCl-イオンとか。水分子に対して近くても結合はしないよと言ってあげる方法は
CONN 0 O_1101 > LAST
のようなコマンドで行う。意味は
O_1101 以降の座標(.insファイルにある)について 最後の行(LAST)まで距離が近くても結合なし
というわけ。
水素原子が生えたら
例)LEU 4文字水素で出力された原子名について、3文字で一義的な名前を付け直す。この作業の手順は
- 該当する残基・原子を.res中で編集(原子名を付け替える)
- その.resファイルをインプットとしてSHELXLを0サイクル流す!
この作業によって.resファイルに書き込んだ3文字水素原子を持つPDB座標が生成される
超高分解能データの最後に
L.S. 1 DAMP 0 0 BLOC 1 BOND
と.insに書き込み、以下のコマンドが含まれている行を削除します。
- SIMU
- DELU
- ISOR
- BUMP
- DFIX
- DANG
- CHIV
- FLAT
これによりフルマトリクスリファインメント、(最終結果に座標や温度因子の)シフト量を加算せず、温度因子抜き、フルマトリックス、結合情報を別ファイルへ保存したリファインメントをやってくれる。
このアウトプットファイル(.lst)をSHELXPROのオプション[E]に突っ込むと、これまでリファインメントやってきた構造の結合距離情報がどのくらい正しいのか?というパラメータ(esd: estimated standard deviation⇒参考:最小二乗法)を出力してくれる。
フルマトリクス精密化時のエラー
2011-05-30:追加
上記のフルマトリクス精密化を行うときに以下のエラーが出て止まることがあります。
** ARRAY B TOO SMALL FOR THIS PROBLEM **
このときのBというのは温度因子のBでは(たぶん)なく、純粋にプログラム中での配列Bのことです。つまり、配列Bのサイズが不足している、と怒られているわけです。解決するにはSHELXLのソースパラメータを変更して再ビルドが必要になります。
- 参考
- http://www.mail-archive.com/ccp4bb@jiscmail.ac.uk/msg01418.html
- http://www.mail-archive.com/ccp4bb@jiscmail.ac.uk/msg10965.html
これらによると、shelxh.f(またはshelxh_omp.h)の冒頭にある、
PARAMETER(LM=3200000,JW=12000000,IM=32000,LU=512)
を修正します。どのぐらいの値にすればいいのかというのはよく分からないのですが、
I compiled a version with LM=3200000 JW=400000000 IM=200000 LU=4096
という報告(上のmsg01418内)があったので、その数値で行いました。shelxh_omp.fではCPUの数とJWの多次元配列を生成するため、CPU数が増えると上限のJWが下がっていきます(後述コラム参照)。そのため、ここの例のように遙かに大きい値を使う場合はOpenMP版ではなく通常版を使うことになるでしょう。64bit環境で行えば上限が増えるはずですが、私は環境がないので試してません。
パラメータを修正したらビルドします(xsse4.2オプションはCPUの種類によって修正してください - コンパイルオプション)。
% ifort -O3 -xsse4.2 -prec-div -heap-arrays shelxh.f shelxlv.f -o shelxh.huge
後は生成されたshelxh.hugeを/usr/local/shelxにコピーして使用します。
LM,JW,IM,LUの最大値は?
配列のサイズに効いてくるのはJWの値なのですが、大きすぎると、
error #7910: A variable may not exceed 2147483647 bytes [B] REAL A(LM),B(JW,maxcpu),C(IM),EF(1880) -----------------^
というエラーが出ます。ここでポイントになるのはマルチCPU対応版(mp)です。上のエラー例はmp版ですが、Bがmaxcpuによる多次元配列になっています。エラーは「変数の大きさ」なのでJW * maxcpuの配列の場合、CPU数が多いほど上限のJWが下がっていくというわけです。そのため、シングルCPUが最も大きな値を確保できる、ということになります。なお、通常版の場合、定義がB(JW)になっています。
ただ、JW * maxcpu * (REAL; 4byte) < 2,147,483,647なら問題がないかというと、今度はコモンブロックのサイズという制限に引っかかるらしく、たとえJWを上限ギリギリのJW=536870911にすると、
#7911: Adding this variable to common-block-object-list causes the common block size to exceed the maximum of 2147483647 bytes. [B] REAL A(LM),B(JW,maxcpu),C(IM),EF(1880) -----------------^
というエラーが出ます。この辺りはCOMMONブロックを見てみると、A(LM)やらC(IM)のサイズも含まれるようです。
定義の部分から逆算すれば真の最大値を計算できるはずですが・・・どなたか試してみてください