StructureAnalysisEnvironment (SAE)

はじめに

現在(2026)においては、ASEや pymatgen などが発展しており、 このプロジェクト自体の存在価値がほぼありません。 すでに死んでいるコードです。

ただ、比較的マイナーな国産のコードも対応していることから、 必要と思うところ無いわけでもないですので、 少し改修して現代で使える形にしたつもりです。 ただし、ほぼテストしてません。

プログラムについて

VASP, WIEN2k, Quantum ESPRESSO, OpenMX, CP2K, HiLAPW, FDMNES, RMC_POT 等の第一原理計算および逆モンテカルロ法の各種計算コードに対応した入出力・解析の一元化を目指した Python フレームワークです。 これにより、計算コードの違いを意識することなく、 構造作成や解析などの計算コードの入出力・解析を統一的な方法で実現できます。 また、同時に提供される、同フレームワークを用いて開発された実用的なツール群により エンドユーザーは気楽にほぼ同一の手続きで計算から解析まで行うことが可能になります。

0.1.0 では、これまでのクラス構成を一歩進めて、計算コードごとのネームスペースと、 その中で扱うファイルや機能ごとのクラスを整理しました。0.0.x でも、構造や計算結果を インスタンスに読み込み、メソッドで変換・解析・書き出しをする形は普通に使っています。 今回もその考え方は同じです。長年の増改築で散らばった処理と呼び出し先を整理し、 既存の数式・アルゴリズム・パーサーによる結果を保ったまま、ライブラリとして扱いやすくするための変更です。

当時のいいわけ

かなり突貫で作っておりまして、まだまだ企画倒れな部分も多数あります。 2015 年あたりから大きな開発は止まり、その後も必要に応じて手を入れてきたものの、中途半端です。 また、当時はPythonがよくわかってなかったので今見るとかなりいい加減です。

履歴

• ver_0.1.0: 2026.10.15 既存のクラス構成を整理・拡張し、計算コード別にネームスペースを分離。Python 3.7 の文法を保ち、パッケージ設定を pyproject.toml に集約
• ver_0.0.18: 2020.11.18 21:11 突貫微調整, 名前空間の問題を（一部）解消
• ver_0.0.15: 2020.11.18 突貫微調整
• ver_0.0.6: 2018.10.15 突貫微調整 (マイナーfix) Python3.0
• ver_0.0.0: 2015.02.16 Last-Release Version (開発停止版)
• ...それ以前の過去の遺物

ライセンスおよび免責事項

Apache License 2.0 です。 ユーザーは使用にあたって Apache License 2.0 を順守してください。 Apache License 2.0 に基づき、作者はソフトウエアに関して何ら責任を負いません。 詳しくはパッケージに同封の LICENSE.txt ファイルをご覧ください。

想定する実行環境

開発のメインは Mac OS X で、テスト環境のメインは Linux です。 0.0.x では Windows 7 Pro および Windows 8.1 Pro でもある程度テストを行っていました。 Python が導入されていればほとんど何処でも動くようにしたいところですが、 0.1.0 で全環境を改めて確認したわけではありません。

0.1.0 のソースは Python 3.7 以上の文法で書いています。 Python 3.7.9 で構文と中心となるクラスのインスタンス生成を確認し、 数値処理を含むテストは Python 3.12.11 で行っています。 Python 3.7 上で、依存モジュールも含めてすべての数値処理を確認したという意味ではありません。 なお、0.0.x の主なテスト環境は Python 3.6.10、3.7.10、3.9.1 でした。

インストール

ソースを展開し、pyproject.toml があるディレクトリで次のように実行してください。

python -m pip install .

wheel からのインストールも可能です。

python -m pip install structureanalysisenvironment-0.1.0-py3-none-any.whl

パッケージ名はこれまでどおり StructureAnalysisEnvironment ですが、 Python から使うときの import 名は sae になります。 ビルド設定、依存モジュール、ツール群の登録は pyproject.toml にまとめました。 0.1.0 はこのパッケージだけで使えますので、以前の版や OLD ディレクトリを置いておく必要はありません。

以前は python setup.py install、もしくは次のような git からの pip インストールを案内していました。

pip install git+http://selenium.spring8.or.jp:8081/analysis/sae.git

これは0.0.xでの配布先と手順です。0.1.0では setup.py は使いません。 さらに古い Windows 64bit 用の StructureAnalysisEnvironment-0.0.1.win-amd64.exe は Python 2.7 向けのもので、Python 2.6 には一部制限がありました。 当時は PyPI に登録していなかったため、このインストーラや setup.py から導入していましたが、 現在はその Windows 用インストーラはサポートしていません。

実行に必要なPythonおよびモジュール

初期の Python 2.7、その後の Python 3.5 以上という想定から、 0.1.0 では Python 3.7 以上の文法に揃えています。 次のモジュールを使います。それぞれ、使用する Python に対応する版を導入してください。

• ASE (AtomicSimulationEnvironment)
• NumPy
• Matplotlib
• pandas
• humanfriendly
• coloredlogs
• xlogger-py

cif 関係では PyCifRW、3D描画やGUIでは VPython と wxPython を使う処理もあります。 GUI部分は旧来の visual と wx の環境を前提としており、 現行の VPython のAPIに書き直したものではありません。 計算コード本体や計算結果のファイル、OpenMX の擬ポテンシャル等の設定は別途必要です。

Matplotlib に必要とされるモジュール

以前の環境では、NumPy と SciPy のほか、以下のモジュールも案内していました。 Matplotlib の版や環境に応じて必要なものを導入してください。

• SciPy: Matplotlib を用いた処理で使用
• pytz: Matplotlib の旧環境で使用
• pyparsing: Matplotlib で使用
• six: Matplotlib の旧環境で使用

フレームワークの基本的な使い方

一般的な Python の OOP スタイルでコードが書けます。 構造情報や計算結果をクラスのインスタンスに読み込み、メソッドを作用させて処理するという、 0.0.x からの基本的な使い方は同じです。たとえば、以下の数行のプログラムにより、 VASP の構造入力ファイルである POSCAR を FDMNES 形式に変換します。 プログラム本体はたった二行で変換作業が終わります。

#!/usr/bin/env python
from sae import VASP

cell = VASP("POSCAR")
cell.write(code="FDMNES")

以前の import StructureAnalysisEnvironment as SAE、 SAE.io.Read(filename='POSCAR', code='VASP') に相当する使い方です。 0.1.0 では、計算コードが決まっていれば、そのコードのクラスを直接使えます。 旧 import 名の互換層は用意していませんので、既存のスクリプトでは import と呼び出し先を変更してください。

これらのクラス・メソッドには様々なオプションがあり、 たとえば構造情報である POSCAR 以外の VASP の入力ファイルを読み込んで、 ほぼ同じ計算条件の入力ファイルを自動作成する機能などもあります。 構造を保持したまま座標を変換し、その結果を書き出すこともできます。

from sae import VASP

vasp = VASP("POSCAR")
vasp.conv_direct2car()
vasp.write(outname="converted", code="FDMNES")

vasp.structure が構造を持つ ReadVaspPoscar インスタンスです。 DOSCAR を扱いたい場合は vasp.read_dos("DOSCAR") とすると、 作成された ReadVaspDoscar インスタンスが vasp.dos に保持され、戻り値にもなります。 各メソッドの状態変更や戻り値、オプションの既定値は既存の処理に従います。 変換するたびに別のインスタンスを返すように統一したわけではありません。

