ToDo:
です。SAD->MADX変換器のデバッグで転送行列を整形して表示するのに 使っていたら、指数部の下一桁が欠落するバグ (例えば、1.23456e-10が、1.23456e-1に化ける) が原因で、思いっきり時間を食った...Orz
つー訳で、amorita branchはRevision 2347で修正入れました。
あと、Emittance[]の返すTransferMatricesとClosedOrbitだが、 どうやらSOL領域は一個ずれているようだ。 原因は、src/tsole.fとsrc/tturne.fでの転送行列(iatr)と軌道(iacod)の 格納法の問題で、src/tturne.fではl番目のエレメントの 入り口の状態をリストのl番目の要素に保存したあとにエレメントの 転送行列を作用させているのに対して、src/tsole.fではl番目の エレメントの転送行列を作用させた結果をリストのl番目の要素に 保存しているので、SOLで囲まれた境界内部では、TransferMatricesや ClosedOrbitのインデックスがズレている。 これと同時に計算されるtwiss配列の更新では、 src/tsole.fではリストのl+1番目の要素へ格納するので整合する。 多分、格納コードをコピー&ペーストしたが 保存と転送の順番を入れ替えに対応してコードを書き換えるのを 忘れたと推測される。
修正は、Revision 2348で修正をコミットした。
アーキテクチャ的には、SOL領域内部の写像は ソレノイド磁場が0となる極限ではSOL領域外と一致するので、 単一のコードで処理すべきだと思う。
一つはこちら側のミスだが、残りはSADの実装バグに起因する Orz
SOL系のエレメントを転送行列近似に切り替えて様子を見ると
という、悩ましい結果に...
QCSL側で、まっすぐ通過している(LER) or 傾いている(HER)の違いが 現れているのだろうか?
別の可能性としては、Emittance[]の返す転送行列が先頭から 各エレメントまでのものなので、エレメント毎の行列を 行列積で計算することによる誤差混入とかSAD-MADX間の 座標系定義の差異とかが疑わしい。
座標系定義に関してはドキュメントをあたって定義を突き合わせてみる。
転送行列とCODをアフィン変換へ展開して、MADX内部で再度 転送行列とCODを計算する過程の演算精度が原因か?
次のステップは、SAD上でアフィン変換展開して後でCODの再構築での 再現精度を検証することかな?
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記