Orz日記 by Akio Morita

_ [FreeBSD]X.Org 7.3

X.Oorg 7.3にアップグレードしたら Synaptics TouchPad(x11-servers/synaptics)が動かなくなって Orz

日曜日に原因究明をする羽目に....

原因は、xorg-server-1.4での xf86ProcessCommonOptions()の仕様変更で エンバグしてるように見えるのでパッチパッチ

--- hw/xfree86/common/xf86Xinput.c.orig	2007-08-23 21:04:30.000000000 +0200
+++ hw/xfree86/common/xf86Xinput.c	2007-09-17 01:48:58.000000000 +0200
@@ -116,10 +116,10 @@
 xf86ProcessCommonOptions(LocalDevicePtr local,
                          pointer	list)
 {
-    if (xf86SetBoolOption(list, "AlwaysCore", 0) ||
-        !xf86SetBoolOption(list, "SendCoreEvents", 1) ||
-        !xf86SetBoolOption(list, "CorePointer", 1) ||
-        !xf86SetBoolOption(list, "CoreKeyboard", 1)) {
+    if (!xf86SetBoolOption(list, "AlwaysCore", 0) &&
+        !xf86SetBoolOption(list, "SendCoreEvents", 0) &&
+        !xf86SetBoolOption(list, "CorePointer", 0) &&
+        !xf86SetBoolOption(list, "CoreKeyboard", 0)) {
         xf86Msg(X_CONFIG, "%s: doesn't report core events\n", local->name);
     } else {
         local->flags |= XI86_ALWAYS_CORE;

_ [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化出来る。

_ [艦これ]Phoenix堀

E5乙 ZZマスを軽量編成・支援無しで採掘中

Oマスでの火力枠として金剛を起用

瑞鶴改二甲/翔鶴改二甲/初月改二/羽黒改二/CommandantTeste改/日進甲

矢矧改二乙/金剛改二丙/雪風改二/時雨改三/潮改二/妙高改二

やはり鬼門はZマスで、現時点の統計では突破率50%前後

Pマスの一発大破に関しては、防空装備とZマス用ダメコンのトレードオフになっている気が…