対象となるファイルのクラスを直接使っても構いません。

from sae.vasp.poscar import ReadVaspPoscar

cell = ReadVaspPoscar("POSCAR")
cell.conv_direct2car()
cell.write(outname="converted", code="FDMNES")

以前はインスタンスの write メソッド以外に、SAE.write(cell, code='FDMNES') のように 関数側から処理する書き方もできました。0.1.0 では、独立していた処理も役割ごとのクラスに まとめていますので、同じ使い分けは StructureWriter のメソッドで行えます。

from sae.vasp.poscar import ReadVaspPoscar
from sae.structure.writer import StructureWriter

cell = ReadVaspPoscar("POSCAR")
StructureWriter().write(cell, code="FDMNES")

その他、スーパーセルを作ったり、オイラー角にしたがって回転させたりなど、 多数の構造に関するメソッドを有しています。他にも、計算後の電子状態に対する処理も 同様の手続きで処理が可能です。それぞれ多数のオプション機能がありますので、 Python でのプログラム経験があれば、構造作成から電子状態の解析まで統一的に扱えると思います。

クラスと内部構造

0.0.x でも、各種の Read クラスや共通の Method クラスにデータと操作をまとめていました。 ただ、対応するコードや機能を足していくうちに、クラスと単独関数の置き場所、 それを呼び出す側の名前がわかりにくくなっていました。 0.1.0 では、この構成を計算コードごとに整理し、それぞれの中で対象ファイルや機能を分けています。

計算コード・対象	ネームスペース	中心となるクラス
VASP	sae.vasp	VASP
OpenMX	sae.openmx	OpenMX
FDMNES	sae.fdmnes	FDMNES
HiLAPW	sae.hilapw	HiLAPW
Quantum ESPRESSO / PWscf	sae.pwscf	PWscf
WIEN2k	sae.wien2k	WIEN2k
RMC_POT	sae.rmcpot	RMC_POT
LOBSTER	sae.lobster	LOBSTER
Bader	sae.bader	Bader
Athena	sae.athena	Athena
PF	sae.pf	PF

たとえば、sae/vasp/vasp.py の VASP クラスは、その計算の構造・入力・出力・解析の 各インスタンスを保持します。POSCAR のデータと座標操作は sae/vasp/poscar.py の ReadVaspPoscar、DOSCAR は doscar.py の ReadVaspDoscar、 POSCAR の出力処理は poscar_writer.py の PoscarWriter という具合です。 ファイル別のクラスからでも、コード単位のクラスからでも、同じ処理を使えます。

FDMNES も同様に、入力の構造は sae/fdmnes/inp.py、入力の生成は inp_writer.py、 計算結果は bav.py と、扱う対象ごとに分けています。出力形式の年代差に対応していた 処理は、その区別も残しています。CP2K 向けの既存コマンドもありますが、 独立した CP2K クラスはまだありません。

共通の座標変換は CoordinateTransforms、スーパーセルの処理は SupercellOperations、 元素表は ElementTable、テキストの読み込みは TextFiles といったクラスにまとめました。 単独関数であった処理も、これらのメソッドとして使います。 各モジュールに処理本体がありますので、以前のソースを外から呼び出す仕組みではありません。 構造や計算結果を読み込むだけでなく、そのデータを使って変換・解析・生成まで行う点は従来どおりです。

配置を詳しく知りたい場合は、実装対応表、 クラス操作の対応表、設計を参照してください。

利用例とサンプル

examples/vasp_conversion.py は VASP の構造変換、 examples/fdmnes_input.py は FDMNES の入力生成の例です。 以前からの実用的な小さいスクリプトも、コメントを含めて examples/legacy に置いています。 必要に応じて書き換えて使うための例としてはこちらも参考になると思います。

examples/ がコードの使い方の例であるのに対して、src/sae/sample_input/ は 計算データ等のサンプルです。テスト用に保存した基準値は tests/golden/ にあります。

各機能についてはここでは詳しくは紹介しませんが、実際には、このフレームワークを用いて 作られたツール群から使うこともできます。普通に計算や解析をするエンドユーザーは、 まずは次のツール群をお使いください。

フレームワークを用いたツール群の解説

ツール群は src/sae/commands にあり、インストール時にスクリプトとして登録されます。 0.1.0 では、内部で呼び出すクラスを新しいネームスペースへ接続しています。 実際に収録している197コマンドは コマンド一覧 と pyproject.toml を 参照してください。以下の説明には以前からの開発予定や旧時点の対応状況も含みますので、 収録一覧とは必ずしも一致しません。BUG を含む名前の古いスクリプトも残っています。

基本ルール

普通ユーザーはフレームワーク自体を直接使うことはほぼ稀となります。実際には、ユーザーはフレームワークとともに提供されるツール群を用いることになります。このツール群は、一部の例外はありますが、基本的には以下のルールに則ってネーミングをされてます。同じような名前のツールはほぼ同じ機能を用いており、多数の機能を似たような手続きで使うことが可能になります。

1. 大文字から始まるコードはユーザーが編集する必要のない汎用ツール。非常に多くのコマンドラインオプションを持ち、かなり高機能化、肥大化しているツールもあります。大抵は -h でヘルプが一応出るようにしてます。汎用の高機能のマクロとも言えます。

2. 小文字から始まるコードはユーザーがその都度必要に応じて直接編集する必要があります。ただし、実施問題小回りの効いた非常に小さいコードであり、Pythonを知っていれば汎用性が高く、簡単に目的に応じて編集できるので、ある意味一番便利なコードでもあります。一種の野良マクロと言えます。

