How I set These Up

[razvan]

I've just found this thread and am trying to do the same. A sanity check: when calculating the ephemeris, which coordinate center should I use?  Horizons defaults to Sun's center, should I leave it as such?

Thank you.

[PMSchu]

Hi Razvan,

I'll defer to BMD on the question of ephemeris calculations in HORIZONS since I only use ST4v to calculate the ephemeris. The trick with ST4v is to input the appropriate epoch for the osculating elements. If the epoch is too far off the ephemeris positions will be incorrect, as you're aware. Back in July 2021 (earlier in this thread) BMD & I tried to input elements from HORIZONS at fractional days, like Jul 9.75 with limited success. This would be the ideal way to deal with close approaches using ST4, enter osculating elements at for example, October 9.0, 9.25, 9.50 & 9.75, then have ST4 choose the closest epoch for the calculations. Currently ST4 doesn't seem to keep epochs that are too close together in time as this would require. I imagine having the program try to keep this all straight would really make things complicated, as if orbital mechanics aren't already complicated.

All this stuff is pretty niche, so I'm sure that Greg has more pressing & useful things to work on for the ST4 community. Perhaps with more users showing interest in this activity, it'll move up the scale in importance. 

Phil S.

[bigmasterdrago]

Always use your observing location. I always use hour steps over what ever time span I'm interested in. And run with the close approach minimum distance time as the center. Like this set up for 48 hours:

   

Or change the "Ephemeris Type" to Osculation Orbital Elements which will let you copy and paste the full hourly element set from a specific time into SkyTools 4v. That give you the opportunity to create a precision ST finder chart for that rock at a time very near (couple hours) that set of osculating elements. This is specifically necessary due to ST not being able to predict an n-body plot. The chart (IA) has to be for the specific time near those elements.

Remember that when making a set of osculating elements to always use UT not UT-(time zone) as you would do for just a strict local time ephemeris.

In the example 2021 TQ1, the Horizons hourly ephemeris indicates the rock is not only too low during that 48 hour near Earth pass, but too faint.

However, 2019 XS on November 9, 3:48UT with an uncertainty of <1min and has good conditions from Nov 9, 23:00CDT to Nov 10, 03:00CDT:


see text file

So use Horizons to make an osculating element set for the hour of expected observation, then copy all of it and edit that rock, pasting that set into the complete field.

Unfortunately, when I copy those osculating elements for 23:00CDT on November 9th and then attempt to edit by pasting in the edit field, I get a (not Responding) then ST4 crashes and 2019 XS is no longer in the database. Maybe the date is too far in the future to predict or edit future elements. But I will try closer to the date of observations. I want a good finder chart so can wait. But for now, Horizons will predict the location or I'll turn to a stand alone gravitational simulator that takes todays elements (JPL epoch July 1, 2021 JD 2459396.5) and predicts the location on Nov. 9, 23:00CDT as RA 2h46m40s DEC -4°8'18s, azi 158°, el 53° moving 62.2"/min, mag 13.2, %ph 96.

[theskyhound]

BMD,

Thank you for this nice description of the process to choose a target & get ST4 set up to observe a close approach. Much appreciated!

Greg, it would be great if this procedure could be added to the ST4 Help system for documentation & reference by other users. Possibly a sticky post in the forum would work too, but not all ST4 users may be on the forum.

Phil S.

My plan is to start making Youtube videos that explain this sort of thing, because I feel that it is easier to understand a video procedure than a written one. The idea is to make them short and to the point for exactly this sort of thing.

My problem has been that coding keeps taking a lot more of my time than I expect it to, and I feel the need to focus on one or the other, so the videos keep getting put off.

The plan is that after the next update I will have time to get a bunch of these done. I will be sure to include this procedure and related procedures.

Thanks

[theskyhound]

By the way, I love that this forum has taken off, and I hope that other observing forums will do the same in the future. But the downside is that it is becoming time consuming for me to scan all of the messages for things I should comment on, and I fear that I am going to miss some posts that I can help with, or that I have been asked to provide an answer. Please feel free to ask me questions when you have them, and in that case, or if you feel that I should be aware of any post for any reason, please send me a private message with a link so that I don't miss it.

Thanks!

[theskyhound]

Hi Razvan,

I'll defer to BMD on the question of ephemeris calculations in HORIZONS since I only use ST4v to calculate the ephemeris. The trick with ST4v is to input the appropriate epoch for the osculating elements. If the epoch is too far off the ephemeris positions will be incorrect, as you're aware. Back in July 2021 (earlier in this thread) BMD & I tried to input elements from HORIZONS at fractional days, like Jul 9.75 with limited success. This would be the ideal way to deal with close approaches using ST4, enter osculating elements at for example, October 9.0, 9.25, 9.50 & 9.75, then have ST4 choose the closest epoch for the calculations. Currently ST4 doesn't seem to keep epochs that are too close together in time as this would require. I imagine having the program try to keep this all straight would really make things complicated, as if orbital mechanics aren't already complicated.


Phil S.

