使用 Fujitsu backend 運行的結果

[IvanaGyro]

下圖是批次運行，同時運行四十份，然後把四十份的結果疊合在一起的圖，基本上是完美疊合。

但是與下圖關閉 measurement 直接計算機率所得到的圖卻相差很大。

用 Fujitsu backend 跑出來的圖在到時間為 8 之後，能量又開始往上，我猜可能跟福點數的經度有關，因為我把變化的時間從 10 改成 40 就遇到如下的錯誤訊息

    target_decomposed = TwoQubitWeylDecomposition(target)
  File "/home/group112/g112-user4/.cache/pypoetry-arm/virtualenvs/qmps-for-fujitsu-CC07Gzsh-py3.9/lib/python3.9/site-packages/qiskit/quantum_info/synthesis/two_qubit_decompose.py", line 183, in __new__
    raise QiskitError(
qiskit.exceptions.QiskitError: 'TwoQubitWeylDecomposition: failed to diagonalize M2. Please report this at https://github.com/Qiskit/qiskit-terra/issues/4159. Input: [
  [(-0.5258339870473885+0.794402033690546j), (0.24352475089756823-0.18035174405978865j), (0.010457038400443621+0.016830667668531446j), (0.004127337650874234+0.01353939092750919j)], 
  [(-0.017921311710546492-0.02752535900430884j), (-0.007315737684729296-0.022293247581944522j), (0.8459484614818802-0.060968145148024566j), (0.528012511410616+0.015084623963678712j)],
  [(0.041546269898369+0.2527287305255189j), (-0.153327847161022+0.7940846767091234j), (0.2344539143255262-0.1716807818997542j), (-0.35693893747962063+0.26167510355376633j)],
  [(0.03925450894776285+0.15558402194369855j), (-0.04495960581072819+0.5015148717190075j), (-0.2976671633388935+0.32743365102090327j), (0.5579105264764727-0.4622028466255367j)]]'

[IvanaGyro]

@hunghaoti

把 np.random.seed() 刪除之後（修正 #6 提到的其中一個問題），並把終止時間拉到 30，利用 Slurm 的 sbatch 同時執行多的程序後，把每個程序的結果畫在同一張圖上。可以看到結果非常地不穩定。大部分時候會在時間 8 以前落到最低點，各自落到最低點的時間點都不太一樣。

下面是刪除的 np.random.seed()

qmps/qite/src/qite_qiskit.py

Line 357 in 9fb8dc4

np.random.seed(0)

master 分支上則是在這兩個相對的位置

qmps/qmps/loschmidts/real_dev_submit/20230711/src/qite_qiskit.py

Line 269 in 27f37bd

np.random.seed(3)

qmps/qmps/loschmidts/real_dev_submit/20230711/src/qite_qiskit.py

Line 297 in 27f37bd

np.random.seed(0)

random.seed() 的作用

np.random.seed() 不應該被以常數呼叫的原因是，一但給予固定的常數，所有的亂數都會從系統中固定的亂數表的固定位置開始依序產生，所以每次執行程式所得到的亂數順序會一樣。

有 np.random.seed(0) 的範例

n.py

import numpy as np

np.random.seed(0)
print(np.random.rand(10))

執行兩次的結果

$ python n.py
[0.5488135  0.71518937 0.60276338 0.54488318 0.4236548  0.64589411
 0.43758721 0.891773   0.96366276 0.38344152]
$ python n.py
[0.5488135  0.71518937 0.60276338 0.54488318 0.4236548  0.64589411
 0.43758721 0.891773   0.96366276 0.38344152]

沒有 np.random.seed(0) 的範例

no.py

import numpy as np

print(np.random.rand(10))

執行兩次的結果

$ python no.py
[0.42981144 0.24336349 0.18485169 0.30104523 0.98099416 0.38252797
 0.10058648 0.99645028 0.65859209 0.44029993]
$ python no.py
[0.70899081 0.21834205 0.64895002 0.55457108 0.27785367 0.03751844
 0.72017198 0.87306548 0.10425161 0.06039664]

[hunghaoti]

當初固定random seed是因為想要讓state的初始狀態一樣，後來直接改為所有params為1，可能後來忘了刪除。不過我也很意外固定random seed會讓他所有用measurement方法測量的結果都一致。

[IvanaGyro]

關掉 measurement ，直接計算機綠，並且刪除把 random generator seed 設定成常數的程式碼之後，的結果如下。

大致上穩定，不如用 measurement 那樣大幅跳動且有時候會 minimize 失敗，但其最後面定態還是有些差距。

[harui2019]

當初固定random seed是因為想要讓state的初始狀態一樣，後來直接改為所有params為1，可能後來忘了刪除。不過我也很意外固定random seed會讓他所有用measurement方法測量的結果都一致。

關於 np.random ，我之前知道的部分是Numpy官方和社群並不推薦這個function運行在多線程的子程序，因為多個子程序的會引用到相同的亂數表造成重複的結果，我之前在處理平行化計算時就有遇到這個問題，我自己目前的做法都是讓random先運作在平行計算之前。再把準備好的隨機結果分發進子程序運作。

[IvanaGyro]

這確實是個問題，我沒有想到這件事。但有沒有相關連結，我想可能需要一個底層的解決方案，或是要從外部另外給每個 job 注入不同的 seed？

[harui2019]

這確實是個問題，我沒有想到這件事。但有沒有相關連結，我想可能需要一個底層的解決方案，或是要從外部另外給每個 job 注入不同的 seed？

numpy/numpy#9650
連結在這

從外部給每個process注入不同的random seed可能是解決辦法，不過我還沒有試過所以不確定