Orz日記 by Akio Morita

_ [SAD]最適化バグ？

GCC 4.2.4 20080430でビルドしたSADの動作がおかしいので設定を 調べていたら、どうやらベクトル化がらみの最適化でおかしくなる模様。 さて、誰が悪いのでしょう？

• GCCの最適化エンジンが腐っている
• SADに別名の参照等の問題が有るコードが含まれていて最適化の結果が保証されない

後者の場合は、言語側の要請を守らないコードが悪いという話になるのだが... この辺を自動的に検出するツールはないものだろうか

_ [SAD]GCC 4.2のバグの件

昨日のバグの発生条件は、 -O2以上の最適化レベルで-ftree-vectorizeを有効にすると 発生するようです。症状としては、以前に GCC 4.2.x + PowerPCで -O2時に不具合が発生すると報告が有った件と同じで、 Emittanceの計算結果がおかしくなる。

ちなみに、GCC 4.3.1 20080501では問題無い模様

_ [SAD]NPARA出力問題

追いかけ回せした結果だが、NPARA>1で並列処理に入るために fork(2)する際にFortran側の Output Bufferが Dirtyな場合、 fork(2)後の子プロセス側でも Bufferの書き出しが発生しているのが 原因の模様。子プロセス側では、write文は実行されないのだが 並列処理を合流させるために子プロセスがSTOPする際に Dirty Bufferが出力されているのかな？

対処法としては、fork(2)前に全ての Dirty Bufferを フラッシュすれば良いわけだが...効率的で移植性のある方法が有りません！

Fortran2003から実装された flush文は装置番号が必要だし、 引数なしで全てのI/Oをフラッシュするflushサブルーチンは ベンダ拡張なので存在が保証されない。また、新しいFortran規格では ストリームと接続可能な装置番号は0〜2^31-1までの整数に 拡張されているので、inquire文ですべて調べるコストは 極めて高いと思われる。

コード内のopen文に渡される装置番号をモニターして 最大値を割り出す必要があるか？ ただし、open文を使わずにwrite文へ未接続の装置番号を 渡して、デフォルトのファイル名で出力しているコードが有るとNG。 write文の装置番号も追跡しないといけないのか...Orz

_ [SAD]GCC 4.2.xサポートはダメっぽい

Fortran規格的に NGなコードのうち、標準規格で再実装可能な部分を 書き換える作業をしているのだが...GCC 4.2.xの Fortran2003サポートは ISO_C_BINDING Intrinsic Moduleが無いようです。 ということで、amorita branchでの GCC 4.2.xサポートは終了かな...

数学関数回りを考えると Fortran2008を使いたい(ガンマ関数とか ベッセル関数が標準入りしている)が、開発版の GCC 4.4で無いと 実装されていない罠

_ [SAD]SAD downloadエリアの自動更新

新しく書き直した amorita branch snapshot更新用のスクリプトが 調子良く動いているようだ

拡張モジュール類もすべて snapshot化して、メンテフリーにするべきか考え中。

Subversion repository用に書いたツールで、repository自体が 単調増加する revision numberを持っていることが前提になっているので、 CVS repositoryで管理されている MAIN trunkに関しては無理

_ [SAD]SAD downloadエリアの自動更新を強化

今まで自動更新だった amorita branchのソースの他に amorita branch側の Subversion repositoryから生成していた 各種拡張モジュールの tar.gzも自動更新にした。

これで、アーカイブ作りから開放されるぞ！ 後は、新モジュール実装時にアーカイブの生成規則を追加するだけ...

_ [LHC]β*ノブ高速化

IPの再マッチングを Corssing Bumpを下ろした状態で行えば 早いのではないとの示唆が有ったので、実装してみた

確かに劇的に早くなるのだが...外部への副作用増えてない？

と言うか、Qの変化量が全然大きいのですが... Orz

拘束条件より自由度が多い問題なので解の唯一性が無いので 同じパラメータに収束しないのは当然ですが、 収束先があまり嬉しくないような気がする

_ [雑記]また寒くなった

ここ暫く、天候に恵まれぽかぽかとした日が続いていたのだが、 寒さが戻った模様...

_ [LHC]軌道レスポンスからβを求める in Transport Line

な話が、持ち込まれて検討中。(厳密にはLHCではなく、CTF3の ビームトランスポートが合わないらしい)

フィット自体は走るのだが結果が思わしくないので、第一原理に戻って よく考えてみると、Transport Lineの場合周期境界条件が無いので、 β(s)/φ(s)が Beamlineの特徴量になっていない(Transport入り口の β(0),α(0)に依存する関数)ので、仮に軌道レスポンスのフィットが 成功してもそこから得られるβ(s)/φ(s)は、あるβ(0),α(0)を Transportに与えた際のβ(s)/φ(s)を得ていることになる。 (厳密には、任意定数λ,Cを含んだλβ(s)とφ(s)+Cが得られる訳だが...)

よく考えれば、当たり前のことだったりする

1. Dipole Kickによる軌道のレスポンスは、Beamlineの写像関数(Transfer Matrix)で決定される
2. β(s)/φ(s)は、Beamlineの写像関数(Transfer Matrix)とβ(0),α(0)の関数
3. 周期境界条件の元では、β(s)/φ(s)は Beamlineの写像関数(Transfer Matrix)のみで決定される

