「ほっ」と。キャンペーン

<   2006年 05月 ( 7 )   > この月の画像一覧

エディタ の テンポラリ・ファイル保存の功罪

 自作ソフトを使い、将来の天文衛星の軌道解析を行なっていた。5年~10年に及ぶミッション期間中の軌道計算を行ない、時々刻々の軌道要素や位置・速度などをテキスト・ファイルに出力。その後、これを幾つかのグラフにして検討。細かい値を確認するなどのために、エディタでそのテキスト・ファイルを開く。

 私は、エディタは「秀丸」を使っている。上記のテキスト・ファイルは非常に大きなファイルであり、読み込むのに数秒~10秒掛かる。上の一連の作業を色々な軌道に対して何度も行なっていると、「C ドライブの残容量が少なくなりました。・・・・」というメッセージが表示された。

 職場で使っている PC は、数週間前に確認した時には、C ドライブの残容量が 800MB 程度は存在した。その後、新しいソフトのインストールはしていないので、C ドライブの残容量が減る要因は考えられない。一連の軌道解析作業が影響しているとは思ったが。ソフトに詳しい若い人に相談に乗ってもらった。C ドライブのテンポラリファイルが格納されている色々なフォルダを調査してくれて、原因が判明した。感謝。「Documents and Settings」 の下の 「Local Settings」 の中にある 「Temp」 フォルダ内に HIDxxxx.tmp という大きなファイルが沢山あった。これらを削除すると、C ドライブの残容量は 1GB を超えた。後で、「秀丸」を調べて、このテンポラリファイルを残さない設定に変更すれば良い。

 自宅で、「秀丸」の設定を調べた。「秀丸」のメニューの右端にある「その他」を押し、上から 2番目の「動作環境(E)...」を押す。すると、下のウインドウが開く。この図は、「パフォーマンス」を押したところ。「テンポラリファイル再利用 あり」となっている。これが原因だった。
c0011875_10274397.jpg

「詳細(D)...」ボタンを押すと、下のウインドウが開く。
c0011875_10295548.jpg

赤丸を付けた所のチェックを外して、テンポラリファイルを残さない設定に変更した。会社の PC も同様に設定すれば、C ドライブの残容量の減少はなくなるだろう。

 C ドライブの残容量には以前から気を使っている。2 年位前に、OS が主記憶の一時格納場所として使うスワップファイルを、デフォルトの C ドライブから D ドライブに変更している。D ドライブは十分に空いているから。それ以降は、新規にソフトをインストールする時も、可能な限り、D ドライブに入れるようにしている。今回の処置により、C ドライブの残容量 1GB 前後を確保できる目処が付いた。一安心。
by utashima | 2006-05-27 11:24 | パソコン | Trackback | Comments(2)

太陽-地球系 L2点周りのハロー基準軌道の設計(その4)

3.3 gap を改善するための定式化1a とその結果
 位置・速度 gap の改善が不十分な定式化1 の iteration 過程を見ると、はじめに等号制約の誤差(位置・速度のgap) が急速に小さくなるが、その後、等号制約を犠牲にして (gap が増大)、目的関数値を減らしている事が判った。これは、目的関数が複雑すぎるために、gap を犠牲にしないと目的関数が改善されないからではないかと考えた。更に、本問題では、gap を高精度にゼロにする事が最も重要であり、目的関数は重要ではない。そこで、目的関数の簡素化を検討した。
 ハロー軌道であるためには、z 方向の運動が毎周回ほぼ同じであれば良い。そこで、前節の (3-1) 式において2乗和を取る周回の数を減らしてみる事にした。ΔREV というパラメータを導入して、以下の目的関数を使用する。
c0011875_1824882.jpg
 この目的関数では、ΔREV によって、∑の項数が表3-1 のように変わる。計算期間が 5年間の場合は、ΔREV = 4 までは複数個の2乗項が存在するが、ΔREV = 5 以降は 1項のみとなる。
 ΔREV に 1 を入れると、今までと同じ目的関数となる。2 を入れると、2周回毎に z1 との差の2乗和を計算し、3 を入れると 3周回毎に計算する。5年間の計算では 10周まであるから、ΔREV = 9 まで考えられる。ΔREV = 9 は、最後の周回の z と z1 の差の 2乗を最小にする事になる。ΔREV≠1 の目的関数で求めた trajectory の yz 平面図が、ΔREV = 1 の yz 平面図と殆ど同じであれば問題ない。この簡素化した目的関数を使用する定式化を、定式化1a と呼ぶ事にする。