3. 先頭の大文字もしくは小文字は、使用する計算コードを示します。これらツールのネーミングセンスの元は、小口先生のHiLAPWに同封されているLAcopyなどのツールに由来します。LAcopy に相当する他の計算コード向けのプログラムなど(例えばVASP用の Vcopy や Vmove など）も多数用意していますが、多くはc-shellやb-shell、もしくは Perl で実装しているために、このフレームワークのツール群としてはパッケージしていません。

   1. CPから始まる CP*.py プログラムは CP2K用
   2. FDから始まる FD*.py プログラムは FDMNES用
   3. LAから始まる LA*.py プログラムは HiLAPW用
   4. MXから始まる MX*.py プログラムは OpenMX用
   5. PWから始まる PW*.py プログラムは Quantum ESPRESSO(PWScf)用
   6. Rから始まる R*.py プログラムは RMC_POT用
   7. Vから始まる V*.py プログラムは VASP用
   8. Wから始まる W*.py プログラムは WIEN2k用

4. 先頭の大文字を除いて同じ名前だったらほぼ同じ操作で同じことが出来ます。

   1. (例) Vplot_LDOS.py と Wplot_LDOS.py は同じく LDOS 描画ツールでほぼ同じコマンドラインオプションで同じ描画をしてくれる機能を有します。
   2. (例) LAcopy と FDcopy はほぼ同等の機能を有します。
   3. (例)*plot*.py が含まれているコードは matplotlib を用いた2Dプロットかもしくは3Dプロットするコードです。

同封しているツールの概略

本フレームワークを用いて開発されたツール群のうち、ある程度メンテナンスが行き届いていて、かつ実用的と思われる ツールをいくつか紹介します。フレームワークのパッケージに同封していますのでフレームワークをインストールすれば自動的にパスが通っているはずなのでコマンドラインから普通に使えずはずです。また、パッケージにはここに記載されているプログラムをより多くのツールが同封されていますが、作者自身の使用頻度が低いものや古いものはとりあえずはここでの紹介は省いています。また、プログラム中から呼び出すことが前提の関数群(モジュールですらなく、そのまま関数的に使うスクリプト)の紹介も割愛します。

特にplot系ツールに関してはかなり機能が肥大化しており非常に多数のオプションを持ちます。ここではそれらについてはほとんど解説しません。各ツールには -h オプション指定で動かす事によりヘルプが出てきます。ヘルプを参照してください。

for CP2K

• CPvasp2inp.py : VASP の POSCAR ファイルを CP2K の *.inp 形式に変換します。*.inp はマクロ的にかなり高度な記述が可能な文法を持つ入力ファイルです。現在では部分的にのみ対応はしています。また、POSCAR の構造情報以外の VASP の計算のコントロール系の情報ファイルも同時に読み込み、ある程度のパラメーターおよび入力書式には対応しています。完全ではないですが、VASP の計算の入力ファイルをそのままCP2Kで動かすことは可能です。順次対応を強化していく予定です。

for FDMNES

• FDbav2xyz.py : *_bav.txt ファイルから xyz 形式のファイルを出力します。計算に用いたクラスター半径に応じて *_bav.txt で記述される構造が変わってきますので、それらをxyz形式に直すことにより、どのようなある半径のクラスターで切り取った構造を容易に可視化することが可能です。xyz形式はVESTAを初めほぼあらゆるツールで可視化が可能です。
• FDcif2fdm.py : *.cif 形式から FDMNES で用いる *.inp ファイルを出力します。また構造情報だけではなく、典型的な計算のサンプルインプットファイルも同時に *.inp に記述されますので、ほとんど修正無く、基本的な XANES スペクトルの計算が可能な *.inp ファイルを cif ファイルから作成可能です。
• FDclean.py : FDMNES の計算結果等のファイルを消し、計算前のファイル構成に戻ります。拙作(c/b-shell/perl版) Vclean、LAclean などの、他のコード向けのツールと同等のセンスで作られています。*.inp ファイルに記述している filout タグからファイル名のプリフィックスを FDMNES用のクラスから取得して初期状態に戻すためにわざわざPythonで記述しています。過去のスクリプトも順次Python版へ移行します。
• FDmove.py : filout タグにしたがって出力されたファイル名を一気に変更する。Vmove などと同様の機能
• FDconv_e2photoe.py: 計算後の *_conv.txt ファイルが above Fermi Energy 形式の時、Photon Energy 形式に直して計算し直します。Energpho をタグを入れずに計算したとき、または逆にもとのFermi Level形式に戻したいときに使います。
• FDfdm2vasp.py : FDMNES の入力形式ファイル *.inp に書かれた構造情報を VASP の POSCAR 形式に変換するスクリプトです。あまり需要は無いと思いますが、何かの構造からではなく手動で FDMNES 用の *.inp ファイルの構造情報を作成されたときにご活用ください。ただし、まだ空間群などの入力形式を初め、いくつかのFDMNES特有の自由な構造入力形式にはすべて対応しきっておりません。
• FDmakeCconvAllsite.py : Absorber を指定せずに、allsite で計算したときなど、複数の Absorber を用いたときは はすべての site で convolution されません。このスクリプトは、計算後にまとめてすべての site で convolution するためのスクリプトです。 convolution 用の *.inp ファイルの一括作成とそれを連続動作させるための fdmfiles.txt の自動作成スクリプトとなります。このスクリプトを動かしたときは fdmfiles.txt は書き換わりますのでご注意ください。
• FDpbd2fdm.py : PDB形式のファイルを FDMNES の入力形式 *.inp に変換するスクリプトです。FDMNESには本来PDB形式ファイルをインポートする機能があります。 PDB形式には、出力するソフトウエアによっては、周期的な構造情報をプロットするために、コメントアウト行にこっそりと格子等の情報を書くことがあります。 正しく知りませんがおそらく正式なPDB仕様ではないと推察しますが、VESTA や CrystalMaker などの多くのソフトで対応しています。 FMNESはこの書式にも実は対応しているのですが、これを読み込む機能がFDMNESはいささかバグっぽいです。 おそらく仕様自体がPDB公式でないためと推察しています。そのため、周期構造をアウトプットした場合は公式の？PDBフォーマットを扱う場合は、FDMNES本来のインポート機能を用いるよりは、このスクリプトを用いて、直接 *.inp に変換した構造を記述した方が意図した構造が計算出来ると思います。当然、通常のxyz形式で書かれたPDBにも対応しております。
• FDplot_XAS.py : *_conv.txt ファイルや *.txt ファイルなどの XANES の計算結果および、*_sd.txt ファイルなどの状態密の結果をまとめて表示したり、それぞれの結果を平均化したりするなどの様々なオプション機能を持つ高機能描画ソフトです。かなり機能がゴージャスです。基本的に　matploblib のGUI画面を持ちますので、そちらで拡大縮小やセーブも可能ですが、このプログラムを実行するだけで、デフォルトで自動的に描画結果はpdf,png,eps 形式に出力されます。詳しくは引数に-hを付けたオプションでヘルプが出ますのでそちらを参照してください。
• FDplot_XASs.py :
• FDplot_XAS_LDOS.py : XAS の結果(convoluton) および選択した原子のLDOSを多段組で表示する。軌道解析用。むしろ、基本機能が FDplot_LDOS.py ですべて実装されてしまっているので、あまり必要ないかもしれない。あるいみショートカット的なスクリプトです。機能の充実は FDplot_LDOS.py の方で精力的に行っているので、もしかしたらそのうちお蔵行きにします。
• FDplot_LDOS.py : 選択した原子のLDOS の結果のみを多段組で表示する。軌道解析用。複数の原子を選択すると、れを足し合わせ表示をしたり、XANES と同時プロット、積分状態密度のプロットなど多数の機能を持ちます。XANESスペクトルの表示(元ファイル and convolutionファイル)や トータルDOSおよび積分状態密度のプロットにも対応しています。もしかすると FDplot_XAS.py は必要ないかもしれませんが、こちらは一応LDOSメインなのでXASの平均化などのオプションは加えておりません。
• FDplot_PDOS.py : 選択した原子のPDOS の結果のみを多段組で表示します。LDOS の PDOS 版です。もともとFDMNES の出力はlm分解なので、こちらが本来のフル機能版の LDOS.py と思っても良いと思います。軌道解析用。表示する起動の選択表記も可能です。
• FDvasp2fdm.py : VASP の入力ファイルPOSCAR を FDMNES の入力形式 *.inp へ変換するスクリプトです。また構造情報だけではなく、典型的な計算のサンプルインプットファイルも同時に *.inp に記述されますので、ほとんど修正無く、基本的な XANES スペクトルの計算が可能な *.inp ファイルを POSCAR ファイルから作成可能です。
• FDxyz2fdm.py : xyz形式(md形式)ファイルを FDMNES の入力形式 *.inp へ変換するスクリプト
• fdExp_comp_XAS.py : FDplot_XAS.py のシンプル機能版にさらに、同フレームワーク中の Athena のノーマライズ形式(nor)を読み込むクラスを用いて実験結果と計算結果度同時にプロットしたりするプログラムです。 比較的シンプルに作ってあるので、実際には状況に応じてユーザーはこれを書き換えて、自由に臨み通りの図をプロットすることが用意です。 このプログラムは、そのためサンプルプログラムであるともいえます。
• fdLDOS.py : *_sd*.txt に記述されている状態密度情報をプロットするプログラムの基本機能のみを抽出したシンプルプログラムです。 FDplot_XAS.py では Absorber の状態密度プロット機能はありますが、別のサイトの局所状態密度まではプロットするようにはしていません。 局所状態密度解析を行うときはこちらをベースにすると便利だと思います。
• fdLDOS0_specified.py : fdLDOS.py とほぼ同等ですが、FDplot_XAS.py に実装されているのと同じく、局所DOSの規格化オプション（サイトごとや原子ごとに直す）も使われていますので、それらの機能確認を使いこなしてプロットするためのサンプルも兼ねた基本プログラムとなっています。
• fdPDOS_XAS_av.py : FDplot_PDOS.py をベースとしてます。複数の計算結果を平均化してプロットするなど、複数の計算結果に直接アクセスするようにしています。ケースバーケースで作り替える必要があります。
• fdLDOSmulti.py : FDplob_LDOS.py をベースとして、多段組を手動作りの最小構成サンプル。subplot を使っている。書き換える必要があるが、ひな形としては柔軟性が回ので実用的。
• fdMulti.py : FDplob_LDOS.py をベースとして、多段組を手動作りの最小構成サンプル。subplot を使わずに数値で値を入れている。fdLDOSmulti.py より小回りがきく。(subplotを使いこなせば良いという話もあるが、そこまでしなくてももっと気楽につかえる。)
• fdXAS.py
• fdXAS_specified.py

for HiLAPW

• LAvasp2sets.py : VASPのPOSCAR形式をHiLAPW の sets.in 形式に変換します。現時点では sets.in の空間群は P1 のみ（VASPでの記述のそのまま）にしか変換しません。HiLAPW用というわけではありませんが、VASPなどのP1で書かれた構造から対称性を探す Symmetry Finder は独自に作ろうと思っています。適当にお待ちください。FINDSYM などの外部のファインダーがあれば対称性は探せると思います。FINDSYMは非常に強力なのでお勧めです。

for OpenMX

• MXEE.py
• MXEI.py
• MXdat2vasp.py : OpenMX の *.dat 形式の中に記述された構造情報を元に VASP の POSCAR 形式に変換するスクリプトです。cartesian および direct への変換オプションを装備しております。
• MXdat2xyz.py : OpenMX の *.dat 形式の中に記述された構造情報を元に xyz 形式に変換するスクリプトです。
• MXdosall.py
• MXfindDAT.py
• MXfindPAO.py
• MXgetvalence.py
• MXjoinxyz.py
• MXmd2vasprun.py : OpenMX の構造緩和の出力結果である *.md　ファイルを VASP の vasprun.xml 形式に無理矢理変換するスクリプトです。VASP の可視化ツールである p4vasp で容易に *.md ファイルのアニメーションが可能です。わざわざP4vsp用のXMLファイルに変換するプログラムはおそらく業界初だと思います。VASPユーザーにとっては以外に便利だと思っています。
• MXplot_ADOS.py
• MXplot_ADOS_portrait.py
• MXplot_LDOS.py
• MXplot_MXEI.py
• MXplot_PDOS.py
• MXplot_TDOS+.py
• MXplot_TDOS.py
• MXplot_temperature.py
• MXtemp.py
• MXvasp2mx.py : VASP の構造情報ファイルであるPOSCAR形式のファイルをよみとり OpenMX の入力形式 *.dat に変換するスクリプトです。OpenMX の *.dat 形式は VASP でいうところの INCAR/KPOINTS などの計算のコントロール系のファイルも兼ねており、本スクリプトはPOSCAR 以外のこれらVASPの入力ファイルがあれば積極的に読み込み、VASP とほぼ同等の計算条件で計算する OpenMX 用の*.dat ファイルを自動作成します。これによりほぼ一対一で VASP と OpenMX の行き来が可能です。様々なオプション指定が可能であり直交座標系から基本並進系の相対座標系まで好きなオプションで変換が可能です。擬ポテンシャルや擬波動関数情報は、VASPのPOSCAR情報を元に、OpenMXのHPにある参考例を元にして、私が勝手にチョイスしますので、一応何も編集なしに *.dat ファイルは意図したように動作します。推奨値が気に入らないときは、PAO や VPP ファイルの修正は各自勝手に行ってください。
• mxDOS1.py

for Quantum ESPRESSO

• PWin2vasp.py : Quantum ESPRESSO (PWScf) の入力ファイルである *.in ファイルを読み込み、VASP の POSCARけいしきに変換するプログラム。PWScf の入力ファイル *.in は構造のみならず計算条件などのコントロール系の情報あるため、その情報をVASPのINCAR や KPOINTS に変換し、さらに擬ポテンシャル情報を読み込み POTCAR を自動作成する尾オプションなどの機能も有しています。
• PWmakePPinp.py
• PWout2vasp.py : Quantum ESPRESSO (PWScf) の計算結果の出力ファイルである *.out ファイルを読み込み(出力ファイル名は任意であるがここでは *.out とする) VASP の POSCAR 形式に変換する。同じく各種コントロロール系の情報を良い込み、計算条件をPWScfとなるべく揃えた INCAR/KPOINTS/POTCAR を用意するオプション機能も用意しています。
• PWout2vasprun.py : Quantum ESPRESSO (PWScf) の計算結果の出力ファイルを読み込み、VASP の vasprun.xml 形式に出力し直すスクリプト。vasprun.xml は VASP の可視化ソフトである p4vasp で可視化が可能であり、MD計算のアニメーション＆フォースなどの可視化を容易に行うこと出来る。現時点では DOS/LDOS などのアウトプットは vasprun.xml 形式には変換できない。
• PWplot_TDOS.py
• PWplot_XAS.py
• PWvasp2in.py : VASP の構造情報ファイルである POSCAR を基礎として、Quantum ESPRESSO (PWScf)の入力ファイルである *.in 形式を出力するスクリプトです。PWScf の入力は標準入力ですのでファイル名は任意ですが、ここでは *.in としています。もし KPOINTS や POTCAR や INCAR があればそれらから情報を読み込み、PWScf 形式へ出力も同時にするオプションも存在します。
• pwPDOS.py : Quantum ESPRESSO の PDOS はアホみたいに K-point を使わないとまともな結果が出ないのでご注意ください（対称化されていません）。
• pwTDOS.py

for RMC_POT

• Rcfg2vasp.py
• RchangeDensity.py
• RcollSplit.py
• RcollSplit_nonSplit.py
• RgetDensity.py
• Rmove.py
• Rmove1.py
• Rplot_Crystal.py
• Rplot_Crystal0.py
• Rplot_CrystalAnimeCFG.py
• Rplot_fit.py
• Rplot_ppcf.py
• Rplot_ppcf2.py
• Rplot_ppcf3.py
• Rvasp2cfg.py

for VASP

• Vacf.py
• Vados.py
• Vband.py
• Vcar2direct.py : cartesian 形式のPOSCARファイルをdirect形式のPOSCARファイルに変換します。
• Vch : VASP の計算に必要なファイルのチェックをしてくれるスクリプトです。計算の前に実行することにより、必要ファイルは必要パラメータを失念するのを少しは緩和できます。
• VchangeVacumm.py : POSCARなどの真空層を再調整するプログラムです。
• Vdirect2car.py : direct 形式のPOSCARファイルをcartesian形式に変換します。現時点では、拙作 Perl 版と比べると格子定数の倍率変化（内部の絶対座標の変化なし）など様々なオプション機能がディスエイブルされています。
• Vextract0.py
• VfindBond.py
• VfindNN0.py
• VfindNN1_library0.py
• VfindNN1_library1.py
• VfindNN2FNC.py
• Vforce.py
• Vforce2md.py
• VgetCOHPinfo.py : COHP解析で計算している軌道成分や、計算している結合ペアの確認に用います。
• Vldos.py : gnuplot 形式（および拙作 Perl 版プロットプログラム)ご関係しに出力するプログラムです。 拙作 Vldos.pl とほぼ同等の機能を持ちます。 現時点では Vplot_LDOS*.py シリーズでほぼ代用できるのでほとんど必要ないかもしれませんが、gnuplot で表示したいとき、gunupot で表示するスクリプトをかなり高度に組んでしまった時などにご活用ください。 lm分解で計算されたときは、l軌道のサムを自動でやってくれます。 gnuplot 形式は index を活用しています。 各原子種ごとに index で分解しています。 詳しくは出力されたファイルのコメント欄をご覧ください。 当然スピンにも対応しております。
• Vldos_COHP.py : Vldos.py は DOSCAR を読み込みますが、その代わりに DOSCAR.lobster を読み込みます。lobster で射影し直した LDOS を gnuplot 形式に変換してくれます。
• VmakeSuperCell2.py : VASP の POSCAR 形式を元に、指定した倍率でスーパーセルを作ります。
• VmodifyAtomPosition.py
• Vpdos.py : gnuplot 形式（および拙作 Perl 版プロットプログラム)ご関係しに出力するプログラムです。拙作 Vpdos.pl とほぼ同等の機能を持ちます。現時点では Vplot_PDOS*.py シリーズでほぼ代用できるのでほとんど必要ないかもしれませんが、gnuplot で表示したいとき、gunupot で表示するスクリプトをかなり高度に組んでしまった時などにご活用ください。くれます。gnuplot 形式は index を活用しています。各原子種ごとに index で分解しています。詳しくは出力されたファイルのコメント欄をご覧ください。当然スピンにも対応しております。
• Vplot_ADOS.py
• Vplot_ADOS_portrait.py
• Vplot_Bader.py
• Vplot_COHP_tate.py : lobster による pCOHP 解析の結果をプロットします。プロットする局所状態密度は pCOHP 解析のためにプロジェクションされ直した状態密度です。 左右の二段組みで、左側が状態密度パート、右側が COHP パートになります。 デフォルト動作はスピンありのときは up-spin のみで、一番目の原子の局所状態密度からの解析結果になります。 指定した番号の原子種のペアのCOHP解析の結果を表示します。 引数で複数の原子ペアの番号を振ると複数の局所状態密度・pCOHP 解析の結果を同時にプロットしますが、原子種・ペアが多いと訳が分からなくなります。 デフォルトではスピンを指定してスピンごとにプロットしますが、up-spin と down-spin の同時プットも出来ますが、同時にプロットすると情報量が多くて訳が分からなくなります。 必要な情報のみを取捨選択して賢くプロットしてください。またプロット前には VgetCOHPinfo.py を実行し、COHP 解析される軌道成分および、結合解析される原子のペアを確認していただけると楽に Vplot_COHP_tate.py にプロットする軌道や原子ペアを指定できるかと思います。
• Vplot_COHP_yoko.py : Vplot_COHP_tate.py とほぼ同等のことをしますが、Vplot_LDOSm.py などで使われている 上下形式の多段組で、実際に COHP 解析を行った LDOS を同時に表示します。局所状態密度にの成分分解の解析を主眼としてプロットするときは、こちらの形式の方が論文に使いやすい図表となる場合があります。複数の結合ペアのCOHP解析の同時プロットや、単独のペアを指定して、それぞれのl成分分解のLDOS表記など多数の機能があります。
• Vplot_Crystal.py
• Vplot_CrystalAnimeMD.py
• Vplot_CrystalAnimePOSCAR.py
• Vplot_COHP_LDOSm.py : Vplot_LDOSm.py と同等です。 DOSCAR の代わりに DOSCAR.lobster を読み出します。
• Vplot_COHP_PDOS.py : Vplot_PDOS.py と同等です。 DOSCAR の代わりに DOSCAR.lobster を読み出します。COHPペアを指定して、COHP解析の結果の同時表記も可能です。
• Vplot_LDOS.py : DOSCAR および PROCAR ファイルを用いて局所状態密度を一段組でプロットします。 引数を指定することで、特定の原子種ごとにプロットします（特定原子種の局所状態密度をプロット)。 描画範囲の指定など多くのオプション機能を持つ多機能のプロットプログラムとなっています。 安直な方法での一発で局所状態密度のプロットは結構便利だと思います。 引数で原子種を指定しますが、その際の*.pdf などの出力結果には原子種のsuffixが付加されます。 スピン表示は単独、もしくは両スピン（上下反転した形式で）表示することも可能です。
• Vplot_LDOSm.py : Vplot_LDOS.py は一段組での特定原子における局所状態密度（l軌道成分分解）を描画しますが、Vplot_LDOSm.py は多段組で、l軌道成分ごとにsubplot分解されて表示されるマルチプロット表示を持ちます。 ほとんどの場合はマルチプロット表示で多段組の方が各軌道成分が見やすいので普通はこちらを使う方が良いと思います。 スピン表示は単独、もしくは両スピン（上下反転した形式で）表示することも可能です。 VASP で計算するときに LORBIT=11 などでlm分解で計算したときは、自動的に l 成分のサムをしてプロットします。 局所状態密度の計算は大は小を兼ねるのでかならずl分解ではなくlm分解で射影した計算をすることをお勧めします。
• Vplot_PDOS.py : DOSCAR および PROCAR ファイルを用いて局所状態密度(lm分解)を多段組でプロットします。 計算している物質系の点群を判別し、たとえばcubicのときの t2g と eg 軌道などに縮退ごとに分割した多段でプロットされる機能をデフォルトで持ちます。
• Vplot_TDOS.py
• Vplot_VDEI.py
• Vplot_VEE.py
• Vplot_VEI.py
• Vplot_band.py : バンド分散(E-K曲線)の計算結果を表示するプログラムです。 EIGENVAL をベースに表示します。 Brillouin Zone の長さをプログラムは正しく把握するため、プロットにおけるゾーンの長さを正しく調整します。 また、この手の計算プロットではバンドを「線」でつないでいる描画プログラムがありますが、VASP は既約表現の計算などを行っていないために「線」でバンドをつなぐのは物理学的に大きく間違っています。 そのため、本プログラムはあえて「点」でバンドをプロットしているために「美しくない」ですが、それはVASPの仕様を正しく表現したためで、一切の誤解無くE-Kプロットされています。 スピン分解の同時表示や別表示、描画モード、バンドインデックスの表示など多くのオプション機能をわりとゴージャスに詰め込んでおります。 詳しくはプログラムのヘルプ(-hオプション)をご覧ください。 拙作perl版ではノンコリニアやスピン軌道相互作用にも対応しておりましたが、python 版ではまだそれらには対応しておりません。 それらに対応している。perl版が欲しい人はご連絡ください。
• Vplot_com.py : バンド分散(E-K曲線)の計算結果を表示するプログラムです。 EIGENVAL だけではなく PROCAR の情報に基づき、各バンドを構成している波動関数の成分表記のプロットに対応しています。 成分の大小によりプロットする点の大きさを変更したり色を段階的に変化させる機能を有しています。これにより、どのバンドがどの軌道のどの射影成分に対応しているのか容易に知ることが出来ます。バンドの解析にかなり強力な手助けになると思います。Brillouin Zone の長さの違いによる調整を行います。 VASPの仕様を正しく再現するために「線」ではなく「点」でプロットします。これにより物理的に誤解無くE-Kプロットされます。Vplot_band.py と同様に、スピン分解の同時表示や別表示、描画モード、バンドインデックスの表示など多くのオプション機能をわりとゴージャスに詰め込んでおります。詳しくはプログラムのヘルプ(-hオプション)をご覧ください。拙作Perl版と比べるとノンコリニアやスピン軌道相互作用の対応など基本機能で劣りますが、可視化機能ではこちらの方が綺麗に描画できるかと思います。
• Vplot_temperature.py
• VrotPOSCAR.py : POSCAR をオイラー角(alpha,beta,gamma)で回転させます。ここで言うオイラー角の定義は応用群論p121の定義(z-y-z)を用いていますのでご注意ください。電場をかけるなどで結晶軸が特定方向を向いてないと定義できない場合に用いると幸せになります。回した後の計算では、真空層があるときは KPOINTS ファイルの kx,ky,kz にはご注意ください。
• Vtdos.py
• Vtemp.py
• Vvasp2xyz.py
• Vxdat2MD.py
• Vxml2CONTCAR_ALL.py
• Vxml2MD.py
• Vxml2POSCAR.py: VASP のXML形式の出力である vasprun.xml から計算に用いた初期の POSCAR 情報を抽出し、吐き出すプログラムです。vasprun.xml には計算の結果がほぼすべて記述してあるので、適切な読み込みクラスさえあれば、実は意外に使い勝手が良いです。
• vLDOSm_3d.py
• vLDOSm_4d.py
• vLDOSmulti.py
• vLDOSs.py

