Orz日記 by Akio Morita

_ [SAD]分離すべき関数

機能毎のSADScript関数の切り離しを行うために汎用で参照される関数を 分離する必要がある

取り合えず、現時点で判明している範囲は次のとおり

• src/tfFileIO_.c
  • cfexptilde_
  • expand_tilde
• src/tfDynamicLink_.c
  • dl_* MI backend
• src/tfBuildInfo_.c.in
  • sadpkgdir_
  • check_build_info
  • sad_pkg_root,build_info_table等のデータベース

作業方針

• cfexptilde_は、src/utils.cに収容(Fortran用だし)
• expand_tildeは、src/sim/sad_api.cへの収容が妥当かな？
• dl_* MI backendは、src/sim/dynl-mi.c辺り？(プロトタイプヘッダは、既にsrc/sim/dynl.hがある)
• BuildInfoに関しては、Feature系同様に独立したframeworkにする(src/buildinfo.[ch]かな？)
• sadpkgdir_は、src/utils.cにてframework呼び出しで実装すべき

多分、src/sim/unix_env_.cの中身も src/utils.cと同じく Fortranコードへのユーティリティー類なのでマージすべきかな？

_ [SAD]SAD->MADX変換

変換精度が出ないエレメントをEmittance[]からtransfer matrixを切り出して matrixで埋め込む作業を始めたのだが、絶賛嵌まり中

SOL内部でSOL/MULT/SOL/MULT/...なチェーンが組んであるとき、 SOLは厚みが無いので、次のMULTの入り口と同じ状態にないと いけないはずだが、Emittance[]から切り出した ClosedOrbitとTransferMatricesは、一つ前のMULTの入り口と同じ値に見える。 多分、SOL内部の計算がtturneからtsoleへ移譲されているが、 演算結果の格納形態が完全互換になっていないように思える。 こいつは、ソースコードを要確認。

取り合えず、次のエレメントを探すコードをハックしてSOL内のMULTを matrixへ展開してみたのだが...結果が全然違う Orz

何が起こっているのだろう？

取り合えず、次の課題は...

• matrixへの展開コードの健全性を別のエレメントで検証する
• SOL内部の転送行列とビーム行列の変換と格納コードを検証する
• 現在省略している DRIFTエレメントのパラメータ展開をサポートする(SOL/DRIFTに転送行列を渡す必要が...)
  • 別案としては、軌道と転送行列を返すハッシュ関数への参照を渡すと言う解も有り