core.moveToAltAzi(90,XX) issue

[Ross]

I write here, because I did not receive any replies in the forum...
This is my problem (it affects all Windows versions of Stellarium, don't know on other platforms):

~~~~~~~~~~~
core.moveToAltAzi(X,Y,1);
~~~~~~~~~~~

If (X != 90 OR X != -90), the function works well and it considers the Azimuthal Y value. But this is not true if the Altitude value is set to 90 (or -90) degrees. In fact, if you call

core.moveToAltAzi(90, <any value>, 1);

the moveToAltAzi moves ALWAYS the view with the "West" cardinal point at the bottom, never mind the Azimuthal value Y passed to the function moveToAltAzi().

The workaround could be putting a value for the Altitude next to 90.0 (i.e. 89.9): it works quite well, but not very well if the Azimuth value is 0 or 180 degrees.

Is this a behavior by design or is it a bug?
Thank you.

[Axel Hoff (0k-axel)]

I can confirm this bug description - I did some extensive tests since I experienced unexpected behaviour when using core.moveToAltAzi in my own scripts in Stellarium 0.11.4, Windows 64-bit version. So I wrote some scripts just for testing purposes; the scripts and the corresponding logfiles are attached.

When testing, I found other kinds of unexpected behaviour. It seems to me that the functions core.getViewAltitudeAngle and core.getViewAzimuthAngle when called after core.MoveToAltAzi return the altitude/azimuth values BEFORE the call of core.MoveToAltAzi call (cf. script test_altazi). Furthermore, core.MoveToAltAzi seems to have no effect if it is called in a loop as in the script test_altazi2.

I experienced more problems with core.MoveToAltAzi in my scripts (seemed to work correct sometimes, but sometimes produced erroneous results as wrong viewing directions even when called with altitude other than +/-90 degrees), but I cannot reproduce those effects by now.

Thank you!

[Axel Hoff (0k-axel)]

results produced with script_altazi.ssc

[Axel Hoff (0k-axel)]

script test_altazi2.ssc

[Axel Hoff (0k-axel)]

results produced with script_altazi2.ssc

[Ross (rosario-ing)]

Alex, I think you confused Altitude with Azimuth in your script. The first parameter is the Altitude and the second is the Azimuth, according to the documentation (http://www.stellarium.org/doc/head/classStelMainScriptAPI.html#a5eb1dfed00ea1cdf8edfded721337d19). You can also wait for the moveToAltAzi function to complete the movement (it takes a little time to complete the movement: this is the third parameter).

So your script should become:

core.moveToAltAzi(90,135,1);
core.wait(1);
for (i=0; i<=72; i++)
{
 // move to altitude=90 azimuth=5*i
 core.moveToAltAzi(90,5*i,0.1);
 core.wait(0.12);
 core.debug("azimuth->"+5*i+" - pass 1");
 core.debug("altitude= "+core.getViewAltitudeAngle());
 core.debug("azimuth = "+core.getViewAzimuthAngle());
 // move to altitude=90 azimuth=5*i second time
 core.moveToAltAzi(90,5*i,0.1);
 core.wait(0.12);
 core.debug("azimuth->"+5*i+" - pass 2");
 core.debug("altitude= "+core.getViewAltitudeAngle());
 core.debug("azimuth = "+core.getViewAzimuthAngle());
}

As you can see, even if the Azimuth value changes at every step, the output shows that the Azimuth value is always set to something next to 270... and the view does not change.

Now, let's set something different than 90 as Altitude, for example 30. The script now shows that the view correctly changes:

core.moveToAltAzi(30,135,1);
for (i=0; i<=72; i++)
{
 // move to altitude=90 azimuth=5*i
 core.moveToAltAzi(30,5*i,0.1);
 core.wait(0.12);
 core.debug("azimuth->"+5*i+" - pass 1");
 core.debug("altitude= "+core.getViewAltitudeAngle());
 core.debug("azimuth = "+core.getViewAzimuthAngle());
 // move to altitude=90 azimuth=5*i second time
 core.moveToAltAzi(30,5*i,0.1);
 core.wait(0.12);
 core.debug("azimuth->"+5*i+" - pass 2");
 core.debug("altitude= "+core.getViewAltitudeAngle());
 core.debug("azimuth = "+core.getViewAzimuthAngle());
}

So, there something wrong with the moveAltAzi function if Altitude is 90 or -90...

[Axel Hoff (0k-axel)]

Hi Ross (hope that's your first name and not the last name, I don't want to be impolite...),

thanks for your comment. Of course you're right and I've got messed things up, just too much testing on the fly...

So the core.moveToAltAzi function is incorrect just as you stated for altitude of +/-90 only. I've corrected the script as you suggested and the logfile shows that stellarium will show altitude=90 and azimuth=270 regardless from the azimuth given to core.moveToAltAzi.

Nevertheless, there remain two other open questions with core.moveToAltAzi:

1. The script test_altazi3.ssc (attached) will produce the correct movements of view in stellarium. But the result of the core.getViewAltitudeAngle and core.getViewAzimuthAngle is correct only after the second call to core.MoveToAltAzi (cf. log file to script test_altazi3). The movement of view itself is done correctly already after the first call to core.MoveToAltAzi . This is in my opinion another bug of this function family (which I incidentally found by testing on your bug report), I don't know whether one should start a new bug report just for this...

2. When a script runs without explicit pause statements - core.pauseScript() as in my first script or core.wait(n) as in test_altazi3.ssc - not all movements due to core.MoveToAltAzi calls are executed by stellarium. When I run the script test_altazi4 (see attachment) starting from the default view (azimuth=180), only a smooth movement from azimuth=180 to azimuth=330 is shown by stellarium, but the initial movement and the movement from azimuth=0 to 180 is not shown and there are no labels printed at all. In this case, the output of the functions core.getViewAltitudeAngle and core.getViewAzimuthAngle does not follow the motion of the view at all. Furthermore, when calling the script again (with azimuth=330 as starting position), no movement of view at all can be seen.

I'm not sure if point 2 is considered as a bug or if this behaviour is by design (like e.g. in MATLAB, where no plots at all are done without explicit or implicit pause commands while a program is running...). If it is by design, a little hint in the API description could be helpful...

Thank you

Axel

[Axel Hoff (0k-axel)]

Just an idea when thinking once more about the behaviour shown in test_altazi3.ssc:

The reason for the observed behaviour may be a parallel processing issue - if core.moveToAltAzi starts a separate thread for performing the movement, then a subsequent call to core.getViewAzimuthAngle would of course see the old position, since the motion is not yet complete. In this case, one might think about inserting a wait for completion of motion in the corresponding "get"-functions or declare this as responsibility of the script programmer (perhaps with a hint in the API description as suggested bove?!)...

[Ross (rosario-ing)]

2012/10/22 Axel Hoff <email address hidden>

> Hi Ross (hope that's your first name and not the last name, I don't want
> to be impolite...),
>

Hi Alex, yes, Ross is the name that friends of mine usually call me! ;-)

I agree with everything you said, including your idea about the thread for
moveToAltAzi function. This function takes some time to complete, so the
getView[ect]() functions could give erroneous results if called immediately
after the moveToAltAzi function, because the movement is going on.

Thanks a lot for your intensive tests!
Ross

>
> thanks for your comment. Of course you're right and I've got messed
> things up, just too much testing on the fly...
>
> So the core.moveToAltAzi function is incorrect just as you stated for
> altitude of +/-90 only. I've corrected the script as you suggested and
> the logfile shows that stellarium will show altitude=90 and azimuth=270
> regardless from the azimuth given to core.moveToAltAzi.
>
> Nevertheless, there remain two other open questions with
> core.moveToAltAzi:
>
> 1. The script test_altazi3.ssc (attached) will produce the correct
> movements of view in stellarium. But the result of the
> core.getViewAltitudeAngle and core.getViewAzimuthAngle is correct only
> after the second call to core.MoveToAltAzi (cf. log file to script
> test_altazi3). The movement of view itself is done correctly already
> after the first call to core.MoveToAltAzi . This is in my opinion
> another bug of this function family (which I incidentally found by
> testing on your bug report), I don't know whether one should start a new
> bug report just for this...
>
> 2. When a script runs without explicit pause statements -
> core.pauseScript() as in my first script or core.wait(n) as in
> test_altazi3.ssc - not all movements due to core.MoveToAltAzi calls are
> executed by stellarium. When I run the script test_altazi4 (see
> attachment) starting from the default view (azimuth=180), only a smooth
> movement from azimuth=180 to azimuth=330 is shown by stellarium, but the
> initial movement and the movement from azimuth=0 to 180 is not shown and
> there are no labels printed at all. In this case, the output of the
> functions core.getViewAltitudeAngle and core.getViewAzimuthAngle does
> not follow the motion of the view at all. Furthermore, when calling the
> script again (with azimuth=330 as starting position), no movement of
> view at all can be seen.
>
> I'm not sure if point 2 is considered as a bug or if this behaviour is
> by design (like e.g. in MATLAB, where no plots at all are done without
> explicit or implicit pause commands while a program is running...). If
> it is by design, a little hint in the API description could be
> helpful...
>
> Thank you
>
> Axel
>
>
> ** Attachment added: "correct version of test_altazi.ssc"
>
> https://bugs.launchpad.net/stellarium/+bug/1068529/+attachment/3408122/+files/test_altazi_corrected.ssc
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1068529
>
> Title:
> core.moveToAltAzi(90,XX) issue
>
> Status in Stellarium:
> Confirmed
>
> Bug description:
> I write here, because I did not...

[Michael Koch (astroelectronic)]

Hi,

I'm not sure if this it related to the described bug.
I'm using Stellarium in a 180° fisheye projection system, and at startup I'd like to have south at the bottom of the screen.
With init_view_pos = 0,0,1 in the config file this doesn't work, south is at the left or at the right (I don't remember).
However, there is a workaround init_view_pos = 0.005,0,1 which rotates south to the bottom. Then the zenit isn't exactly in the center of the screen, but the error is quite small.

Michael

[gzotti (georg-zotti)]

r8103 should provide a fix for the original issue (scripting). The init_view_pos is not yet dealt with.

[gzotti (georg-zotti)]

r8181 introduces some magic in handling of init_view_pos: To look into the zenith, use x,y,1, so that
0,1,1=West is bottom
0,-1,1=East is bottom
1,0,1=North is bottom
-1,0,1=South is bottom
and intermediate values for x/y give azimuths between those. E.g., 1,1,1 would yield NorthWest at screen bottom.
I hope this works now with all useful configurations...

[gzotti (georg-zotti)]

It seems this is again open!
https://sourceforge.net/p/stellarium/discussion/278769/thread/e8426fb1/?limit=25#cb7e

Something broke between r8181 and V0.15, maybe merge r8441.