for WIEN2k

• WchkEparm.py
• Wgeteparm.py
• Wgeteph.py
• Wgetepl.py
• Wldos.py
• Wplot_ADOS.py
• Wplot_ADOS_portrait.py
• Wplot_LDOS.py
• Wplot_LDOS_portrait.py
• Wplot_LDOSm.py
• Wplot_TDOS.py
• Wplot_XAS.py
• Wstruct2vasp.py
• Wvasp2struct.py
• wLCOS_core.py
• wLDOS_core.py
• wLDOSm_3d.py
• wLDOSm_4d.py
• wXAS.py
• wfch_XAS.py

リリースノート

0.1.0 の整理と確認

今回の変更は、これまでのクラス構成を整理・拡張し、計算コードごとにネームスペースを 分けたものです。構造変換や解析の方法を作り直したわけではありません。 同じ入力から従来と同じ結果と生成物が得られることを基準にしています。 既存の増改築で名前や引数、戻り値の受け渡しが合わなくなっていた箇所は、 呼び出される側の元の処理に合わせて接続を直しています。

OLD に保存した0.0.xの実ソースとの比較では、904メソッドを対象に、 ネームスペース、import、単独関数への self 追加等を揃えると890件の本体が一致しました。 残る14件は、元素記号の bytes/str 境界、スーパーセル生成先の確保数と戻り値の接続、 属性名、動的 import、型判定の参照先、GUIから既存の変換処理への接続です。 実際の差分は メソッド差分 にあります。 この比較だけで、すべての入力に対する結果の一致を確認できるわけではありませんので、 数値と生成ファイルの比較も行っています。

