• (2021 Sep 27) Can generate ephems from Lagrange points
• (2021 Sep 21) Many user interface improvements
• (2021 Aug 24) Better initial orbit determination
• (2021 Jun 07) Added state vector ephem options
• (2021 May 07) Ability to solve for four-parameter comet model
• (2021 Mar 7) Observers specified correctly (usually) for
program codes
• (2021 Mar 7) New 'non-gravs' selection menus
• (2021 Jan 23) Reset format for RA/decs in ephemerides
• (2021 Jan 23) Can show asteroid names
• (2021 Jan 23) Better initial orbit determination
• (2020 Nov 06) Ephems for a list of arbitrary times
• (2020 Oct 24) Better ability to combine
observations from different designations
• (2020 Oct 24) Menu bar improvement
• (2020 Oct 24) Ability to specify ephemeris location
• (2020 Oct 24) Ephems for times/places of the observations
• (2020 Oct 24) 'Automatic' ephemeris step size
• (2020 Oct 24) Cut/paste works
• (2020 Oct 24) JSON ephems, elements, observations,
residuals
• (2020 Oct 24) Mouse clicks in 'observatory' area
handled
• (2020 Oct 24) Astrometry written to the ADES format
• (2020 Oct 24) Ability to specify telescope
parameters
• (2020 Oct 24) Exposure duration/SNR in ephems
• (2020 Oct 24) 'Galactic confusion' in ephems
• (2019 April 4) (Much) better Spanish translation
• (2017 November 4) Ability to treat all observations
as if they're a single object
• (2017 November 4) Better initial orbit determination
for longer arcs
• (2017 November 4) Proper handling of A/YYYY objects
• (2017 November 4) Revised astrometric error handling
• (2017 June 22) Fixed bug in handling .rwo data
• (2017 June 22) Fixed bug with satellite observations
and Monte Carlo variant orbits
• (2017 January 18) Many small changes
• (2017 January 18) Ability to reset comet
constants in the Marsden-Sekanina model
• (2017 January 18) Ability to get vectors
in km/s and km, or other units; and in equatorial or ecliptic frames
• (2017 January 18) Revised handling of Find_Orb
extensions for sigmas, epochs, etc.
• (2017 January 18) Setting of epochs improved
• (2017 January 18) Elliptical position sigmas, and new ways to set sigmas
• (2016 April 21) Satellite offset workaround
• (2016 March 14) 64-bit Windows Find_Orb
• (2016 March 14) Better language support
• (2016 March 14) Debiasing problem fixed
• (2016 March 14) Vector ephemeris options
• (2014 August 8) Find_Orb can now use DE-432, 431t, 432t
• (2014 August 8) Ability to specify uncertainties in magnitude and time;
revised weighting scheme
• (2014 August 8) New formats for precise RA/decs
• (2014 August 8) Use of .rwo radar data
• (2014 August 8) Use of radar data
• (2014 August 8) Fix for bug in asteroid perturbations
before 1800 and after 2200
• (2013 November 15) Ephemeris uncertainties, mag limit
• (2013 November 15) Information about MPC station locations
• (2013 November 15) Way to reset the available time range
• (2013 November 15) Ability to 'greenlight' NEOCP data for distribution
• (2013 November 15) 'Computer readable' ephemerides
• (2013 September 1) Fix for MOID bug
• (2013 Aug) Fix for impact lat/lon bug
• (2013 Aug) Find_Orb can now use DE-431
• (2013 February 24) More asteroid perturbers
• (2013 February 24) Asteroid mass determination
• (2013 February 24) Asteroid-centric ephemerides
• (2013 February 24) Radar observation info
• (2013 January 11) Better stability
• (2013 January 11) Display of uncertainties
• (2013 January 11) Extensions to the MPC astrometric format
• Revised observation filtering/blunder management
• Better handling of over-observed objects
• Precise residual check-box
• Use of AstDyS/NEODyS .rwo weights and biases
(Plus other changes going back to about 2000, but which I've not indexed
as nicely as the above.)
• (2021 Sep 27) Can generate ephems from Lagrange points: In the Make Ephemeris dialog, you can enter the codes (SE1), (SE2), ... (SE5) to generate ephemerides as seen from the Sun-Earth Lagrange L1-L5 points. (To review, Sun-Earth L1 is about 1.5 million km closer to the sun than we are, and is where DSCOVR and SOHO are. Sun-Earth L2 is 1.5 million km the other way, outside the earth's orbit; this is where Gaia and Spektr-RG are, Herschel and Planck were, and where we devoutly hope the James Webb Space Telescope gets to. SE3 is on the far side of the sun from us, and SE4 and SE5 are the "Trojan points" one AU from both us and the sun.) Similarly, (EM1)... (EM5) are the Lagrange points for the earth-moon system, and (SJ1)... (SJ5) are the Lagrange points for the Sun-Jupiter pairing. SJ4 and SJ5 can be of modest use when examining Trojan asteroids.
• (2021 Sep 21) Many user interface improvements:
• (2021 Aug 24) Better initial orbit determination: Quite a bit of work has been going on "under the hood" to ensure that Find_Orb is more likely to simply read in observations and get the correct orbit, without human intervention being required. This was proving to be badly needed for automated use, where one might (say) take observations of the million or so objects tracked by MPC and compute orbits for all of them. Find_Orb still does not do that -- I'm chasing down a lot of "problem" cases -- but it's much better than it was.
• (2021 Jun 07) Added state vector ephem options: If you enter the Make Ephemeris dialog and hit C (or click on "C Observables"), you'll get a list of possible ephemeris types, including "State Vectors" and "Cartesian coord positions". For those two, the resulting menu will show options to determine if the state vectors/positions generated are in equatorial or ecliptic J2000, and if they are in kilometers, Earth radii, or AU. For state vectors, you can also switch between having the velocities be per second, minute, hour, or days. As before, you can set the "location" for such ephemerides to be (Bar) for a barycentric frame of reference, (Sun) for heliocentric results, (500) for geocentric, and so on.
• (2021 May 07) Ability to solve for four-parameter comet model: The "usual" three-parameter comet model says that the comet is active as a function of distance from the sun, generating an outward force; a force "along" the orbit perpendicular to that; and an "out-of-plane" force. Sometimes, a fourth 'DT' parameter is used, giving a time delay, because comets sometimes don't reach peak activity until some days or weeks or months after perihelion. So we compute the total comet acceleration based on how far the object was from the sun DT days ago.
If you hit '*' or '^', or click on 'NonGravs' in the menu bar*, you will see that in addition to the previously available options, there is a new "Comet model (A1, A2, A3, DT)" option.
Be warned that you need (usually) three or more oppositions before you can get a meaningful result. You'll see the residuals drop with shorter arcs if you use this model, but it will not necessarily correspond to any actual comet physics in such cases.
You probably won't see 'NonGravs' in the menu bar by default. Click on '+' in the menu bar to get more menu bar options, though, and it'll show up.
• (2021 Mar 7) Observers specified correctly (usually) for program codes: Tony Evans kindly pointed me to an update for the MPC's list of program codes (the version I had dated back to about 2005). If the observers aren't specified in the input astrometry, Find_Orb can use this information to figure out which observer(s) made the observations for a given obscode/program code combination, and list them correctly in the pseudo-MPEC.
• (2021 Mar 7) New 'non-gravs' selection menus: Selecting non-gravitational force models was possible in Find_Orb, but somewhat convoluted. In particular, the choice between inverse-square forces of the sort caused by solar radiation pressure (SRP) and comet outgassing forces was determined by looking at the object designation, and was not easily changed.
Now, if you hit '*' (asterisk) or click on 'NonGravs' in the menu bar bar*, Find_Orb will show a small menu with available non-grav models. Select one, hit 'f' to do a full least-squares step, and Find_Orb will converge on a solution (if one exists) using that model. Click on the [?] shown in the small menu to get further documentation.
• (2021 Jan 23) Reset format for RA/decs in ephemerides: When making ephemerides, if you select the 'advanced options', you see that the display of RA/decs can be turned on or off. When you turn it on, you get a little menu that will look like this :
(*) HH MM SS.sss, dd mm ss.ss ( ) HH MM SS.ssssss, dd mm ss.sssss ( ) HH MM.mmmm, dd mm.mmm ( ) HH MM.mmmmm, dd mm.mmmm ( ) Decimal degrees to 10^-6 deg ( ) Decimal degrees to 10^-15 deg ( ) Decimal hours and degrees
The top line has been the only option for years, and I had some requests for more flexibility. Pick a different format, and the ephemeris output will be in that format.
Pro tip : You can get this by clicking on 'Advanced options', then on 'RA/decs' to turn it off, then on 'RA/decs' again to turn them back on. However, hitting '1' in the ephemeris dialog will switch that option, even if the advanced options aren't showing. When I want to switch RA/dec formats, I just hit '1' twice.
Further pro tip : if you want to add further possible formats, edit efindorb.txt and search for RA_DEC_FORMAT for instructions on how to do it (it's not particularly difficult).
• (2021 Jan 23) Can show asteroid names: Normally, if you load up data for, say, asteroid (4179), the name of that object won't be shown. If you download this file to your Find_Orb directory, Find_Orb will show that asteroid as (4179) Toutatis. The name will appear in orbital elements and in the pseudo-MPEC.
• (2021 Jan 23) Better initial orbit determination: The program stumbled over some situations involving bad data, and often if there were some radar observations in an arc, even if those observations were perfectly good. It now does a much better job in such cases. Still some work to be done, but the vast majority of arcs just load up and result in good orbits, with outliers appropriately identified and rejected.
• (2020 Nov 06) User-specified irregular horizons : Telescope pointing limits can be specified in scope.json. For many people, being able to say that they can't go below a certain altitude, and/or above a certain declination (for equatorial mounts that can't reach Polaris) or above a certain altitude (for alt/az mounts reaching "Dobson's Hole") may be enough.
Others, however, can specify their horizon as a series of alt/az points. A made-up example is given for (310) Minor Planet Center Test Code; see site_310.txt for details. You have considerable freedom in specifying these points; the interval in azimuth is not fixed. You're really just describing the horizon as "it goes from here to here to here to here." It's assumed that the last point connects back to the first point.
You can't go more than 180 degrees at once (say, from a point at azimuth 90 clockwise to one at azimuth 300). You'd need an intermediate point at, say, azimuth 200.
• (2020 Nov 06) Listing exposure duration and/or SNR in ephemerides : If you tick the 'show advanced options' box in Make Ephemeris, you'll see options for SNR and exposure duration. Given a bit of information about your telescope (size, quantum efficiency, etc.), Find_Orb can take the computed object magnitude, altitude above the horizon, airmass, and sky brightness expected from sun, moon, and airglow, and come up with a decent estimate of how long an exposure you'd have to take to get a particular SNR, and/or what SNR you'd get with a particular exposure length.
To set the telescope parameters, you'll have to edit scope.json with a text editor. You'll see that there are default options present for (500), the "geocentric observer"; if nothing else is given, that's what Find_Orb falls back on. As you'll see, the geocentric observer uses no filter, has a 72-cm telescope with a 25-cm central obstruction, uses a six-arcsecond aperture, has three-arcsecond FWHM seeing, 90% quantum efficiency, 3" pixels, a read noise of 8 counts/pixel, and can see everywhere (no limits on altitude, dec, hour angle, or elongation.)
The sky brightness at the zenith is 20 magnitudes/pixel on the darkest night, indicating the level of light pollution there.
If you look in environ.dat, you'll see lines that read
EXPTIME=30 SNR=4
These tell Find_Orb that when computing expected SNR, assume 30-second exposures; when computing exposure duration, assume you're targeting an SNR of 4. Obviously, photometric observers will need to increase that.
Not everybody will reset all of these values. The SNR and exposure time calculations are pretty good, but still somewhat approximate. If you just reset the "primary" and "obstruction" bits, you may get times good enough to indicate "this is a possible observation" vs. "we'll never get enough SNR to see that/we'd need a ten-hour exposure to see that".
If you add data for your observatory to scope.json, I strongly suggest that you send a copy to me. I'll add your data to the default scope.json distributed with Find_Orb.
• (2020 Nov 06) Ephems for a list of arbitrary times: This is something of a follow-up to the ability to get ephems for times/places of the observations. You can make a file giving the times for which you want ephemerides and tell Find_Orb to use that file. As is usual with specifying times in Find_Orb, the formats can be flexible (and mixed within a file). For example, you could save the following as times.in :
# Lines that don't parse out as times are ignored. Starting with '#' # can mark a line as commentary. # Times can be somewhat free-form, JD or calendar, as shown below. # See https://projectpluto.com/fo_ephem.htm for a more complete list of # your time formatting options. # This line specifies that all times are TD (default is UTC). OPTION TD # This line causes the output to be sorted in ascending order (default # would be same as input order). OPTION DESCENDING is also a valid choice. OPTION ASCENDING 2020 10 20.259899 2020 Oct 23.490433 2020 11 04 17:03:14.5 2020 11 05.380085 2020 11 05.339583 2459159 2020 11 05.118895 2020 10 23.307322 mjd 59170.3 2020 11 05.289850
...and then, in the 'make ephemeris' section, set the ephemeris time step to be t. You'll be prompted to select times.in or similar file. If you then generated ephemerides, the starting ephemeris time and number of steps would be ignored; the ephemeris would contain ten lines, corresponding to the ten lines shown above.
• (2020 Oct 24) Better ability to combine observations from different designations: This (and a matching bit about getting the file you need to report a linkage to MPC) has full documentation here. Methods to add by clicking on another designation, or adding comment lines to the input file, or via command line switches, are described.
• (2020 Oct 24) Menu bar improvement: Click on the [+] at the end of the menu bar at the top of the screen to get another line of menu items. Click on the [-] to remove a line of menu items. You can edit command.txt to rearrange menu bar entries (and to change colors).
• (2020 Oct 24) Ability to specify ephemeris location: Instead of entering a three-character MPC code, you can tell Find_Orb that your ephemeris location is "N 44.01, W69.90" or similar. The program is fairly flexible -- you could enter that as "w69.9 n44.01", "e 290.1; N 44.01", for example -- but if in doubt, check that the lat/lon reported in the menu is correct. Also, note that if you expect to use that location frequently, I'd advise editing rovers.txt and following the instructions therein for adding your own "unofficial" observatory code. (Or contact me at pôç.ötulpťcéjôřp@otúlm (minus diacritical marks!) and I'll add in for you.)
• (2020 Oct 24) Ephems for times/places of the observations: Set the 'ephemeris step size' to be 'Obs', and ephemerides will be output for the times and places of the individual observations. Do this for an object where you have 23 observations, and you'll get 23 lines, each describing ephemeris data for the time/location of one observation. The ephemeris start/end times will be ignored.
This can be useful if you're wondering, for example, what the sky brightness or object motion or alt/az was at the time one or more observations were made.
Note that there's also a way to specify an arbitrary list of ephemeris times.
• (2020 Oct 24) 'Automatic' ephemeris step size: Set an ephemeris step size of, say, a.05, and the ephemeris step size will be chosen to keep the change in position between steps at 5%. The object may be 5% closer or further from you at each step, or move crosswise by 5% of its current distance. As it gets closer, a smaller step size will be used; if it goes away from you, a larger step size will be used.
The idea behind this is that you often would like to have some detailed ephemerides as an object is going past you, with less detail for the times when it's distant. A step size of a-.05 will do the same thing, except going backward in time.
• (2020 Oct 24) Cut/paste works: In Windows Find_Orb, click and drag with the left mouse button to select text; it will automatically be copied to the clipboard. Hit Ctrl-V to paste text into Windows Find_Orb.
In other OSes, the copy/paste mechanism will vary from terminal to terminal. But Ctrl-Shift-C to copy and Ctrl-Shift-V to paste appears to be a popular choice.
• (2020 Oct 24) JSON ephems, elements, observations, residuals The JSON (JavaScript Object Notation) format has become quite popular in recent years, especially among Python programmers. When Find_Orb writes out orbital elements, ephemerides, and residuals, it now does so both to its "usual" files and to four JSON files. You get an 'elements' JSON file giving elements, uncertainties, MOIDs, a summary of the observational data, and then data for each observation. The 'short elements' file contains the same, minus the data for each observation. (If there are thousands of observations, the full elements JSON file can be quite large; not everybody really wants the full-freight version.)
The 'ephemeris' JSON file contains the same data as the on-screen ephems, except with more digits and a more computer-friendly format. The 'combined' JSON file contain both the 'elements' and 'ephemeris' data, i.e., it combines everything into one file.
Click here for information about how to specify where the JSON output files go.
• (2020 Oct 24) Mouse clicks in 'observatory' area handled Click anywhere in the lines at the bottom of the screen that list the MPC codes that submitted astrometry for your object, and you'll get a pop-up menu giving various options. You can adjust the number of MPC codes shown; find the next or previous observation from an an MPC code; or bring up a list of all MPC codes that got the current object, and find the next observation from any given code.
• (2020 Oct 24) Astrometry written to the ADES format : Find_Orb already wrote out a copy of the astrometry to observe.txt, with some COM lines added to indicate uncertainties. It now also writes out an observe.xml file in the ADES format. This can be useful if you've loaded up astrometry in either or both formats and have modified astrometric uncertainties within Find_Orb. It also means you can load up files that contain 80-column formatted data, or a mix of formats, and produce a single output file suited for submission to MPC. (That last being the main reason I added the feature.)
• (2020 Oct 24) Ability to specify telescope parameters: If you look at the file scope.json, you'll see that it lists some basic parameters for some observatory codes. Data such as the telescope size and camera characteristics are used to compute SNR and telescope exposure times (see the next section). From the pointing limits, Find_Orb can suppress ephemerides for times when the object would be below your visible horizon, or behind a pier, or beyond an hour angle where the cables won't go.
If you edit this file, I recommend you send your version it to me. I'll update the 'official' scope.json to give the correct details. That way, you won't lose them the next time you upgrade.
• (2020 Oct 24) Exposure duration/SNR in ephems: You'll have to click on 'Show advanced options' for these options to appear in the ephemeris menu, after which you can click to toggle them.
These options will show the exposure duration required to get the object at its current magnitude, airmass, and background sky brightness, assuming you're trying to get an SNR of 4, and/or the SNR you'd get assuming a 30-second exposure. The target SNR and default exposure length can be edited in the file environ.dat; look for the SNR= and EXPTIME= lines.
To really get it to work properly for your site, you should also edit the file scope.json described in the above section. Otherwise, Find_Orb will assume a default one-meter telescope with certain pixel sizes, seeing, etc. for your site.
• (2020 Oct 24) 'Galactic confusion' in ephems: You'll have to click on 'Show advanced options' for this to appear in the ephemeris menu, after which you can click to toggle it.
I wrote some code to process Gaia-DR2 to get a value from 0 to 100 in any point of the sky to indicate the amount of 'galactic confusion' you'd find there. If the GC is 100, finding your object at that particular point in the sky may be difficult. If it's 0, the background should be very uncluttered. This works somewhat better than the usual idea of "don't observe within X degrees of the galactic equator". The star background isn't a simple band. Click here for further details on 'galactic confusion', and some thoughts on how this function may eventually get improved.
• (2017 November 4) Ability to treat all observations as if they're a single object: If you put this line at the top of your file of observations :
COM Combine all
then all observations in that file will be treated as if they were of a single object; the different designations will be ignored. This can be very useful in (for example) testing linkages; you can just concatenate the observations without having to modify the designations. (Many improvements and extensions have been made to this idea.)
• (2017 November 4) Better initial orbit determination for longer arcs: Rob Matson pointed out that he ran into difficulties when attempting to link 2013 SM19 to 2000 TF2. Meanwhile, I was seeing it link automatically (which is what I would have expected.) After a bit of puzzling, I not only found and fixed the bug that was causing Rob trouble; I also added some code to do a considerably better job in situations where Find_Orb has two short arcs with a long time span (in this case, thirteen years) separating them. (There is still work to do here; there's a couple of interesting tricks for finding an orbit linking even just a pair of observations to another "distant" pair... but that's work for another day; the current version will at least handle many cases where a short arc must be connected to another short arc, or even just a pair of observations.)
• (2017 November 4) Proper handling of A/YYYY objects: Since about 1995, the Minor Planet Center has held out the theoretical possibility that an object given a C/year comet designation might, for one reason or another, be reassigned to have an A/year designation. It hadn't happened, and I must confess I never created a "fake" version to see how Find_Orb would handle it.
It recently did happen, with the discovery of the first interstellar asteroid. MPC initially designated it C/2017 U1, probably just because they assumed an object with that orbit "must" be a comet. Since no nebulosity was found, it was redesignated A/2017 U1. Find_Orb then attempted to treat it as if it were a comet, with comet-style magnitudes. This is now fixed.
• (2017 November 4) Revised astrometric error handling: Following some discussion of the mishandling of .rwo data, I realized that I ought to make at least two improvements in how "over-observing" errors were handled. In particular, I'm now using a modified re-weighting scheme that has a more mathematically defensible method of differentiating systematic and random errors. Also, instead of treating over-observing as a function of a particular night or a fixed time span, the computing of the extent to which an object is 'over-observed' is slightly more reasonable, and lacks the arbitrary disconinuities of other schemes.
Note that the difference is more theoretical than practical. The actual orbits and uncertainties I've seen do not appear to have changed much (and have a variety of issues greater than this anyway.)
• (2017 June 22) Fixed bug in handling .rwo data: Daniel Bamberger pointed out to me that for about the last two years, the astrometric uncertainties in the AstDyS/NEODyS .rwo files have not been an estimate of the actual astrometric uncertainty, as I had thought. Instead, the uncertainties are multiplied by the square root of the number of observations made from that observatory on that night.
The purpose of this is to address the problem of "over-observing": if one station makes a lot of observations of an object, and all observations are weighted purely by the astrometric uncertainty, the observer who makes a lot of observations can have an unreasonably large influence on the orbit. (Say you and two friends weigh a rock. Two of you make a couple of measurements each, just to be confident you got it right. The third goes overboard, weighing the rock a hundred times. But he didn't calibrate his scale correctly, so he's always off by the same amount. Average all the measurements, and it'll come out closest to whoever made the most measurements... all of which, in this case, are systematically wrong. That's the "over-observing" problem.)
The current .rwo "solution" does ensure that if you take a hundred, or five or 17 observations, it will have no more effect than if you had taken a single observation. It introduces a long list of problems, though. The problems are fixed in this update, but be warned: they taint any answers you got from Find_Orb since early 2015, if you used .rwo data.
I've fixed this in Find_Orb: give it a .rwo file that has these corrections baked into its sigmas, and it will remove the correction, dividing each sigma by the number of observations made on that night from that observatory. That causes the sigmas to revert to "real" sigmas: an estimate of the uncertainty in the astrometry. Find_Orb can then proceed "normally", applying the error model you've selected in the Settings dialog (over-observing parameters and blunder management.)
• (2017 June 22) Fixed bug with satellite observations and Monte Carlo variant orbits: Marco Micheli pointed out to me that if you load up astrometry with observations from satellites (WISE, SOHO, etc.) and generate Monte Carlo variants, the residuals can increase weirdly. If you're lucky, they increase enough to let you know that something is wrong, but the error may be subtle enough to go unnoticed.
The problem was that the moment you started the Monte Carlo variants, the offsets between satellite and the geocenter were zeroed, and they stayed that way. This is now fixed.
• (2017 January 18) Many small changes: If you look at the detailed log of changes made to the software, you will see that I skip most of the smaller changes, such as "small improvement to Russian translation" or "improved computation of whether an object was in the earth's shadow". If you're interested in minor changes, though, that's where to look.
• (2017 January 18) Ability to reset comet constants in the Marsden-Sekanina model : The "standard" M-S model describes the non-gravitational forces on comets due to sublimating water ice. The idea is that that force is strongly dependent on distance from the sun, following a somewhat complicated function with four parameters (plus the distance from the sun).
However, some comets have non-gravitational behavior due to ices of other substances than water; when that happens, those four parameters need to be modified. If you look for the COMET_CONSTANTS line in environ.dat, you will see directions for modifying those constants for non-water ices.
• (2017 January 18) Ability to get vectors in km/s and km, or other units; and in equatorial or ecliptic frames. Look for VECTOR_OPTS in environ.dat for a discussion of how this works.
• (2017 January 18) Revised handling of Find_Orb extensions for sigmas, epochs, etc. : For some time, Find_Orb has accepted certain commands within astrometry files. For example, if your file contains
(first batch of observations in the 80-column MPC format) #Posn sigma 0.3 #Mag sigma 0.23 #Time sigma 1 #coord epoch 1950 (second batch of observations) #suppress_obs (third batch of observations) #include_obs #toffset 13 #coord epoch 2000 (fourth batch of observations)
, Find_Orb would (and will) treat the first batch of observations with default values for sigmas and other behavior; the second batch with assumed position sigmas of 0.3 arcseconds, magnitude sigmas of 0.23 magnitudes and positions assumed to be in the 1950 epoch; third batch, same, but the observations aren't included in orbit fits; fourth batch is again used in determining orbits, but the coordinates are returned to the default J2000 frame and all times are increased by thirteen seconds.
All of that is still true. The problem with it is that the Minor Planet Center will balk at any of it; send the above to them, and it'll get bounced. So the '#' can now be replaced with 'COM ' (note the space) for all of these. The above would become
(first batch of observations in the 80-column MPC format) COM Posn sigma 0.3 COM Mag sigma 0.23 COM Time sigma 1 COM coord epoch 1950 (second batch of observations) COM suppress_obs (third batch of observations) COM include_obs COM toffset 13 COM coord epoch 2000 (fourth batch of observations)
MPC is fine with comments. It won't actually make use of the above, sadly (only Find_Orb will pay attention to those comments), nor will this information be distributed to orbit computers. Nor should you expect MPC to interpret the 'coord epoch' or 'toffset' directives. However, if the MPC switches at some point to the proposed new astrometry format, as I expect they will, they conceivably could process the magnitude and positional sigmas above and your old observations would suddenly appear with the sigmas you specified. Possibly, anyway. (Note that I expect to provide conversion routines to and from the 'new' IAU2015 format. So you could take your old MPC-formatted data and re-submit it in the new format, with MPC then being able to take notice of your sigmas.)
Similarly, one can override the time in a given 80-column formatted observation using COM time instead of #time.
• (2017 January 18) Setting of epochs improved: Maik Meyer and Steve Hutcheon pointed out that Find_Orb's handling of coordinate epochs didn't work as specified (you could get B1950 coordinates to work, but mean coordinates of date were broken and there was no way to handle apparent coordinates.) This is all fixed.
• (2017 January 18) Elliptical position sigmas, and new ways to set sigmas: Find_Orb has provided ways to specify astrometric uncertainties for a long time, but those uncertainties have always been assumed to be circular (same in RA as in dec for any given observation.) However, one can now specify elliptical uncertainties. The separate uncertainties in RA and declination that are given in AstDyS/NEODys .rwo data, or sigmas given in columns 57-65 of the MPC format, or sigmas provided in Dave Tholen's style, will also be correctly used.
• (2016 April 21) Satellite offset workaround: (This is actually an old feature; I'm just getting around to documenting it.) By default, Find_Orb accepts observations from off-Earth satellites using the MPC's prescribed method: the Cartesian coördinates of the satellite are given, in kilometers or in AU, in the equatorial J2000 frame, relative to the earth. (See Find_Orb's rovers.txt file for instructions on how to handle offsets from other solar system objects.)
In the MPC format, the position of the decimal point is precisely described, so that the maximum value in kilometers is 99999.9999 km and the maximum value in AU is 9.9999999 AU. Either of these can be a nuisance. (I've had data from slightly high-flying satellites that were more than 100,000 km from the earth. I've never had data from more than ten AU away, but could easily see it happening with Cassini observations, for example; or for New Horizons observations of the Pluto system.)
If you add a line starting with relax_xyz before any satellite coördinates are read, the requirement is relaxed, and you can put the decimal point a place or two to the right, getting ten or a hundred times the range. (With ten or a hundred times less precision, of course. But I would be quite surprised if there are cases where the satellite position is so well determined that the format didn't give enough places.)
• (2016 March 14) 64-bit Windows Find_Orb: As can be seen from the Download section of the Find_Orb page, you can now get a 64-bit Windows executable for Find_Orb. This tends to be a bit faster than the 32-bit one. Other than that, I don't think you'll see much of a difference.
• (2016 March 14) Better language support: Find_Orb can run in English, French, Italian, or Russian. (Text for each of those languages is only very partially translated. If you're willing to provide a more complete translation, or to add another language, please let me know. Translation is quite simple; if you look at the files efindorb.txt, ffindorb.txt, ifindorb.txt, and rfindorb.txt, you'll see right away how it works.) Certain accented characters didn't show up correctly on some systems. I am pretty sure that those languages should work on any system now.
• (2016 March 14) Debiasing problem fixed: A bug was pointed out on the Find_Orb user list in which astrometry from AstDyS .rwo files would always be debiased, even if the 'Apply debiasing' check-box wasn't checked. (Click here for information about observational debiasing.) This bug is now fixed; if you turn off debiasing, it will "stay" off, for any type of input astrometry.
• (2016 March 14) Vector ephemeris options: A request was made on the Find_Orb user list for state vectors in ecliptical J2000, instead of in equatorial J2000. This really requires an option in the user interface, and I expect to add one. For the nonce, however, I have added the code for Find_Orb to support both systems, and to allow output in units other than AU and AU/day.
To do this right now, edit the file environ.def (the 'default' settings for Find_Orb) and look near the bottom. There are comments and a default setting for VECTOR_OPTS explaining how to get ecliptic J2000 coordinates, and/or switch to units such as kilometers, Earth radii, and seconds or minutes instead of days. Using this, you can set up desired values in VECTOR_OPTS in environ.dat. The user interface will eventually catch up with this.
• (2014 August 8) Find_Orb can now use DE-432, 431t, 432t: JPL has been quite busy with new ephemerides over the last year or so. The newest versions, 431 and 432, also come in 't' versions; Find_Orb can now use these (which means it can use any DE version as of 2014 August). Click here to read about how to use DE with Find_Orb.
The 't' versions DE-431t and -432t contain, in addition to the usual planetary and lunar positions, ephemerides for TT-TDB. Roughly speaking, TT-TDB is the difference between time as measured on the surface of the earth and time as measured by an observer outside the solar system's gravity well, and at rest relative to the solar system's barycenter. (TT= Terrestrial Time = time as measured by clocks on the surface of the earth, TDB = Barycentric Dynamical Time). Find_Orb does not, as yet, actually use the TT-TDB data in the 't' variants. (The difference is under two milliseconds, which may actually matter when Gaia astrometry comes in.)
Incidentally, if you're using the JPL ephemeris reading code from this site, you'll see that it has been updated to read the new ephemerides.
• (2014 August 8) Ability to specify uncertainties in magnitude and time; revised weighting scheme: One can now specify the uncertainty in the position, magnitude, and timing of astrometric observations. (Including timing errors is a new and somewhat unusual thing; as far as I know, nobody else has gotten around to doing it. Click here for a discussion of why timing errors matter.)
The way in which uncertainties are handled in Find_Orb is fundamentally different in this version. Instead of speaking in terms of somewhat dimensionless "weights", quantities have "uncertainties" or "sigmas". Click here for details on how uncertainties are now specified and handled. I think you will find the new system makes much more sense than the previous one did.
There are still some weak spots in how errors are handled, though, and you should be at least somewhat aware of them. You may also want to read about why timing uncertainty matters (it doesn't, always, but there are situations where it's a Big Deal.)
• (2014 August 8) New formats for precise RA/decs: There are now several new ways in which to specify RA/decs in the input data. The new formats all fit within the same columns in the MPC's 80-column astrometric records, but allow you to use different units and/or specify more precise positions.
• (2014 August 8) Use of .rwo radar data: For some reason, MPC only provides radar data for numbered objects. AstDyS and NEODyS not only provide radar data for unnumbered objects; they tend to be very quick about it, so you don't have to wait for the Minor Planet Circulars to be published sometime around full moon. So you can now feed Find_Orb a .rwo-formatted file including radar data, and it will process them and use them.
I tend to prefer the AstDyS/NEODyS .rwo data in several respects anyway. Unlike the MPC's hoary 80-column astrometric format, .rwo includes sigmas for position and magnitude. (Though not, unfortunately, for time.) It also gives extra decimal places for the time, something that can only be done in the MPC format with some non-standard workarounds; and you can store information as to residuals and which observations were excluded. So even without the fact that it includes radar data not distributed by MPC, I'd recommend it.
.rwo has only three drawbacks. First, the format doesn't allow one to store the five-character reference given in the 80-column format. I've put in a request for this to be fixed; it might happen the next time the format is revised for some other reason.
Second, the astrometry is not always up-to-date. But that's because AstDyS/NEODyS sometimes has to wait for the data; it's not a fault of the format.
Third, it doesn't fit as nicely on a standard IBM 80-column punched card. But I don't really see that as a major drawback for most users.
• (2014 August 8) Use of radar data: By default, radar observations are excluded. (This is simply because the "usual" initial orbit determination methods use optical data, not radar-style range/range-rate data.) If you turn radar observations on and do a 'full step', Find_Orb will include them in the solution, resulting (usually) in a drastically improved orbit.
NOTE that there are a few things that really need to be done at some point. Radar allows you to measure orbits much more precisely, which means some effects I was able to ignore can no longer be ignored. For example, you pretty much have to have all perturbers on, including asteroids. (Well, you can leave out Pluto.) For longer arcs, the Yarkovsky effect may become apparent, and Find_Orb doesn't do anything with that yet. Also, Find_Orb has a fairly simple Earth-orientation system, using the IAU nutation model and interpolating Delta-T within a table at two-year spacings. The radar data is almost good enough so that the empirically-measured departures from the modelled nutation ought to be included. However, this is a borderline requirement; thus far, these adjustments have not, in practice, been an issue.
Also, NOTE that for some objects, including (at present) all unnumbered asteroids, you'll have to use AstDyS or NEODyS .rwo data, because the MPC's data will not include radar observations.
• (2014 August 8) Fix for bug in asteroid perturbations before 1800 and after 2200: A small bug that may have gone unnoticed: if you had asteroid perturbers turned on, and tried to do an ephemeris going before the year 1800 or after 2200, Find_Orb would crash. This is fixed.
However, the positions of the perturbing asteroids will be computed using the orbital elements from 1800 or 2200. (We have precise elements for that time span, thanks to the Baer-Chesley BC405 asteroid ephemerides. But they don't go past that span, except by extrapolation, which may not be wonderfully accurate.) I doubt it really matters, since other effects will probably contribute much larger errors. The important part of this fix is really just the fact that Find_Orb won't crash in the admittedly rare case where asteroid perturbers are used for distant dates.
• (2013 November 15) Ephemeris uncertainties, mag limit: The Ephemeris dialog now has a check-box to show the amount and direction of the positional uncertainty in the ephemeris. At present, this uncertainty is computed from the covariance matrix. Mathematically, that means that if you've done 'full steps' on the observations and it hasn't diverged, you'll get sigmas (both in the ephemerides and in the orbital elements on-screen).
In such cases, the uncertainty is almost entirely along the line of variations. So Find_Orb can say things such as, "the uncertainty at this time is 50 arcseconds, along position angle 123", and you can be reasonably confident that the object will be found somewhere within that distance and at that position angle. Be warned that this is a one-sigma uncertainty; while the object will probably be found within that limit, it may be two or three times further away.
Also, the Ephemeris dialog has an edit box for 'limiting magnitude' which can allow you to suppress all ephemeris lines that would be below your observable limit.
• (2013 November 15) Information about MPC station locations The summary of data about an observation has always included the name, MPC code, and latitude/longitude of the observatory. It will now (almost always) include the country, and possibly a region identifier such as "US/Arizona" or "Australia/QLD". This also appears in pseudo-MPECs.
• (2013 November 15) Way to reset the available time range: Alessandro Odasso pointed out that you couldn't compute anything for dates before about -5000. If somebody asks for ephemerides that far back, it's usually a mistake. However, you can now tell Find_Orb to accept observation and ephemeris dates over a desired time span, rather than just being stuck with the default limits.
• (2013 November 15) Ability to 'greenlight' NEOCP data for distribution: For some time, NEOCP astrometry has had a warning message that NEOCP astrometry is not to be redistributed. (I notice that this message appears to have disappeared, but as far as I know, the restriction still applies.) Certain observatories are a little cautious in this regard, and don't want their data going public in an uncontrolled manner. As a result, when Find_Orb produces an MPEC, the NEOCP data is redacted (filled with pseudorandom characters and, just to be sure, is shown blacked out.)
However, some observatories don't mind their data being redistributed. In particular, CSS (MPC stations (703) and (G96)) has given permission for their data to be redistributed, and their observations are now "greenlit" and appear in pseudo-MPECs. If you edit environ.dat, you'll see a line :
GREENLIT=703 G96
More stations may be added to this line, should the observers be willing to have their data distributed in this manner.
• (2013 November 15) 'Computer readable' ephemerides: A few people are generating ephemerides in Find_Orb for use in other programs. Find_Orb normally goes to some lengths to make the ephemerides easy for humans to figure out. RA/dec are shown in "base 60", Babylonian format. Distances are shown in AU where appropriate, but are switched to kilometers, meters, light-years, etc. if that wouldn't fit. Dates are shown in Gregorian calendar format. All this makes the ephemerides easy for humans, but a little more difficult for programs to parse than would be ideal. Set the new 'computer readable' check-box in the Ephemeris dialog, however, and the output will show RA/dec in decimal degrees, distances in AU, and the time will be in JD form.
• (2013 September 1) Fix for MOID bug: Charles Bell pointed out, on the Find_Orb user list, that for C/2012 S1 (ISON), the file elements.txt showed zero MOIDs for Saturn, Uranus, and Neptune. It turned out that in this somewhat unusual (and therefore not previously noticed) case, the first five planets checked had small enough MOIDs to be shown in the on-screen elements. There wasn't room to display more, so Find_Orb stopped computing MOIDs, and left zero values for the outer planets. This is now fixed.
• (2013 Aug) Fix for impact lat/lon bug: Filip Fratev pointed out, on the Find_Orb user list, that the impact lat/lon computed for 2008 TC3 was completely wrong. (The orbit was right, and the impact time was almost exactly right.) This bug is fixed.
• (2013 Aug) Find_Orb can now use DE-431: Recently, JPL provided a new DE-431 ephemeris; you can download it here (warning: it's about 2.7 GBytes), and you may need to right-click on the link and then "Save link as..."; otherwise, your browser may just show garbage.
The benefit of DE-431 is that it provides planetary ephemerides over the jaw-dropping time range of -12000 to +17000. (The best previously available from JPL was -3000 to +3000.) The downside is, of course, that large file size. However, it may be worth it if you want to analyze the motion of an object over a really long time span; for example, to see if a given TNO is apt to get near to Neptune.
• More asteroid perturbers: (2013 February 24) Previously, clicking on "asteroids" as a perturber resulted in Ceres, Pallas, and Vesta (the "Big Three") being added in as perturbers. For most purposes, those three are more than sufficient. It's not especially common to see orbits where turning asteroids on, then doing a "Full Step", even causes the residuals to budge. And after you get past the Big Three, the masses (and therefore the perturbations) drop off quickly :
Mass (sun=1) of the most massive asteroids: < 4.755e-10 (1) Ceres 1.344e-10 (4) Vesta 1.060e-10 (2) Pallas 4.420e-11 (10) Hygiea 2.800e-11 (31) Euphrosyne 1.950e-11 (704) Interamnia 1.930e-11 (511) Davida
However, there are situations where asteroid perturbers have noticeable effects, usually on very long (50-year) arcs. In some cases, the effects are enough to allow one to determine the mass of the perturbing asteroid (subject of the next section). A case of an highly perturbed object came up recently on the Find_Orb user list, which has prompted me to revise Find_Orb to make use of the BC-405 ephemeris of asteroid perturbers. With this, one can include perturbations from 300 "significant" asteroids over the years 1800 to 2200. Click here for details on BC-405. Essentially, BC-405 provides orbital elements and masses for the 300 asteroids that were used in computing the JPL DE-405 ephemeris.
The current version of BC-405 was provided by Jim Baer, and is kindly hosted via anonymous ftp by the Minor Planet Center; you can click here to download it (about 130 MBytes). Log in as "anonymous", using your e-mail address as a password. Save the file to your Find_Orb folder. (Some information on the file's format and contents is provided here.)
The next time you run Find_Orb with asteroid perturbers turned On, you'll see a pause for a few seconds while the program processes BC-405. This will happen once, while Find_Orb converts the file from ASCII to binary. After that, asteroid perturbers will still slow the program down quite a bit; it takes a while to compute the positions of 300 asteroids at each step and add in their perturbations. (Though Find_Orb has a little logic to ensure that "insignificant" perturbations are not computed, so it's not quite as bad as one might expect. Still, it's a big computational load.)
I do have ideas for speeding things up. One would be to switch from Find_Orb's current numerical integrator (a Runge-Kutta-Fehlberg one) to a faster solution, probably Gauss-Jackson. Also, use of multiple cores could help. However, the current version is perfectly adequate for a reasonably patient user.
One way to get better speed is to compute, not the first 300 asteroids, but the first N asteroids, where N is a smaller number. Set N=3, for example, and you'd go back to using just the "Big Three" asteroids, Ceres, Pallas, and Vesta. To use, for example, just the first ten asteroids, you would edit the file environ.dat and add a line such as
BC405_ASTEROIDS=10
To test asteroid perturbers out, I'd recommend running asteroid (50278) 2000 CZ12. As was noted by Aldo Vitagliano and Reiner Stoss in this paper, (50278) came within about 55200 km of the asteroid (15) Eunomia on 2002 March 4. A "normal" solution with planets and the Big Three leaves some observations with enormous residuals. In fact, Find_Orb is unable to determine an orbit that fits the entire arc; some of the older observations are not included, and have residuals of half an arcminute or more.
However, if one turns on asteroid perturbers and does a "full step" or two, the residuals will rapidly converge on a much lower value. One can then turn on the remaining observations and do another "full step" or two. You can click here to get astrometry for (50278) 2000 CZ12. The data will be in the .rwo format used by AstDyS. I recommend using this source; the .rwo files contain some additional data, such as observational weighting and biases, that are not provided in MPC observations. Find_Orb can handle .rwo data without difficulty.
I realize that in some cases, 300 asteroids may not be enough. One may want to determine the mass of, or generate an ephemeris from, an asteroid not in the 300. I do expect to provide a way to add more asteroids.
• Asteroid mass determination: (2013 February 24) It's not a large step from including asteroid perturbers (as described above) to computing the masses of those perturbers. Basically, you need to find an object that was strongly perturbed; load up its astrometry; and then, instead of solving for just the usual six orbital elements, you solve for seven values: the six orbital elements, and the asteroid mass that best fits the orbit.
As an example, I'd recommend trying the example of (50278) 2000 CZ12. As described, you can get an orbit that includes the perturbations of (15) Eunomia, with the mass of Eunomia assumed to be the default value of 1.600E-11 that of the sun. (The list of masses is given in mu1.txt in the Find_Orb folder.) But now, go into the Settings Dialog, set the "alternative format" for orbital elements, and set the 'constraint' to be
m(15)
and do a "full step" or two. Find_Orb will now treat the mass of Eunomia as a parameter to be solved for. The value it gets and the uncertainty are shown in the orbital elements. I got...
Orbital elements: (50278) Perihelion 2011 May 2.171750 +/- 0.00064 TT; m(15)=1.568e-11 +/- 3.208e-13 Epoch 2013 Jan 17.0 TT = JDT 2456309.5 Find_Orb M 144.689108 +/- 0.00014 n 0.231196191 +/- 8.15e-9 Peri. 105.100623 +/- 0.00052 a 2.629151415 +/- 6.18e-8 Node 249.030399 +/- 0.00050 e 0.03794657 +/- 1.27e-7 Incl. 1.265614 +/- 0.000011 P 4.26 H 15.7 G 0.15 U 0.4 q 2.529384118 +/- 3.09e-7 Q 2.728918713 +/- 3.71e-7 From 375 observations 1950 June 15-2013 Jan. 17; mean residual 0".520.
Note that you won't usually get so good a result (a 2% error estimate!) We lucked out in that (50278) came so close to (15) Eunomia, resulting in an unusually strong effect. Jim Baer and Steve Chesley's paper on BC-405 lists some other pairings resulting in measurable masses.
• Asteroid-centric ephemerides: (2013 February 24) It has long been possible to generate planet-centered ephemerides in Find_Orb. You had to specify an MPC "code" such as (Sun), (Mer), (Jup), etc. (Previously, that was entered in the Longitude box; things have been revised in the current version so that there is a separate MPC code box.)
One can now specify an MPC "code" of Ast1 for (1) Ceres, Ast15 for (15) Eunomia, etc. Note that at least at present, only the 300 asteroids from BC-405 are available; they're listed in mu1.txt in the Find_Orb directory.
This can be easily tested with the above example of (50278) 2000 CZ12. If you run an ephemeris centered on "MPC code" Ast15 for dates around 2002 March 4, you should be able to see the close approach to within about 55200 km described in Vitagliano and Stoss' paper.
• Radar observation info: (2013 February 24) When clicking on a radar observation, Find_Orb will show the observed time delay and Doppler shift and sigmas, and the computed time delay and Doppler shift. (This is mostly just to pave the way to Find_Orb actually including radar data in its orbital determinations.)
• Better stability: (2013 January 11) Previously, if you asked for elements at an epoch far from the observations and did a "full step" or two, things could diverge. There were some numerical stability issues which, I think, are now pretty thoroughly fixed.
• Display of uncertainties: (2013 January 11) The Settings dialog now has an "Alternative Format" checkbox. Tick this, and Find_Orb will usually show uncertainties for almost all orbital elements. The result looks like this:
Orbital elements: 2012 DA14 Perihelion 2012 Nov 30.043842 +/- 3e-5 TT = 1:03:07 (JD 2456261.543842) Epoch 2013 Feb 1.0 TT = JDT 2456324.5 Earth MOID: 0.0003 M 61.858817 +/- 0.0017 (2000.0) Find_Orb n 0.982569760 +/- 4.94e-8 Peri. 271.106040 +/- 0.0040 a 1.002060138 +/- 3.36e-8 Node 147.2260020908 +/- 0.0019 e 0.10835193 +/- 6.86e-7 Incl. 10.3454231192 +/- 0.0040 P 1.00/366.38d H 24.4 G 0.15 U 1.5 q 0.893484988 +/- 6.67e-7 Q 1.110635288 +/- 7.14e-7 191 of 194 observations 2012 Feb. 23-2013 Jan. 9; mean residual 0".366.
To get all of this to fit, I threw out the P and Q vectors; moved the object name up next to the "Orbital elements:" text; split q and Q to a new line; and displayed the total number of observations in the last line, as well as the number actually used. It looks somewhat like the usual MPC eight-line format, but not quite.
I wrote that uncertainties will "usually" be shown. Uncertainties aren't available for Monte Carlo orbits, or after doing an Herget step, or for Vaisala orbits. Uncertainties are computed after doing a full six-parameter fit, which happens when you've clicked Full Step, or Auto-Solve, or Filter Observations. (At some point, I expect to have uncertainties computed from Monte Carlo and statistical ranging orbits.)
• Extensions to the MPC astrometry format: (2013 January 11) I've recently encountered observations with times given as JD or MJD or in HH:MM:SS.sss form, and with RA/decs given as decimal degrees or hours. Rather than writing converters each time I see such things, I decided to revise Find_Orb to be more flexible in its input. At the same time, I wanted to allow times to be given to greater precision; people making video observations have already learned that the 10^-6 day precision of the MPC time format is not good enough for really fast-moving objects (close NEOs and most artificial satellites).
Find_Orb will now consider all of the following "MPC observations" as equivalent (with some precision differences), with the first two being examples of how MPC expects to see things.
COM Two lines in 'usual' MPC formats
J97Z99Z C1997 04 21.34707 13 57 33.13 -09 12 14.3 413
J97Z99Z C1997 04 21.34707113 57 33.132-09 12 14.29 413
COM Four lines in Find_Orb-specific formats; not to be sent to MPC
J97Z99Z C2450559.84707 13.959202778-09.20397221 413
J97Z99Z CM 50559.347071234209.3882 -09.20397 413
J97Z99Z CJ970421.3470712 13 57.6 -09 12.2 413
J97Z99Z CJ970421:08194684813 57.6 -09 12.2 413
The first two examples are the most common MPC formats, giving the year, month, and day to five or six decimal places, and the RA and dec to either "standard" precision or with an additional decimal place. The second line, given to a millionth of a day, corresponds to a precision of 86.4 milliseconds, and is to be used only in situations where you really think your timing is that good. (At the other extreme, some older observations are given to fewer places. For example, MPC's data for Chinese observations made in 1737 of the comet P/109 are given to a precision of a tenth of a day. So really, MPC will accept YYYY MM DD.dddddd, to one through six places, and nothing else. Everything else we're about to discuss is Find_Orb only; DON'T SEND DATA TO MPC IN ANY OF THE FOLLOWING "EXTENDED" FORMATS.)
In the third example, the date is shown as a JD, the RA in decimal hours (to nine places, the maximum available), and the declination in decimal degrees (to eight places, again the maximum available.) On the fourth line, the date is given as an MJD (to nine places, the maximum available, a precision of 86.4 microseconds); the RA is given in decimal degrees, and the dec in decimal degrees, this time only to five places.
If the decimal point for an RA is in column 36, it's assumed that the value is in decimal degrees. Put it in column 35, and it's assumed to be in decimal RA hours.
In the fifth and sixth examples, the year is given in MPC's letter-for-a-century form (J=1900s, K=2000s), followed immediately by a two-digit year, two-digit month, and two-digit day. In the fifth example, a decimal fraction of a day follows (again with nine places possible). In the sixth example, a ':' is used to indicate that what follows is not a fraction of a day; it is the time in HHMMSS (and decimal seconds) form; .3470712 days = 8 hours, 19 minutes, 46.848 seconds.
One can, of course, mix-and-match any of the time formats to any of the RA formats to any of the declination formats.
You'll see that, in addition to avoiding having to reformat data, the Find_Orb-specific formats allow you to specify time to a precision up to 1000 times greater than the usual MPC format (to 10^-9 days = 86.4 microseconds, instead of to 10^-6 = 86.4 milliseconds; the last format gives one-millisecond precision.) RA and dec can be specified to 10^-8 degree = 36 microarcsecond precision. This will, I hope, be enough precision for anybody.
• Revised observation filtering/blunder management: The Settings dialog contains a "filtering" section which determines what happens when you click on "Filter Obs". The default is to filter as before, in the manner probably used by almost all orbit computers: observations greater than a "Max residual" limit are excluded, and those within that limit are included. The limit is now taken to be in sigmas. By default, Find_Orb assumes a one-arcsecond error for all observations, though this can be adjusted by setting weights for observations in a variety of ways.
Alternatively, one can assign a "blunder probability". This new way of filtering observations is described here. The basic idea is that observations far from prediction are included to the degree we think they are not blunders. (By default, I'm assuming that 2% of all observations are blunders. If we knew, a priori, which observations were in that 2%, we'd just eliminate them... but we don't.) An observation close to prediction will be included at nearly full weight; one ten sigmas off prediction will have almost zero effect on the solution. An observation two or three sigmas will be included, but to a lesser degree than would otherwise be the case.
• Handling of over-observed objects: On occasion, you'll find that an object was observed three times by one observer, four by another, three by yet another... and then there's somebody who made 57 measurements on one night. In the normal course of things, the guy who made 57 measurements will dominate the solution, even if he made 57 bad observations. (The usual cause of over-observing is data gathered for a light curve.)
I've tried to come up with a good solution to this issue, and have implemented one based on ideas kindly suggested independently by Marco Micheli and Alan Harris, currently called the "t-and-k scheme". The idea is that if, over a t-day time period, the number of observations n_obs made is greater than a constant k, then the observations should be reweighted downward by sqrt( k/n_obs).
Find_Orb's Settings dialog now contains an "over-observing parameters" section, where one can set t ("time range", defaulting to one day) and k ("observation ceiling", defaulting to five observations.) With these parameters, if Find_Orb notices that a given observation is one of twenty made from the same observatory during the same day, the observation will be given half the weight it would otherwise receive.
Thus, the total effect of the 57 observations would be as if five had been made. All 57 will be used to remove noise that would have been apparent from only five observations. But that observatory will no longer dominate the orbit.
• Precise residual check-box: The Settings dialog now contains a check-box that will cause residuals to show an extra digit. This option has long been available in console Find_Orb; I've found it handy mostly in ensuring that Find_Orb was replicating results from NEODyS and AstDyS, right down to the milliarcsecond. (In the normal course of things, the only observations I can think of that might be good to such a level would be HST and Hipparcos ones.)
• AstDyS/NEODyS .rwo weights and biases used: The .rwo files of astrometry provided through AstDyS and NEODyS include estimated uncertainties in RA and dec, as well as biases computed using "Treatment of star catalogue biases in asteroid astrometric observations", by Steve Chesley, Jim Baer, and David Monet. When Find_Orb loads .rwo files, it will now apply the biases and use the RA/dec uncertainties. (Find_Orb assumes these to be identical, so it uses the geometric mean of the RA and dec sigmas.)
• Weight switch: The Settings dialog now has a check-box to turn the use of observation weighting on or off. The weighting scheme is described in the file weight.txt: weights are assigned based on some (admittedly somewhat arbitrary) opinions regarding the accuracy of their astrometry. Check this box, and the weight.txt weights will be assigned to each observation (and you'll be able to see that weight listed when you click on an observation). Un-check it, and all observations will be assumed to be accurate to one arcsecond, and hence to have unit weight.
Note that the observations still will be re-weighted according to the over-observing parameters. If you want everything to be truly weighted equally, you'll have to set the "time range (days):" parameter in the Settings dialog to be zero.
• (July 2012) Monte Carlo noise properly weighted: It was pointed out to me that when generating Monte Carlo orbits, the noise ought to be scaled by the inverse of the weight given to that observation (click here for information about setting weights for observations). That is, if you're adding one arcsecond noise for most observations, but some observations are considered twice as accurate as most and are given a weight of 2, then only .5 arcseconds of noise should be added to them. Find_Orb now does this.
• (July 2012) Fixed orbit viewer: Joe Hobart and Norman Falla pointed out that the link to the "orbit visualization tool" provided on pseudo-MPECs was broken. I'd made use of a Perl script from a JPL site, now missing. After a bit of head-scratching, and with some help from people on the Find_Orb mailing list, I was able to devise a workaround, and the link works again.
• (July 2012) Perturber specifiers in mpcorb-formatted files: Andy Puckett pointed out that the mpcorb-formatted files produced by Find_Orb didn't include information about perturbers ( MPC provides documentation on how perturbers are supposed to be specified in mpcorb-formatted elements). This is fixed; if all perturbers from Mercury to Neptune are turned on, the files mpcfmt.txt (written whenever new elements are computed) and mpcorb.dat (written when Monte Carlo or statistical ranging is run) will show perturber data. Note that this format provides no way of specifying situations where only the Earth's perturbations are included, for example, or just those of Jupiter. So unless Mercury through Neptune are included, the perturber specification is left blank.
• (June 2012) Better initial orbit determination: I improved the initial orbit determination (IOD) routines for short arcs. Find_Orb got orbits in such cases, but not necessarily very good ones. I am still working on this. The ultimate goal is for Find_Orb to get a correct orbit in all cases, but to remain fast. This is, to put it mildly, challenging. However, I've hopes of having Find_Orb get a good orbit quickly for about 99% of cases. In the remaining 1%, it will have to spend some extra time looking for more exotic orbits.
• (May 2012) Non-interactive orbit determination program: Instead of just building the find_orb interactive console application, a non-interactive fo program is also built. Run fo (filename), and all objects from that file will be loaded and orbits determined for them. A brief summary of the elements for each object will be shown on-screen. Full elements will be stored in elements.txt and mpc_fmt.txt.
fo works, but needs improvement. In particular, the orbit it finds may not include all observations. Roughly speaking, if the arc covers more than about 60 degrees, it will look for a subset of observations that cover a shorter arc in the sky. And if it fails to determine an orbit for a given arc or sub-arc, it looks for a still shorter arc that does lead to a valid orbit. It essentially uses the same IOD engine as console find_orb and Windows find_o32. I've hopes to make these improvements, thereby making all flavors of Find_Orb better. But the current fo is useful already, so I wanted to get it out into the world.
• (2012 Feb 19) Documented statistical ranging: It took a while, but I finally described how SR works.
• (2012 Feb 7) Ephemerides can show helio/observer-centric ecliptic lat/lon and PABs: There have been recent inquiries on the Minor Planet Mailing List about ephemeris software computing the Phase Angle Bisector (PAB). This is the point midway between the observer-target direction and the sun-target direction, expressed in ecliptic coordinates. It's a useful quantity when doing photometric/light-curve analysis. There is now a check-box for it in the Ephemeris dialog.
In the course of doing this, I realized that it should be made possible to display heliocentric or observer-centric ecliptic lat/lons, and there are now check-boxes for those in the Ephemeris dialog, too. (And also options to toggle all these from within the console version.)
• (late 2011) U parameter shown, uncertainty data provided: When one does a "full step", Find_Orb will (almost always) show the U "uncertainty" parameter in the orbital elements. U will not be shown for highly uncertain orbits, or for satellite or parabolic/hyperbolic orbits. It's also not shown for Herget, Gauss, or simplex orbits, where there isn't a formal covariance matrix.
If one looks in the file covar.txt, one will see that errors are also computed for orbital elements (time of perihelion, eccentricity, etc.) These eventually ought to be shown on-screen; I mention it because interested citizens can at least access that uncertainty data just by looking at the bottom of the file.
• (2011 Apr 15) Ability to set a fixed epoch: Andrew Lowe mentioned on the Find_Orb user list that it would be nice if one could ensure that all orbits were in a user-specified epoch. One can now add a line such as
EPOCH=2455600.5
to environ.dat to have all orbits with epoch JD 2455600.5 = 2011 Feb 8. Alternatively, one can use EPOCH=2011 feb 8 or EPOCH=mjd 55600. As with entering the epoch time in Find_Orb's edit box, or entering the starting time for an ephemeris, there is a lot of flexibility in how the time is specified.
• (Another) fix for satellite observations: When loading satellite observations from places such as (249) SOHO or (C51) WISE, Find_Orb converted the observer's coordinates from equatorial to ecliptic coordinates. Then it converted them again (sound of forehead hitting palm). Not a good idea at all, and I'm surprised it hadn't led to noticeable errors earlier. (Though I'm noticing that results for SOHO comets are much better than they were. I'd just assumed that SOHO data wasn't very good.)
Also, satellite observations from .rwo (NEODyS and AstDyS) files were sometimes loaded completely incorrectly. These bugs are fixed.
• (2011 Mar 10) mpcorb output changed: Rolf Wildberg pointed out that the mpcorb files generated by Find_Orb had asterisks in certain fields. Specifically, the number of oppositions, perturbers, and the four "hex digit mask" fields were all filled with asterisks.
I did this because I had some problems in filling in those fields, and thought it better to put in asterisks than possibly misleading values (such as zeroes). The problem is that some programs, including Astrometrica, will object to these asterisked fields. To get around this, I've set the number of oppositions to 1, and set the perturber descriptor correctly, to follow the rules specified at the MPC site. Note that to get a non-blank perturber descriptor, the perturbers Mercury through Neptune must be turned on. This will result in a descriptor of zero. Turn on the Moon and asteroids as well, and the descriptor will adjust accordingly. (Be warned, by the way, that asteroid perturbers slow the program down and rarely matter very much.)
I've left the "number of oppositions" at one, because it's unclear to me what constitutes an "opposition" in the minds of the folks at MPC (I'll probably just ask them at some point). It's pretty clear what an opposition is for an object outside the earth's orbit. It gets murkier when the object goes inside our orbit.
The four "hex digit masks" flag orbit properties such as the object being an NEO, scattered-disk object, potentially hazardous, and so on. It's probably safe to leave these zeroed out for the nonce; I may return to the problem someday and attempt to set at least some of them correctly.
• Find_Orb is now under the under the GPL (GNU General Public License): Since its release, Find_Orb has been copyrighted freeware. I've long intended to release it under the GNU General Public License, but never got around to it... until now. The C/C++ source for Find_Orb, and the C/C++ source code for basic astronomical functions that goes with it, now have the required license information at the top of each source file. (If I overlooked any, please let me know.)
It doesn't make much practical difference, I think, since I'd released the source code years back. I've a faint hope that it will help lure some folks into improving the program further.
• Warnings for below horizon and in-sunlight observations: Observations that are physically impossible are now automatically excluded, and you get a warning dialog about them.
Ideally, there'd be some tighter constraints on this. An observation made with the object just a hair above the horizon, and the sun just a hair below it, passes at present. It should probably be required that the object be above some limiting altitude, and the sun below some limiting (negative) altitude.
• (2011 Jan 10) Additional ephemeris options: The Make Ephemeris dialog has been restructured to allow for some new output possibilities. Click here for details.
• Display of reference catalog info: Andrea Milani recently mentioned on an MPML post that byte 72 of an MPC report specifies the reference catalog used. I'd been trying to figure that one out for a while, without success; but given that clue, I was able to determine what most of the codes meant. The paper "Treatment of star catalogue biases in asteroid astrometric observations", by Steve Chesley, Jim Baer, and David Monet (Icarus 210 (2010), pages 158-181), gave me the remainder...
a USNO-A1 b USNO-SA1 c USNO-A2 d USNO-SA2 e UCAC-1 f Tycho-1 g Tycho-2 h GSC-1.0 i GSC-1.1 j GSC-1.2 k GSC-2.2 l ACT L 2MASS (used for WISE and PanSTARRS astrometry) m GSC-ACT n TRC o USNO-B1 p PPM q UCAC2-beta r UCAC-2 s USNO-B2 t PPMXL u UCAC-3 v NOMAD w CMC-14 x HIP-2 z GSC-1.x
...except for 'L' for 2MASS; Tim Lister kindly filled in that blank. (A full list is now present at http://www.minorplanetcenter.net/iau/info/CatalogueCodes.html, with over twenty additional catalogue codes.)
Now, the reference catalog for an observation is shown when you click on that observation.
• Fixed reading of satellite observations in .rwo format: Rob Matson pointed out that WISE data wasn't being read in properly, a problem I was initially unable to replicate. We quickly realized that it was because he was using NEODyS data in the .rwo format. Find_Orb will read such data, but had issues handling satellite observations. This is fixed.
• Improved handling of .rwo observations: In the course of fixing the above, I realized that the 'note' field wasn't read for .rwo data. Also, I saw that the number of significant digits is given, sort of implicitly, so that the original MPC record can actually be re-created more closely than I thought (i.e., proper number of digits shown).
• Fix to computation of residuals and mean residuals:
My residuals didn't quite match those shown in .rwo files. I
eventually figured out that I was missing a cos(dec) term; including that
gets me to within a few milliarcseconds of NEODyS results. I've also
long been aware that I don't replicate the mean residuals shown in
MPC orbital elements. After a bit of testing, with a tip from
Gareth Williams as to how MPC is doing it (answer: the obvious way
I ought to have assumed from the beginning; the 'mean residual' is
the root-mean-square of the residuals in RA and dec, treated
separately:
mean_resid = sqrt( Σ (xresidi2 + yresidi2)) / (2 * n_obs)
), I figured out the problem and fixed it; the mean
residual shown for an orbit by Find_Orb ought to match that
shown in MPC orbits, and is therefore now shown similarly
formatted.
• (2010 Oct 11) The program took about 45 seconds to load up the MPC's complete file of (as of this date) 544655 comet observations. It turned out there was an easy speedup; changing a few lines resulted in the program loading that file in about four seconds. One can now load up the 'observations of unnumbered objects' or the 'isolated tracklet file' (what used to be called the 'one-night stand file') in under a minute. Even the still larger 'observations of numbered objects' file loads up fairly quickly. (All of these, as well as the file of natural satellite observations, are available via the MPCAT-OBS page.)
• (2010 Oct 11) Handling of observatory and observer links in "pseudo-MPECs" has been improved. In particular, the program will now get links from either its original obslinks.htm file, or from the Minor Planet Center's list of MPC station Web sites. The latter appears to be quite comprehensive and fills in some holes in my list. Also, links for satellite stations such as SOHO, WISE, and STEREO-A and STEREO-B were getting mangled; this is fixed.
• (2010 Sep 9) Joe Hobart pointed out that if you load in data for an object with mixed permanent and provisional designations in the reports, such as
08983J69T00V* A1969 10 07.90479 00 37 13.33 +02 16 38.6 16.5 M3076095 08983J75X04X* A1975 12 03.96104 06 12 38.67 +07 50 01.2 17.5 M4228095 08983J77E01D* A1977 03 13.96142 12 30 54.62 -03 50 42.8 17.5 M4588095 08983J77G00P* A1977 04 10.63485 12 12 04.90 -00 16 35.4 17.8 M7316381 08983J85V02U* A1985 11 09.02493 03 20 05.33 +06 52 22.9 17.0 12273095 08983J85V04X* A1985 11 11.86382 03 17 50.49 +06 35 33.9 17.0 12274095 08983J90S28U* A1990 09 24.97558 02 21 03.35 +08 38 00.1 16.0 19093095 08983J77E01D 1993 04 17.38889 14 53 25.74 -07 45 16.9 a1660675 08983J98J00D C1998 04 21.20445 13 40 18.37 -04 08 54.5 17.1 aa1447704 08983 C1998 04 24.32485 13 38 05.41 -03 48 02.1 17.3 Vai0593691 08983 S2010 05 21.32791 21 58 04.30 -02 57 26.5 L~0I8gC51 08983 s2010 05 21.32791 1 + 5655.0515 - 3920.5802 - 648.7908 ~0I8gC51
...Find_Orb doesn't recognize these as all one object; instead, it will list 1969 TV, 1975 XX4, and so on, plus (8983). I did have a switch to toggle that behavior, but it's in the console version only, and one would really want the objects to be recognized as one and the same 99% of the time. I've revised the code to default to recognizing data such as the above as being for a single object.
• (2010 Sep 6) Joe Hobart also pointed out that at the default size of the Find_Orb dialog, the 'Toggle Obs' button gets overwritten by the data about the observation. This is a minor cosmetic nuisance, but it did lead me to think about the fact that in general, it would be well if Find_Orb "remembered" its placement from one run to the next. That is, if you've dragged it to the right side of the screen and opened it up a bit to show more observations, it should display that way the next time you run it. I've made it work that way.
• (2010 Aug 26) Find_Orb will now handle satellite and roving observer data even if lines are scrambled (as sometimes happens), and will display both lines of the observer reports in pseudo-MPECs.
• (2010 Aug 17) If you make a "pseudo-MPEC" for a heliocentric object, the pseudo-MPEC will have two new links at the top. One leads to an orbit diagram, provided by the JPL 3D orbit visualization tool. The second links to a search for the object on SkyMorph.
• (2010 Aug 17) When in the Ephemeris dialog, clicking on "pseudo-MPEC" causes your browser to be started (if it wasn't already) and the pseudo-MPEC to be displayed in it. (The pseudo-MPEC is stored under the name mpec.htm.)
• (2010 Aug 16) I've added some more fixes for satellite observations. (Quick summary: observations made from satellites, such as SOHO or WISE, are supposed to be reported on two consecutive 80-byte lines, in a particular order. Sometimes, though, MPC files have the lines the wrong way around. I've revised Find_Orb so that it'll handle such data no matter what oddball order it may be in.)
• (2010 Jul 11) The Settings menu now contains a 'physical model' section.
• (2010 Jul 11) The main dialog now has a 'simplex' button.
• (2010 Apr 10) Over the course of two days, a few bugs were found, and I made some small improvements. Maik Meyer pointed out that comet magnitudes in the ephemerides were wrong. (This was due to Find_Orb switching over, partway through, from the comet magnitude formula to the asteroid one.) Daniel Dimitru pointed out that the MOID shown in the console app version of Find_Orb was wrong. I noticed an asteroid transiting the Sun , which led me to a bug in how magnitudes were computed. It also caused me to modify the ephemerides so that, at phase angles of less than 60 degrees, magnitudes in ephemerides are marked with a '?', because such magnitudes are usually completely unreliable.
• (2010 Apr 10) In trying to figure out the magnitude problems for the transiting object 2005 YU55, I added an option to the console version of Find_Orb to allow one to include the phase angle in ephemerides.
• (2010 Apr 10) Also, I realized that the state vector given in the elements.txt file isn't necessarily for the correct epoch. This is fixed.
• (2010 Apr 10) Andrew Walker made a couple of suggestions on the Find_Orb users list. He suggested that when solving for Monte Carlo orbits, it would be helpful if the data in elements.txt for each "virtual asteroid" was stored. It now is, in state.txt. In the course of doing this, I found and fixed the bug mentioned in the above paragraph.
• (2010 Apr 10) Andrew also asked if Find_Orb could provide the state vectors for the planets at epoch. I don't think this will be a widely used feature, but it was easy enough to do; if one adds the line PLANET_STATES=y to environ.dat, then the planet state vectors will be output to elements.txt.
• (2010 Mar 28) Steve Hutcheon pointed out that one can't load ancient observations into Find_Orb (nothing before 1000 AD). That also caused me to realize that the Gregorian calendar is used for all dates, including those before the switchover from the Julian calendar in 1582 October. I've fixed both of these. Dates to -999 are now accepted. To go before that, I'd have to resort to some sort of trickery, since MPC-formatted dates have four digits, minus sign included. Such trickery is certainly possible -- see this documentation of a way to set arbitrary observation times -- but it is completely untested and probably useless. I won't bother unless somebody points out to me a need to examine dates after 2100 or before -999.
• (2010 Mar 12) Peter Birtwhistle pointed out, on the Find_Orb users group, that if one does about 500 Monte Carlo variants, the Windows version of the software crashes. (The console app versions on DOS, Linux, and OS/X are unaffected by this bug.) I found the problem and fixed it.
• (2010 Mar 12) In the course of fixing the above bug, I realized again that making Monte Carlo variants was slow. Find_Orb computes one such variant every half-second. For short arcs, or with no perturbers, it could be computing far more than that. I revised the code so it would compute Monte Carlo orbits for a quarter second, once every half second. In short, with MC turned on, half the CPU time will be devoted to computing Monte Carlo orbits.
I may make this user-tunable ("I want this to run in the background, not using much CPU time, while doing other things... set it to ten percent", versus "I'm going out for a few hours; the computer might as well crunch Monte Carlo orbits 100% of the time.") But I've not done that yet.
• (2010 Feb 18) Andy Puckett pointed out that inclusion of asteroid perturbers was broken. I fixed this.
• (2010 Feb 18) At Andy Puckett's suggestion, I've added an 'All Perturbers On' button (which becomes an 'All Perturbers Off' button when perturbers are on). Click here for details.
• (2010 Feb 18) Handling of the new WISE (C51) observations was sometimes not as good as it might be. Satellite observations are provided in two lines; sometimes, for WISE data, those lines were the opposite of what one might expect. I revised Find_Orb to handle that situation, and to do somewhat better error checking on the observations in general.
• (2009 Oct 21) The console app version is now known as find_orb (or, under Windows, find_orb.exe). It had previously been known as dos_find, which got increasingly confusing as it was ported to Linux and OS/X!
• (2009 Oct 21) The program handles the absence of key files more intelligently now, giving you warning messages or errors as needed. Also, the absence of ephemeris files is not as disastrous as it once was. It's still best to set up JPL ephemeris files, but you'll get pretty good results for most objects without them (though the program is apt to be slower).
• (2009 Oct 21) One can now compute ephemerides from the surface of another planet or moon or the sun. It was already possible to compute ephemerides from the center of any planet or the moon or the sun. But you can now do it from surfaces, too. You can see how by looking at rovers.txt. An example "rover" is given for the impact point of the LCROSS mission. Given astrometry for LCROSS, this results in an ephemeris with the range dwindling to zero at the time of impact. < < This may also allow one to include "off-earth" observations from the surfaces of planets. But I have no data with which to test that idea yet. (Edit: this has now been done, using Mars rover data for Phobos and Deimos. 'Spirit' and 'Opportunity' are both in rovers.txt now.)
• (2009 Oct 21) The console app version now shows impact data in blinking text, just to make sure you don't overlook possible impacts. Similarly, MOIDs less than .01 AU are shown blinking. This may be extended to some other text that really should get user attention. Unfortunately, I don't see a way to do this properly in Windows (yet).
• (2009 Sep 19) Reiner Stoss pointed out that the posted version was actually the April one, completely missing the improvements listed below for 28 May. I've posted a current version. In addition to actually providing the improvements that should have been made in May, the current version has several bug fixes that will, I think, resolve some crashes that were reported. Also, there's a "maximize" button for the main and ephemeris dialogs.
• Also: a while back, I posted some pseudo-MPECs with NEOCP data. Shortly thereafter, MPC added the following note at the end of all NEOCP astrometry files:
REMARK: Not to be redistributed. For personal use only.
So all pseudo-MPECs you generate now will have the lines with NEOCP data "redacted", sort of like a classified document. (Note that as of late 2013, you can now 'greenlight' an observatory if it is willing to have its data redistributed.)
• (2009 May 28) Bug fixes: Reiner Stoss pointed out that you should be able to save residuals in MPC format by using a .res extension. It turned out that this had been "broken" for a little while now. Also, the program crashed when it encountered an MPC code it didn't know about, instead of giving the "MPC code XXX is unknown" message it was supposed to show. (This happens most frequently when one has new data with new observatories, but an out-of-date list of MPC observatories.) Both bugs are now fixed.
• (2009 Apr 15) A few small fixes:
• (2009 Apr 6) On 1 March, I revised the main dialog and ephemeris dialog so they were resizable. But you could make them too small; it was left up to you. Now, the main dialog can only be resized in height, and you're prevented from making either dialog so small as to cause trouble. Also, the ugly font for ephemerides has been replaced with a more readable one. Also, a make file for the MinGW compiler (a version of the gcc compiler for Win32) is included, and a few small changes made to the source code to accommodate that compiler.
• (2009 Mar 24) John Dailey asked about some problems in compiling the Linux console version on a 64-bit system. It turned out that this was possible to do, after we made some small modifications to certain parts of the program that assumed 32-bit integers. While I was about it, I also cleaned up most of the remaining g++ compiler warnings.
• (2009 Mar 9) Recompiling the Linux console version with Ubuntu 8.10 and a current g++ compiler turned up a small bug (nothing affecting DOS/Windows users). I also fixed a few compiler warnings.
• (2009 Mar 9) Andy Puckett suggested that if ephemerides were made with, say, a .02-day step size, then the ephemerides should be given to .01-day precision. Now, they are.
• (2009 Mar 5) Several improvements:
• (2009 Mar 3) The handling of JPL DE ephemerides is simplified. In most cases, as long as the JPL ephemeris file is in the Find_Orb folder, Find_Orb will recognize it, without you having to add its name to environ.dat.
• (2009 Mar 3) You can specify positions in epochs other than J2000, useful when dealing with historical data in mean coordinates or B1950 or other epochs.
• (2009 Mar 1) Several improvements:
COLLISION_ALTITUDE=50to have the impact data reflect an altitude of (for example) 50 km.
• (2008 Oct 14) Three small improvements:
• (2008 Sep 10) Several small improvements:
• (2008 Feb 25) Several small improvements:
• (2006 Nov 13) Several improvements:
• (2006 May 3) The MOID (Minimum Orbit Intersection Distance) relative to the Earth's orbit is shown if that distance is less than one AU. It is also shown for other planets if the distance is small enough (limits are .1 AU for Mercury, Venus, and Mars, and one AU for the other planets).
• (2006 May 3) It's possible to reset the weights for observations, in any of three different ways. Click here for details.
• (2006 May 3) You can now get ephemerides in Cartesian coordinates (either position-only, or position-plus-velocity).
• (2006 May 3) The text-based (console) version of Find_Orb now supports some mouse commands, at least on some platforms.
• (2006 May 3) In addition to MOID data, a few other minor details are now shown in the elements, such as the apoapsis distance (Q) and the time of perihelion, expressed in HH:MM:SS form.
51 language i 51 language f