c0011875_1842725.jpg

 3.2 節と同じ初期軌道を使用し、ΔREV を 1~9 まで変えた時の定式化1a の結果を表3-2 に示す。INDEX は SQP ソフトの終了コードであり、0 は最適解と判定された事を示す。GAP/ODerr には、軌道決定誤差を 1km, 1mm/s と仮定し、位置と速度の gap の内で決定誤差との比の大きい方を記した。ΔREV が 5 以降は全て INDEX=0 であり、GAP/ODerr も 1e-5 以下である事が判る。図3-6 に ΔREV に対して GAP/ODerr のグラフを示す。
c0011875_22152979.jpg
c0011875_2219119.jpg
 ΔREV が 5 を超えて (3-2) 式の ∑ の項数が 1 になれば、どの ΔREV でも大きな違いはないが、ΔREV=9 つまり、最初と最後の z 値を一致させるのが最も良い事が判る。目的関数に使われている z 値は制御変数であり、何らかの複雑な計算をしなければ値が判らないものではない。目的関数もこれらの制御変数の差の 2乗和に過ぎず、極めてシンプルなものに思える。にも拘らず、∑ の項数が 1つ減る毎に収束性がどんどん改善されるのには驚いた。

 図3-7 に、ΔREV=1, 3, 5, 7, 9 に対して、iteration 毎の目的関数と等号制約関数の絶対値最大成分の変化を描いた。
c0011875_22295541.jpg

 ΔREV=9 の場合の収束解を図3-8 ~ 図3-10 に示す。目的関数の簡素化は、収束解に悪い影響を与えていないと判断できる。
c0011875_1873188.jpgc0011875_1874561.jpg
c0011875_188201.jpg

 以上の検討より、ハロー基準軌道の設計には、定式化1a の方法を ΔREV=(2×計算期間-1) (5年間計算の場合、9)で適用するのが良いと言える。

***(その5)に続く・・・***
by utashima | 2006-05-21 18:10 | 宇宙機の軌道設計/ 解析 | Trackback | Comments(0)

耐熱シールドを使わない衛星回収(補足)

 私のブログ記事『耐熱シールドを使わない衛星回収』では、非常に大きな断面積のバルーン等を膨らませて大気の上層において大きく減速する事で、空力加熱を抑え、耐熱シールド無しで衛星を回収する事の可能性について記した。最近の「野尻ボード」における議論をきっかけに、この回収法を再調査してみた。その結果、1997 年頃の検討はまだ不十分であり、私が誤解している部分もある事が判った。そこで、上記のブログ記事の補足をここに記す。

 1997 年に実施した解析は、高度 150km の円軌道において、断面積 S のバルーンを膨らませて放置した後の軌道変化を、高度 10km に達するまで計算して調査したものである。バルーンは抗力のみを発生させ、揚力はないとしている。通常の再突入のような軌道離脱制御は行なわない。断面積 S としては、78m2 (直径10m の円)、314m2 (直径20m の円)、707m2 (直径30m の円)のみを使用した。断面積を大きくするほど落下時間が長くなり、最大空力加熱率が小さくなった。直径 30m のバルーンの場合は、落下時間は 3.3 時間であった。断面積を大きくすると衛星は大きな抵抗を受けるので早く落下すると考えるのが普通ではないか、と気付いた。つまり、数値計算結果に対する物理的解釈ができていなかった。

 そこで、断面積 S を 1m2 から色々変えて計算してみた。その結果の 1 部を以下の表 1 に示す。1997 年に作ったプログラムがそのまま使えた。
c0011875_21251328.jpg

最大空力加熱率は、断面積の増大に対して単調減少している。しかし、落下時間は単調な変化ではない。断面積が約 10m2 の時、落下時間が最小になっていた。それより小さい断面積の領域では、断面積を大きくすれば早く落ちて来る。これは直感と合っている。約 10m2 より大きい領域では、傾向が逆転しており、物理的メカニズムが異なっていると考えられる。そこで、表 1 の 3ケースに対して、速度-高度図、時間-高度図、時間-速度図を描いてみた。それらを以下に示す。特に、時間に対して、高度と速度を描いてみては、とのコメントを戴いた野田篤司さんに感謝します。
c0011875_21185578.jpgc0011875_21285346.jpg
c0011875_2129977.jpg

 各図中の青線、青点は、空力加熱率が最大になる場所を示している。速度が約 6km/s の所で空力加熱率が最大になっているが、どの断面積においてもほぼ同じ速度で空力加熱率が最大になる理由は良く判らない(下のコメント欄を参照)。図 1、図 2 を見ると、断面積が大きいほど、空力加熱率が最大になる高度が上がっており、その結果、最大加熱率が小さくなっている。また、図 2、図 3 より、S=707m2 の時は、落下開始から約10分で速度が約100m/s まで下がっている事が判る。その時の高度は約 71km である。この断面積の時は、3.3 時間も掛かって落下しているが、殆どの時間は速度が 100m/s 以下である事に驚いた。この殆どの時間帯において、衛星はバルーンに支えられてゆっくりと降下していると言える。と言う事は、衛星は落下開始点の殆ど真下に落ちている事になる。1997 年頃は、3.3 時間の間に地球を 2~3 周しているものと勘違いしていた。

 以上、揚力が無い場合の検討結果を補ったが、これだけの結果から、揚力があった場合 (L/D=1 程度で)の影響を推し量るのは難しい。きちんとシミュレーションを行なう必要があろう。
