Memo developing

From Ecal

Jump to: navigation, search

Contents

gtvにおけるlogical 変数のデフォルト

m_rdctl.Fでは、汎用のctrlファイル読み込みルーチンgtvを呼び出すことで、 ctrlファイルを読み込んでいる。どうもlogicalのときにデフォルト値が ただしく読み込めないようだ。それで、temporaly fixingとして

ctakao Sep2009
      mxcst1=F
      mxcst2=F
      mxcst4=F

を、m_rdctrl.F:L1091のallocate文のあとに挿入してある (sep2009)。 これがないとgfortran-core i7ではmake checkを通過できない。out.lmf.copt.gzと比較すると Vfloat=Fとなっており、mxcst4=Fのデフォルト値が入ってないようだった。

#if blockをきちんとfortranのブロックにネストさせる

do loopの冒頭をMPIと非MPIモードで変更するようなfpp directiveだと、 directiveをコメントとみなしたとき、解析ツールであつかえない。それで修正した.(mar2010)

f90,cpp

f90以外はのぞいていいだろう。cppは結構やらしいかもしれない.アナライザーを使いにくくする。

並列化をすっきりさせる

bessel関数

bessel関数をkino氏の用意してくれたものに差しかえた。FTMESHを大きくとれるようになった。 大きいスーパーセルでも問題なくうごくようになった。どこに効いてたのか? fp/mshvmt.F,fp/msh21c

gfortanのfpgw/exec/make.inc

注:いまのpakcage 3ad7c59d8abb1fe0553f3f0f415ad37d7e36b674(May29,2009)では、 fpgw/execのしたのmake.inc.ifort,make,inc.gfortranが欠落してます。 それで、make.incのみ が入ってますが、これはgfortran用です。このFFLAGSには、-cpp $(CPPSWITCH_INTELLINUXIFC) が抜けています.これを付け加えてください. なくても動きますが、たぶんすこし遅いだろうとおもいます(blasなどがcallされてなかったりする)。 新しいバージョンではたぶん関係ないです

Makefileの依存性がかけてない==

Fatal Error: Can't open module file 'm_struc_def.mod' for reading at (1): No such file or director でたら、make subs/obj.gfortran/m_struc_def.oなどとする。 直す。また、へんなエラーがでたらmake cleanしてからやる。それでもだめならmake cleanobjしてからやる。 lmf-MPIのときなど最後にエラーがでてmakeがおわるようにみえるがlmf-MPIとlmfgw-MPIができてれば問題ない.

dependencyが上書きされているせいです。

m_rdctrl.o: の部分が2つあります。上の*.modがある依存関係を下のが上書きしていて正しい依存関係を書けてません。上のm_rdctrl.o: foo.mod の右側を、下に書き足すと正しく動くことを確認しました。

Makefileの書き方として、general ruleの m_rdctrl.o: foo.mod ... はMakefileに書いて, machine dependentなrule上書きの m_rdctrl.o: m_rdctrl.F foo.mod ... をMake.inc.${PLATFORM}に書くべきです。

normchk

GW計算の値がおかしいきにはまず、normchk.siを見ないといけない. これによりlmfgwが用意した波動関数の規格化がきちんとできてるかどうかが わかる。高い固有値のとき、だいぶわるくなる場合も多い. これはLMXA,KMXA,GMAXなどと関係してる.


GW計算でのバグ(というか仕様?)

LMXAを原子ごとにかえるとGW計算はできない。 LMXのみ指定されてる場合もデフォルトで、それに応じて LMXAが動いて、原子ごとにずれたりしうるので注意。 将来直す。

ifort11よりf95? on centos5. corei7.

何がいいか? centos5+corei7。たぶん、現状では、以下の4.(あるいはblas,lapackをnetlibから取ってくるか) がいちばん「まとも」な感じ。ifort11はソースによれば異常にコンパイル時間がかかるとかの点 でもおかしい.木野氏によると「ifort11で、blas+lapackをnetlibからとってきてコンパイルしたら、 まともに動かなかった。でも、gfortran(f95)では正常動作」とのこと。

