Few arcseconds offset

[dpieterse]

Hello,

When I use astcheck on the centre of my FOV with a radius encompassing the entire FOV, and then use the d_ra and d_dec values it returns to compute the position of the asteroid as:
ra = ra_centre - d_ra/cos(dec)
dec = dec_centre - d_dec
I find that the computed position often is a few arcseconds off from the position that MPChecker returns for the same asteroid and observation date/time.

Do you have any idea what causes this?

[dpieterse]

Update:
The offset that I found was due to the fact that I did not integrate MPCORB to the observation epoch. When doing this, using your integrat script, there is no longer a large offset.

I do have a follow-up suggestion:
It appears that there is an inconsistency in the use of comet data files in your different scripts. astcheck uses the .sof file created by mpc2sof.cpp from the MPCORB.DAT asteroid database and JPL's comet database ELEMENTS.COMET, as you describe on the astcheck webpage (https://www.projectpluto.com/astcheck.htm). For my purposes of finding asteroid/comet positions, I first need to integrate the databases with integrat before using mpc2sof to avoid large offsets for fast-moving objects. This can be done for MPCORB.DAT. However, as I understand, integrat cannot be used on JPL's comet file. Instead, it only runs on the MPC files (https://www.minorplanetcenter.net/iau/MPCORB/CometEls.txt for the comets), which are differently formatted. And I believe that I cannot use the MPC comet file in mpc2sof. Perhaps you could change this for future versions, such that integrat and mpc2sof can make use of the same comet data files.

[Bill-Gray]

Apologies for the late reply on this!

Yes, astcheck just does a two-body (heliocentric) solution. For speed reasons, I don't expect that to change. If you want to check, say, a bunch of data from 1957, you have to run integrat to get your 1957-era version of mpcorb.sof. That'll take a while, but should be a one-off cost.

Another reason I didn't try for pinpoint accuracy is that for simply identifying objects, knowing that it's within arcseconds and shares the object's motion is sufficient. My real focus has been on getting IDs for cases where the object is arcminutes or degrees off prediction, which is a knottier problem; solving it properly will require some knowledge of the orbit's uncertainty (which, sadly, MPC is either unable or unwilling to provide; if it happens, I'll probably have to compute my own uncertainty data... which, fortunately, I can do.)

You are correct that integrat currently works only with the MPC files. At the time, I'd not come up with the .sof format. It would have simplified my life a lot, since I'd then have had one format for both asteroids and comets (and natural satellites). Integrating comets with non-gravitational effects would also become a reasonable thing to think about; it's pointless with the various MPC formats that don't support non-grav parameters.

So revising integrat to just use .sof for all input and output is definitely tempting. Must concede it's unlikely to happen soon, though, mostly because I'm woefully behind on about a dozen other projects...

[dpieterse]

Thank you very much for your response! And thank you for explaining the history regarding your .sof format. I understand that adapting integrat to allow it to use JPL's comet file as input does not have priority, nor should it I think. Perhaps sometime in the future.

I agree that for identification purposes, an offset of a few arcseconds is often irrelevant. Nevertheless it is good to know that the combination of astcheck and integrat can provide an accurate prediction of the positions of well-known asteroids if required or preferred. Which in my use case it is. I am very grateful for the code you have written! Especially as there is no real suitable alternative if one wants to obtain a list of all known asteroids that were in the pointings for analysis purposes.