What it is: This is a command-line program with (at present) exactly one purpose: it reads in a file of asteroid astrometry in the usual 80-column MPC astrometry format, finds objects listed in that file, and attempts to match them with known minor planets. It's essentially a clone of the MPC's MPChecker service, except that it all runs locally and is therefore not dependent on being on-line.
(Note, however, that astcheck is now available as an on-line service, thanks to the efforts of Arto Oksanen.)
One can also use JPL's Small Body Identification service, though this has an extremely "user-abusive" interface from the viewpoint of asteroid astrometrists. However, I think it includes perturbations, making it a better choice if you want to check objects from years past. (Neither MPChecker nor astcheck includes perturbations, so their accuracy gradually degrades as one gets far from the epoch of the elements.)
astcheck has the advantage that it makes use of motion and uncertainty data; this can allow it to make identifications even if the object is several degrees off prediction.
astcheck is distributed under the GPL (GNU General Public License), version 2, which basically means you can do what you want with it (and with the source code), and can use/distribute it without having to pay for it. Use in or with commercial software is forbidden without written permission from Project Pluto:Project Pluto 168 Ridge Road Bowdoinham ME 04008 (UNITED STATES) tel (207) 666 5750 plutó@projectplutô.cóm http://www.projectpluto.com
If you use it for something interesting, though, please let me know!
Why it exists: MPChecker is an excellent service, but it's frequently unavailable, either because the server is busy or one isn't on-line. It's also a bit slow. This program is not (except for a half-minute or so required when fed data for a new night; more on this below.) Also, because it makes use of both position and motion data, you can usually identify objects even if they are several degrees off prediction.
How to set it up: First, one needs a current copy of either the Lowell ASTORB dataset or of the MPC's MPCORB dataset. A compressed version of astorb is available here (about 39 MBytes). An uncompressed version is available here (about 142 MBytes).
Links to mpcorb.dat are provided here. I've mostly used astorb because it has "current ephemeris uncertainty data". I expect to be able to use this to estimate how likely a given match between observation and known object might be. But in some cases, it may be helpful to be able to use mpcorb.dat instead, especially since astcheck isn't actually making any use of the ephemeris uncertainty data yet anyway.
Also, you should download the MPC's list of observatories so that astcheck can figure out your topocentric position. (Without it, positions will be slightly more off than they really ought to be.)
And, of course, you'll need to download astcheck.exe. Or if you're on Windows and have the MinGW compiler installed, you can download the source code and run make -f lunar.mng. (Or, if using Visual C++, nmake -f lunardll.mak; or, with OpenWATCOM C/C++, run wmake -f watmake. Interestingly, one's choice of compiler can make a big difference in speed.)
Also, you can download the source to a Linux box and run make -f linlunar.mak.
How to use it: Put astcheck.exe, astorb.dat, and ObsCodes.html into a common folder. From a command prompt, run
where ifile is the name of the input MPC astrometry file. astcheck will load up the data and look for objects.
For each object in the file, the name and its motion in RA and dec, in arcminutes/hour, will be shown. (If there's only one observation, you'll get a "no motion available" message.) This will be followed by a list of matching objects, up to a one-degree radius, ordered by distance from the observation. Example output:
ASTCHECK version Dec 28 2010 15:49:08 astorb.dat version 2010 12 14, with 541500 objects (257455 numbered) d_ra d_dec dist mag motion J99XE1M: 276"/hr in RA, 202"/hr in dec (0.38 hours) 1999 XM141 4 1 4 18.2 275 202 K03SM2V: -64"/hr in RA, -36"/hr in dec (0.45 hours) 2003 SV222 0 -0 0 19.5 -64 -36 K04B01V: -87"/hr in RA, 40"/hr in dec (1.26 hours) 2004 BV1 0 0 1 19.7 -86 40 K05GC0C: 194"/hr in RA, 174"/hr in dec (0.14 hours) 2005 GC120 59 63 86 16.9 195 176
For each object, the packed designation, the apparent object motion, and the arc used to determine that motion are given. (If only one observation is available for an object, you'll just see a message "only one observation". This isn't a good idea. astcheck will usually check candidate matches based on both position and apparent motion. If the only matching it can do is position-based, you'll get a lot of possible matches.)
For each possible match, offsets in RA and dec and the total distance (all in arcseconds) are shown. This is followed by the computed magnitude and computed motion. Most of the above objects were close to position, except for 2005 GC120, which was 86" off prediction. Objects with well defined orbits are usually within an arcsecond or two of prediction.
By default, the program goes down to mag 21 and has a one-degree search radius. Also, the motion must match to within 10"/hour. One can reset these using the -m, -r and -z switches, respectively. For example,
astcheck ifile -m22.5 -r1800 -z15
would result in asteroids down to mag 22.5 being shown, out to a half degree (1800 arcseconds), with the motion required to match to within 15"/hour. (The default 10"/hour motion requirement may seem excessively lax. Indeed, if your observed arc is more than ten minutes, you ought to have determined the motion more precisely than that. However, even a very lax motion requirement almost always weeds out spurious matches, i.e., objects within the search radius that are moving in a different direction.)
Other command-line options are -e to have the ephemeris uncertainties from astorb.dat displayed for each object, and -u to limit output to unnumbered objects only. There is also a -l option to show distance from the line of variations (LOV), and a -v option to show verbose comments... but neither of these last two should be needed except when debugging certain problems.
By default, checking will be done against astorb.dat. If that file is unavailable, or if astcheck is run with the -M command line switch, then mpcorb.dat will be tried.
Execution speed can be quite variable. There's a slowdown of about 11 seconds (on my admittedly antique machine) when loading up objects on a "new" night; after that, it's really fast for any other object on that night. So if you checked a hundred observations made over three nights, it'll take about 33 seconds to compute the "nightly" data, then check all the observations very quickly. More on this below.
How it works: Figuring out what objects might match among over 500,000 candidates can easily slow down even a fast computer. To speed matters up tremendously, astcheck will compute where each of those objects would have been at the start and end of the current Julian Day. For example, if fed data for JD 2455314.15926 = 2010 Apr 27.55926, it would compute the RA/dec of all 500,000+ objects for JDs 2455314 and 2455315. This data will then be cached to the hard drive under the file names 20100427.chk and 20100428.chk , useful for all observations between 27.5 and 28.5 of April 2010.
The good news is that the program can then be blindingly fast for any observations over those 24 hours, because it can look at the RA/decs at the start and end of the day and (for about 99.9% of objects) say, "No way that object matches this observation." Or maybe only a dozen or so are possible matches. Thus, in the usual scenario wherein one is looking at many objects all observed on one particular night, it's apt be fast.
When it comes across an observation made on, say, 2010 Apr 28.11, the program would need to compute and create 20100429.chk (it would already have 20100428.chk), and could then proceed with any objects observed on that night.
I compiled this code using three compilers: MinGW, OpenWATCOM, and Visual C/C++. Time taken to compute one .chk file was 13 seconds in VC, 21 seconds in MinGW, and 11 seconds in OpenWATCOM. It was 7 seconds on a Linux box, but it was a different (and faster) box; I've not done an apples-to-apples test here yet.
Note that you'll obviously need to update astorb.dat (or mpcorb.dat) from time to time. All you need do is replace the existing file; astcheck will be bright enough to notice that the file has changed and will discard cached data (the .chk files) accordingly.
Plans for the future: