JPL verilerini kullanarak Jovian Uydularının / Aylarının yörünge konumlarını hesaplama

PKCLsoft

2018-08-04 11:24:30 UTC

view on stackexchange narkive permalink

Bir oyunda güneş sisteminin bir modelini oluşturmaya çalışıyordum. Şimdiye kadar, https://ssd.jpl.nasa.gov/?planet_pos adresindeki Keplerian öğelerini ve formüllerini kullanarak gezegenlerin her birini konumlarına yerleştirmeyi başardım Jüpiter için bir örnek:

  ae IL long.peri. long.node. AU, AU / Cy rad, rad / Cy deg, deg / Cy deg, deg / Cy deg, deg / Cy deg, deg / Cy -------------------- -------------------------------------------------- ------------------------------------- Jüpiter 5.20288700 0.04838624 1.30439695 34.39644051 14.72847983 100.47390909 -0.00011607 -0.00013253 -0.00183714 3034.74612775 0.21252668 0.20469106

Bu noktada, Jovian uydularından birkaçını eklemek istiyorum, ancak aynı site bu uydular için aynı tür verileri sağlamıyor gibi görünmüyor, belki de aylar farklı davranır. Ne yazık ki matematiğim harika değil; Genelde yazılı bir şeyi uygulayabilirim, ancak bunu kendim çözmek için gerekli olan bilgiye sahip değilim.

Jovian uyduları için veriler https: // ssd adresinde listelenir. jpl.nasa.gov/?sat_elem#jupiter İşte Ganymede için bir örnek:

  Sat. a e w M i düğümü n P Pw Pnode R.A. Aralık Eğim (km) (derece) (derece) (derece) (derece) (derece / gün) (gün) (yıl) (yıl) (derece) (derece) (derece) Ganymede 1070400. 0,0013 192.417 317.540 0.177 63.552 50.3176072 7.155 63.549 132.654 268.168 64.543 0.068

Burada verilerin " Yerel Laplace düzlemlerine atıfta bulunan ortalama yörünge öğeleri " olduğunu belirtirler, " Büyük Gezegenlerin Yaklaşık Konumları için Kepler Unsurları " nın tersine.

İlk 6 parametre aynı görünürken (a, e, w, M, i, düğüm), Keplerian öğeleri ayrıca "oranlara" veya zaman türevlerine (buna göre gönderi: https://space.stackexchange.com/questions/8911/determining-orbital-position-at-a-future-point-in-time). Kepler unsurları için NASA tarafından nazikçe sağlanan forum, bu oranlara dayanmaktadır.

Jüpiter uyduları için "oranları" nasıl belirleyeceğimi anlayabilirsem, o zaman aynı formülü kullanabilirim ( Yapılması gereken doğru şey bu mu?) Bana öyle geliyor ki bu oranlar, aylar için sağlanan diğer verilerden hesaplayabilmem gereken bir şey, ancak nasıl olduğunu belirleyemedim.

Şüphem, Laplace Planlarını kullanarak hesaplama için farklı bir formüle ihtiyacım olduğu veya bu 'oran' değerlerini hesaplamam ve zaten sahip olduğum formülün aynısını kullanmam gerektiği.

Oluşturmaya çalışıyorum (0,0,0) belirli bir tarih / saat için (genellikle "şimdi") Jüpiter'in merkezi olduğu her Ay için kartezyen (x, y, z) koordinatları.

Ben Bu konuda yanlış ağaca havlıyor muyum merak etmeye başlıyorum Herhangi biri ışık tutabilir mi

İstediğiniz ay için ELEMENTS ayarını kullanarak https://ssd.jpl.nasa.gov/horizons.cgi#top'u denediniz mi? Osilasyon elemanlarını oradan alabilirsiniz.

Evet, ne yazık ki nasıl yardımcı olduğunu tam olarak anlamıyorum. Evet, bu site bana belirli bir zaman aralığı için statik veriler verecek. Herhangi bir tarih için pozisyonu hesaplayabilmek istiyorum (2050'den önce, çünkü bu, ortalama verilerin geçerliliğini yitirdiği ve oyunumun ~ 30 yıl içinde var olma olasılığı düşük olduğu için görünüyor)

Doğru veriler istiyorsanız, SPICE (https://naif.jpl.nasa.gov/naif/) gibi bir şey kullanmanız gerekir. Salınımlı öğelere bakarsanız, taklit edebileceğiniz yaklaşık bir modeli izlediklerini görebilirsiniz. Teorik olarak, başlangıç konumları verilen diferansiyel denklemleri bile çözebilirsiniz, ancak bu çok zaman alır. Sonuçta, bu bir bilgi teorisi (bu yörüngeler sadece o kadar basit değil) ve zaman / uzay değiş tokuşu (konumları kaydetmek istemiyorsanız, onları hesaplamanız gerekecek) meselesi.

Tamam teşekkürler. Bu utanç verici. Hafta sonu SPICE'a bir göz attım ve açıkça istediğimi yapacak olsa da, API tarafından biraz şaşırdım ve muhtemelen onu iOS'a taşıma ihtiyacıyla yüzleşeceğim gerçeği. Ayları şimdi yörüngede döndürmeyi başardım, ancak doğru yerlerde olmayacaklar ki bu utanç verici.

Mevcut salınım öğelerini kullanabilir ve ayların yörüngelerinin her zaman eliptik olacağını düşünebilirsiniz - bu, kısa vadede doğru olur. Ayrıca, ücretsiz yardım için doğrudan benimle iletişime geçmekten çekinmeyin (iletişim bilgileri profilde). SPICE, iOS'ta "olduğu gibi" derlenmelidir, ancak onu orada hiç kullanmadım, bu yüzden emin değilim. Temelde sadece bir C ++ kitaplığıdır, bu nedenle, C ++ 'yı biliyorsanız, onu kullanabilmelisiniz.

@barrycarter teşekkür ederim, bu çok cömertçe. Buna geri döneceğim çünkü en azından denemeden tatmin olmayacağımı biliyorum. Biraz konu dışı, ancak yörüngelerin her zaman eliptik olmadığına dair yorumunuz aklınızı kaçırdı. Bu şeyler nasıl olur da etki etmeden değişen yörüngelere girmeyi başarır? Kabaca aynı düzlemde oldukları için mi, yani yörünge yarıçapları onları yeterince uzakta tutuyor mu?