Qiskit Nature v0.5 移行ガイド#
このチュートリアルでは、コードを Qiskit Nature v0.4 から v0.5 へマイグレーションするプロセスをガイドします。
概要#
まず、リファクタリングされた設計の概要について説明します。 Qiskit Natureのリファクタリングの主要な動機は、 Qiskit Natureを他の古典的な計算コードとより厳密に統合するために準備することでした。最もモジュラー的でかつ保守性の高い方法でこれを実現するには、BaseDriver
クラスから BaseProblem
という表現を切り離す必要がありました。
これにより、 Qiskit ネイチャー・パッケージの抽象的な設計は以下のようになりました:
ご覧のとおり、パッケージは論理的に2つの概念に分かれています:
問題: 解を求める科学的な問題の表現
アルゴリズム: この問題に対する解決策を見つける手段を提供する
それぞれの場合に、Qiskit Natureには以下の3本の柱があります:
問題:
電子構造の問題: 分子系の電子のシュレーディンガー方程式の問題を表す
振動構造問題: 分子系のワトソン・ハミルトニアンによって引き起こされる問題を表す
格子モデル問題: 格子で定義された問題を表す
アルゴリズム
基底状態ソルバー:問題の基底状態を見つける
励起状態ソルバー: 問題の励起状態を見つける
ハミルトニアン・シミュレーション: 問題のダイナミクスをシミュレートする (v0.6 で計画されています)
これらのコンセプトのいくつかは、Qiskit Natureの以前のバージョンでもすでに存在していましたが、それほど明確に分離されてはいませんでした。さらに、古いバージョンでは古典的なコードとの統合が非常に制限されており、そのような統合の潜在的なアプリケーションだけでなく、我々の BaseProblem
表現の能力や、パッケージの残りの部分でのその使用法も制限されています。
このガイドの使い方#
このガイドは複数のファイルに分かれており、v0.4 と v0.5 の間の各サブモジュールの変更点を、必要なときに確認することができます。つまり、一度にすべての詳細を読む必要はなく、あちこちに飛ぶことを強く推奨します。
一般的には、リファクタリングによって qiskit_nature.X.second_quantization
から qiskit_nature.second_q.X
へとコードが大きく再配置されました。これは、ほとんどの場合において、ソースコードをナビゲートするのに役立つはずです。しかし、いくつかのケースでは、特定のモジュールやクラスを再分類しているので、詳細については以下のガイドを参照してください。
どのようなファイルに注意を払う必要があるのかを理解するために、以下のトピックのリストをよく確認してください:
重要な一般的な注意事項#
多すぎる位置指定引数について#
Qiskit Nature v0.5では、公開APIの特定の引数を キーワード専用 の引数にすることを義務付けるようになりました。この変更は、以下の利点が動機となっています。
可読性の向上: 以下の例では、与えられた引数が何をするのかがすぐにわかります。
前方互換性の向上: キーワード引数は順序に依存しないため、将来的に引数を追加することが非常に簡単になります。
つまり、移行作業中にインポートパスを更新するだけであっても、以下のようなエラーに遭遇する可能性があるということです:
以前#
from qiskit_nature.mappers.second_quantization import LogarithmicMapper
mapper = LogarithmicMapper(2)
ここで、インポートパスを新しい場所に更新すると、エラーが発生します:
from qiskit_nature.second_q.mappers import LogarithmicMapper
mapper = LogarithmicMapper(2)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-2-74b842b89d77> in <module>
1 from qiskit_nature.second_q.mappers import LogarithmicMapper
2
----> 3 mapper = LogarithmicMapper(2)
TypeError: __init__() takes 1 positional argument but 2 were given
このような場合は、使用しようとしているクラスのドキュメントを確認することをお勧めします。それは、引数を 位置的 な使用から、キーワードでの使用に変更する必要がある可能性が非常に高いです。例えば、以下のような感じです:
新規#
from qiskit_nature.second_q.mappers import LogarithmicMapper
mapper = LogarithmicMapper(padding=2)
予期しない軌道または量子ビットの数#
Qiskit Nature v0.5では、スタック全体を num_spin_orbitals
の使用から num_spatial_orbitals
の使用へと変更しました。この背景には、奇数のスピン軌道を指定した場合の動作が未定義であり、ガードされていないため、驚くべき結果を引き起こす可能性があるということがあります。空間軌道の数に切り替えることで、 (スピン軌道の合計数を得るために2倍される) この問題はもはや発生することはありません。
もし、予期しない軌道や量子ビットの数に遭遇した場合、入力を更新する必要があるかどうか確認してください。例えば、以下のような場合です:
以前#
from qiskit_nature.circuit.library import HartreeFock
from qiskit_nature.converters.second_quantization import QubitConverter
from qiskit_nature.mappers.second_quantization import JordanWignerMapper
converter = QubitConverter(JordanWignerMapper())
init_state = HartreeFock(num_spin_orbitals=6, num_particles=(2, 1), qubit_converter=converter)
print(init_state.draw())
┌───┐
q_0: ┤ X ├
├───┤
q_1: ┤ X ├
└───┘
q_2: ─────
┌───┐
q_3: ┤ X ├
└───┘
q_4: ─────
q_5: ─────
新規#
from qiskit_nature.second_q.circuit.library import HartreeFock
from qiskit_nature.second_q.mappers import JordanWignerMapper, QubitConverter
converter = QubitConverter(JordanWignerMapper())
init_state = HartreeFock(num_spatial_orbitals=3, num_particles=(2, 1), qubit_converter=converter)
print(init_state.draw())
┌───┐
q_0: ┤ X ├
├───┤
q_1: ┤ X ├
└───┘
q_2: ─────
┌───┐
q_3: ┤ X ├
└───┘
q_4: ─────
q_5: ─────