Orz日記 by Akio Morita

_ [SAD]SAD->MADX変換

LHCの latticeを MADX->SAD->MADXと round trip変換したものを MADXで計算した結果が、オリジナルとほぼ一致するところまでは 実装出来た。(エレメントの情報量が全単射な変換ではないので round trip変換が恒等写像にならないため)

KEKB latticeの変換はアーク部に関しては、quadrupoleの fringeが MADX側に無いために betatron tuneがずれるようである。

IR部を含んだ変換は、twissパラメータの計算が収束しない模様

おそらく、DX/DYの処理と K0/SK0で軌道を変えずに dipole fieldを 入れるための小細工が必要と思われる。(MADXの multipoleの 0次項は bendと同様にデザイン軌道を曲げるらしい)

QUADのF1/F2サポートは、quadrupoleの前後にmatrix(2次までの写像を 記述できるエレメント)を貼り付けて、SADのlinear fringeの項を 加えるしかないか...

まあ、どんなSAD latticeでも変換できる変換エンジンとしては

1. TrackParticlesで写像を微分して全部 matrixへ変換する(2次までは正しいはず)
2. MADXを改造して SADのエレメントをまるごと実装する
3. SADに MADXの台本やコマンドを直接読める皮をかぶせる

2と3の方法は、本質的にはMADX互換のインターフェースを持ったSADの オプティクスモデルである。 多分、MADX版の latticeが欲しいと言う人間は、SADとMADXの信頼性や 精度を比較して MADXを使いたいと言っているのではなく、単に MADXしか使えないからだと思われるので、それなら UI部が MAD互換で ありさえすれば中身のコードは別に MAD由来でなくても良いはずだよね？

少なくとも、Makefileで使う perlスクリプトが source repositoryに 含まれて無かったり、テストセットが付属していないという意味では MADXがSADよりも良くテストされているとは思えないのだが...

コードの規模が小さいと言う意味では、本格的なテストを実施しやすい 素養はあるが、定期的に実施し結果を公開していなければ意味が無いし (外部ユーザーから見た信頼性という意味で)、コードの小ささは 機能の少なさの裏返しだし...

MADXのエレメントパラメータに一貫性が無いのはなぜだろう？ rbend/quadrupole等ではlength = 0が使えないのに、multipoleは lengthを指定できないとか... Orz