Python 3.12.11 でのテスト結果は 1,188件成功です。 以前保存した移植作業用スナップショットとの算術式比較899件、クラス接続260件、 保存済みの旧版の数値・生成物との比較13ケース、既存の接続修正等11件に、 文書・コメント・データの保持とGUI関係の確認5件を加えています。 算術式の比較と、今回のOLD実ソースに対するメソッド全体の比較は別の検査です。 Python 3.7.9 ではソース・利用例・テスト計348ファイルの構文と、11個の中心クラスの 空インスタンス生成を確認しています。また、旧パッケージをimportできない環境で、 wheelからの各実装モジュールの読み込み、VASP変換、FDMNES入力生成を確認しました。

ソース内の説明や履歴も引き継いでいます。対象342ファイルの23,666コメントトークンを 照合し、クラス・メソッドのdocstringも、インデントと外側の空白を除いて欠落がないことを 確認しました。コメント中に旧名称や過去の使い方が残っているのはそのためです。 元ファイルと移植先の対応、データのハッシュは 移植一覧、 以前の設定やパッケージ初期化の説明・履歴資料は docs/history にあります。 このREADMEでも、従来のツールの説明や開発経緯を残しながら、0.1.0の使い方を各項目に織り込んでいます。

全197コマンドやすべての計算コード・形式・実データを実行したわけではありません。 GUIの実表示、Python 3.7上での数値処理全体も未検証です。 従来と同じ終了状態や未実装のメソッドが残る箇所もあり、 そのことを数式やアルゴリズムの問題とは判断していません。 詳しい結果と範囲は 検証記録、移植監査、 各版の変更履歴は CHANGELOG を参照してください。

