Target rise/set times give negative altitudes.

[jberlanga]

Not sure if this is a real issue or just a misuse of target_rise_time/target_set_time by me.

I noticed (when wrapping up the current iteration of the Summer Triangle tutorial) that if you plug target rise/set times into an altaz frame, you get negative altitudes on the order of a few arcseconds below the horizon. This is a problem for plot_sky, at least, if users employ the broadest definition of "visible" for targets (sun is down, looking at target at/between rise and set times).

See example below:

altair_rise = subaru.target_rise_time(time, altair)
altair_set = subaru.target_set_time(time, altair)

vega_rise = subaru.target_rise_time(time, vega)
vega_set = subaru.target_set_time(time, vega)

In [128]: subaru.altaz(altair_rise, altair).alt
Out[128]: −0∘00′01.5222′′

In [130]: subaru.altaz(altair_set, altair).alt
Out[130]: −0∘00′01.4204′′

In [132]: subaru.altaz(vega_rise, vega).alt
Out[132]: −0∘00′02.2992′′

In [134]: subaru.altaz(vega_set, vega).alt
Out[134]: −0∘00′05.0659′′

[bmorris3]

This is the way rise/set are intended to work at present – the last step in the rise/set time calculations is an interpolation with an accuracy of a few arcseconds.

@astroplanners/astroplanners-contributors Would anyone consider this a bug, or should we just put a warning into the rise/set docstrings describing the precision? Maybe we should post another issue reminding ourselves to write a precision kwarg for rise/set/transit calculations.

[cdeil]

I'd say it's normal that altitudes are slightly below or above 0, because computing the rise time and altitude has a finite precision.
+1 to explain this somewhere in the docs, so that users asking about this can be referred to that section.

[bmorris3]

@cdeil Where do you think an appropriate place in the docs is? Should it go in the rise/set examples?

[cdeil]

I don't know. Let's wait for #42 and the other large PRs to go in master first.
I think this issue is a minor add-on somewhere in the docs that can be postponed to 0.2 if no-one has time to address it tomorrow.

[bmorris3]

@eteq / @cdeil Now that #42 is merged, is there a natural place to leave a note about how we expect the precision in rise/set time to be +/- a few seconds?

[cdeil]

I'm still not sure where to put it.

But I think it could go next to http://astroplan.readthedocs.org/en/latest/tutorials/iers.html.
That IERS section isn't really a tutorial ... maybe both could go in a FAQ or "caveats" section?

(I also think the current "Getting started" section is too short ... it doesn't do anything interesting ... maybe we can have another short hangout today to discuss docs? I'm available for another hour or two ...)

[cdeil]

Moving this to 0.2 ... it shouldn't block the 0.1 release which is long overdue.

[bmorris3]

The docs explaining this counter-intuitive result have been added into the FAQ in #94.