Update example and add stationary scenario to plot as optional line

[wbalmer]

The new default days_forward and days_backward for generate_plots are not good matches in the example, so we should also make a change in hd131339a.py, to set these parameters to 2600 days backward and -1200 days forward when we call generate_plots in the example. (although with these parameters the year axis labels get a bit dense)

location in your repo if i'm not mistaken: https://github.com/tomasstolker/backtrack/blob/f1c92d6bef08c49aaba4f358182be188228e459c/tests/hd131339a.py#L8

The stationary background plot was commented away so that plot is no longer made. (do we want to integrate the stationary scenario in the regular plot as an optional line )?

Originally posted by @gotten in https://github.com/wbalmer/backtrack/issues/13#issuecomment-1859011840

[wbalmer]

Should be addressed in de0e8f6 and included in PR #18 . I've added an option to include the stationary case in both radec and seppa modes of the trackplot function.

[gotten]

We probably have to make the days_forward,days_backward,jd_tt parameters a bit more intuitive (make the parameters the start and end date for the generated track (in decimal years and convert to jd for internal use?), delete the jd_tt parameter. Don't precisely recall what I used jd_tt for originally but it doesn't add anything at the moment (apart from confusion). It defines a reference data somewhere in 2022 against which days_forward and backward are defined.

We probably have more use for a time parameter at which to pin the stationary solution. (For a future commit)

In the current system/commit: Days_forward=-500 (note the minus) probably gives a clearer example without weird (fractional) x-labels.

[wbalmer]

Definitely agree about jd_tt, it's vestigial of the old first notebook. I'll open a new issue to keep track of that improvement, since I agree it makes sense to overhaul the time interface/bookkeeping.