[Kstars-devel] SatLIb verification

[Bernard GODARD]

Hi,

I downloaded kstars from svn yesterday.
The satellite code seems still to contain the wrong sign for the longitude.

Also, there is a problem with the graduation mark along the satellite
track. They appear OK when the program starts, but they get messed up
after some user actions:
see image : http://godard.b.free.fr/echange/kstars/kstars.png

On this image you can also see that there is a problem with the DST Rules.
Local Time shown by Gnome (top right of the image) is 20:36
Local Time shown by Kstars is 19:36 (not correct)
UT shown by Kstars is 18:36 (correct)
Time Zone is UT+1 and Daylight Saving Time for Europe applies
If I change DST Rules to US (without overriding data for the city), I
get the correct time (20.36) , but when I open the geographic window
again, DST Rules is still set to EU and changing it to '--'
(nothing), 'EU' or 'US' doesn't have any effects : kstars still show
20.36.

On another note is it normal that almost everything is commented out
in SkyMapComposite::update?

I had a hard time compiling everything. The instructions at
http://edu.kde.org/kstars/svn.php are always outdated since KDE4 is
still growing.
I had to compile kdesupport, kdelibpims, kdebase and download plenty
of required dev packages to get kstars to compile.

Clear skies,

               Bernard

On Sun, May 6, 2007 at 3:01 PM, Bernard GODARD <bernard.godard at gmail.com> wrote:
> Hi,
>
> I have re-compiled the kstar code changing
> data->geo()->lng()->Degrees() in line 65 of
> satellitecomposite.cpp by  -(data->geo()->lng()->Degrees()) and it now
> seems the predictions are not far from those from Heavens Above
> (tested with Envisat and locations : Toulouse/Fance +
> Lancaster/Pennsylvania).
>
> On another note, the DST rules are not working for EU and US (I had to
> manually change
> the UT offset in the Geographic Settings Window for Summer Time).
>
> Clear Skies,
>
>              Bernard
>
> On 5/1/07, Bernard GODARD <bernard.godard at gmail.com> wrote:
>>
>> On 5/1/07, Bernard GODARD <bernard.godard at gmail.com> wrote:
>> > I've just modified my test program to find all the HST passes on a ten
>> > day period using SatFindPosition and keeping only the data where
>> > elevation is above 10 degrees and I found all the passes predicted by
>> > heavens above but some of them were flagged as being in Sun light
>> > (visibility = '*') but not being on the night side (visibility = '+')
>> > whereas Heavens above gave a sun altitude at maximum elevation
>> > negative. It seems the sun sets later in SatLib.
>> >
>> > Heavens above seems to report only passes with altitude > 10 degrees.
>> > That's why SatNexPass in SatLib reports much more passes (elevation >
>> > 0)
>> >
>> >
>> > On 5/1/07, Bernard GODARD <bernard.godard at gmail.com> wrote:
>> > > Hi,
>> > >
>> > >
>> > > On 5/1/07, Jason Harris <kstars at 30doradus.org> wrote:
>> > > > Hi,
>> > > >
>> > > > So do I have an old version of SatLib or something?  Because when I
>> > > > run the demo, I am seeing some problems.
>> > >
>> > > I did my test with the SatLib.h and SatLib.c code I found in the
>> > > satlib directory of kstars svn. I didn't use the demo code. I made a
>> > > custom C test program.
>> > >
>> > > > First of all, It reports a
>> > > > Julian Day number that is off by about a month (and calendar dates
>> > > > reported in the output tables also reflect this month-old date).  I
>> > > > have to hack the code like this if I want the correct JD:
>> > > >
>> > > > jd=Julian_Date(cdate) + 30.0;
>> > > Just tested. same problem here!
>> > >
>> > > >
>> > > > There are some ambiguities in the meanings of some parameters:
>> > > > + What time is reported by the demo?  I assume it's UT, and looking
>> > > > at
>> > > > the code I'm pretty sure that is correct.
>> > >
>> > > That's what I did too.
>> > >
>> > > > + What convention is used for geographic longitude?  Are west
>> > > > longitudes positive or negative?  From the longitude you gave for
>> > > > Toulouse, I guess west longitudes are negative.
>> > > >
>> > > I was wrong about that but the difference is not so important for
>> > > Toulouse because it's almost zero longitude. I just did the test with
>> > > west longitude positive and I have now a better match of the Heavens
>> > > Above results.
>> > >
>> > > > Assuming my guesses are correct, as I said before, I can't find any
>> > > > correlation between SatLib predictions and those of
>> > > > NASA/Heavens-above/calsky.
>> > > >
>> > > > For example, for JD=2454221.5 from Tucson, AZ (lat=32.222,
>> > > > long=-110.926), SatLib gives the following pass prediction for HST:
>> > > >
>> > > > % ./demo HST
>> > > > JD=2454221.516105
>> > > > 90037B HST 2007-05-01 12:15:10   0.03 185.72  38   9  251   2727
>> > > >  73294 +
>> > >
>> > > I have tried to re-do your test and it seems SatLib's demo finds many
>> > > more passes than Heavens Above.
>> > >
>> > > But I did another test with my test program which doesn't use
>> > > SatNextPass but SatFindPosition and I made it print the epheremeris
>> > > for the 3 may 19h30 (local time = GMT-7) pass above Tucson (
>> > > 32.2220°N, 110.9260°W, alt 751m) predicted by Heavens Above and I have
>> > > a very close match.
>> > >
>> > > _________________________________________________________________________
>> > >
>> > > test program
>> > >
>> > > _________________________________________________________________________
>> > >
>> > > #include "SatLib.h"
>> > > #include <stdio.h>
>> > > #include <stdlib.h>
>> > > #include <math.h>
>> > >
>> > >
>> > > #define NBPTS 3600
>> > >
>> > >
>> > >
>> > > int main(int argc, char *argv[]){
>> > >
>> > > char *sat1 = "HST";
>> > > char *obsname = "Tucson";
>> > > double latitude = 32.222;
>> > > double longitude = 110.926;
>> > > double altitude = 751.0;
>> > > char *TLE_file = "hst.tle";
>> > > int result = 0;
>> > > double jd_start = 2454224.60417;
>> > > double step = 1;
>> > > int i=0;
>> > > int h,m;
>> > > double s,s1,s2;
>> > > double t;
>> > > SPositionSat * pPositionSat[NBPTS];
>> > >
>> > > for (i=0;i<NBPTS;i++)
>> > >   pPositionSat[i] = (SPositionSat *) malloc(sizeof(SPositionSat));
>> > >
>> > > result = SatInit(obsname, latitude, longitude, altitude, TLE_file);
>> > > result = SatFindPosition(sat1, jd_start, step, NBPTS, pPositionSat);
>> > >
>> > > for (i=0;i<NBPTS;i++){
>> > >   t = (jd_start-0.5)+i*step/86400.0;
>> > >   s1 = (t - floor(t))*86400;
>> > >   h = floor(s1/3600.0);
>> > >   s2 = s1 - h*3600.0;
>> > >   m = floor(s2/60.0);
>> > >   s = s2 - m * 60.0;
>> > >
>> > >   printf("UT TIME : H: %d, M: %d, S : %f, ALT : %f, AZIM : %f VISI:
>> > >
>> > > %c\n",h,m,s,pPositionSat[i]->sat_ele,pPositionSat[i]->sat_azi,pPositionSat[i]->visibility);
>> > > }
>> > >
>> > >   return 0;
>> > > }
>> > >
>> >
>>
>