1 ifort + mkl --->bugあり 次元を大きくした時、対角化でこけた。
2 ifort + acml4.2.0 --->いまのところ正常動作。
3 f95 + acml4.2.0 --->bugあり(下の記事)
4 f95 + yum install blas lapack fftw3 で/usr/lib64/libblas.a /usr/lib64 liblapack.so.3.0.3 -lfftw3でリンク --->いまのところ正常動作。
5 f95 + yum install atlas
   りんくのしかたよくわからないので、
   f95  lmf.o fp/libfp.a subs/libsubs.a slatsm/slatsm.a \
    -L/usr/lib64/atlas/ /usr/lib64/atlas/liblapack.so.3 /usr/lib64/atlas/libf77blas.so.3  \
    /usr/lib64/atlas/libcblas.so.3 /usr/lib64/atlas/libatlas.so.3 -lfftw3  -o lmf
    としてる。ーーー>ちゃんと動かない。/usr/lib64/atlas/libatlas.so.3.0.3などとなってる。
    normcheck.siでNaNがはいってる。lmfgw01はコンソール出力は正常に見えるが不明。3の場合と同じか?

依存性のチェックでmakeがちょと問題有。MAKEINC/Make.incにモジュール依存性はいれたほうがいい。module名が*.modになるとは限らない(たぶん)なので。2と4の速度比較。おそらく2の方がlmfに関しては2割程度高速。GWの部分は同等(なぜか4のほうが早い場合もある.hsfp0など)。ただし大規模系でのチェックはまだ。

gfortran on centos5. corei7.へのインストール(上の4.)は

yum install blas 
yum install lapack
yum install fftw3

で、インストールし、 /usr/lib64/libblas.a /usr/lib64/liblapack.so.3.0.3 -lfftw3でリンクした. (最後のfftw3はちゃんとpathを書かないといかん?)そんなに遅くない? クロックのチェック必要.

ATLASのインストール-b 64うまくいかなかった.よくわかってない。 atlas3.8.3.tar.gz /usr/bin/cpufreq-selector -g performance /home/takao/MATHLIB/ATLAS/configure -b 64 などをしたが。--Tkotani 19:28, 20 May 2009 (UTC)

バグ in LIBLOC= /opt/acml4.2.0/gfortran64/lib/libacml.a -lfftw3

gfortranの上でのacmlのzgemmがおかしい。gas_gwscのサンプルで発覚。 gwd/pwmat.F (sugw.Fからよばれる)のさいごあたりのzgemm

     call zgemm('N','N',ngp,ndimh,ngmx,dcmplx(1d0,0d0),
    .  ppovlx,ngp,pwh,ngmx,dcmplx(0d0,0d0),pwhovl,ngp)
(かわりに call matm(ppovlx,pwh,pwhovl,ngp,ngmx,ndimh) を使っても等価)

がおかしくなる.matmulを使うと正常なあたい。サムチェック

     print *,'sss:  pwmat ppovlx=',sum(abs(ppovlx))
     print *,'sss:  pwmat pwh   =',sum(abs(pwh))
     call matm(ppovlx,pwh,pwhovl,ngp,ngmx,ndimh)
     pwhovl= matmul(ppovlx,pwh)
     print *,'sss:  pwmat pwhovl=',sum(abs(pwhovl))

で比較して発見。(まずノルムチェックnormcheck.gasをみるとむちゃくちゃになってて 気がついた)。--Tkotani 18:23, 20 May 2009 (UTC)

normchk.gas

intel11+lapack,blas(from netlib)

#     eval          IPW        IPW(diag)    Onsite(tot)   Onsite(phi)      Total
...
     0.79725     14.350775  35251.220006      0.680608      0.665815     15.031382
     0.79725     18.174365  40215.413806      0.680608      0.665815     18.854972
     1.03135    110.570491 377996.269556      0.926774      0.827678    111.497265

2009/06/01 Kino

github上のファイルの現状(apr.22,2009)

いちばん最初の本家本元は nim-hrkn/ecalの  lm-7.0betaK001(6314196bd133be29b415ddf029104474892a0320) です。で、これに対してmasterとexpr_paramake のブランチがあります。

