Qiitaの検索画面、検索結果に対してミュート処理をしてから結果画面を生成している感じの挙動で、検索結果1画面まるごとミュートユーザーが投稿していたりすると結果画面の生成に対して検索結果ゼロ件の情報が渡されて、その検索ワードに対して1記事もヒットしない(1件も投稿されていない)という表示になる。URLでページ番号を指定して、そのページにミュートしていないユーザーの記事があれば結果が表示されるけど、アドレスを手動で指示するのは面倒くさい。
ほとんど説明を書かずにワチャワチャなコードだけ貼り付けた記事を大量に投稿している人がいて、その人をミュートしたいんだけど、ミュートするとそのユーザー以外の有益な投稿も全部ミュートになる。もどかしい。
一人が検索結果のページを専有して、かつその人をミュートする、みたいな状況って想定していないんだろうな。一人しか投稿していないようなニッチな分野なら貴重な情報源であるその人をミュートする状況はほとんど無いだろうし、情報源として使いづらい記事を連投している人はたいていある程度活発な領域に多いだろうし。
H3ロケット2号機、観測衛星搭載せず 文科省方針 - 日本経済新聞
うわー、載りたい人多そう…… QPSとか、RAISE-3とか。でも流石に時間がたりなさそう。あとはNano-JASMINEとか? あれってまだすぐ飛べる状態で保管されてるんだろうか。QPSはLauncherOne打ちで衛星作っていて、Virgin Orbitが事業終了したから、それを振り分けるって可能性もあるか。QPSはイプシロンで打った実績もあるからJAXA内でも解析データは持ってるだろうし、それをベースにH3向けに解析し直したりとかはやりやすそう。全く同じ衛星ではないにしても、設計思想のすり合わせとかはある程度済んでるだろうし。
データ取得機器ってH-II系のVEPみたいなものだろうけど、どうやって作るんだろうか。予備部品とかかき集めて作るんかな? 最近はMHIでも小型衛星を何機か作っているから、ロケットチームから社内の衛星チームにお願いして仕立ててもらうことはできるか。MEHLCOとかに頼むよりはやりやすそう。ただ、衛星チームはRAISE-3の代替で忙しそうではある。かといってRAISE-3を作り直すのは間に合わなそうな気がするし。あるいは、RAISEを大急ぎで作り直して、一部の用意できるミッション機器だけ載せて、間に合わなかったミッション機器のかわりにセンサのインターフェースを用意して、ホットロンチで打って打上げ環境のデータを収集して、とか? /* VEPって探してもほとんど資料が出てこない */
H3は3号機の実機を使ってテストしたり、2号機のH3-30形体を1号機のH3-22に変えて飛行計画を流用できるのは「まず機体を製造して、コンフィグレーションは後から需要に応じて変更する」が活きてきてるな。部品が共通だから使い回しが楽。
https://www.jstage.jst.go.jp/article/ieejjournal1888/82/888/82_888_1509/_pdf
'62年の宇宙関連のエレクトロニクス、主にRF周り(TT&C)の話(オンボードセンサとかの話もいくつか)。最後に少しプラズマの話が出てきて、例えばロケットの再突入だったり、飛翔体の運動への影響だったり、電気推進への応用だったり。
最近の開口面はほとんどが放物面、周波数が低い領域では八木が少し、といった印象があるけど、この頃は多素子ヘリカルを使っていたりとか。小学校の図書室にあったハードカバーのSFでそんな挿絵があったような気がするなー。オールドファッションなSF世界観だとヘリカルアンテナとかループ八木アンテナは外せない。
地上ではあんまり見かけないとしても、衛星搭載だと一部では最近も使われているかな? GALILEOのSAR受信アンテナとか(測位送信アンテナはパッチアレイ)。QZSも1,2,4号機はヘリカルアレイだけど、3号機と1R以降は平面になってきている。やっぱりヘリカルアレイみたいに構造的に複雑なものは可能であれば避けたい方向性なんだろうな。地上なら耐風性とか、衛星なら打上げ時の共振とか、いろいろ考えることが多そう。
ASTRO-F('06年2月)、赤外線掃天観測を目的とした衛星なので、視野は慣性空間に固定されず、軌道運動の角速度で衛星も回転する(SNR改善用に慣性ロックする場合は最大10分まで)。姿勢はSTTを使用してオンボードで決定されるが、STTも自律的に処理される。オンボードでカタログを持ったSTTはALOSで開発されたものだと思っていたけど。ALOSは'06年1月打上げだし、ALOSもASTRO-FもどちらもNECだから、バス機器として共通して開発していたのかも。
他には、MUSES-C('03年)のSTTも、オンボードで姿勢決定ができるらしい。……あれ? ALOSよりだいぶ早いぞ。。。オンボード姿勢決定ができるようになったのはM-Cから、非慣性ロックで姿勢決定できるようになったのはALOS/A-Fあたりから、といった感じなのかな? M-C搭載STTは太陽系惑星の軌道要素も持っているので、視野内に火星等が写り込んでいればそれも使って姿勢決定ができるらしい。オンボードで惑星の軌道計算ができるなら、探査機の軌道要素と地球の軌道要素を与えて、さらにオンボードで姿勢決定を行えば、ソフトウェアによってはコマンド1発でHGA地球指向姿勢に変更できて便利だろうから、そのあたりで惑星軌道計算のロジックが入っているのかも。で、せっかくならSTTでも活用しよう、みたいな。
M-Cは惑星間ミッションだからオンボードで処理したほうがいいということで、そういうロジックを組んで、ALOSやA-Fではそれを非慣性ロックでも使えるように拡張して、みたいな感じだったのかな。
なお、科学衛星で精密姿勢決定を行ったのはASTRO-C('87年、X線天文)が最初らしい。IRUやSTT等を地上処理で姿勢決定。地上処理なので様々なアルゴリズムを試せる。SOLAR-A('91年、太陽観測)になるとオンボードで姿勢決定されるようになるが、これは太陽観測衛星なので太陽センサとの相性がいいこと、光軸周りの回転は許容値が大きいこと、高黄緯のカノープスが使えること、といった理由でオンボード処理がしやすかったらしい。ASTRO-D('93年、X線天文)ではSTTのオンボード処理が行われるようになったが、これは視野内の恒星をアップリンクすることで処理を行い、スターカタログをオンボードで持っていたわけではない(マヌーバ時に恒星のリストも更新する必要がある)。
***
SAOカタログで遊んでいるけど、proper_motion_raが謎いので、試しにGDR3とペアリング。
SAOとGDR3(全部読み込むと多すぎるのでごく狭い一部の領域だけ)のRa/Decから単位ベクトルを作成し、ベクトルの内積が10秒角以内をペアと判断し、ペア毎を比較。ただしmagの差が1を超えているペアは外れとして除いてある。
横軸がSAO、縦軸がGDR3、だと思う。Ra/Decは、それが一致するようにペアリングしているんだから当たり前だけど、しっかり直線に乗る。magは誤差が大きいけど、それでも良い一致をしている。pmdecは約1000倍のスケーリングがあるが、これはSAOが秒角、GDR3がミリ秒角であることを反映している。
一方でpmraは、一部は直線に乗っているような感じもあるが、あまり綺麗な一致はしていない。スケールも中途半端。15000くらいならDMSとHMSを取り違えている可能性があるけど、そこまで大きくはない感じがする。ラジアンと秒(HMS)を取り違えると約13751倍になるけど、さすがにそんなことはないと思うし。仮に内部表現でラジアンを使っていたとしても、秒角への変換を2回呼んでいるわけだし。12000倍くらいでちょうど良さそうな気もするけど、12という数字がどこから出てきたんだという問題になる。24hの半分ではあるけど、そんな数字使うかな。
なかなかに謎い。
/* 書いてから気がついたけど、SAOが2000年、GDR3が2016年だから、10秒角だと625mas/yr以上をペアリングできないので、不適切だった気がする */
***
ちょっと大きめのテーブル(100MB程度)を3重ループするような処理とか、もう少し大きめのテーブル(500MB程度)を2重ループするような処理を書いていると、アホみたいに遅くてびっくりする(そもそもDebugビルドで回してるのが悪いって話もある)。L1キャッシュが1GBくらい乗ってるCPUが欲しい。。。
GPUで処理すると、並列数を稼げるってだけ以外にも、メモリ帯域幅が桁違いに早い利点が大きそうだ。Mac StudioもCPUやRAMをオンボードで実装している分で帯域幅が広い。汎用WindowsPCはCPUソケットやメモリスロットがある分で帯域幅が稼ぎづらそう。
スパコンのCPUってどんなもんなんじゃろ?と思ってA64FXのカタログを見てみると、Core i7とかと単純に比較できるわけじゃないけど、数字的には意外と大したことない印象。並列化しやすいアルゴリズムで最適化して数でゴリ押しして早くしてる感じなのかな。
サボらずにテーブル間引くなりフィルタリングして不要なデータ捨ててから回す方が早いんだろうなー。とはいえ、その処理がちゃんと動いているかの動作確認が面倒で云々。
せっかくGPUも買い替えたことだし、GPGPU方面も手を出してみたい感はあるけど、データストレージを主目的としたPCで低レイヤに触れるような処理はちょっと遠慮したい気持ちもある。あと、ノートPCとかミニPCみたいに可搬環境で使いたいみたいな状況が想定される処理では、NVIDIAみたいに環境依存のコードを書きたくないという理由もある。
WebGPUってどうやって書くんだろう? JavaScriptを書いてEdgeで動くならGPGPU環境としては究極にお手軽な環境だけど。そもそもGPGPUが必要な処理をJSで書くな、とか言われたらぐうの音も出ないが。
0 件のコメント:
コメントを投稿