find_orb icon indicating copy to clipboard operation
find_orb copied to clipboard

What is the cause for the difference in orbital elements/state vector results between On-line Find_Orb and local 'fo'?

Open void4 opened this issue 1 year ago • 2 comments

When I run On-line Find_Orb with the following observations and with the the default settings

     K23O01V* C2023 07 23.05038923 27 14.050-60 15 50.54         17.89cVEO075M22
     K23O01V  C2023 07 23.05220423 27 06.996-60 16 40.37         17.91cVEO075M22
     K23O01V  C2023 07 23.05597523 26 52.054-60 18 25.88         17.70cVEO075M22
     K23O01V  C2023 07 23.07770923 25 27.576-60 28 09.98         17.57cVEO075M22

I get these results:

Orbital elements:  2023 OV1
   Perihelion 2023 Apr 13.12937 +/- 82.9 TT =  3:06:17 (JD 2460047.62937)
Epoch 2023 Jul 23.0 TT = JDT 2460148.5   Earth MOID: 0.0009   Ve: 0.0507
M 110.49561384 +/- 60               (J2000 ecliptic)             Auto-Find
n   1.09541911 +/- 0.502            Peri.   53.27510 +/- 46
a   0.93199984 +/- 0.285            Node   117.10053 +/- 60
e   0.1951036 +/- 0.194             Incl.   11.07695 +/- 13
P   0.90/328.64d           [H](https://www.minorplanetcenter.net/iau/lists/Sizes.html) 25.27  G  0.15   U 12.3  SR
q 0.75016328 +/- 0.158    Q 1.11383640 +/- 1.32
From 4 observations 2023 July 23 (39.3 min); mean residual 0".72
[Residuals in arcseconds:](https://www.projectpluto.com/mpec_xpl.htm#resids) 
[230723](https://www.projectpluto.com/cgi-bin/fo/fo_serve.cgi#o001) [M22](https://www.projectpluto.com/cgi-bin/fo/fo_serve.cgi#stn_M22)  .45+  .34+    [230723](https://www.projectpluto.com/cgi-bin/fo/fo_serve.cgi#o003) [M22](https://www.projectpluto.com/cgi-bin/fo/fo_serve.cgi#stn_M22)  1.3-  1.2-    
[230723](https://www.projectpluto.com/cgi-bin/fo/fo_serve.cgi#o002) [M22](https://www.projectpluto.com/cgi-bin/fo/fo_serve.cgi#stn_M22)  .58+  .64+    [230723](https://www.projectpluto.com/cgi-bin/fo/fo_serve.cgi#o004) [M22](https://www.projectpluto.com/cgi-bin/fo/fo_serve.cgi#stn_M22)  .22+  .19+

When I run a local fo on the above observations as a text file (./fo "2023 OV1.txt") however, it returns the following in elements.txt:

Orbital elements:  2023 OV1
   Perihelion 2023 Apr 11.33001 +/- 82.9 TT =  7:55:12 (JD 2460045.83001)
Epoch 2023 Jul 23.0 TT = JDT 2460148.5   Earth MOID: 0.0051   Ve: 0.0683
M 145.81219034 +/- 60               (J2000 ecliptic)             Find_Orb
n   1.42020261 +/- 0.548            Peri.   24.41514 +/- 46
a   0.78385520 +/- 0.202            Node   113.52780 +/- 60
e   0.3458996 +/- 0.194             Incl.    7.82497 +/- 13
P   0.69/253.48d           H 24.18  G  0.15   U 12.3  SR
q 0.51271995 +/- 0.158    Q 1.05499044 +/- 1.32
From 4 observations 2023 July 23 (39.3 min); mean residual 1".03
# State vector (heliocentric equatorial J2000):
#   +0.512093714988  -0.811838052610  -0.368989369723 AU
#  +13.028062337580  +5.313212537661  +0.217692901554 mAU/day
# MOIDs: Me  0.157862 Ve  0.068349 Ea  0.005057 Ma  0.333207
# MOIDs: Ju  3.969187 Sa  8.420934 Ur 17.735407 Ne 28.923689
# 1 oppositions
# Elements written: 27 Jul 2023  7:04:47 (JD 2460152.794997)
# Full range of obs: 2023 July 23 (39.3 min) (4 observations)
# Find_Orb ver: 2023 Jun 08
# Perturbers: 00000001 ;  JPL DE-421
# Tisserand relative to Earth: 2.92168
# Earth encounter velocity 8.3955 km/s
# Barbee-style encounter velocity: 7.8024 km/s
# Diameter 60.1 meters (assuming 10% albedo)
# Score: 0.554254
#  $Name=2023%20OV1  $Ty=2023  $Tm=04  $Td=11.330008  $MA=145.81219
#  $ecc=0.3458997  $Eqnx=2000.
#  $a=0.7838552  $Peri=24.41514  $Node=113.52780  $Incl=7.82497
#  $EpJD=2460148.500  $q=0.512720  $T=2460045.830008  $H=24.2
# Sigmas avail: 3

I understand that these are very few observations, but I'd like to understand why the results are different nonetheless.

When I re-run local fo on the same observations, the computation results in the same output, so the algorithm seems to be deterministic.

So the difference must lie in the settings I suppose? Does On-line Find_Orb use settings that differ from a newly compiled fo?

void4 avatar Jul 27 '23 07:07 void4

Same here, comparing an old version (~June 2021) with the most recent one:

E.g. for these observations

 P21GsoD  C2023 06 20.54420422 30 36.196+03 52 05.09         22.03wX     F52
 P21GsoD  C2023 06 20.55637522 30 36.511+03 52 12.66         21.85wX     F52
 P21GsoD  C2023 06 20.56856522 30 36.801+03 52 20.39         21.92wX     F52

I get this orbit with the old version of fo:

P21GsoD 17.54 0.15 K236L 333.11277 85.65540 268.16661 12.79879 0.1402956 0.20784448 2.8225635 FO 230620 3 1 35.1 min 0.07 Find_Orb 0000 P21GsoD 20230620

With the recent version of fo I get:

P21GsoD 19.12 0.15 K236L 291.35139 323.82483 147.43272 19.55859 0.9381982 0.77811153 1.1706889 FO 230620 3 1 35.1 min 0.07 Find_Orb 0000 P21GsoD 20230620

The determined orbit with the old version looks more reliable.

a-doppler avatar Aug 09 '23 16:08 a-doppler

Yes, there are definitely likely to be differences between versions, especially with these very short arcs.

For one thing, I've occasionally had to tweak the "evaluate orbit likelihood" function a bit. This is a drastically simplified version of MPC's digest2 code, which has a complete model of the likely asteroid population and of the fraction of that population we've actually found. That enables them to do a very good job of saying "this orbit looks reasonable."

Find_Orb just has a histogram of the number of objects in particular inclination and semi-major axis bins, plus some constraints on eccentricity and some other parameters. It works fairly well, but some odd cases do get past it, and I've modified it a bit from time to time.

Bill-Gray avatar Aug 17 '23 16:08 Bill-Gray