また、これと同じものlm-7.0betaK001(6314196bd133be29b415ddf029104474892a0320) がtkotani/ecalにあり、そのmasterを小谷がひとつのばしています。 ちょっとへたなことをしたので、うまくリンクされてないけど IDがおなじなので、nim-hrkn/ecalにあるものと同一のものから 伸ばしてるのがわかります。

ですので、いまのところ、kinoさんのブランチ2個、kotaniのブランチ1個 が6314196bd133be29b415ddf029104474892a0320から派生しています。


G-cutoff fixedバージョン(Apr22,2009)の説明

http://github.com/tkotani/ecal/commit/64a79cfaedea4bdf6d73fe8788304357c4e98d59

上をクリックしてもらうと、 もとになってるlm-7.0betaK001との差がみれます。

変更点

いらないファイル subs/bndfp.F gtv.F partks.Fなどを消しました

ASAバージョンはすでに捨ててたので、たぶんもうすこし入らないファイルを 掃除していった方がいいと思っています。 ただ、ASAバージョンではGGAとかNon-colinearとかtransportとか、将来FPバージョンにも とりいれていきたいような点があったのも確かで「ASAも動く状態で保持していきたい」 とも考えてたんですが、そのためだけに保持していくのもコスト高であると考え捨ててしまいました。 とにかく完動のASAバージョンの入ったものは、lm-7.0betaK001(たぶん。あるいは、 その前のアップしてないバージョン)までもどらないといけないとおもいます。

木野氏のcont.awk struc.awkいれときました。

これはlstra.Fを解析するためのツールですが、 gawk -f cont.awk lstra.F | gawk -f struc.awk としてうごかします(lstradataにこれが入ってる)。 結果はecal/lm-7.0betaK001/TOOLS/lstratableでした。とにかく、いま、木野さんが このよくわからない独自構造体をf90上のシンプルなものに書き換えてくれてます。すぐてきてくると おもいます。 新しいバージョンでは書き直せてます

サブルーチン等の定義位置とどこで呼ばれてるかなどのanalyzerを追加

  • analyze.shを引数なしで起動すると、

lm-7.0betaK001/TOOLS/ANALYZE/analyze.pyがよばれ、callとcallerのデータベースが生成できます。 (修正版analyze.py 27May2009)。将来的には、データベース作成部分とツリー作成部分をわけたいです. データ構造やフローも解析したい。他のIDEのチェックもする。

実行方法

  1. analyze.shをlm-7.0betaK001/におく
  2. analyze.pyをTOOLS/ANALYZEにおく(もとのやつに上書きする)。最初の行が/usr/bin/python2になってるので動かないとき修正。
  3. lm-7.0betaK001/で./analyze.shを実行(引数無し)。空ファイルがあると実行が止まるので、サイズゼロの.Fファイル(僕の場合、slatsm/fmain.F subs/bndfp.F subs/gtv.Fなど)を消してください。

analyze.pyでは、ツリーを書く前に、まずどこでcallが発生してるか、サブルーチンなどの 定義が発生してるかを調べてます。 で、callcaller.datとlmfp_treeを書きます(analyze.shみてください)。

callcaller.datとlmfp_treeの見方

callcaller.datはある種のデータベースです。grepで見ます。

  • grep def@ calltree_temp| grep sp2cls

 とやるとどこで定義されてるかわかります。

  • grep def@ calltree_temp| grep gvputf

 とやるとgvputfが二箇所で定義されてるのが  def@ sub: gvputf subs/gvlist.F 390 405  def@ sub: gvputf+ slatsm/gvgetf.F 16 31  (最初の定義があとでツリー作成につかわれます)。

  • grep def@ calltree_temp| grep fmainだと
def@   sub: fmain subs/prjpos.F 172 308
def@   sub: fmain+ subs/ropyln.F 121 176
def@   sub: fmain++ subs/shorps.F 119 199
def@   sub: fmain+++ subs/shorps.F 202 231
(以下略)

