问题标签 [skyfield]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
pyephem - jplephem ephemerides api 记录在哪里?
我正在研究可能是一个独特的用例——我想使用 Skyfield 对假设的恒星系统进行一些计算。我会通过创建自己的星历表并使用它而不是实际的星历表来做到这一点。我发现的问题是我找不到关于 API 的文档来用我自己的替换星历。
有文档吗?Skyfield 是否足够灵活,可以做我正在尝试的事情?
编辑:为了澄清我的要求,我知道我将不得不做一些引力模型(我非常愿意配置这所房子里的每台电脑、平板电脑、有线电视盒和烤面包机,以便在几天内处理这些数字: ),但在我真正深入研究之前,我想知道数据是什么样的。如果它只是一个带有许多命名的 numpy 2d 数组的模块......这让它变得相当容易,但我没有在任何地方看到这个记录。
astronomy - Getting latitude and longitude of the Sun on a world map with PyEphem
I'm trying to determine the latitude and longitude of say the Sun, the Moon and Mars. I need the result relative to the Earth's equator and the Prime Meridian in order to produce a result similar to this map.
I believe that's also what the author of this question wanted, however the answer there doesn't add up for me (comparing with values from the first link).
Expected result, obtained from the page linked to earlier:
On Thursday, 1 January 2015, 00:00:00 UTC the Sun is at its zenith at Latitude: 23° 02' South, Longitude: 179° 29' West
So the latitude/declination seems about right, but no 180° wraparound will fix that right ascension, probably because it starts at the Vernal Equinox.
I have also unsuccessfully tried to use an observer at 0,0.
Can this be done using PyEphem, Skyfield or astropy? It seems odd that artificial satellites in PyEphem have the convenient sublat and sublong attributes, but it's so hard for celestial bodies.
python - python将au转换为km
我正在尝试编写一个非常简单的程序,以公里为单位打印到任何行星的当前距离。我正在使用天域。这是我的火星代码:
这将以天文单位打印出距离。为了转换为公里,我尝试乘以 149597871:
但这会返回一个错误:
我能做些什么?
python - PyEphem:至日和春分的日期及其在较长时间尺度上的有效性
我的问题是 PyEphem 为至日和春分以及太阳几何的日期提供准确结果的时间跨度是多少。
到目前为止,我在 GitHub https://github.com/brandon-rhodes/pyephem/issues/61上的这篇内容非常丰富的帖子中发现了 BC 9998-03-20 到 AD 9999-12-31 的限制, 并总体表明结果在当前任一地点移动超过 +/- 20,000 年时变得不稳定。
我想澄清这一点,因为我试图在更长的时间内获得太阳的位置 - 通常可以追溯到 10,000 年 BP - 为了计算在给定的太阳高度和方位角的入射太阳辐射地点。PyEphem 似乎为 Berger, 1978 (J. Atmosph. Sc., 35: 2362-2367) 提供的功能提供了一个很好的替代方案。对我来说,PyEphem 相对于这些算法的一个重要优势是它还可以跟踪时间,而在上述算法中地球轨道通常固定在某个特定时刻(例如,3 月 21 日的春分)。
通常,使用 Berger 和其他人的算法在地球轨道上的变化是在末次冰期的规模上评估的(高达 126,000 年 BP)。在该范围内评估 PyEphem 时,当日期远在今天之前,我发现了一些关于至日日期的奇怪行为:
给出:
当我将日期设置为date= ephem.date((-25000,1,1))
.
如果 PyEphem 确实在我感兴趣的时期(10,000 年 BP)内给出了准确的结果,那将符合我的目的。但是,我想澄清这一点,并愿意提出扩大这个范围的建议,即使它只是为了验证。我将 SkyField 视为替代方案,但它似乎没有提供扩展范围。
对 PyEphem 有效性范围的清晰描述以及任何建议将不胜感激。
python - 日心说位置
有没有办法用 Brandon Rhodes 的 python 程序 Skyfield 计算日心行星坐标(经度和纬度)?
如果我只这样做:
mercury(utc=(1980, 1, 1)).ecliptic_latlon()
我得到一个重心物体,因此纬度和经度与日心值不匹配。
我试过了:
sun(utc=(1980, 1, 1)).observe(jupiter)
但这会引发错误:
使用 Python 3.4,天空0.4, de423
谢谢!
python - Skyfield 中的地球形状似乎不对 - 我的蟒蛇是否正确?
使用Skyfield绘制从地球中心到各个(lat, lon)
位置的距离显示出随纬度的变化,但与经度无关(亚毫米)。这可能是包中记录的近似值、我的脚本中的错误或其他完全不同的东西。我在这里做错了吗?(当然,除了使用jet)
作为交叉检查,我尝试了一些具有相同纬度的随机位置对:
并得到了这个(第四列显示了微米的差异):
python - 地球到木星的距离与 Skyfield
我正在尝试使用 Skyfield 来绘制从地球到太阳系行星的 au 距离作为时间的函数。这超级简单,甚至在包主页的首页中都有。然而,虽然这对水星、金星和火星非常有效,但它不适用于其他行星。我不熟悉 JPL 星历文件,但似乎 Jupiter 在 de421.bsp 文件中没有可以解释该问题的密钥条目。
这是一个最小的示例(来自主页的示例):
错误如下。请注意,如果在上面的代码中将 'jupiter' 替换为 'mars',它不会崩溃。
我是否以错误的方式使用星历文件(重心错误?)或者这只是 de421.bsp 文件的限制?我在 Skyfield 网站(此处)上阅读了星历文件的描述,但不确定我是否完全理解它。
有关如何使用 Skyfield 执行地球-木星距离的简单计算的任何建议?
谢谢 !
performance - 来自 Skyfield 的轨道与太阳系重力场的整合 - 速度问题
在下面显示的时间测试中,我发现Skyfield需要几百微秒到一毫秒才能返回obj.at(jd).position.km
单个时间值jd
,但较长对象(时间点列表)的增量成本JulianDate
仅为每点大约 1 微秒. 我使用Jplephem和两种不同的星历表看到了相似的速度。
我的问题是:如果我想随机访问时间点,例如作为使用自己的变量步长的外部 Runge-Kutta 例程的奴隶,有没有办法可以在 python 中更快地做到这一点(无需学习编译代码)?
我知道这根本不是 Skyfield 的典型使用方式。通常我们会加载一个JulianDate
包含一长串时间点的对象,然后一次计算它们,并且可能会像轨道积分器那样做几次,而不是数千次(或更多)。
解决方法:我可以想象一种解决方法,我NumPy
通过使用具有精细时间粒度的对象运行 Skyfield 一次来构建自己的数据库JulianDate
,然后编写我自己的 Runge-Kutta 例程,该例程通过离散量上下改变步长,这样时间步长总是直接对应 NumPy 数组的跨步。
或者我什至可以尝试重新插值。我没有进行高度精确的计算,所以简单的 NumPy 或 SciPy 2 阶可能没问题。
最终我想尝试在太阳系重力场的影响下整合物体的路径(例如深空卫星、彗星、小行星)。在寻找轨道解决方案时,可能会在 6D 相空间中尝试数百万个起始状态向量。我知道我应该使用ob.at(jd).observe(large_body).position.km
方法之类的东西,因为重力像其他一切事物一样以光速传播。这似乎花费了大量时间,因为(我猜)它是一个迭代计算(“让我们看看......木星会在哪里让我现在感觉到它的引力”)。但是,让我们一次剥一层宇宙洋葱。
图 1.我的笔记本电脑上针对 de405 和 de421 的不同长度JulianDate
对象的 Skyfield 和 JPLephem 性能。它们都差不多——(非常)第一个点大约是半毫秒,每个附加点大约是一微秒。此外,脚本运行时要计算的第一个点len(jd) = 1
(地球(蓝色),带有)还有一个额外的毫秒伪影。
地球和月球较慢,因为它是内部的两步计算(地球-月球质心加上围绕质心的各个轨道)。水星可能更慢,因为它与星历时间步长相比移动得如此之快,以至于它在(昂贵的)切比雪夫插值中需要更多的系数?
SKYFIELD DATA 脚本 JPLephem 脚本位于更下方
JPLEPHEM 数据 的脚本 Skyfield 脚本在上面
julian-date - 如何在 Skyfield 中添加 JulianDate 对象或偏移量
Skyfield中的JulianDate
对象是一种方便的方法,可以快速生成并保存一组儒略日时间值,并将它们传递给 Skyfield 的方法,以计算各种坐标中的天文位置。(参见示例脚本)at()
但是,我似乎找不到add
oroffset
方法,以便可以向JulianDate
对象添加时间偏移或可迭代的偏移。我似乎总是与日期和时间作斗争。
这是一个非常简单的抽象示例。我生成jd60
的偏移量是任意jd0
60 天。作为一个简单的检查,我计算了两次地球的位置,并确保它移动了大约 60 度。
从任意 t_zero 开始:
现在,使第二个 JulianDate 对象偏移 60 天
这有效:
但是,我想要的是这样的:
现在计算位置并找到近似角度,看看它是否有效。
给
python - 为什么 scipy.optimize.minimize (默认)在不使用 Skyfield 的情况下报告成功?
scipy.optimize.minimize
使用默认方法返回初始值作为结果,没有任何错误或警告消息。虽然使用此答案建议的 Nelder-Mead 方法可以解决问题,但我想了解:
为什么默认方法返回错误答案而不警告起点作为答案 - 有没有办法可以防止“没有警告的错误答案” 在这种情况下避免这种行为?
请注意,该函数separation
使用 python 包Skyfield来生成要最小化的值,这不能保证平滑,这可能是 Simplex 在这里更好的原因。
结果:
测试结果:[ 2.14159739 ]'正确': 2.14159265359初始:0.0
默认结果:[ 10000. ]'正确':13054初始: 10000
Nelder-Mead 结果:[ 13053.81011963 ]“正确”: 13054初始值:10000
这是完整的脚本: