Last updated 2022 Feb 02
This is a command-line program with two purposes. You can have it read in a file of astrometry in 'traditional' MPC 80-column format and/or ADES format, and it will match them with known minor planets and comets. In this mode, it is essentially a clone of MPC's MPChecker service, except that it all runs locally and is therefore not dependent on being on-line, and can be quite a bit faster. astcheck
astcheck has the significant advantage of making identifications based on both position and object motion. That can allow it to identify objects despite them being well off the predicted position, and means it can rule out most spurious matches.
astcheck's second purpose is that you can specify a date, time, RA/dec, and MPC station, and have the program output a list of all known asteroids and comets within the field of view.
As is the case with virtually all of my source code (except for some that's too embarrassingly ugly to post), the source code is freely available on GitHub under the GPL. astcheck will be built by default when you run make (Linux, BSD, probably MacOS) or nmake -f lunar.mak (Windows).
Most Windows users are not especially interested in building software from source code. I don't currently have executables posted for Windows, but plan to do so (mostly a matter of getting a spare hour or two).
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 pause of a few seconds 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.
The program uses orbital elements in my proposed 'standard' orbit format (.sof). The benefit of this is that it means it can handle comets (the MPC's MPCORB.DAT format is limited to elliptical orbits), and should eventually handle non-gravs and objects orbiting planets.
My plan is to supply a catalogue of orbital elements, one that includes comets and asteroids and provides a one-sigma variant orbit, so that you'll have uncertainty data and an LOV. Until then, though, you'll have to download the MPC's MPCORB dataset (to get asteroid orbital elements) and JPL's DASTCOM comet elements. Then, you have to run the mpc2sof utility. (mpc2sof will be built along with astcheck, when you run 'make' on the 'lunar' (basic astronomical functions) library). mpc2sof will simply read in both files and output mpcorb.sof.
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.)
Note that you'll obviously need to update MPCORB.DAT and ELEMENTS.COMET (and then run mpc2sof again to get a correspondingly updated mpcorb.sof) from time to time. That will be all you need to do. astcheck will be a little sluggish the next time you run it, because it will notice that various cached calculations involving the old data need to be re-run.
Put astcheck.exe (just plain astcheck on non-Windows systems), mpcorb.sof, MPCORB.DAT, and ObsCodes.html into a common folder. To check astrometry, you would run the command
astcheck ifile (Windows)
./astcheck ifile (anything else)
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
mpcorb.sof 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 five-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.)
Another command-line options is -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.
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 almost instantaneously. More on this below, in the 'how it works' section.
For this, you'll need to install the same files as listed in the previous section. Then, to run it, you use a command such as
astcheck -c 2021dec25.23348 30.97379 +26.65 T08
This specifies, in order, the date/time, RA and dec in decimal degrees, and MPC station code. The time can be in any of several formats; if it contains spaces, though, you'll need to add quotation marks around the time, such as
astcheck -c "2021 12 25.23348" 30.97379 +26.65 T08
As with the astrometry-checking mode, one may add -r(radius) to set a search distance and/or -m(mag limit) to set a magnitude limit.
You don't need to know the following to use the program, but it may help if you're curious about why it's sometimes blazingly fast, sometimes takes a few seconds, and sometimes only takes a few seconds the first time you do something.
Figuring out what objects might match among over a million or so 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 1,000,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.