Kstars bugs I can work on

Sun Sep 3 14:28:26 UTC 2017

So I checked VSOP87 calcEcliptic but can't see anything obvious there that
would indicate why it doesn't match JPL values. Julian millennia is
calculated OK. One small issue is that we do not take into account deltaT
since VSOP87 expect JDE (Julian Ephemeris Date) which is based on TT
(Terrestrial Time) while we just send plain JD. Today the difference is
about 70 seconds, but even when that taken into consideration when
calculating Tau (Julian Millennia) it can't account for the ~0.25 degrees
difference in ecliptic longitude. It's not constant either, the 0.25
differences increases slightly as well with time.

So I don't know what's causing this. Is it precession? or something else?

Regards,
Jasem

On Sun, Sep 3, 2017 at 12:51 PM, Jasem Mutlaq <mutlaqja at ikarustech.com>
wrote:

> So I continued investigating this, and here are a couple of observations.
>
> 1. If I set location to Greenwich, then all heliocentric ecliptic
> coordinates become valid! So there is a time component to this (Julian
> days?) that offsets the values.
> 2. Even if heliocentric ecliptic coordinates are correct, the geocentric
> ecliptic coordinates are wrong. Why? Because Earth ecliptic longitude and
> latitude are inaccurate.
>
> EDIT: As I am writing this, I found line 107 of KSNumbers with a note on
> this. We seem to be using a constant for ecliptic longitude of Earth
> perihelion. It's set as 102.94719
>
> I used JPL Horizons system to calculate current value for Sep. 4th, 2017
> and it is 104.8089842092676
>
> Earth orbital elements MUST be updated periodically then. The Earth
> ecliptic coordinate reported by Horizons is:
>
> Long: 341.4178043
> Lat: 0.0004911
>
> While in KStars, it is:
>
> Long: 341.6696035955447
> Lat: -5.294750917241062e-5
>
> Once I manually correct Earth's ecliptic coordinates, the asteroid
> location is pretty accurate. More investigation is required.
>
> Regards,
> Jasem
>
>
> On Sat, Sep 2, 2017 at 5:43 PM, Jasem Mutlaq <mutlaqja at ikarustech.com>
> wrote:
>
>> Hi Robert,
>>
>> Oh!! I am working on this bug now. I'm not getting anywhere with it so
>> far. I use JPL Horizons system to check the orbital parameters:
>> https://ssd.jpl.nasa.gov/horizons.cgi
>>
>> I am calculating all orbital elements and comparing it with JPL values
>> starting from Mean Anamoly, then True Anamoly..etc. Here are JPL values
>> from Horizon:
>>
>> JPL Heliocentric Orbital Elements
>>
>> $$SOE
>> 2457998.500000000 = A.D. 2017-Sep-02 00:00:00.0000 TDB
>>  EC= 4.232744439134506E-01 QR= 1.020269859137170E+00 IN= 2.215206298911301E+01
>>  OM= 3.360953610775869E+02 W = 2.784196493952410E+01 Tp=  2458020.936332046986
>>  N = 4.188758125005247E-01 MA= 3.506019631843183E+02 TA= 3.348867725600903E+02
>>  A = 1.769073432535834E+00 AD= 2.517877005934499E+00 PR= 8.594432747284709E+02
>> 2457999.500000000 = A.D. 2017-Sep-03 00:00:00.0000 TDB
>>  EC= 4.232901835419896E-01 QR= 1.020263438440515E+00 IN= 2.215145437416221E+01
>>  OM= 3.360952684752951E+02 W = 2.784456004960867E+01 Tp=  2458020.938336936291
>>  N = 4.188626190102440E-01 MA= 3.510202820436723E+02 TA= 3.359645930024024E+02
>>  A = 1.769110580961994E+00 AD= 2.517957723483473E+00 PR= 8.594703457918157E+02
>> $$EOE
>>
>> JPL Heliocentric Ephemeris
>>
>> **********************************************************************************************************************************************************
>>  Date__(UT)__HR:MN     R.A.__(a-apparent)__DEC hEcl-Lon hEcl-Lat               r        rdot            delta      deldot    ObsEcLon    ObsEcLat Tru_Anom
>> **********************************************************************************************************************************************************
>> $$SOE
>>  2017-Sep-02 00:00     22 56 46.97 +08 13 17.0 338.6177   1.0264  1.049795367593  -4.4410821 1.04979536759279  -4.4410821 338.6176978   1.0264441 334.8811
>>  2017-Sep-03 00:00     23 00 48.31 +08 38 34.4 339.6187   1.4332  1.047281909825  -4.2622642 1.04728190982466  -4.2622642 339.6187413   1.4332183 335.9589
>> $$EOE
>>
>> JPL Vector Data (Rectangular Heliocentric Coordinates):
>>
>> $$SOE
>> 2457998.500000000 = A.D. 2017-Sep-02 00:00:00.0000 TDB
>>  X = 9.774013251109912E-01 Y =-3.825877896251375E-01 Z = 1.884479352236287E-02
>>  VX= 4.155441472803211E-03 VY= 1.801646315290931E-02 VZ= 7.391156829632851E-03
>>  LT= 6.063034210721955E-03 RG= 1.049781831306806E+00 RR=-2.564399485651484E-03
>> 2457999.500000000 = A.D. 2017-Sep-03 00:00:00.0000 TDB
>>  X = 9.814311564582442E-01 Y =-3.645229326093622E-01 Z = 2.623313001987751E-02
>>  VX= 3.903753134260795E-03 VY= 1.811258715727221E-02 VZ= 7.385185521988751E-03
>>  LT= 6.048521037259282E-03 RG= 1.047268953218673E+00 RR=-2.461117456681675E-03
>> $$EOE
>>
>>
>> They precess all values while we don't precess anything in asteroid
>> class. In comets we precess OM, so I added that back into asteroid class to
>> precess OM (Longitude of the Ascending Node). Here is KStars values for Sep
>> 2nd 00:00:00:
>>
>> EC = 0.4233003617604261
>> W = 27.84698664318219
>> MA = 350.5485275538136
>> E = 343.7697842874328 (Not shown in JPL above, the Eccentric Anamoly)
>> TA = -25.252507942167078 = 334.747492057832922
>> IN = 22.1507826948212
>> A = 1.769132449016887
>> OM = 336.095126120893 (After I precessed it, it's not in code yet)
>> r = 1.0510131460163505
>>
>> You can see we have some differences in the true anamoly and by extension
>> sun distance. There are small differences in other elements, but these two
>> stand out leading to inaccurate heliocentric ecliptic coordinates and
>> eventually to wrong geccentric J2000/JNow coords. At first glance it
>> appears that the eccentric anamoly value might be inaccurate, but we use
>> the same iterative algorithm we already use in the comets class. Comets can
>> also be inaccurate but not as bad as this case.
>>
>> I think it might be a good idea to add another backend for this, we could
>> be utilizing JPL Development Ephemeris (e.g. 406+) for solar system
>> calculations. Another option is to switch to MPC for data source, but I'm
>> not sure what difference will this make.
>>
>> Regards,
>> Jasem
>>
>>
>> On Sat, Sep 2, 2017 at 3:45 PM, robert <robert at navsoft.plus.com> wrote:
>>
>>> Great - I'm starting with *Bug 384276*
>>> <https://bugs.kde.org/show_bug.cgi?id=384276> - [kstars 2.8.2] Wrong
>>> placement of asteroid Florence
>>>
>>> R
>>>
>>> On 02/09/17 13:05, Jasem Mutlaq wrote:
>>>
>>> Hi Robert,
>>>
>>> You can start by submitting patches to me, and then later on we'll
>>> create you an account on the system to handle it directly. So yeah clone
>>> KStars, then when you have a fix, run git diff and send me a patch.
>>>
>>> Thanks for the help!!
>>>
>>> Regards,
>>> Jasem
>>>
>>>
>>> On Sat, Sep 2, 2017 at 2:38 PM, robert <robert at navsoft.plus.com> wrote:
>>>
>>>> Hi Jasem,
>>>>
>>>> I've had a look. Reminds me of when I worked for a living;  but very
>>>> happy to help.
>>>>
>>>> 1. I guess I need, at least, permission to assign myself the bugs that
>>>> I am working on.
>>>>
>>>> 2. Is the source at "git clone git://anongit.kde.org/kstars"?
>>>>
>>>> 3. How should I submit proposed mods? Published KDE procedures?
>>>>
>>>> Robert
>>>>
>>>
>>
>
>
> --
> Best Regards,
> Jasem Mutlaq
>
>

-- 
Best Regards,
Jasem Mutlaq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20170903/5944ad04/attachment.html>