Orz日記 by Akio Morita

_ [雑記]UPS

本日、16時ごろ停電した際にFile ServerのOMRON製UPSが切替え失敗 Orz 過負荷?それとも寿命ですかね?(かれこれ、3.5年経ってるし...)

ちなみに、Nipronのノンストップ電源は 途切れなく電力を供給していましたw

_ [SAD]午前中の仕事が台無しに Orz

SAD Terminalから計算結果のグラフを描かせている際に、 tfcanvasclip.fが Segmentation Faultした

多分、ilistの多段参照のコードでこけているので 無効な参照を検証せずに使っているものと思われる

再現法

g0 = ListPlot[Range[10]];
Show[g0, g1];

で再現することから Show[]や Canvasクラスでの引数検査の不備？

不正な引数で関数がエラーを起こしてプロンプトに戻るのは問題ないが、 内部エラーで Segmentation Faultするのはかなり NGだと思う

_ [LHC]Transfer Matrix Reconstructionの評価

擬似乱数でノイズを乗せたテストベクターから Transfer Matrixを再構築して モデルと比較すると統計を貯めるのに時間がいくら有っても足りない (収束がとても遅い)ので、測定データー(テストベクター)にノイズが 乗っている状態で最小化している評価関数がオプティクスのエラーに対して どんな依存性を持つかを調べてみる。

外来ノイズが無い場合、オプティクスエラーが十分小さな領域では 評価関数は正の相関を示すが、外来ノイズの導入により オプティクスエラーへの依存性が消える領域に関しては オプティクスエラーの判別が不能になり、そこがオプティクスエラーの 検出限界になるはずである。

実際の最小化プロセスでは、極小点に落ち込む可能性があるので 上記の評価は最小化アルゴリズムがうまく動作したときの最大の オプティクスエラー検出能力の限界を制限することになる。

測定エラーのソースとしては、「測定値のばらつき」と「校正エラー」を想定する。

前者はガウシアン分布するサンプル毎のばらつき、 後者は軌道応答セット単位で共通なゲインエラー (軌道測定のタイムスケールで不変な測定系のシステマティックな校正エラー) としてモデル化する。

後者の分布関数をどうするかであるが、校正エラーの最悪値が保証される場合、 カット付きのガウシアン分布、放物線分布、均一分布などいろいろ考えられるが 今回は放物線分布で評価してみた。

ビームラインモデルは、手頃なモデルが無かったので KEKB HERを INSモードで 計算してアーク部で代用。 (定量的な評価を行うには、測定対象のビームラインモデルが必要だが、 定性的な性質の確認とオーダー評価ならこれで十分)

オプティクスエラーを Quadrupoleの ΔK/Kにノイズを入れることで模擬する場合、 測定ノイズ無しでは σ(residual) ∝ σ(ΔK/K)が成り立っている。 (σ(residual)は、軌道残差の標準偏差) また、Log-Logプロットで見る限り、オプティクスエラーのばらつきによる σ(residual)の広がりはオーダー1(一桁)である。

測定にノイズを導入すると、導入したノイズに応じて σ(ΔK/K) 〜 0側の σ(residual)に下限が現れる。σ(ΔK/K)非依存なノイズが合算されると 解釈してSqrt[(a * x)^2 + b^2]でFit[]して、誤差曲線がノイズ無しの 曲線に合流する点をLog-Logで読み取ると、 ±1e-3の校正エラーでおおよそσ(ΔK/K)〜6e-4、 ±1e-2の校正エラーでおおよそσ(ΔK/K)〜9e-3 となった。測定のばらつきを考慮するとさらに悪化すると思われる。

無次元量の相関係数のビームラインへの依存性が小さいならば、 1%の精度でオプティクスエラーを検知するには、 1%より良い校正精度が必要で 0.1%あれば十分であると 思われる。

_ [LHC]Crab Opticsの情報きた〜！

前々から、Crab Opticsのシミュレーションやらんかといわれていた話

やると言っておいたのだが、肝心のOpticsの素案が来てなかったのですが、 やっと届いた...

IPを挟む案と全周で Crabingさせる案と両方あるようです

最初の仕事は、最新の nominal optics modelベースで Crab Opticsの計算モデルを SAD上に構築するあたりかな？

_ [FreeBSD][雑記]in-kernel NATについて

in-kernel NAT試験でnatd + ipfw/divertとipfw in-kernel NATでincomming packetに対する挙動が異なる件だが、原因判明

sysctl net.inet.ip.fw.one_passが1(default)だと、natアクション作用後にパケットはipfwに戻ってこない

nat configでdeny_inオプションが指定されてない場合は、NATテーブルによる逆変換・redirectを受けなかったincommingパケットは破棄されず(deny_inなら破棄される)・ipfwにも戻らないので、inet層に届くことになり実質的に変換されないパケットにpassアクションが適用されたことになる Orz

divertアクションはsysctlによらずipfwに戻ってくる動作と比べると、分かりづらい挙動であるので要注意