search

Bill-Gray / find_orb

Orbit determination from observations
https://www.projectpluto.com/find_orb.htm
GNU General Public License v2.0
98 stars 45 forks source link

Problems with orbit fitting when using Orbit Determination #32

Open berres2002 opened 2 years ago

berres2002 commented 2 years ago

I am having issues with fitting an orbit of an asteroid using find_orb's orbit determination function. I am currently building an end-to-end tester for find_orb, and one of the parameters it outputs is some of the information from the residuals of orbit determination. I am using the asteroid 594913 'Aylo'chaxnim (2020 AV2). I am giving orbit determination 30 observations (1 observation per day for 1 month) starting from the epoch time of 59000.00 mjd. I find that it only fits 11 out of the 30 observations given. Furthermore, my tester gives back the difference in the state vectors of a test orbit and the one generated by orbit determination. I find the difference in location hovers around ~100,000,000 kilometers, which is very high for observations with no astrometric error given. I have provided all the files necessary to recreate the conditions of this test using only find_orb in the file 2020_av2.zip. Just unpack it and cd into the folder and run the bash script masterRunTEST.sh. Here is some relevant data from my tester,

orbit_id observatory_code arc_length [days] num_obs num_obs_fit epoch [mjd] astrometric_error [mas] delta epoch [mjd] delta r [km] rms delta ra [arcsec] rms delta dec [arcsec] rms delta time [seconds]
0 (2020 AV2) 500 29 30 11 59029 0 9.99775e-07 2.28587e+08 974.513 323.737 15555.4

2020_av2.zip

Bill-Gray commented 2 years ago

Hi Aidan, I see what you mean. I took the shortcut and just loaded your observations into interactive Find_Orb, and it got a lousy fit to seven of 30 observations, insisting they were about 0.007 AU away. Hit 'r', set the distance to the object as 1.6 AU, and do a couple of Herget steps, and it converges rapidly on the (correct) orbit on the far side of the sun, and the other observations can be turned on and a full least-squares fit done, resulting in mean residuals of 1.0 milliarcsec.

I think the problem here is that you've got "observations" all within 11 degrees of the sun, with the object on the far side of the sun, all geocentric (no topocentric parallax), and no actual tracklet from which Find_Orb can get an initial orbit. I hadn't thought much about getting it to work with theoretical cases of this sort. I'd expect it to work frequently, but would also expect you'd have some failure cases.

I'll give the problem some thought; there's probably a way to get decent results even in these hypothetical scenarios. Theoretically, you should be able to take any three of those points and get an orbit fitting with zero residuals; add a fourth point, and you should be able to get the solution that's on the far side of the sun. Practically speaking, it can be another matter... but I may be able to come up with something.

On a side subject, the milliarcsec mean residuals are roughly at the level of relativistic light bending for a case of this ilk. For bizarre (in my opinion) reasons of "convention", ephemerides are usually generated without differential light bending included; if you generate ephems and feed them back in as observations, you'll see that milliarcsec level of residuals. That's the way Horizons, for example, does it. Find_Orb defaults to including differential light bending in its ephemerides. If the discrepancy (and resulting ~milliarcsec residuals) is a problem for your use case, you should take a look at the paragraph about this in Find_Orb's environ.dat file, above the line DISABLE_LIGHT_BENDING.