Orz日記 by Akio Morita

_ [SAD]閏秒データベース更新

現在、SADでの UTCと SAD epoch timeの相互変換には使っている libtai用の 閏秒データベースに 2008-12-31 23:59:60 UTCを挿入した。

これは、 閏秒対応の unix timeで運用している計算機のみが影響を受ける話だが、 年末までにはバックポートを済ますべきかな...

_ [SAD]SAD->MADX変換

変換時のモデリングと軌道・分散関数の再現性だが、 もっとも高い再現性を得る手法はEmittance[]から得られる TransferMatrices/ClosedOrbitに基づいてアフィン変換列を 作り、それを直接MADXのmatrix要素に使う手法である。

それを基準に、各要素をMADXの要素に置換した場合の 軌道・分散関数の再現性への影響

• 軌道再現性
  • DRIFT/QUAD/SEXTは大きな影響無し
    • ただし、LERの垂直シケインで軌道エラーが見える(matrix展開でも若干現れるので、MADXとSADの軌道計算モデルの差異が原因か？)
  • BEND/MULT等のK0パラメータを含むもの(hkickerへ展開する)は、NG
  • SOLの境界座標変換は影響無し
  • SOL/DRIFTをsolenoidへ変換すると再現性が桁で悪化する
  • SOL/MULTをsolenoid+multipole+hkickerへ変換するとSOL/DRIFTより影響が大きい(2〜3倍？)
    • 垂直方向の再現性への影響はSOL/MULT >> SOL/DRIFT〜SOL

• 分散関数再現性
  • BEND/MULT等のK0パラメータを含むもの(hkickerへ展開する)は、NG
  • DRIFT/QUAD/SEXTも地味に影響が出る＆影響の出方がバラバラ(分散フリーな直線部でμmオーダー)
  • SOLの境界座標変換は影響無し
  • SOL/DRIFTをsolenoidへ変換すると再現性が桁で悪化する
  • SOL/MULTをsolenoid+multipole+hkickerへ変換するとSOL/DRIFTより影響が大きい(2〜3倍？)

SOLの境界座標変換に関しては、Emittance[]の計算エンジンsrc/tsconv.f から持ってきているので当然の結果と言える。

現時点では、SOL内部のエレメント(DRIFT/BEND/QUAD/MULT)に関しては SAD側のモデルの転送行列を移植する以外の再現手段が無い。 (物理的な内容を反映したモデリングでは、軌道すら再現できない)

BEND/MULTで K0を含む場合の分散関数の発生や軌道の偏向の再現性に難がある。 おそらく、MADX内部の kickerのモデリングの問題がある＆ SADでは ANGLE依存の出入り口の座標変換と ANGLE+K0依存の軌道偏向計算を 取り扱っているためと思われる。

_ [SAD]64bitSADの可能性

gfortran 4.4でI/OのencodingにUTF-8がサポートされ、内部の文字列を UCS-4(kind = 4)で扱うことが出きるようになったらしい。

原理的には、8倍精度実数(kind = 32)と128bit整数(kind=16)が有れば、 real = 2 * integer = 8 * characterの関係を維持したままLP128化出来る。

問題は、8倍精度実数なんてものを実装したハードウェアが実在しない辺りかな...

4倍精度実数関しては、IEEE754rのドラフトベースのハードウェア実装が SunのSPARCやIBMのPOWERに有るらしいので、gfortranを改造して UCS-2(kind = 2)な内部表現をサポートしてもらえば、 4倍精度実数(kind = 16)と64bit整数(kind=8)と組み合わせて real = 2 * integer = 8 * characterの関係を維持したままLP64化出来る。