Transport Lineの場合は、三番目の条件が無いので、軌道レスポンスに β(s)/φ(s)をフィットする操作は、R^2の広さを持ったTransport Lineの β(s)/φ(s)の集合から一個の元を拾い上げる操作で、何らかの拘束条件を 課して固定しない限り、望みの解が得られる確率は激しく低い。

フィットの繰り返しの途中で、暫定解を拘束関数で変換するのが 一番簡単な実装と思われるが、線形変換(λ,C)の自由度があるので その変換は非線形変換か sに関して不連続な変換である必要が有る。 また、完全に拘束するには最低2自由度の拘束が必要と思われる。

_ [LHC][雑記]KEKB Linacで完成しているって話

シングルキックの軌道レスポンスを解析して KEKB Linacの Q Fudgeを 補正してモデルとマシンの一致が改善したという話が、 LCGのMLに流れているのは読んだのだが、内容的にはモデルでの 軌道レスポンスを実測したレスポンスへ合わせる Qパラメータを 推定しているようだ。この場合、多数のレスポンスから転送行列を 推定して、モデルの転送行列との差を補正していることになる。

インタラクティブなモデルが無く、静的なテーブルで渡される (MADXのTWISSテーブルダンプが標準みたい)という状況下で、 離散的なモニターの場所毎の光学関数のモデル値は既知だが、 モニター間の構造物の知識(Quadや Bendがどこに有るか)が無い場合に、 どうやって誤差を含んだマシンのレスポンスからマシンの 光学関数を復元するかという問題は、かなり厄介な気がする。

十分な数の位相の異なるレスポンスを集まれば、未知数と連立方程式の 数からは転送行列を決定出来はずだが、光学関数を復元には最低2個の 既知なパラメータ(最上流のα＆βなど)が必要だが、それ自体が測定が 必要な観測量なわけで... Orz

周期境界条件が無い場合は、光学関数はビームラインの固有量に なっていないから、それ指標にモデルと実測を比較して誤差を 論じようという考え自体に無理があるのでは無いだろうか？ (私が聞いたのは、「Transportのβを測りたい」という話なのだが)

_ [LHC]Transport Lineでのβ/φフィット

コアエンジンの内部で CELL/INSモードの切り替えを行わないように改造して、 位相差 φ(s)-φ(s')の符号関数を差し替えて可能にして、 Transport Lineも扱えるようにする作業は、先週のうちに終わっているので、 モデルからレスポンスを生成してはフィットエンジンの挙動をチェックする 作業を行う。

結論から言えば、ほぼ予測通りの結果

• 初期値に使うβ(s)/φ(s)が悪いと局所解に捕まってしまう(エラー無しのレスポンスの場合でも)
• 軌道レスポンスへのフィットが成功した場合(Residual -> 0)、得られるβ(s)/φ(s)はβのスケール変換とφの原点シフトの不定性以外に、β(0)とα(0)の不定性を含んでいる
  • 再構築されたβ(s)/φ(s)関数を再現するように、モデルのβ(0)/α(0)をパラメータとしてフィット可能
• フィットに成功しても、2個目のステアリングより前のβ(s)/φ(s)は出鱈目(決定に必要な情報量が無い)

実用上の障害は、β(0)/α(0)の不定性のため、 インタラクティブなモデルで無いと比較出来ない。

また、再構築された情報にはα(s)が含まれないために、それ自体だけでは β(0)/α(0)に合わせて変換することが出来ない。

メリットは、転送行列よりも情報量が少ないので再構築に必要な レスポンスセットが小さいことかな？(未知数と方程式数の比較から転送行列 の再構築には最低限4種類のレスポンスが必要だが、β/φなら3種類で十分)

_ [雑記]天候不順

朝は雨で寒かったのに、午後から日が出てきて熱くなってきたが、 まだ雲がかなり残っている。

_ [LHC]LIUWG(LHC Insertion Upgrade Working Group)の打ち合わせを聞く

2時すぎに始まって終わったのが5時半...長かったが結構面白い話題だった。 内容的には、Chromaticity correctionとか Off-momentum β beating correctionの話題

Arc部の SD/SFのファミリを組み替え＆セルの位相を調整して SDファミリに対して 2φ(s)を揃えて Off-momentum β beatingを補正するとか、 SD/SFの高次効果を抑制すれるという提案。 Arc単位でやってるみたいだけど、内容的にはKEKBの SD/SFペア毎に 転送行列を-I'にして高次効果を抑制してまま Chromaticity correctionする 話と同じ原理に思える。こっちでは Phasingとか呼ぶみたい

これの副産物で、SDが強くできる(Designパラメータの定格を越えているが)ので Arc部のバンプ軌道でIPの交差バンプが生成する Dispersionを補正可能になる らしい(正確には、許容出来る高さのバンプで補正できるだが)。

LHCの Design Latticeを見て気になっていたIPの交差バンプが作る Vertical DispersionとかHorizontal Dispersionの乱れだが、 スライドを見る限り 10年前から問題になっていたようだ

そんなに前から問題だったなら、なんでVertical Dispersion Suppressorが 入って無いんだろう？