2022 Sep 30
This update contains many small improvements and bug fixes to Find_Orb.
The revised source code is on GitHub; if you're on Linux or MacOS or FreeBSD, you can follow the usual instructions for building and installing or updating Find_Orb on non-Windows systems.
I've not posted Windows .EXEs to the "usual" Find_Orb download site yet. As noted, this is still 'in testing'. But you can click here for the revised Find_Orb for 64-bit Windows or click here for the revised Find_Orb for 32-bit Windows. Then (as is usual with pre-built Windows Find_Orb) unZIP it in your directory of choice.
As far as I know, this update is quite stable and problem-free. However, it's mostly been tested by me, and software often breaks when used by people who didn't write it (please let me know what issues you see!). So I suggest either backing up your existing Find_Orb install, or simply running this in a new directory.
• You can reset G (magnitude slope parameter). (This was the change that prompted me to post an 'in testing' update.)
• On loading an object, you get a splash screen with version information.
• Hit 'c', and you get a calendar showing lunar phases. (Sort of silly, but I, for one, find having that info a keystroke away to be useful.) You can copy the file calendar.txt to calend.txt and edit it with any text editor, and insert your own events, and Find_Orb will then use calend.txt. The only currently-listed events are phases and solar and lunar eclipses.
• Find_Orb's initial orbits are slightly more likely to get it right the first time, without requiring you to tweak anything.
• Lots of documentation changes within the program for the various 'help' screens (the ones that show up when you hit an unrecognized key or click on the [?] buttons.)
• Generate ephemerides for the "observatory code" (Opt), and Find_Orb will show ephems for the "optimal" place on the earth, one that puts the object decently above the horizon and the sun decently below the horizon at that moment. This was something that was added for NEOfixer use, so we could say "is it possible for anybody to get this, and is your particular view of it so bad compared to somebody else's that maybe you ought to look at something else?"
• The galactic confusion parameter should be slightly more accurate, especially in places where the value varies a lot in that area (borders between confused and "clearer" areas). I was extracting the GC value from a lookup table; now, the code interpolates within the table.
• The program can be compiled and run on FreeBSD. You may need to install gmake; it's not available by default. I've recently been using the GhostBSD variant of FreeBSD, and rather like it.
• New option in the 'make ephemeris' menu to turn on display of the three-character abbreviation for the constellation (UMa, Cas, Sgr, etc.) in which the object happens to be.
• If the mouse 'hovers' over the H (absolute magnitude) text, you'll see the expected range of diameters as hover-text. Move the mouse over an observatory code listing at the bottom of the screen, and you'll get info on how many observations that observatory made and the time range.
• You can generate ephemerides that show motion in total/PA and in separate RA/dec components at the same time. (Previously, you could get one or the other, but not both.)
• If you select state vector output for ephemerides, you can choose the epoch (defaults to 2000, but you can enter any year or 't' for true or 'm' for mean epoch of date).
• The sky brightness takes into account the effects of lunar eclipses. Run ephemerides during such an eclipse, and the sky brightness will drop and the recommended exposure times will be shorter. (Added for the 2022 May 16 eclipse, and should help for the upcoming 2022 November 8 eclipse. The sky gets remarkably darker during a total lunar eclipse, or even an umbral one.)
• Lots of really nitpicky fixes for observatory positions. MPC's position for Arecibo, for example, is at least 90 meters off horizontally and about 50m vertically. Dave Tholen has nailed down the position of (T12) to about a meter, which caused a (tiny) correction to every telescope on Mauna Kea. You can generate ephemerides centered on any of the five Lagrange points for the Earth-Moon, Earth-Sun, or Earth-Jupiter cases. The rovers.txt list of observatory corrections documents the various changes.
Important: If you've run into a bug not listed below, please e-mail me at pôç.ötulpťcéjôřp@otúlm (after removing diacritical marks.)
• Hitting the Enter key on the numeric keypad didn't do anything when entering text, at least on most platforms.
• You could hit Ctrl-D and tell Find_Orb to generate a slew of statistical ranging orbits. But it would only run for three seconds, then return however many it had computed by that point.
• If you set up Find_Orb on a big screen with a small font, and had more than 280 columns, it would usually crash. (My screen isn't quite that big, and my eyesight isn't up for a font that small!)
• Ephemeris uncertainties were frequently wrong if the solution involved non-gravitational parameters.
• If you had Find_Orb read in a file with more than one object, Find_Orb could (under unusual circumstances) get confused and apply the uncertainties given for object A to observations of object B.
• The links in pseudo-MPECs to Tony Dunn's (very nice) Orbit Simulator were broken.
• Some people reported display issues on OS/X (strange colors). I ran into a similar issue in FreeBSD and fixed it. I think it'll fix the OS/X problem as well, but will have to rely on a Mac user to tell me.
• Element covariances and uncertainties were always accurate... but were always computed for ecliptical elements, not the selected frame. If you reset Find_Orb to show equatorial or body frame orbital elements, the uncertainties didn't change (and would be wrong). This affected uncertainties in Ω=ascending node, ω=argument of perigee, and ι=inclination; other quantities were unaffected.
Some background: This change was added after a discussion about magnitude uncertainties. 2022 OS2 had been observed at phase angles of about 19 to 21 degrees. A month later, Dave Tholen tried to observe it at a phase angle of 52 degrees, and found it to be 1.8 magnitudes fainter than expected.
This sort of thing happens annoyingly often. Usually, an object turns out to be fainter than predicted, and you waste time taking exposures that are too short to show the object. Less often, the object turns out to be brighter than expected, and you waste observing time taking a longer exposure than was really needed. Dave suggested that trying a range of possible G values might give you a concept of how uncertain the predicted magnitude was. Obsevers could then plan accordingly. To test that out, I added the ability to modify G.
Click here for some discussion of what was learned about magnitude predictions by doing this.
Assuming you've got the new version up and running, things should be quite straightforward :
Lessons learned about magnitude predictions : Naturally, I tried finding a value of G that would have enabled Dave to get the correct magnitude prediction. It turns out you have to set G=-0.3 to get anywhere near the magnitude Dave actually measured. Maybe G=-0.25, if you allow for the fact that the photometry was at the faint end and probably not as precise as you'd ideally want.
Setting negative G is Wrong. (Maybe even Rong, so wrong it's not even spelled correctly.) Negative values of G are physically meaningless; I had to modify Find_Orb to handle them without crashing with square roots and logarithms of negative numbers. With G=-0.3, any prediction at a phase angle greater than 76 degrees gets a math error.
My initial thought had been that in a case such as this, where you only have a small range of phase angle data and G can't be fitted accurately, one should compute magnitudes with (say) G=0 and G=0.35 (a range suggested by Petr Pravec, based on observing lots of NEOs) and consider the difference to indicate photometric uncertainty. I still think that'll work in some cases. In the above case, though, G=0 would have led to a predicted magnitude of 22.01, and G=0.35 to mag 21.71, only a 0.3-mag difference.
Several possible reasons were suggested as to why this particular object was fainter than predicted, and why predictions tend to be too optimistic in general :
• Survivor bias. The photometry we get comes from people who observed the object. If it was faint at the time (light-curve effects, for example), you don't get that photometry pulling your H value fainter.
• Misleading photometry. There's one station here with magnitude residuals that are a little toward the bright end of things, and that did bring the predicted magnitude brighter by a hair. It wasn't nearly enough to explain matters here, but you could see it being an issue with other objects, especially ones with only a few tracks.
(I should note here that there are some things I could do better in Find_Orb here. Photometric outliers should be excluded. I don't do a particularly good job of weighting photometry. Find_Orb has a lot of good code in it to handle photometric errors; it adjusts for 'over-observing', can correct for the assumed rate at which observers blunder, and corrects for catalogue bias. None of that applies to photometry. And I don't think others are doing much better.)
• Irregular shape. 2022 OS2 had (before Dave's observation) H=23.0, and is certaintly small. If it's a little flat, Dave may have been observing it edge-on, or just caught it at the faint point in its light curve.