問題タブ [skyfield]

私はおそらくユニークなユース ケースに取り組んでいます。Skyfield を使用して、架空の星系でいくつかの計算を行いたいと考えています。これを行うには、独自のエフェメリスを作成し、実際のエフェメリスの代わりにそれを使用します。私が見つけている問題は、エフェメリスを自分のものに置き換えるための API に関するドキュメントが見つからないことです。

ドキュメントはありますか？スカイフィールドは、私が試みていることを実行するのに十分な柔軟性を備えていますか?

編集：私が求めていることを明確にするために、重力モデリングを行う必要があることを理解しています（そして、この家のすべてのコンピューター、タブレット、ケーブルボックス、トースターを構成して、これらの数値を数日間処理することを完全に望んでいます： ) ですが、実際に詳しく説明する前に、データがどのように見えるかを知りたいと思いました。それが名前付きの numpy 2d 配列を含む単なるモジュールである場合...それはかなり簡単になりますが、これがどこにも文書化されているのを見たことがありません。

任意の惑星までの現在の距離をキロメートル単位で出力する、非常に単純なプログラムを作成しようとしています。スカイフィールドを使用しています。火星のコードは次のとおりです。

これにより、距離が天文単位で出力されます。キロメートルに変換するために、149597871 を掛けてみました。

しかし、これはエラーを返します:

私に何ができる？

私の質問は、PyEphem が夏至と分点の日付と太陽の幾何学について正確な結果を提供する期間はどのくらいかということです。

これまでのところ、GitHub https://github.com/brandon-rhodes/pyephem/issues/61のこの非常に有益な投稿で、BC 9998-03-20 から AD 9999-12-31 までの制限 と、その結果の全体的な兆候を見つけました。現在のいずれかのサイトで +/- 20,000 年を超えると不安定になります。

特定の位置における太陽の高度と方位角から入射する太陽放射を計算するために、より長期間にわたって太陽の位置を取得しようとしているため、これを明確にしたいと思います-通常は10,000年前にさかのぼります-位置。PyEphem は、たとえば Berger、1978 (J. Atmosph. Sc.、35: 2362-2367) によって提供される機能の優れた代替手段を提供しているようです。私にとって、これらのアルゴリズムに対する PyEphem の本質的な利点は、前述のアルゴリズムでは地球の軌道が通常 1 つの特定の瞬間に固定されるのに対し、時間も追跡できることです (たとえば、3 月 21 日の春分点)。

通常、Berger などのアルゴリズムを使用した地球軌道の変動は、最終氷期 (最大 126,000 年 BP) のスケールで評価されます。その範囲で PyEphem を評価しているときに、至点の日付が現在よりかなり前にあるときに、いくつかの奇妙な動作に遭遇しました。

与えます:

日付をdate= ephem.date((-25000,1,1)).

PyEphem が実際に私の関心のある期間 (10,000 年 BP) にわたって正確な結果を提供する場合、それは私の目的に役立ちます。ただし、これを明確にしたいと思います。検証のためだけであっても、この範囲を拡張するための提案を受け付けています。代替手段として SkyField を検討していましたが、拡張範囲を提供していないようです。

PyEphem の有効範囲の明確な説明と提案をいただければ幸いです。

Skyfieldを使用して地球の中心からさまざまな(lat, lon)位置までの距離をマッピングすると、緯度による変化が示されますが、経度には依存しません (サブミリメートル)。これは、パッケージ内の文書化された概算、スクリプト内のバグ、またはまったく別のものである可能性があります。ここで何か間違ったことをしていますか？(もちろん、jetを使用して)

クロスチェックとして、同じ緯度の場所のランダムなペアをいくつか試しました。

これを取得しました（4列目はミクロンの違いを示しています）：

Skyfield を使用して、地球から太陽系の惑星までの距離を時間の関数としてプロットしようとしています。これは非常にシンプルで、パッケージのホームページのトップページにも掲載されています。ただし、これは水星、金星、火星では完全に機能しますが、他の惑星では機能しません. 私は JPL エフェメリス ファイルに詳しくありませんが、たとえば Jupiter には問題を説明するファイル de421.bsp にキー エントリがないようです。

これは最小限の例です（ホームページのもの）：

エラーは以下です。上記のコードで「jupiter」を「mars」に置き換えても、クラッシュしないことに注意してください。

エフェメリス ファイルを間違った方法で使用していますか (重心位置が間違っていますか?)、それとも de421.bsp ファイルの単なる制限ですか? Skyfield の Web サイト (ここ) でエフェメリス ファイルの説明を読みましたが、完全には理解できませんでした。

Skyfield を使用して地球と木星の距離を簡単に計算する方法について何か提案はありますか?

ありがとう ！

以下に示す時間テストでは、Skyfieldobj.at(jd).position.kmがの単一の時間値を返すのに数百マイクロ秒から 1 ミリ秒かかることがわかりましたjdが、より長いオブジェクト (時間内のポイントのリスト) の増分コストはJulianDate、ポイントごとに約 1 マイクロ秒に過ぎません。 . Jplephemと 2 つの異なるエフェメリスを使用した場合、同様の速度が見られます。

ここでの私の質問は次のとおりです。たとえば、独自の可変ステップサイズを使用する外部ルンゲクッタルーチンのスレーブとして、特定の時点にランダムアクセスしたい場合、Python内でこれをより高速に実行できる方法はありますか(コードのコンパイル方法を学ぶ)?

これは、Skyfield の一般的な使用方法ではないことを理解しています。通常、JulianDateオブジェクトを長いリストの時点でロードし、それらを一度に計算します。軌道積分器が行う方法のように、おそらく数千回 (またはそれ以上) ではなく、数回実行します。

回避策:時間粒度の細かいオブジェクトをNumPy使用して Skyfield を 1 回実行し、タイムステップが常にJulianDateNumPy 配列のストライディングに直接対応します。

または、再補間を試すこともできます。私は非常に正確な計算を行っていないので、単純な NumPy または SciPy の 2 次で問題ないかもしれません。

最終的には、太陽系の重力場の影響下にあるオブジェクト (深宇宙衛星、彗星、小惑星など) の経路を統合してみたいと思います。軌道解を探すとき、6D 位相空間で何百万もの開始状態ベクトルを試すかもしれません。ob.at(jd).observe(large_body).position.km重力は他のすべてのものと同じように光速で移動するため、メソッドなどを使用する必要があることはわかっています。これは反復計算であるため（推測では）かなりの時間がかかるようです（「見てみましょう...木星はどこにあったので、今すぐ重力だと感じます」）。しかし、コズミックオニオンを一度に1層ずつ剥がしましょう.

図 1. de405 と de421 のさまざまな長さJulianDateのオブジェクトに対する私のラップトップでの Skyfield と JPLephem のパフォーマンス。それらはすべてほぼ同じです-（非常に）最初のポイントで約0.5ミリ秒、追加のポイントごとに1マイクロ秒です。また、スクリプトの実行時に計算される最初のポイント(Earth (blue) with len(jd) = 1) には、追加のミリ秒のアーティファクトがあります。

地球と月は、内部で 2 段階の計算 (地球と月の重心と重心に関する個々の軌道) であるため、処理が遅くなります。水星は、エフェメリスの時間ステップと比較して非常に速く移動するため、（コストのかかる）チェビシェフ補間でより多くの係数が必要になるため、遅くなる可能性がありますか?

SCRIPT FOR SKYFIELD DATA JPLephem スクリプトはさらに下にあります

SCRIPT FOR JPLEPHEM DATA Skyfield スクリプトは上にあります