ToDo:
最近需要があるらしい が、掲示板で話題になったことは無い辺りがなんとも...
GUIが無いと操作できない人相手に、Cygwinのインストールや SADのコンパイルをサポート出来る体制では無いと思うのだが...
amorita branchに関しては、メンテナーに名乗りを上げる人がいない限り 期限切れで cygwin用のコードは廃止する予定
使用する軌道応答の数を6から 30まで増やしても、Transfer Matrixの 初期値に誤差を入れた際に収束先がバラつく問題は改善しない。 Transfer Matrix間の距離(行列のノルム)だが、確かに モデルから出発したものと誤差を入れて出発したものの間で 収束後に距離があるのは確かなのだが、出発時の距離から 桁で小さくなってる(接近してきている)。また、Transfer Matrix自体の ノルムを基準に相対距離を見ると1e-7オーダー、応答軌道の フィッティングでの残差は1e-10m台(一部の steering/BPMの組み合わせで1e-8m) なので、評価関数(残差２乗和)を評価する際の有効精度の限界に当たっている？ その場合、真の解周辺にある2次形式な極小が浮動小数点表現の 桁落ちや演算誤差でデコボコしていて、入ってくる経路に依存して 停止位置が変わっていると解釈できる。 少なくとも、初期値に導入する誤差を大きくしていった際に、 あるしきい値を越えると収束後の残差２乗和が有意に劣化して まったく別の極小点へ収束するようになるので、 大域的にはうまくいってるのかな？ (精度が測定の要求に満足するかは別問題だが)
現在は、測定データ側にランダムエラーを入れた際の収束性を検証中
それなりに、使い物になりそうなら、入出力部を書いてプログラム化
なんか、MAIN trunkに Cygwin用の変更が入っているが、 見るからに uglyなコードですねぇ
MacOSX上の VMwareで動かす Cygwin on Windosから MaxOSX上の File Systemを見ると:が%003Aに化けるそうだが、 VMware3の頃と同様にホストOS側とゲストWindowsのFile System共有に SAMBAを使っているのなら SAMBAの HEX codingが原因に思えるのだが...
だとすると、環境側の問題なので取り込むべきでは無いよね
もしも、Cygwin上で展開したFile Name Space上の:文字が 化けるとしたら、File System層のエミュレートにバグがあることになる
WindowsのローカルなNTFSを bin modeで Cygwin側にマウントしている 状況で、Cygwinな bashからecho foo > bar:zooを実行すると barというファイルが出来る。つまり、:から先の PATH名が 無視されている。unix互換じゃないぞ！(2008-07-08追記)
以前、MacOSX上で shellからでは無く GUI付きのMacアプリな展開ツールで tar.gzを展開すると:が別の文字に変換されるという事例に 遭遇したことがある。 MacOSの PATH Separatorは :だが、unix側のAPIを使うと(unix shell等) unix API側で:と/を入れ替える変換を内部的に実施しているが、 昔ながらのMacOS API(おそらく Carbon)ではそのような変換を行わないので アプリ側が変換しているのが原因だった。
実在しないファイルの依存関係が commitされている
make dependするときは、cleanな source treeで行いましょう
uglyですねぇ...
ucontext_tに関しては、SUSv2/POSIX.1-2001辺りに有るらしいし、 sigaction(2)で POSIX SA_SIGINFOなハンドラが使える場合は 第3引数が ucontext_t*なのでその定義が必要で、 SA_SIGINFOマクロが未定義という問題が出ていない以上、 環境依存のucontext_t型を定義するヘッダーは存在しなければならないはず。 したがって、無いのは全面的に Cygwin側が悪いような気がする。
SA_ONSTACK/SA_NOCLDWAITが未定義な際に、 0以外の定数マクロを定義するのは、移植性的に NG。 フラグビットの位置は環境依存だからこそ、マクロで定義している訳で、 これを未定義だからと言って環境を考慮せず 0以外の定数にすると どんな副作用があるか分からない。
そもそも、フラグマクロが未定義ということはサポートされていないと言う ことなので、src/tfProcess_.c側で SA_ONSTACK/SA_NOCLDWAITフラグを 操作するコードを #ifdefで無効化すべきところ
IPv6をサポートするための Address Family Independent APIなのですが、 IEEE Std 1003.1-2004(POSIX.1)/RFC 3493らしいので、無いのは Cygwinが悪い。 あと、この手の未実装APIを独自の実装で置き換える場合、 移植性を考えると呼出側に埋め込まずに APIの実装を別ファイルにして リンク時に組み込みを制御すべきところ(置き場的には、src/simの下かな？)
Cygwin/w32api 1.5.25-15 IPv6 extension0.22なんてものが有るらしい。 つまり、Cygwinの libcは IPv6未対応ということ(2008-07-08追記)
SA_ONSTACK/SA_NOCLDWAIT機能フラグは、 SigAction関数がユーザーに提供しているだけなので、 Revision 2209にてSA_ONSTACK/SA_NOCLDWAITマクロが 未定義の場合は、当該フラグのサポートしないようにした。
具体的には、sigaction(2)に渡す環境依存フラグを組み立てるコードで 関連する部分を ifdefで無効化しています。
他のSA_*マクロが無い場合の同様の処置が可能なはずだが、 SA_SIGINFO/SA_RESTART/SA_RESETHANDに関しては SAD側の SIGFPEハンドラ等の実装に使ってるので必須です。
他の部分に関しては、昨日の日記にも書いたけど Cygwin側の POSIX機能の実装が不足しているのが原因なんで Cygwin環境側で 対処すべき問題だと思う。
sigaction(2)で、SA_SIGINFOを使えるようなので、 POSIX SA_SIGINFOなハンドラのプロトタイプ void handler(int, siginfo_t *info, ucontext_t *uap) が使えるはずなので、環境依存なucontext_t型の定義を 行うヘッダーファイルが存在するべきなのだが... Orz
また、Cygwinに getcontext(3)が存在しないとの情報も有るので、 User Thread Context自体がサポートされていないと思われる。
POSIX SA_SIGINFOなハンドラは、第3引数経由で割り込み時の User Thread Contextを受け取ることになっているので、 sigaction(2)がSA_SIGINFOなハンドラを受け入れる以上 getcontext(3)やucontext.hが未実装なのは SUSv2的に NG。
SUSv2的には、前出のSA_ONSTACK/SA_NOCLDWAIT機能フラグが 存在しないのも NGなのだが...
Cygwinの IPv6 APIの実装が不足している。
外部プロジェクトで、実装を 進めている人々がいるので、その成果物をインストールするか、 自前で RFC3493を実装すべし
仮想マシン上で、母艦のファイルシステムを使う場合は CIFS等の ネットワークマウントに於ける名前空間変換の問題がある。
Cygwinで NTFSをローカルマウントした際に":"キャラクタと パス名に使用できないのは、Cygwinの実装上の制限と思われる。
軌道応答に対してTransfer Matrixを当てはめる動作原理自体には 問題は無いようなので、ツール形式のものを作成＆テストベクターを 作って入出力の検証を開始。
ラフなテストでは、エラーに対する感度がβ関数のフィットよりも 厳しいような感触なのが気がかりだが、それ以上に致命的なのが 実行速度で、テストデータで共役勾配法が収束するのに手元の NotePCで2時間以上かかる。
βのフィットが数分のオーダーで終わることを考えると100倍程度遅い。 使っている軌道の本数の差を考慮しても 20倍以上遅いので、 オンラインでの使用には厳しいだろう。
ただ、問題の次元数を考えると当然の結果かもしれない。 β関数のフィットの場合、軌道に摂動をかけるステアリング側の β関数と位相関数をパラメータにして計算しているのに対して、 Transfer Matrixのフィットでは各BPMに 3自由度 (実際には4自由度＆行列式への拘束条件)を与えて計算しているので 「BPMの数 / 軌道の数」の比で演算量が増えている。 それなりに実用的な条件を想定すると、「BPMの数 >> 軌道の数」が 成立するので、激しく重くなる。
SAD Terminalから計算結果のグラフを描かせている際に、 tfcanvasclip.fが Segmentation Faultした
多分、ilistの多段参照のコードでこけているので 無効な参照を検証せずに使っているものと思われる
g0 = ListPlot[Range[10]]; Show[g0, g1];
で再現することから Show[]や Canvasクラスでの引数検査の不備？
不正な引数で関数がエラーを起こしてプロンプトに戻るのは問題ないが、 内部エラーで Segmentation Faultするのはかなり NGだと思う
擬似乱数でノイズを乗せたテストベクターから 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 opticsのアップデートを追いかけるべく、変換作業を行っていたのだが なぜかLHCB2がうまく変換できない。 Drift Element挿入時に Element順序に矛盾が発生するというエラーで 3時間ほどコードを彷徨うハメに...
原因は s座標の変換に伴う丸め誤差と厚み0のElementのコンボで ソートに失敗するという物。しかも、サブルーチン毎に入力ビームライン情報を ソート(不完全な入力データ対策)していて、最初の変換用の中間データを 抽出している部分を直しても最終結果が直らなかったので、かなり悩んだ Orz
Tkinter導入過渡期に、python/tkinterを呼び出すために埋め込まれていた SADへのPython組み込み機能をamorita branchから削除しました。
削除理由は
などです。 要するに、長らくまともに動いていない＆声が上がってこない機能なので 切り離しても良いだろうという判断です。
通信量が多いとか内部データ構造へのアクセスや内部APIを叩く必要が無けれ ば、外部プロセスとして pythonを立ち上げてpipeや network経由で 通信で十分だと思うのですが、どうでしょう？
もしも、SADに Pythonインタープリターを組み込む必要が再び出てきたなら、 界面設計あたりからやり直して dynamic loading moduleで実装すると 言うことで...
MADX->SAD変換後の latticeをロードしてβ-Knobパネルを立ち上げると opticsが変に乱れていたので、MADXの計算結果と比較しようとすると V6.501の latticeは計算出来るのに V6.503だと negative drift in front...などといって計算してくれない。
どうやら、古い MADX(3.04.03)では計算出来ないようです。 最新の 3.04.40だと動くようなので、新機能を使ったか 3.04.03のバグを 踏んだか...
Sequence fileの先頭に要求 Versionを描いておいて欲しいと思う。
で、スタンドアローンで SAD版の latticeから抽出した twissパラメータは MADX版と一致する(latticeを反転させるモード(bv flag付き)だと sとか yの符号が変わりますが)ので、暫く悩むことに...
原因は、V6.503の古い日付のバージョンと最新の V6.503で K値の min/maxの 制限値が変更になっていたのが原因でした。
と言うより、そういう変更したら minor versionとか patch levelを 変えて欲しい。
現場レベルでの Revision Controlや Configuration Managementが 機能していないのは世界共通なのかな？
アルゴリズムレベルのバグ見つけた Orz(てか、最初に気付けよ)
近接する BPM間の Transfer Matrixをデータとして保持している場合、 一部のデータに不良がある際の処理が面倒＆転送を繰り替えした際の 丸め誤差の蓄積がいやらしいので、基準点から BPMへの Transfer Matrixで 保持することを考えたのですが...
この場合、基準点での位相空間を軌道情報と Matrixの(1,1)成分と (1,2)成分を 使って復元することになり、これを各BPMでの軌道に焼き直すのにも (1,1)成分と (1,2)成分を使う表現になる。 つまり、行列式の拘束条件が有っても 1自由度余っている。
BPM間の Transfer Matrixでデータを保持しても、等価な情報量なので 1自由度分拘束が不足していることになる。
改めて表現型を整理してみると当り前だよねぇ
と言う訳で、結論としては使えないということ。
なぜ模擬データでそこそこ動いるように見えるかだが、 おそらく共役勾配法のアルゴリズム的にゲインが無い方向へは無理に 坂を降らない＆初期値はモデルにランダムなエラーを加えた物なので 未拘束の自由度に入るエラーもランダムであり初期のエラーが大きく なければ収束後の値は十分正しく見えると言う辺りが真相だと思う。 (初期エラーが大きいと別の極小点にトラップされるし...)
は完了したので、擬似乱数でビーム分布を生成して Trackingテスト開始... したものの一周目で全部ロスした。 Orz
Element by Elementで Tracking結果を調べた結果、MADXから変換された APRTエレメントでロスしていることが判明。 アパーチャのパラメータ変換時の問題かデフォルト値が悪い？ 確かに、DX1などは0なのだが...SAD版では、 パラメータは未定義になっている。 実は、APRTエレメントのデフォルトは全閉なのか？
モデル上の Crab Cavity Voltageを計算するとキック電圧が 数GVというあり得ない数字が...(一体何台並べれば実現する？)
落ちは、Crossing Angleの単位が間違。 届いたメールには、Crossing Angle 285mradって書いてあるんだよね Orz
APRTエレメントに明示的にアパーチャを設定して、Trackingする。 一応動くのだが Transverse方向の重心が振動して、暫くすると分布の端の 方から分布が変形してロスしてしまう。ロスする原因はダイナミック アパーチャだと思うが、重心が振動するのは NGだよな... RADCOD付きの Emittance[]を見る限り EMITモジュールの計算する CODと一致していないようなので、統計を貯めて Trackingでの平衡点を 求める必要があるようだ Orz
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にして テストする必要ありかな？
サーバーのログに
Jul 18 13:12:53 **** powled[1122]: AC line fault happens. Jul 18 13:12:53 **** powled[1122]: Shutdown start within 60 Seconds. Jul 18 13:13:05 **** powled[1122]: AC line recover.
なる記録が...瞬停でも有ったにしては少し長い。 施設側の保守に伴う停電にしては短いような。
昨日の件だが、原因究明に向けて鋭意調査中
現時点で判明してること
状況的に、MULTエレメントの tracking engineが怪しそうだが horizontal軌道の不一致の原因が分からない...
来週のタスクは、系統的なlocal bumpサンプルを集めて比較かな？
不一致を引き起こすエレメントの共通点が確認出来たら、 短い test latticeを組み立てて再現性の確認と tracking engineのフロー解析を行う。
SAD上のLHC latticeで TrackParticles[]と Twiss[]で求めた軌道を比較して結果
| Switch | K0 | SK0 | DX | DY | MULT | COD |
| on_x1 | o | o | x | o | o | NG |
| on_x2 | o | x | x | o | x | OK |
| on_x5 | o | x | o | x | x | OK |
| on_x8 | o | x | o | x | o | NG |
どうやら、CODの不一致の原因はMULTエレメントで軌道を 蹴っているかどうかに依存している模様
にもかかわらず、(MARK DRIFT MULT DRIFT)なビームラインでは TrackPatciles[]とTwiss[]の軌道が一致している...なにゆぇ Orz
もう少し、Ticketのタイトルを考えてほしい気がする。 おそらく本人も後から見ると内容が想像できないと思うのだが...
これ自体は、Ticket-16 同様に明文化されていない仕様なのだが、このレベルの話は amorita branchの ITSに上げても誰も議論に参加しないと思う。 直す気があるのなら、SAD掲示板で声を上げないと...
src/tturn.f辺りから糸を辿って src/tdrift.fのコードのバグで ある所までは同定した。現在、場当たり的な変更を加えて結果を検証中。 きちんとした修正には、分岐条件の検討が必要と思われる。
ANGLEパラメータの無い BENDは src/tquad.fの tthin()に 流れ着くのに、K0,SK0のみのMULTだと src/tdrift.fの tdrift()に流れ着く不思議。同じ結果を期待されるコードが複数箇所に 個別の実装として存在するのは、保守性と言う側面ではかなり不味いと思う。 (プリプロセッサ等を使って、単一の雛形を展開したものが複数箇所に 存在するのは問題無いのですが...)
tdrift@src/tdrift.fで alが0の時に ak0xやak0yが反映されないバグを修正 (Ticket-19)
手元の LHCB1 latticeでは CLAC/Twiss[]で求めたCODに対して TrackParticles[]で求めたCODが $10^{-15}$オーダーまで一致するようになった。
Trackingに必要な時間の見積り用にベンチマークを取ってみた(Rev.2230)
| CPU | NORAD/NPARA=1 | NORAD/NPARA=2 | RAD/NPARA=1 | RAD/NPARA=2 |
| CoreDuo2 T7200 @ 2.0GHz | 1.775 | 0.907 | 3.628 | 1.841 |
| CoreDuo L2300 @ 1.5GHz | 2.909 | 2.001 | 6.629 | 3.921 |
| Opteron 242 @ 1.6GHz | 2.049 | 1.059 | 3.769 | 1.916 |
単位は msec/turn/particle @ LHCB1
メモリ使用量は、100MB程度なので純粋に CPU/Cache/Memoryの速度で 律速されていると思われる。
NORAD時に NPARA=1とNPARA=2のTracking結果が同一に なることを確認した。したがって、processor coreが余っていれば NORADの計算に関してはNPARAでレイテンシイを短縮できる。
疑似乱数列から単純に生成すると、粒子数の有限性から各種モーメントが 残留する(平均や相関)。
対処法としては
辺りがあると思うが、一長一短。 (1)は、$1/\sqrt{Np}$でしか改善しないので効率が悪い。 (3)は、意図的な相関を入れることになる(2次元だと r,θでθに付いての 回転対称性を人為的に導入するとか)。 (2)は、生成に必要な時間とのトレードオフが気になる所
本質的には、Npを無限大に持っていくのが正しいのだが演算資源的に無理
HAMMER FSのアイデア自体は結構おもしろそう
開発者的な立場からは、libc/libmの ISO C99準拠度が気になる所
元々は、FreeBSD 4からの forkなので libc/libmは FreeBSD由来なはずだが、 fork以降の開発状況はどうなってたのかな...
FreeBSD C99 and POSIX Conformance Projectのステータスを 見る限り libmの long double対応はまだ完了していないけど、*BSD系だと 実用上はFreeBSDの実装が一番進捗している気がする (NetBSDに ISO C99な math function fmin/fmaxが無かったりとか...)
darwinの実装がそこそこ進んでるのは、おそらく FreeBSDの デッドコピーなのためだと思う
Jul 27 18:38:00 aeka powled[1122]: AC line fault happens. Jul 27 18:38:00 aeka powled[1122]: Shutdown start within 60 Seconds. Jul 27 18:38:25 aeka powled[1122]: AC line recover.
で、またしても停電があったようです
Yet another SAD Interpreterの実装を目指す YaSAI Projectだが、 構文解析器の構築で難航中...
SADScriptに含まれる暗黙の積演算子と単項の+/-演算子の 優先順位問題を Context-free Grammar による記述では、文脈に依存しないが故にうまく解決できないので、 LR(1)での記述を諦めて、Parsing Expression Grammar を用いるために、PEGなパーサージェネレータとPEGによる SADScriptの文法記述を開発してきたわけですが、 最大の難関は&などに代表される単項で優先順位の低い後置演算子であ る模様
優先順位が低くとも後置演算子であるが故により高い優先順位を持つ 2項演算子の左オペランドに成ることが出来るために、二つの演算子の 生成規則の間で左再帰が起こるわけで、PEGによる決定論的な動作と 大変相性が悪いことに...
左再帰をサポートする拡張されたパーサーでも複数の再帰を含むルールだと うまく動作しないので簡略化した文法での動作解析とパーサーの改良が 必要な模様
久々のバグ修正のバックポート
同時に、Unsetと Member演算子に関するマニュアルの修正と UpSet/UpSetDelayed演算子のスペルミスの修正をバックポートした
1000粒子のガウス分布からでは、normal coordinate側で見た エミッタンスが増大するのは極めて早く crab cavityを立ち上げた 場合だけのように見える。 (super conducting cavityの Qとしては $10^5$を下回る場合に相当)
僅かな増加が、粒子数の統計からくるノイズに埋もれている可能性や crab cavity立ち上げ後の tracking時間が短く(2シンクロトロン周期程度) 10000粒子の分布での trackingと crab cavity立ち上げ後のターン数を増やした trackingを行ってみる。多分、結果は来週後半かな？(特に 10000粒子のやつ)
ただ、まともに運転できてる状況では、crab cavity立ち上げに伴う 分布の攪拌は、ビームのライフサイクル的には1回しか起こらない イベントだと思われるので、よほど無茶な立ち上げをしなければ 影響しないように思われる。
現時点の trackingで使っている latticeはnominal optics用のもので、 crab optics用にベータ関数を調整した物ではないが、 crab cavityでの$\sqrt{\beta}$と電圧の積を一定に保つ場合 (IPの$\beta$を固定した場合)では、crab cavity周辺の high beta section以外の領域からの寄与は変わらないはずなので、 localな opticsの違いからくる影響を小さいと考えているのだが、 いずれはきちんと数値的な評価をつける必要があると思う。
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記
Before...
_ A. Morita [電源スペースの奥行きが足りないというパターンかな だとすると、フォームファクターは昔ながらのATXではなく EPS-..]
_ 管理人さん [その通りで、奥行きスペースの問題でした。 5年半使った計算機ですが、そろそろリプレースを考えた方が良い時期なのかも知..]
_ A. Morita [安いアルミケースで金具が張り出しているのではなく プレスでわずかに出っ張りをつけてる場合だと、 5インチベイのネジを..]