トップ «前の日(07-16) 最新 次の日(07-18)» 追記

Orz日記 by Akio Morita

ToDo:

  • 15 SAD Fit[]回りの障害事例の解析
  • 10 smart pointer版PEGクラスの再実装(Left Recursionまわり)
2006|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|06|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|09|10|11|12|
2013|01|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|06|07|08|10|12|
2016|01|02|03|05|06|08|10|11|
2017|01|02|03|04|05|06|07|09|10|11|12|
2018|01|02|03|04|06|07|08|09|10|11|12|
2019|01|03|04|05|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

2008-07-17

_ [LHC]Transfer Matrix Reconstruction in Transport Line

アルゴリズムレベルのバグ見つけた Orz(てか、最初に気付けよ)

近接する BPM間の Transfer Matrixをデータとして保持している場合、 一部のデータに不良がある際の処理が面倒&転送を繰り替えした際の 丸め誤差の蓄積がいやらしいので、基準点から BPMへの Transfer Matrixで 保持することを考えたのですが...

この場合、基準点での位相空間を軌道情報と Matrixの(1,1)成分と (1,2)成分を 使って復元することになり、これを各BPMでの軌道に焼き直すのにも (1,1)成分と (1,2)成分を使う表現になる。 つまり、行列式の拘束条件が有っても 1自由度余っている。

BPM間の Transfer Matrixでデータを保持しても、等価な情報量なので 1自由度分拘束が不足していることになる。

改めて表現型を整理してみると当り前だよねぇ

と言う訳で、結論としては使えないということ。

なぜ模擬データでそこそこ動いるように見えるかだが、 おそらく共役勾配法のアルゴリズム的にゲインが無い方向へは無理に 坂を降らない&初期値はモデルにランダムなエラーを加えた物なので 未拘束の自由度に入るエラーもランダムであり初期のエラーが大きく なければ収束後の値は十分正しく見えると言う辺りが真相だと思う。 (初期エラーが大きいと別の極小点にトラップされるし...)

_ [SAD][LHC]Crab Optics作り

  • V6.503のMADX->SADコンバート
  • Crab Cavityを挿入するツールの準備
  • Design Reportなどから nominal beam profileのデータの抜きだし

は完了したので、擬似乱数でビーム分布を生成して Trackingテスト開始... したものの一周目で全部ロスした。 Orz

Element by Elementで Tracking結果を調べた結果、MADXから変換された APRTエレメントでロスしていることが判明。 アパーチャのパラメータ変換時の問題かデフォルト値が悪い? 確かに、DX1などは0なのだが...SAD版では、 パラメータは未定義になっている。 実は、APRTエレメントのデフォルトは全閉なのか?

Crabing Angle

モデル上の Crab Cavity Voltageを計算するとキック電圧が 数GVというあり得ない数字が...(一体何台並べれば実現する?)

落ちは、Crossing Angleの単位が間違。 届いたメールには、Crossing Angle 285mradって書いてあるんだよね Orz

_ [LHC][SAD]LHC Opticsでの Tracking

APRTエレメントに明示的にアパーチャを設定して、Trackingする。 一応動くのだが Transverse方向の重心が振動して、暫くすると分布の端の 方から分布が変形してロスしてしまう。ロスする原因はダイナミック アパーチャだと思うが、重心が振動するのは NGだよな... RADCOD付きの Emittance[]を見る限り EMITモジュールの計算する CODと一致していないようなので、統計を貯めて Trackingでの平衡点を 求める必要があるようだ Orz

_ [SAD][LHC]Tracking上の COD

TrackParticles[]時の重心が振動するのはうれしくないので、いろいろ調べる。 KEKBの latticeでも行ったが、Emittance[]の OrbitAtExitや Twiss[]の DX,DPX,DY,DPYで軌道にオフセットを乗せても消えない。 KEKBの時はダンピングに任せて目分量である程度オフセットを入れた分布を ぐるぐる回してダンピングした後の分布をそのまま使ったのだが、 今回は真面目に定常状態を探してみる。

まずは、NORADで放射減衰を止めて横方向の振動のみを考える。 様子見のために原点(0,0,0,0,0,0)を TrackPatricles[]すると綺麗な ベータトロン振動のカーブが現れた。起点は、IR部の vertical bendあたりを 起点にして、horizontal/verticalに振動が励振されている。 この領域にはカップリングが有るので両方励振される事自体は不思議ではない。 ここで、出発点を変数にしてTrackParticles[]で一周したときに出発点に 戻る閉軌道を共役勾配法で探してみる。確かに見つかるのだが、 Emittance[]や Twiss[]で求めた位置と大分ずれてる。 (例えば、DXが 200μm違う) このTrackParticles[]関数の閉軌道を描いてみると...なんか10mmオーダーの 振幅を持った軌道で、OpticsPlotの DX/DYのチャートと似ても似つかない 形をしているのですけど... Orz

これは、原因をきちんと確かめないと使えない予感

可能性としては、高次項の影響などがあり得るけどここまで差が生じる物で あろうか? K2より上の磁場やエレメントの非線形効果、フリンジ回りを OFFにして テストする必要ありかな?


カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記