You are correct that SkyTools will look at the epoch of osculation and use the orbit with the closest time. The only limitation that I am aware of, for epochs being close together recognized as the same epoch, comes from the a test for round off error in the times so that epochs that are indeed the same are recognized as such. I just checked the code and it is set to consider epochs that are within one minute of each other to be the same epoch. So unless my conversion of one minute to Julian Centuries is off, then epochs that are more than a minute apart will be stored separately.

So I suspect that the orbits are being combined for other reasons. The orbital elements are also checked against each other, and if there is little difference, then they are determined to be the same orbit (epoch). So for example, if you took two orbits for a main belt asteroid that were calculated for times a day apart, they would probably have almost the same elements, and presumed to be the same orbit. So it may simply be that your orbital elements aren't changing as quickly as you think they are.

SkyTools 3 had a less accurate orbital model, so when we had close passes in years past, I would use Horizons to generate orbital elements like you guys are doing in order to improve the accuracy. I found that producing elements once per hour was sufficient.

[PMSchu]

Hi Greg,

Back when BMD & I were trying to use a set of elements for a close pass, I tried to input elements from HORIZONS at 6 hr intervals. ST4v (4.0j R2) would only keep the first one that I entered & entering a new one was ignored. It also seemed that after a new set of elements was entered, all of the precalcs used to speed up plotting on the charts got repeated each time. With my MP database this took some time & I ended up with the same epoch date anyway - a waste of time. Can't add an element set from the MPC for different times because they only provide their 'standard' epoch time, like 2021 July 4 or the NEAs at Today's Epoch as options. Trying to add elements directly into the MP DB was an old method that you thought was eliminated, but we wiley users tried anyway  .

Would it be feasible to use a set of 3 osculating elements pre-, at & post-close approach taken from the HORIZONS system & interpolate between them during the pass? It would complicate the ephemeris calculations, but since it's only needed for the object of interest, it shouldn't be time prohibitive. As noted above this is a very niche application, so understandibly not a priority. I don't know how well interpolation of positions calculated from 2 sets of elements would work. Possibly weighting the results based on the time difference between the element epochs & the time for the calculation could work.

Cool stuff,

Phil S.

[razvan]

There are two things I wanted to ask

1. Most of the lists in the "Update Minor Planets Data" dialog do not appear as subscriptions - only "current bright and interesting minor planets" are subscribable.

It requires 7 clicks (shown below) to update a list and while it's a small thing, the programmer in me wishes there were an automatic refresh. I understand why some of the larger lists (eg ASTORB or the full MPCORB) should stay as an explicit load, to avoid hitting the distribution servers unnecessarily, but perhaps some of the smaller ones could be made available as subscriptions?

• click on Data
  
• click on Minor Planets
  
• click on Download/Import Data
  
• click on the desired list
  
• click on Download
  
• click on Close (after the d/l finished)
  
• click on Accept
  

2. There are two lists for NEAs. Is there any reasons not to always use the second one (perhaps only when looking at dates distant from today)?

• MPC NEA: Orbits for Near Earth Asteroids (NEAs). Updated a few times per day.
  
• MPC NEA Today: Orbits for Near Earth Asteroids (NEAs) at today's epoch for more accurate positions. Updated a few times per day.
  

Thanks,
Razvan

[theskyhound]

There are two things I wanted to ask

1. Most of the lists in the "Update Minor Planets Data" dialog do not appear as subscriptions - only "current bright and interesting minor planets" are subscribable.

It requires 7 clicks (shown below) to update a list and while it's a small thing, the programmer in me wishes there were an automatic refresh. I understand why some of the larger lists (eg ASTORB or the full MPCORB) should stay as an explicit load, to avoid hitting the distribution servers unnecessarily, but perhaps some of the smaller ones could be made available as subscriptions?

• click on Data
  
• click on Minor Planets
  
• click on Download/Import Data
  
• click on the desired list
  
• click on Download
  
• click on Close (after the d/l finished)
  
• click on Accept
  

2. There are two lists for NEAs. Is there any reasons not to always use the second one (perhaps only when looking at dates distant from today)?

• MPC NEA: Orbits for Near Earth Asteroids (NEAs). Updated a few times per day.
  
• MPC NEA Today: Orbits for Near Earth Asteroids (NEAs) at today's epoch for more accurate positions. Updated a few times per day.
  

Thanks,
Razvan

Hello,

1. There is an oid saying in software development: "simple things should be simple and complex things should be possible". I think this falls under that. Most users will be satisfied with the automatic downloads of minor planets. Only a very few are going to want to do it manually, and that makes them power users. Power users generally want options because what they are trying accomplish is complex and varied. The number of steps you describe are due to the fact that this is not something even a power user should not be doing very often under most circumstances, and having lots of options is almost a requirement. I don't see a lot off streamlining that could be done while preserving the functionality.

2. I'll refer you to the MPC docs for better information about the difference between these two lists, but in general, the second list should be more accurate since it is generated for today's epoch rather than their absurdly spaced standard epochs. BTW they used to generate standard epochs as often as every 40 days. With so much time passing between standard epochs now, even main belt asteroids are no longer accurately plotted at opposition when too much time has passed. The problem is that you may find that they have not included all of the NEA's in both lists...this is why I included both as downloads.

[razvan]

Thanks Greg, that helped.