How I set These Up

[theskyhound]

I just realized that I missed the first part of your No. 1.

You said, "Most of the lists in the "Update Minor Planets Data" dialog do not appear as subscriptions - only "current bright and interesting minor planets"

I'm not sure what you mean by that. I think maybe you are confusing the SkyTools subscriptions with the MPC lists. They aren't the same thing. The SkyTools subscriptions are a special curated list that I generate every month in house.

[razvan]

What I meant was whether MPC downloads can be added to the Subscriptions page, so that the manual steps can be avoided. 

BTW, it's not fully clear that the subscriptions must be SkyTools subscriptions, i.e. lists prepared by you and distributed via skyhound.com. The screen reas "Choose what to automatically download at startup", the help says "SkyTools 4 it will check the internet for new available downloads". These imply a generic download function. If you meant the subscriptions to be specific to ST, you may want to clarify that.

Another minor comment: if I go in Nightly Planner/Get Observing List/Skyhound, the "Current Bright and Interesting Minor Planets" list appears twice, with two different filenames, current_mp.stx and current_Img_mp.stx. The details (upon doubleclicking) and sizes are identical (see screenshot). I have both ST4V and ST4I installed, perhaps the latter is a list for ST4I?  Sorry to sidetrack the conversation for a moment, it was related to MPCs but if this requires a longer conversation we can do it in a separate thread.

Thanks.

   

[PMSchu]

As a user of the MPC's data, I'm happy with the way this is implemented in ST4. The amount of time required to update the MP data isn't something that I want occurring on program startup. I used to have the Current Bright Minor Planets list update automatically, but with the full MPC database, the time required for the update of the Current MP list (from Skyhound) takes too long & the ST4 splash screen sits in the middle of the desktop until the processing is completed. Now I update that list manually around the beginning of each month then turn it off again.

The time required to select the appropriate MP download option from the MPC  or Bowell list is trivial compared to the time required for the update itself.

I've noticed that the MPC's standard epochs are ~6 months apart. Just barely within the 200 day window for elements.

Phil S.

[theskyhound]

Another minor comment: if I go in Nightly Planner/Get Observing List/Skyhound, the "Current Bright and Interesting Minor Planets" list appears twice, with two different filenames, current_mp.stx and current_Img_mp.stx. The details (upon doubleclicking) and sizes are identical (see screenshot). I have both ST4V and ST4I installed, perhaps the latter is a list for ST4I?  Sorry to sidetrack the conversation for a moment, it was related to MPCs but if this requires a longer conversation we can do it in a separate thread.

Thanks.

The lists for visual observing and imaging may sometimes be identical, but often they are not. Obviously much fainter comets can be imaged than can be seen visually. But what determines inclusion in a list is recent observational data of magnitudes and coma diameters, not limiting magnitude, so this is sometimes the same list of objects. The purposes of these lists is to allow me to distribute curated comet data, something no other software does. When you couple that data with the algorithms for visual difficulty and imaging SNR, you have a powerful way to determine which comets you should be targeting. The casual observer may think that magnitude alone is a good, but they would be very wrong about that. Unlike minor planets, we still rely heavily on amateur observations of magnitudes, coma diameters, and degree of condensation, in order to make accurate predictions for comets.

[razvan]

Phil, that's a fair point, at least as long as updates are synchronous. Perhaps one day they will happen in the background and then automatic updates can take place, but I'll venture to say that'd be a low-priority improvement on Greg's plate. Cloud busting capabilities towards the target objects would be more needed 

[theskyhound]

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.

I outlined the reasons why it would fail to add a new orbit: unless something is broken, the "new" orbit won't be recognized as new unless the numbers don't match. It is possible that the orbit simply didn't change enough. By the way, precalculating the elements doesn't take that long. What takes a long time is when the databases used to plot minor planets on the charts, which are separated by epoch for speed, have to be re-sorted. But this should only happen when a new orbit has been successfully added or updated. I suspect the latter was the issue for you. Unfortunately the amount of coding required to insert the new orbit is a lot, but maybe someday.

I don't understand what you are asking regarding calculating osculating elements... are you suggesting that SkyTools have an n-body calculation built into it to take into account perturbations? If so, that's not a minor thing at all....