特徴

現在のところ、各種計算コードの入出力の変換機能がメインとなります。たとえば、構造の変換で言えば、結晶・分子構造をその計算コードで要求される形式に変換するだけではなく、その他計算に必要な入力項目の変換も含んでいます。基本方針としては、一度どれかの計算コードにおいて、計算が可能な入力ファイルを作れば、別の計算コードでもそのまま無編集で計算まで持っていけることを目指しています。つまり、計算コードの入出力に関して、可能な限り計算コードの違いを吸収することが目的の一つとなります。計算コードを扱う際の入出力の一元化に関しては、当然計算コードのアルゴリズム上、本質的に同じように扱うことが無理な場合も多数あります。その場合は、ある程度は私自身の推奨する独断と偏見の初期パラメーターを与えて簡略化をしています。当然詳細設定も可能です。無論、最初から一元化を諦めて特化機能としている部分も多数ありますが、これらはほぼ同じ手順で簡単に操作が可能としています。入力の構造のみならず、計算結果や、電子状態の解析など、あらゆるシーンで、対応する計算コードの一元的な操作環境を提供しています。特に解析機能が充実しているのも特徴となります。

フレームワーク

中間ファイルは可能な限り吐き出さず、すべてPythonのOOPモデルの元、フレームワーク上で一元的に処理しています。この手の統合環境では中間ファイルを積極的に用いる小規模コードの集合体としての開発方針もあるとは思いますが、OOPによる開発コスト軽減と一元化が目的なのでこのコードでは採用していません。フレームワークを用いた開発を行うことにより、たとえばことなる計算プログラム間の構造変換はたった二行のコードを書くことにより変換できます。これはとてつもないメリットを生み出します。

0.1.0 でも、このOOPによる一元的な処理という方針は同じです。 既存のデータとメソッドのまとまりを活かしつつ、VASPなら sae.vasp、FDMNESなら sae.fdmnes の中を見れば関係するクラスがわかるようにしています。 個々のファイルを扱うクラスと、計算コード単位でそれらを持つクラスの使い分けについては、 前述の「クラスと内部構造」を参照してください。