と表示されます。fmainはテスト用のメインで(subroutineとなってるけど、 これはlmv7.FのL34のfmainの代わりをします)、cppで隠されるけれどいろいろ定義されてます。

  • grep def@ calltree_temp| grep mod

でmodule定義がどこにあるかもみえます。

  • packi.Fのなかで使われてる関数をみるには、

 grep 'packi.F' callcaller.dat

  • lmfp_treeには、メインのlmv7.Fから呼ばれるfp/lmfp.F以下の3階層下までのcall tree、lmfp_treeができてます。たとえば、
tree0  pack1 fp/lmfp.F 200
tree1  |   salias subs/lstra.F 609
tree2  |   |  words subs/salias.F 46

なら、lmfpの200でcall pack1(現状の出力では関数かサブルーチンかはわかりません)、が発生し、そのpack1が定義されているのがsubs/lstra.Fファイルでその L609で、call saliasが発生してるという意味です。tree2などというのはlmfpからみて二階層下ということです。

このanalyze.py自体は汎用性があります。analyze.shのlmfpを 他の変えればちがうツリーも書けるし、そもそもデータベース部分と ツリー作成部分はanalyze.pyのなかで、内部的には分離してるので、 データベースは固定したのちルーチンをわけて、ツリーを書くように したほうがいいです。そのうちなんとかもうちょっと使い勝手をよくしてきちんとしとこうとは思ってるんですが、いまんところ非常にprimitiveです。 それにもうすこしテストしないといかん(バグがありえます)と思ってます。

fp/ncutcorrect.FでGのカットオフ補正

lmfでは平面波展開をいくつかの点で利用しています。その、 ひとつがHamitonianを作る際に、smooth Hankel関数を平面波展開するところです。このときのq+Gのカットオフが、lmfp-suham-sugcut(job=1,...)と lmfp-bndfp-suham2-sugcut(job=2...)で生成されています。 job=1が通常のMTO基底、job=2がlocal orbital基底にたいおうします。 一気にやらずに別の場所でやってるのは歴史的理由だと思います。

で、そのq+Gの個数は"spec ngcut" と名づけられ、rsibl.F,hsibl.Fで引用されます。ここでちょっと問題点があるのは、sugcut.Fがどう呼ばれてるのかを見てもらったらわかるように、q=0でのみq+Gの個数を決めてしまっていた点です。 このため、qによってはサイズ的に縮退しているq+Gを とらなくなってしまうことがおこってました。 (注:gvlist.F、gvlst2.F内でsort routinepvglstで|q+g|でsortしてます. sortの不定性を防ぐ修正も加えました)。 それを補正するため、rsibl,hsiblのなかに、そのngcutを補正するよう subroutine ncutcorrectを挿入しました。まあ、これは「自動カットオフ」 では一般におこりがちな不連続性の一例ですが。

また、これにしたがって、make checkが通るように、

  1. lm-7.0betaK001/fp/test/dos-mull.fe.gz
  2. lm-7.0betaK001/fp/test/out.lmf.copt.gz
  3. lm-7.0betaK001/fp/test/out.lmf.gdn.gz

をおきかえました。これらはcore i7, centos, ifort, acml で作成。

残る問題点。 これで、答えの対称性、安定性がすこしだけ向上するはずだと思います。 (が、make checkなどで値のずれを見てると全体的には大した影響はないみたい)。しかし、ひょっとするとまだ、異方性の高い物質では q+Gの数が突然変化してへんなことがおこることはありえます。 まだlmfできちんと分析してないのですが、alat+dlatの方法 を使えば問題ないのかもしれません (alat+dlatの方法:基本的な格子をきめ(たいてい対称性の高い構造) それでいろんなカットオフをきめ、格子を任意に変形させたときも それをつかって計算する方法.dalatだけでなく一般的変形が可能)。


  • dos-mull.fe (mulliken population解析。詳細は調べれてない、make check

のfeの場合)やpartial DOSは空間の分割GMAXに対する収束が遅いようにみえますが、マークさんにいわせるとそういうものだそうです。feの例でgmax=8とgmax=13だとエネルギー値によっては、たしか1%ぐらいはずれてたかと思います)。totalDOSなんかの収束は早いです。

Personal tools