Merge lp:~i-martividal/stellarium/Observability-newHeli into lp:stellarium
Status: | Merged |
---|---|
Merged at revision: | 7173 |
Proposed branch: | lp:~i-martividal/stellarium/Observability-newHeli |
Merge into: | lp:stellarium |
Diff against target: |
239 lines (+99/-15) 4 files modified
plugins/Observability/src/Observability.cpp (+86/-11) plugins/Observability/src/Observability.hpp (+11/-2) plugins/Observability/src/gui/ObservabilityDialog.cpp (+1/-1) plugins/Observability/src/gui/ObservabilityDialog.ui (+1/-1) |
To merge this branch: | bzr merge lp:~i-martividal/stellarium/Observability-newHeli |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
gzotti | Approve | ||
Alexander Wolf | Approve | ||
Review via email: mp+242650@code.launchpad.net |
Description of the change
Dear all,
I have to give a talk about Archaeoastronomy this afternoon, and wanted to use Stellarium for a nice real-time exercise. Then I realized that the outputs for "Acronycal" and "Cosmical" are swapped in the screen. Apart from this bug, these quantities are computed with respect to the Sun's rise/set at the horizon, and not with respect to the astronomical twilight (which should give better estimates for the Heliacal and Acronycal events).
So:
1.- I have corrected the swap. Now the output agrees with what the documentation says.
2.- The Heliacal and Acronycal ephemeris are now computed with respect to the astronomical twilight. Since the Sun's altitude at this twilight can be fine-tunned in the config window (together with the effective altitude of the horizon for the star to be visibile), this gives the user a lot of flexibility to study the Heliacal rise and set of stars.
3.- I've also changed the documentation, to reflect the new way Observability estimates these ephemeris.
Now, the matching between the Heliacal rise of Sirius at 2500 bC and the beginning of the old Egyptian calendar is perfect, as well as the Heliacal rise of eta-Uma, as seen from the Cochasqui pyramids in Ecuador (for this heliacal rise, the star is only visible above ~10 degrees from the pyramids, so the option of increasing the horizon's altitude was quite useful here!).
Best Wishes,
Ivan
Hi Ivan!
The terms "acronychal" and "cosmical" relate to geometry, not observability. And these events relate always to mathematical horizon, not any twilight phase, solar or horizon altitude or practical observability. Think about renaissance scholars doing this simple analysis on an astrolabe (planisphere precursor). Please fix that to adhere to these definitions for these particular terms.
Of course, real observability is of greater concern to most of our users out under the sky (or indoors planning an observing session or their next astro travel). So adding a line "object visible for sun lower than (settable: e.g.-12) degrees" or similar may be more helpful to those users.
Your plugin can become superbly important when the heliacal predictions become more accurate. There are two known families of procedures I am aware of: One goes back to early 20th century research around Mesopotamian clay tablet records. Carl Schoch has written table-based procedures (based on the arcus visionis in the Almagest), but his work may be hard to find (at least online.)
A more modern approach was worked out by Brad Schaefer, e.g. in JHA adsabs. harvard. edu/full/ 1987JHAS. ..18... 19S
http://
There is also an article by him with (a bit rough) BASIC code in some Sky&Telescope of that period. The algorithm includes some approximations of solar positions etc, these need to be replaced by calls to StelCore methods.
Although his method claims superiority, it is according to observers not yet fully clear which is the better approach, so I'd like to have even both models implemented sooner or later.
Maybe you can follow Schaefer's steps for a first more thorough solution of heliacal phenomena. See also http:// www.iol. ie/~geniet/ eng/vislimitass ump.htm for more related work. Putting these various methods in Stellarium would be very fine! (Some parts occur in various places of sky brightness already.)
Another thing is the landscape horizon height. You don't need your switch any longer: I have added functionality in 0.13.0 to make landscapes more intelligent: You can test opacity at a given direction. Opacity==0 means "landscape is transparent, i.e., no mountain in the way". This would be very nice to see used for true-landscape analysis. Just make sure to get the lowest appearance of an object, in case something rises along a valley, hides behind a mountain and becomes visible again...