小谷先生流にかっこ良く言えば「計算のための独自言語」を設計していると言い換えること出来ます。

エンドユーザーから見るとおそらくこのフレームワークは全く意味を持たずに、私自身がこのフレームワークを用いて開発したツール群が実態として意味を持つことになるかと思います。また、第三者がこのフレームワークを用いて開発することは現時点ではお薦めしません。設計がかなり右往左往しています。現時点でしたら、特別の理由がない限り、既存の代表的なASEフレームワークを用いて開発したほうがはるかに有意義かと思います。

無論、どのようなフレームワークのデザインに設計し直そうとも、エンドユーザーが使うツール群のインターフェースは変えませんので、ユーザーから見ると基本的には使い勝手は変わらないようには開発は進めます。

マイナー対応

このフレームワークは、一部国産コードや逆モンテカルロなどのマイナーコードや、Plane Wave系の基底では pCOHPなどのマイナーな解析出力に対応している(lobsterなどのコードに対応)のが実用上の特徴かと思います。また、なにげに RMC\_POTへの対応は業界初だと思っています。Pythonフレームワークの意味では、pCOHPもおそらく業界初です。特定の手法への特化ではなく統合的な環境の意味では、FDMNESが対象に含まれているのもこちらもおそらく業界初かと思います。日本のXANESコミュではFDMNESはそれほど普及していないので、このツールの普及を兼ねてFDMNESの普及も狙っています。VASP等のコード<-->FDMNESなどが自由に出来るフレームワークはほとんど無いと思いますので、きわめて有効に作用するかと思います。FDMNES対応で判るように、わりとXANES関係には力を入れていますのでそっちの業界の人には結構役立つと思います。OpenMXやRMC\_POTを除き、対応している第一原理計算コードはすべてXANESスペクトル計算が可能であり、その意味ではこのフレームワークはXANESスペクトル計算フレームワークであるとも言えます。実際、現時点での仕事上の開発の主目的は、ほぼXANESスペクトルの解析とも言えますので、その利便のために開発しておりますので当然です。微妙に実現しているとは言いがたいですが、割と便利には使えると思います。

解析対応

電荷密度、局所状態密度、バンド分散、Barder電荷、XANESスペクトル、pCOHP解析などを始めとした、基本的な解析対応だけではなく、様々な計算の解析・プロット、およびそれらへの入力支援を行う機能を多数含んでいます。おそらく、ASEよりも解析関係のログ解析やプロット機能が豊富ではないかと推察します。現時点での開発者自身の開発のモチベーションの主軸はむしろ解析支援部分の機能の開発にあります。

構造作成支援

スーパーセルの作成から配位数やボンドのサーチ、指定した局所構造の並進移動・回転操作などの座標のモディファイ、表面作成や真空層作成なども含みます。ただ、わりと構造系の支援はしてくれるクラスや関数は作っているのですが、現時点ではあまり賢く作ってないのと、機能もまだまだ不十分です。ASEのようにナノパーティクルとかナノチューブとかは自動では作ってくれません。

2Dプロット機能

2Dプロット機能は基本的にはmatplotlibモジュールを用いていますので、PDF/EPS出力に対応しています。局所状態密度解析などを初めバンド計算で用いられる一般的な解析のテンプレートは多く実装しており、かなり容易に、論文に使える図表などの作成をルーチンワークに持っていけると思います。スクリプトからの自動実行・ルーチン作業化が大前提ですので、GUI化には全く力を入れておりません。当然バンド分散プロット等では波動関数成分の可視化をE-Kプロット上に連続的な色の変化やポイントのサイズの変化で同時に表示することにも対応しています。また、VASPの一般的な可視化ソフトであるp4vaspのXML形式へ各種計算コードの結果を変換する機能を持っているのがおそらくマニアックな特徴となります。おそらくp4vaspへ無理矢理変換する発想も、その機能も、業界初だと思います。たとえば、OpenMXで計算したMDのxyz形式をp4vaspでアニメーションする形へ持っていくのも容易に出来ます。XCrysDen に対応しているツールは多いと思いますが、本ツールではまず p4vasp に対応しました。XCrysDen にはまだ対応してません。小口先生のPSP形式の対応はこっそりとは進んでいますが、maplotlib 機能で直接PDF出力したほうが現時点では健全かつ便利です。

3Dプロット機能

0.1.0 では、従来の CrystalMaker と単位胞の描画処理を sae.gui にまとめています。 描画の仕組み自体は従来のままですので、必要な visual と wx の環境については、 「実行に必要なPythonおよびモジュール」も参照してください。

3Dプロット機能およびGUIはほとんどおまけといいますかまだ機能テストの段階です。主に VPython + wxPython を用いることにより、間接的に OpenGL を用いています。OpenGLを用いた3Dプロットの可視化およびGUIの設計で、もう少し自由度を上げるために VTKからのOpenGL利用や直接OpenGLを用いることを検討しています。現在一部機能は準備中でして、これは解析支援の柱の一つだとは思っています。ただ、実際問題、開発リソースが１人で、しかも内職ですので全く構想に開発が追いついていません。現段階では、役立ち機能では Barder 解析の結果を3D可視化する機能の実装は出来ており、これは比較的役に立つ3Dプロットだとは思っています。当然スーパーセル化などには対応しています。それ以外では、出力結果をVESTA/p4vaspで描画したほうが現時点ではまだマシです。

開発の経緯と現状

元々は作者が大学院時代からポスドク時代までのおよそ１５年位の間にほそぼそと個別に作っていたAWK/Perl/Cなどを用いた多数の変換・プロット・解析支援プログラムがベースになっています。これまで、それぞれの支援コードにおいて、各支援コードが同じような方法論で使えるインターフェースを持ちつつ、それぞれの支援コードが相補性的に機能するように'なるべく'作ってきましたが、対応する計算コードの増加と、開発規模の肥大化に伴い、全体像としての開発が破綻しかけていたのがまず現状としてあります。そのため、自身の利便性と趣味でPython化したことから始まっています。そのため完全に独自実装をしてます。