by utashima | 2006-05-16 21:18 | 宇宙機の軌道設計/ 解析 | Trackback | Comments(9)

Google デスクトップの不具合

 数日前、家庭の PC を起動していると、起動処理の最後に、以下のエラーメッセージが表示された。
c0011875_11434758.jpg
画像が鮮明ではないので内容を以下に記す。
「データベースをアップグレードできませんでした。ドライブに十分な空き容量がないか、他のプログラムによりデータベースがロックされています。空きディスク容量を増やすか、Googleデスクトップをアンインストールしてから、再インストールしてください。D 80070020 4.2006.315.959」
 私の PC には、全てのドライブに十分な空き容量がある。そこで、Googleデスクトップをアンインストールしてから、再インストールしてみた。正常にインストールできた(ように見えた)。ところが、翌朝、PC を起動すると、再び同じエラーメッセージが現れた。

 Google デスクトップのヘルプセンターに該当するエラーメッセージについての説明があった。そこの冒頭に、
Google ではこの問題を認識しており、エンジニアが解決に向けて努力しております。 問題が解決するまでの間、次の方法をお試しになることをお勧めします。
と書かれ、幾つかの対策が記されている。私の PC に当てはまる可能性の有るのは、以下の二つだが、まだ調べていない。

(1)インデックスが破損し、Google デスクトップでインデックスを読み取れない
(2)セキュリティ ソフトウェアで Google デスクトップによるシステム プロパティへの書き込みがブロックされている

 今度は、アンインストールせず、「スタート・ボタン」→「プログラム」→「Google デスクトップ」で Google デスクトップを起動し、1時間位掛けてインデックスを作成し、スタートアップのフォルダに Google デスクトップのショートカットをコピーして、PC の電源を落として、再び PC を起動してみた。今度は、そのエラーメッセージは表示されず、Google デスクトップは正常に機能している。当面、この状態で様子を見る事にする。職場においても、Google デスクトップを使用しているが、そちらは正常である。
by utashima | 2006-05-14 11:42 | パソコン | Trackback | Comments(0)

『ステルス』、『4日間の奇蹟』

 この連休中に、2つの映画 DVD を借りて観た。『ステルス』 と 『4日間の奇蹟』。共に 2005年に公開された作品である。『ステルス』は今年の初めから観たいと思っていたが、『4日間の奇蹟』は全く知らなかった。借りに行く時に家内の希望も聞いてみた。吉岡秀隆氏の作品を観たいというので、ネットで調べた。幾つかの作品の中から、これを選んだ。折角借りたのだから、私も『4日間の奇蹟』を観た。とても感動した。『ステルス』が霞んでしまう程。

 『4日間の奇蹟』の序盤に、長い白い綺麗な橋を車で走るシーンが有る。ここはどこなのだろうと思い、ネットで検索した。このホームページが見つかった。この橋は、角島大橋という 2000年11月に開通した橋だった。山口県の北西部にある角島に渡る橋である。この映画は、角島が主な舞台になっている。

 『ステルス』は、CG の出来がとても良かったことが印象に残った。実在しないステルス機が空母に着艦するシーンなど、実物が飛行しているように見えた。このサイトを見ると、この CG には、1分間当たり 8000万円のコストが掛かっているとか。
by utashima | 2006-05-07 16:39 | 映画・ドラマ | Trackback | Comments(0)

MS IME2003 の異常動作と復旧

 家庭では、2005年11月から、DELL の Dimension 4700C を使っている。今日、メールを送ろうとして、変な現象に出くわした。私は、「メール」と入力して変換キーを押すと、私のメール・アドレスが出て来るようにしているが、それが出てこない。他の登録済みの単語も全く出て来ない。辞書ツールで確認すると、2つの登録単語を残して、全て消えていた。昨日までは問題なかった。5月4日の夜に、Windows Media Player 10 をインストールした。今まで、ver.9 を使っていたので、version up した。システムに変更を加えたのは、これだけ。これが悪さをしたのだろうか。

 原因は兎も角、復旧させる必要がある。毎週バックアップを外付け H/D に取っているのが役に立った。以下の手順で、無事に復旧した。c0011875_12571941.jpg

