almanac issue

[Jasem Mutlaq]

In addition to these issues, looks like we also an issue with the Sun's
diameter as reported here: https://bugs.kde.org/show_bug.cgi?id=497129

--
Best Regards,
Jasem Mutlaq



On Fri, Dec 6, 2024 at 10:45 PM Akarsh Simha <akarshsimha at gmail.com> wrote:

> Hi Hy,
>
> On the contrary, this is the behavior I would expect of the method in the
> KStars pop up menu and details dialog. Relatedly, the bug reported by
> Giovanni on the mailing list through the YouTube video may be because
> transit time is not behaving like this — it’s instead always predicting the
> next transit. For the Sky Map use case, I would want the method to produce
> the closest occurrence to the given time — past or future.
>
> You’re right that this is not what we want always.
>
> But I presume your use case here is to show the moon’s interference in the
> night in the imaging planner. Then, isn’t this exactly the behavior you
> want?
>
> I could be wrong in understanding here; but I’m think if the moon is up at
> midnight + 1 minute, you would want to show a band from the previous rise
> (happened on someDay - 1) and the next set (happening on someDay). One of
> the two, rising or setting would likely be during the day so your moonshine
> band would run either from the rise time all the way into morning twilight
> or from the evening to the set time.
>
> Similar if the moon is not up and rising — you want someDay’s rise for
> this application. You don’t care about the set time.
>
> Finally if the moon is not up and setting — you want someDay’s set time
> and not interested in the rise time.
>
> How else should the API be structured in your opinion? What is the
> expectation? I ask because if you want the moonrise and moonset on a
> particular calendar day (from 00:01 to 23:59) then there are days when
> there is no moon set (because the moonset happens on the next day) or days
> when there is no moon rise.
>
> Regards
> Akarsh
>
>
> On Fri, Dec 6, 2024 at 01:00 Hy Murveit <murveit at gmail.com> wrote:
>
>> Akarsh (and FYI Jasem),
>>
>> I can see some issues in kstars/skyobjects/skyobjects.cpp
>> Please look at comments on line 100 and line 116 (they were written by
>> you Harris and you/Akarsh back in 2004 and 2009).
>>
>> When we ask the almanac for rise and set times on a given "midnight", it
>> either goes ahead 12 hours if the object's AZ < 180 or goes back 12 hours
>> hours if the AZ is > 180, and then
>>
>> this next method has the comments
>>
>>     // We iterate once more using the calculated UT to compute again
>>     // the ra and dec for that time and hence the rise/set time.
>>     // Also, adjust the date by +/- 1 day, if necessary
>>
>>     // By adding this +/- 1 day, we are double-checking that the
>>     // reported rise-time is the _already_ (last) risen time, and that
>>     // the reported set-time is the _future_ (next) set time
>>
>>     // However, issues with this are taken care of in
>>     // SkyObject::riseSetTime()
>>
>> So, assuming the code is accurately following the comments, then the
>> semantics of the calls to KSAlmanac::moonRise(), moonSet(), getMoonRise(),
>> getMoonSet() when KSAlmanac is constructed with midnight on a given date
>> are complex...depending on if the moon is up or not.
>>
>> Working this out and trusting the comments, then if the moon is up, then
>> the reported times are the previous rise and the next set.
>>
>> However, if the moon is not up and rising the the rise is the next rise
>> and the set is the set after that.
>>
>> But if the moon is not up and going further down, then the is the
>> previous rise and previous set.
>>
>> So putting this all together, it seems to me that if I ask for a
>> particular day's rise set by calling with KStarsDateTime(QDate(someDay),
>> QTime(0, 1)) -- one minute after midnight on 'someday', then I may get:
>>
>>    - someDay-1's rise and someDay's set (if the moon is up)
>>    - someDay's rise and someDay's set (if the moon is down but rising)
>>    - someDay-1's rise and someDay-1's set (if the moon is down and going
>>    further down)
>>
>> All that is certainly not what I was expected when coding the imaging
>> planner (really the moon graphics on the alt-vs-time plot).
>>
>> It is possible that these semantics make sense for some aspect of KStars,
>> but we should probably clarify the semantics of the APIs and likely add
>> some new ones for situations like mine.
>>
>> Now that I understand that, I could try and fix that for my special case,
>> but this is really an issue with SkyObject and any code that winds up
>> calling the SkyObject::riseSetTime methods.
>> Do you have time to take a look and let me know how you think we should
>> proceed?
>>
>> Hy
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20241207/b7e268ae/attachment.htm>