I do wonder if you guys aren't taking this to an unnecessary extreme. It is important to recognize that there are many reasons for an orbit to be inaccurate during a close pass. Most orbits simply aren't determined well enough! That is the primary reason for the asteroids to plot off-line, or more commonly, early or late, not the perturbations.  In all but the very closest passes, adding the perturbations should be unnecessary. As they say, you can't polish a turd. Unless the object has really good astrometry that goes back at least for many months, if not years, it may not be worth the trouble to use different sets of elements, unless it is passing very close (say, withing the earth-moon distance). Even then, for most I would think a set of three elements: before, closest, and after, should suffice.

[PMSchu]

Hi Greg,

No, I wasn't suggesting that solving the n-body problem was the way to go in ST4. I do like the idea of a set of 3 element sets calculated for the before, middle & after close approach as HORIZONS provides & have SkyTools interpolate between them as appropriate as you said at the end of your 2nd paragraph: "Unless the object has really good astrometry that goes back at least for many months, if not years, it may not be worth the trouble to use different sets of elements, unless it is passing very close (say, withing the earth-moon distance). Even then, for most I would think a set of three elements: before, closest, and after, should suffice." FYI, Mythbusters did succeed in polishing a turd  .

Phil S.

[theskyhound]

Hi Phil,

I don't think interpolating between sets of osculating elements is a thing. You'd have to assume that everything changed linearly and that none of the elements was coupled heavily to the others. This is why I went straight to an n-body calculation... its the only correct way to do your "interpolation." Its an interesting idea, and maybe there is a paper out there on it, but as I said, I think three sets of elements is fine in most cases, and adding more near close approach is a better solution.

[PMSchu]

Hi Greg,

Sorry I wasn't clear. I didn't mean to interpolate the individual component values of the elements, then calculate a position. What I intended was, assuming we call the preapproach element set E(1), close approach E(2) & postapproach E(3), to calculate a position using E(1) then E(2) and do a time interpolation between those positions before close approach. After close approach, switch to E(2) & E(3) & again interpolate between the calculated positions.

This seems like a possible way to find a good position without the effort of solving the n-body problem. At least one good enough to find the object. If the epochs of the elements aren't too far apart the path of the MP should be close to the line between the positions calculated using E(1) & E(2) for example. If things don't work that way, I stand corrected.

If the described approach is workable, the question becomes, how close do the epochs of osculation need to be to be good enough? It would be interesting to plot the positions calculated by several sets of osculating elements for a time t(x) to see where they appear on the sky. What kind of curvature would the plot of positions show? 

BMD are you aware of software that could perform this type of calculation & plotting? SkyTools would be great for the plotting, but I'm not sure how to get it to calculate a position using a particular epoch for the elements. It picks the elements internally.

Just some spitballing here. It seems like we might be close to something useful.

Phil S.

[bigmasterdrago]

I really like to plot within SkyTools using an hourly osculating element set produced by Horizons. SkyTools has the reference frame of the full deep sky catalogs and really beautiful stellar charting. On the other hand, do a Google for "astronomy gravitational 3D simulation" I've only used Universe Sandbox on a Virtual Reality system. It was beautiful but I never got it to do the solar system simulations I was looking for. Used AstroGrav as a rock simulator for over 12 years. A movie of some of what it does is at https://vimeo.com/629439423

What it illustrates is that each one minute step creates a new element set to produce the next step. So osculating taking into account the gravitational effects of any perturbers. The generated ephemeris is for the elements from the MPC but the positions for the JPL and Lowell are also plotted on the FOV for 2019 XS. What is lacking in AstroGrav is huge sets of catalogs of all of the deep sky objects. You can import as many or as few comets and minor planets as floats your boat, but no faint fuzzies. The stellar data is from GAIA2, soon to be GAIA3. All it does is gravity simulations. No deep sky catalogs.

---

Sorry, I did not finish.
Go let Horizons make you an osculating element set. It will have times (I use 1 hour step near time I want to observe).

Highlight (select) all the text. Copy (Ctrl+c in Windows) the full set at the time you want to observe. The full set:

2459049.708333333 = A.D. 2020-Jul-19 05:00:00.0000 TDB
EC= 5.110455240473311E-01 QR= 5.463558241559977E-01 IN= 7.681152919084764E-01
OM= 1.584502008168773E+02 W = 2.489835182502317E+02 Tp= 2459111.211830436718
N = 8.344366050810789E-01 MA= 3.086792306767361E+02 TA= 2.481067701965983E+02
A = 1.117396099282022E+00 AD= 1.688436374408047E+00 PR= 4.314288201259102E+02

Then edit the rock and paste in the new set. Let it finish. It takes some time. Then create in SkyTools, your own personal ephemeris of that date and time near what was in the osculating set.