(1)バックアップしていたユーザー辞書(imjp9u.dic)をデスクトップにコピー。
(2)その名前を少し変更し、imjp9u2.dic とした。
(3)それを、ユーザー辞書のあるC ドライブのフォルダにコピー。
(4) IME のプロパティ(右の画面)を開いて、ユーザー辞書名を新しいもの (imjp9u2.dic ) に変更。

 この段階で、昨日までの環境が復旧した。しかし、ユーザー辞書のファイル名を元に戻したい。

(6)そこで、PC を再起動した後、C ドライブのフォルダの古いファイル (imjp9u.dic) を消去した。PC を再起動しないと、消去できなかった。
(7) C ドライブのフォルダの新しいファイル (imjp9u2.dic) をデスクトップにコピーし、名前を元のもの (imjp9u.dic) に戻した。
(8)そのファイルを、C ドライブのフォルダにコピーし、IME のプロパティから、ユーザー辞書として使う設定をした。
(9) PC を再起動し、imjp9u2.dic のファイルを消去した。

 これで、完全に元に戻った。IME のユーザー登録辞書の情報が消えたのは、初めての経験。1 週間に 1 度程度のバックアップは必須である事を実感した。原因は、WMP10 なのだろうか?
by utashima | 2006-05-06 13:00 | パソコン | Trackback | Comments(4)

太陽-地球系 L2点周りのハロー基準軌道の設計(その3)

3.SQP 法によるハロー基準軌道の設計
 第2章では、円制限三体問題の線型解を用いて、ハロー初期軌道の作成を行なった。地球公転軌道の離心率と月潮汐力を考慮すると、この初期軌道は約10万km の位置 gap と約100m/s の速度 gap を持った。本章では、これらの gap を、逐次2次計画法(Sequential Quadratic Programming Method; SQP 法)で小さくする事を考える。

3.1 定式化1
 リサジュ基準軌道の設計法と同様に、L2 点中心回転座標系における xz 面で分割される半周単位の軌道群をマッチングして、位置・速度の gap のない基準軌道を設計する。リサジュ軌道と異なるのは、ハロー軌道では、z 方向の運動が xy 面内の運動と平均的に同期する必要のある事である。そのため、各半周軌道の初期位置速度の z 成分も制御変数とする。
 以下に、非線型計画法における制御変数、等号制約、目的関数を記す。NHREV は、ミッション期間の半周単位の周回数である。図3-1 を参照。
c0011875_20411551.jpg
c0011875_2017453.jpg

c0011875_2018074.jpg

c0011875_20181124.jpg
ハロー軌道では z 方向運動に最も関心があり、xz 面通過時の z 値の変動が小さいほど良いハロー軌道と考えられるので、上式の様に xz 面通過時の z 値のバラツキの2乗和を最小にする。2乗和を使うのは収束性を良くするためである。以下、この定式化を『ハロー軌道の定式化 1 』と呼ぶ。


3.2 月潮汐力も考慮した場合の定式化 1 の解
 2.1 節の初期軌道の作成において、位置・速度の最大 gap が大きかった初期時刻 2006年3月30日 0 時UT の場合を使って、定式化1 による解を検討した。この初期軌道の位置・速度の最大 gap は、約10万km と 100m/s であった。
 2.1 節で作成した初期軌道を入力して、定式化1 のソフトを実行した。設定した iteration 上限値の 200 回の iteration 後に、INDEX=2 で終了した。ペナルティ関数の減少量は十分小さいが、Kuhn-Tucker 条件を満足していない場合に INDEX=2 が出力される。この時の位置・速度の最大 gap は、69.2m と 3.19e-2mm/s であった。軌道決定誤差の1~2 桁下である。iteration=200 での trajectory の xy 平面図を図3-2、図3-3 に示す。図3-2 には初期軌道も黒線で描いている。最後の1/4 周は大きくずれているが、ミッション期間よりも 1 年余分に基準軌道を作成しておけば問題ない。
c0011875_2049527.jpgc0011875_2050684.jpg

 図3-4 と図3-5 に、iteration=200 における trajectory の yz 平面図を示す。

c0011875_20513674.jpgc0011875_20515331.jpg

 定式化1 で得た解は、位置・速度の gap が、軌道決定誤差より 1~2 桁小さいだけであった。これでは基準軌道としては不十分と考えられるので、次節で改善策を検討する。

***(その4) に続く・・・***
by utashima | 2006-05-03 20:11 | 宇宙機の軌道設計/ 解析 | Trackback | Comments(0)