フレームワーク化により開発にまつわる多くの問題は解決されます。Pythonフレームワーク設計ですので、ASEをご存じの方は、ASEを思い出すと思いますが、本コードは結果的にはASEの廉価版だと思ってくれてよいです。末端のReadクラスからの構造の読み込み・書き込みなどの基本機能の使い勝手、関数として呼び出しても良いしMethodで呼び出しても良い点など、ほぼASEと同じです。インスタンス作成からの流れや、マルチパラダイムな点は、ASEでなくとも、Pythonフレームワークならばどれも発想は同じなると思います。ですので、自虐的にASEの類似品と言うよりは Python OOP の自然の帰結だと思います。(むしろASEは基本構造としてクラス・メッソド・継承などのOOP的な手続よりは、多くは関数で作られている印象があります）。内部構造は当然まったく異なります。ただ基本機能の意味で、現時点ではかなりASE廉価版かと思われます。かなりショボイかもしれません。開発当初は自身の不勉強のためにASEの存在をあまり良く知らなかったこともあります。今になって振り返ると、Python フレームワークで計算の統合環境といえば、ASEがダントツで優れており、業界標準です。欧米では第一原理計算コードはASE対応が前提なものがほとんどです。おそらくASE以外にはそれに匹敵する同等のツールは必要ありません。本フレームワークは、結果的に似たようなフレームワークなので、開発として無駄だった点もあるかもしれませんが、独自開発故のメリットも当然多数あります。

一応、このフレームワークの意義は、自身の利便性のための自身のためのコードでして、その意味ではASEとは別の価値があるとは思います。私自身が必要とする機能の迅速な開発のための、開発環境の提供こそ意味があります。一応ミソとしてましては、ASEで対応していない国産のマイナーコードやマイナーな解析に対応している特徴はあります。さらに、自身の利便のために可視化も含めて様々なツール群を作っていまして、おそらくユーザーの視点で見るとフレームワークというよりはフレームワークとともに配布するツール群には一定の価値は見出していただけると思います。

同じく、マイナー対応では小谷先生が、同じくPythonフレームワークでXtalEditを開発されてまして、そちらの方が国産コードの対応が出来てるかと思いますが、開発は停滞しているようです。XtalEditは私のような解析中心ではなくて群論的な構造作成機能が中心です。当然ASEには同じ機能はあります。やはり Python を使った計算シミュレーション系の統合環境フレームワークは、結果的には老舗であるASEを追いかけ、その廉価版になってしまうのは必然かもしれません。おそらく、自己満足以外の目的では、計算物理屋は自身でこのようなコードを開発せずにいるのが賢明です。マイナー機能やマイナーコードの対応クラス等が欲しかったならば、ASEへ何らかの形でをコントリビュート、もしくはASEからのブランチとしたほうが健全ではないかとは思っています。

もし、国産コード対応が目的で、GUI が前提でしたら、近年ではCMSIなどのコミュニティがすすめるC-Toolsがあるかと思います。MateriApplsLiveに同封されています。GUI は割とシンプルでまだかなり機能も原始的ですが、それなりに最低限の需要は満たしていると思います。国産のマイナーコードの構造変換等の対応でしたらだいたいOKです。同じく、小谷先生のXtalEditも開発は止まっていますが、JavaのUIは一応持っています。それらのツールを使うのも手かもしれません。私の用意するフレームワークはまだGUI部分に限ってみれば、それらのツールには及んでいませんし、今後も迫る予定もほとんどありません。

現状と未対応状況

現状では、昔開発していた AWK/Perl/Cなどの各種コードを用いた古い解析・計算支援系コードのうち、特に、KANSAI-92、LmtART、MarkさんのLMTO、FHI-AIMSなどへの対応した機能は、現時点では全くフレームワークへの移植・対応はしておりません。私自身、最近はそのあたりのコードを使ってないので将来的にも対応予定は今のところありません。その他VASPなどのコードにおいても、まだ一部の機能しか実装できていない問題があります。たとえば、ごく基本的な構造変換以外、まだHiLAPW対応もまったく進んでません。この６〜７年、HiLAPWも使っていませんので対応もかなりおざなりです。

最大の問題は、統合的なフレームワークのデザインで未だに自身の方針が二転三転しているのと、自身のスキルなさと、そのスキルの変遷、特にOOP デザインへの理解度の変遷が、コードのリファクタリングにまったく追いついていません。そろそろきちんとリファクタリングしないと開発が発散してしまいそうで、少し限界に近い状況でもあります。フレームワーク＋ツール群で5万行くらいコードがありますので、そろそろしんどいです。リファクタリングを一気にやってスリム化したいです。ただ、いまだに対応するコードや機能が増加中で、あらゆる開発が追いついていないのが現状です。

このような増改築を整理するため、0.1.0では既存のクラスを土台にネームスペースと 内部の呼び出し関係を整理しました。対応する計算コードを増やしたり、解析手法を 変更したりする作業とは分けて、まずは既存の処理を見通せる構成にするところから進めています。

名前

ネームスペースを作る都合、現時点ではStructureAnalysisEnvironment (SAE) と名づけていますが、ASE (AtomicSimulationEnvironmet)の存在を知る前につけたネーミングでして、今の実感だとこの前はこの名前はありえないと思っています。自身でもASEと混乱します。そのうち変更予定ですがセンスが無いので思いつきませんのでこのままかもしれません。（最近は三文字ではなく、略称としてはSAEnvとしてます）。

ASEモジュールおよびcif対応

残念ながら現状では、群論に関するごく一部機能をASEのモジュールから用いています。ASEに慣れてくると自身のフレームワークの存在価値を失いそうになるのですが、一応、これら群論機能の独自実装は一部では進んでますのでそのうちフレームワーク本体からのASEモジュールの使用は除きます。ただ、時間が足りていないのと、ぶっちゃけASEモジュール利用で困ってないので、困っています。その他、現状では私のフレームワークでは直接 cif の読み書きは直接できないので、この機能を ASEモジュール に頼るか PyCifRWモジュールに頼るか、中途半端な独自実装をするかは迷ってます。cif変換系はASEのフレームワークを使う支援プログラムとして、ツール群の中に一緒に放り込んではいますので、ユーザー視点としてみれば、実用上は問題無いとは思います。一般にはcifからの変換系ツールでは [cif2cell](http://sourceforge.net/projects/cif2cell/) が対応フォーマットの多さと利便性と知名度で何歩か進んでいると思います。cif2cell だと当然彼らも独自実装せずに、PyCifRWモジュールで対応してます。ともあれ、正直cifに関しては、VESTAを一度通せばほとんど対応できるので実際問題微妙にモチベーションは低いですが、シームレスな対応の意味では見逃せないポイントではあります。

今後

群論機能の充実と、それを基盤にしてバンドフォールディング機能の実装などは目論んでいます。当初はそれを目玉機能とするつもりだったのですが、それも [unfolding](http://www.ifm.liu.se/theomod/compphys/band-unfolding/) コードを別途見つけてしまったのでいささかモチベーションが低いです。作ろうと思っていたことはほぼ実現されてしまっています。私自身の開発は、基盤フレームワークの整備が思ったより肥大化して、しかも肥大化が止まる気配がないので、現状フォールディング等の機能の実装が完全に止まっています。むしろ、既存の unfolding コードは使うにあたっての手続きがかなり煩雑なのでそれをラップするだけでもかなり便利かもしれません。解析利用という一点で見れば、その方向性はありとは思っていますので、少し検討中です。ただ、大前提として解析手法の開発基盤開発が目的でもありますので、群論機能の充実は今後の開発の心臓部分だと思っています。無論、心臓だけでは何も出来ませんので手足もドンドン作っていく予定です。

特に解析(よび構造作成)に関しては特定の計算コードにとらわれずにツールを作ることは大切だと思っています。PAWの波動関数からの内殻の情報を再計算するなども、いまさらFortranで書くのもいまいち戸惑うのも本音です。なるべく周辺部分は計算コード依存を無くしていきたいと思います。

特にこの手のコードは、ASE が世の中にある現場、マイナーの計算コード対応と、独自の解析機能実装と、GUI機能の充実以外ではおそらくオリジナリティと利便性は出てこないと思います。開発の意義は多分それです。独自の実装を含む解析の機能充実とマイナーコードの対応はドンドン進めていく予定です。GUIは必要に応じて作りますが、おそらくかなり手抜きだと思いますので、期待は出来ません。一応、趣味もかねて、wxPython,wxWiget でクロスプラットホームで, Pythonのみならず、C++などのネイティブなGUIも含めて開発は進めています。

結局、どれに時間と力を注ぎこむのかは今後次第です。ただ残念ながら、しばらく計算をする仕事からは離れそうなので、あまり開発は進められない気もします。