bill-gray / find_orb Goto Github PK
View Code? Open in Web Editor NEWOrbit determination from observations
Home Page: https://www.projectpluto.com/find_orb.htm
License: GNU General Public License v2.0
Orbit determination from observations
Home Page: https://www.projectpluto.com/find_orb.htm
License: GNU General Public License v2.0
The code for non-gravitational forces (solar radiation pressure, comet model, with others such as Yarkovsky to be added) is messy. Constrained non-gravs are poorly implemented, and sometimes result in being unable to determine an orbit. This has to be fixed before Yarkovsky or YORP or other models are added. Also, one sometimes wants to have only tangential forces added (i.e., A1=0, and A2 is the only desired parameter).
At present, Find_Orb uses the "standard" asteroid H/G magnitude model unless an object has a comet designation. In that case, it uses a comet magnitude model.
That decision really ought to involve looking at the orbit. If the object is in a near-parabolic orbit, the comet magnitude model should be used. (And if it's in orbit around the earth, an artsat magnitude model should be used... but that's another issue (q. v.).)
I'd like to do ephemeris calculations from various locations on the globe to get the expected azimuth and altitude angles in case something like 2023 CX1 happens again :)
The fo usage site seems to document the -C flag to provide an observatory code. Observatories are not too densely scattered around the globe, however:
(Thank you for providing mpc_stat.txt, which allowed me to create this graphic, I've put it now as an interactive map up here: https://void4.github.io/obsmap.html)
Is it or would it be possible for ''fo' to accept custom lat/lon coordinates from the command line?
Occasionally, files are not opened that lead to fatal errors. In such cases, one should get a message such as "unable to open abc.txt: Permission error". I need to ensure that all file opens either lead to a graceful error message, or that the inability to open a file is handled inside the code in a graceful manner. (Noted in the Windows version, where a user saw that installing in non-root mode led to trouble; but it's a general issue.)
At present, Find_Orb can determine an orbit linking point A to B in time t0 in half an orbit. It won't get an orbit going "the wrong way" or making three-and-a-fraction orbits. Having that capability would really enhance the ability to do linkages. I've got this part mostly working, but not incorporated into Find_Orb yet.
I was getting used to using find_orb, but then somehow I broke it (kept getting an error about a missin ps_1996.dat file that was totally there), so I deleted everything and installed again. This time, producing ephemerides (with the C
option set to observables
) just returns a single line of periods instead of the ephemerides requested, like so:
#(568) Mauna Kea: Col3N10
Date (UTC) RA Dec mag " sig PA
---- -- -- ------------- ----------- --- ---- ---
................
Given that this was the first thing that I did after re-installing and that it worked for the same (mpc-formatted) astrometry file before I broke the previous install, I don't really understand why this is happening...
Hallo,
I could not find norad.h in any of your source trees. Please kindly help with a respective pointer.
Cheers,
Steffen
Running on Ubuntu 19.04. Doesn't save out an elements.txt file to the default find_orb directory when running fo obs.txt. Also fails with a different error message when trying to just save it out with the -s switch and a path.
Segmentation fault (core dumped)
Thanks Bill!
Current sungrazer orbit determination is pretty bad. The code currently looks for a parabolic orbit with inclination near 144 degrees (usual Kreutz). The constraints should be in perihelion ecliptic lat/lon and distance, with other constraints used for Meyer, Kracht, etc.
Dear Bill,
as time permits, please kindly add a copyright statement where there is none, yet. I happily perform that presumed routine work over here and send a pull request if that is of any help. This is about the files
about.h
bmouse.h
curs_lin.h
details.h
ephem.h
find_orb.h
generic.h
lsquare.h
monte0.h
monte.h
mpc_obs.h
mt64.h
mycurses.h
orbitdlg.h
settings.h
sigma.h
stackall.h
stdafx.h
bc405.cpp
bias.cpp
bmouse.cpp
cssfield.cpp
details.cpp
errors.cpp
geo_pot.cpp
healpix.cpp
miscell.cpp
monte0.cpp
monte.cpp
nanosecs.cpp
roottest.cpp
shellsor.cpp
simplex.cpp
stackall.cpp
stdafx.cpp
I know. It is about complete confidence that the source tree may be redistributed with Debian - or anybody, really - and that no license is violated.
So, as I said, should you feel like instructing me to add
/*
Copyright (C) 2010, Project Pluto
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA. */
to all these files then I will just do that and send a PR about it.
Many thanks
Steffen
Hello.
I built the latest version from master and after running I get the following error:
./find_orb
find_orb: mpc_obs.cpp:4851: int load_default_environment_file(): Assertion `!rval' failed.
Aborted (core dumped)
My build pc:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230801 (GCC)
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 |
Ideally, if one loads observations of C/2007 Q3, Find_Orb would show it as "C/2007 Q3 (Siding Spring)". If you loaded observations of the minor planet (4179), it would show up as "(4179) Toutatis". And the artsat 1999-066A would appear as 1999-066A = NORAD 25989 = XMM-Newton. Files with these cross-designations are available; it wouldn't be difficult for Find_Orb to use them.
Hi Bill, we are using your excellent software to compute updated element sets close to the observation date for NEO observations where precise pointing is critical. What we would like would be a way to specify a particular epoch of elements to the command line fo
version (since this code is being run offline in a non-interactive way). This would fix issues on e.g. incoming NEOs which haven't been seen on a while.
An example would be 2016 AZ8. We were trying to recover it in 2019 January but if you fed the file of observations at the time (ending on 2016 03 29.180673) you would get an epoch of elements during that 2016 apparition which gave much worse predictions of the potential position. If we could have said to fo
to compute an element set for 2019-01-15 for example, this would be very helpful.
Cheers,
Tim Lister
I'd like to provide a 'fo'-based service for asteroid hunters that allows them to run their own observations against many observations of existing objects simultaneously, to see if the residuals are close enough that they could match up and be the same object.
For this I expect many runs of 'fo' simultaneously, which could be problematic because the JSON output files could be overwritten if the requests are not spaced far enough apart in time. Right now I'd have the options to
(1) Create a request queue that ensures that requests run sequentially, modifying environ.def before each fo
execution - this would probably be too slow with the number of objects considered
(2) When a new request comes in, indicate (for example with a new, empty file or an extra information line in environ.def or some kind of lock) that environ.def has been modified and is waiting to be read, then programmatically change the following lines
JSON_EPHEM_NAME=~/json/eph%p_%c.json
JSON_ELEMENTS_NAME=~/json/ele%p.json
JSON_SHORT_ELEMENTS=~/json/short%p.json
JSON_COMBINED_NAME=~/json/com%p_%c.json
to point to a unique output directory for this request, then start fo and wait the minimum time until it has read that configuration file and delete the indicator file. All processes wanting to make a request would check for the existence of the file/hint/lock and have to wait until it is removed.
These workarounds could be avoided if fo
included a command line flag that allowed one to specify the output directory (and/or paths including filename) for these JSON files, overriding the settings in environ.dat(/.def)
Edit: I suppose another option/possible feature would be to add a flag that allowed one to specify an environ.def path, then a custom environ.def could be created for every request
Edit2: Oooh, I see that is possible with https://www.projectpluto.com/fo_usage.htm#option_D - great!
Edit3: It seems that using this approach, I can specify the JSON file output paths, but not the elements.txt one (there doesn't seem to be a flag for its path either)? I need the elements.txt because it includes the state vector data, which I need to generate a custom orbitsimulator.com link (and therefore I don't have the option to read from elements.json, because that file doesn't include them)
At present, Find_Orb shows the mean (unweighted) residuals from the orbit fit. This is mostly just to replicate what people are used to. Showing the mean weighted residuals and applying the chi-square test of significance would be more useful. I've written code to compute the incomplete gamma function required for this, so it shouldn't be a big deal.
While fitting 2023 PC, I noticed a discrepancy in the normalization of the mean anomaly M between the elements.txt
, which was correctly in the range of 0...360 degrees and the value in the elements.json
which wasn't.
elements.txt:
Orbital elements: 2023 PC
Perihelion 2023 Nov 18.166035 +/- 0.0107246 TT = 3:59:05 (JD 2460266.666035)
Epoch 2023 Aug 17.0 TT = JDT 2460173.5 Earth MOID: 0.0313 Ve: 0.0980
M 265.36145981 +/- 0.0118074 (J2000 ecliptic) Find_Orb
n 1.01580516 +/- 9.82149e-6 Peri. 311.44475 +/- 0.0027232
a 0.98008205 +/- 6.31727e-6 Node 126.07916 +/- 0.0005508
e 0.1829179 +/- 8.47122e-5 Incl. 5.58480 +/- 0.0032467
P 0.97/354.39d H 24.6 G 0.15 U 5.0
q 0.80080746 +/- 7.78775e-5 Q 1.15935663 +/- 9.04761e-5
34 of 45 observations 2023 July 10-Aug. 10; mean residual 0".22
elements.json (relevant segment only, MOIDS trimmed):
"elements":
{
"central body": "Sun",
"epoch": 2460173.50000000,
"M": -94.63854019, "M sigma": 0.0118074,
"n": 1.01580517, "n sigma": 9.82149e-6,
"a": 0.98008205, "a sigma": 6.31727e-6,
"e": 0.18291793, "e sigma": 8.47122e-5,
"q": 0.80080747, "q sigma": 7.78775e-5,
"Q": 1.15935664, "Q sigma": 9.04761e-5,
"i": 5.58480168, "i sigma": 0.0032467,
"arg_per": 311.44475676, "arg_per sigma": 0.0027232,
"asc_node": 126.07916128, "asc_node sigma": 0.0005508,
"Tp": 2460266.66603521, "Tp sigma": 0.0107246,
"H": 0.15,
},
Files attached (JSON file renamed to elements_json.txt
since github doesn't allow upload of that type)
elements.txt
elements_json.txt
I've followed all the procedure here.
Although I had some uncertainties in finding the equivalent package on Debian for "ncurses-devel" and "libcurl-devel".
All compiled fine and I am able to launch: ~/find_orb/lunar/jd
.
But when compiling 'find_orb' and 'fo' as:
cd ~/find_orb/find_orb
make
I always end up with:
g++ -c -O3 -Wall -pedantic -Wextra -I ~/include orb_func.cpp
orb_func.cpp: In function ‘void light_bending(const double*, double*)’:
orb_func.cpp:724:18: error: ‘dot_product’ was not declared in this scope
phi1 = acose( dot_product( result, observer) / (rlen * olen));
^~~~~~~~~~~
orb_func.cpp: In function ‘int get_sr_orbits(double*, observe*, unsigned int, unsigned int, unsigned int, double, double)’:
orb_func.cpp:1672:4: error: ‘INTENTIONALLY_UNUSED_PARAMETER’ was not declared in this scope
INTENTIONALLY_UNUSED_PARAMETER( noise_in_sigmas);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
orb_func.cpp: In function ‘double dotted_dist(observe*)’:
orb_func.cpp:2374:12: error: ‘dot_product’ was not declared in this scope
return( dot_product( obs->vect, obs->obj_posn) - dot_product( obs->vect, obs->obs_posn));
^~~~~~~~~~~
orb_func.cpp: In function ‘double score_orbit_arc(const observe*, unsigned int)’:
orb_func.cpp:3428:26: error: ‘dot_product’ was not declared in this scope
const double dot = dot_product( xprod, obs[i].vect);
^~~~~~~~~~~
orb_func.cpp: In function ‘void look_for_best_subarc(const observe*, int, double, int*, int*)’:
orb_func.cpp:3471:22: error: ‘dot_product’ was not declared in this scope
&& dot_product( obs[i].vect, obs[j + 1].vect) > cos_45_deg)
^~~~~~~~~~~
make: *** [makefile:197: orb_func.o] Error 1
Any advice?
I'm working on an Apple Macbook M1 ("Apple Silicon") which is an ARM platform. I'm running inside a Docker container so my OS is Ubuntu, but the architecture is 64 bit ARM.
Building fails to me on the current version:
$ make
g++ -c -Wall -pedantic -Wextra -Werror -I ~/include -O3 fo.cpp
g++ -c -Wall -pedantic -Wextra -Werror -I ~/include -O3 ades_out.cpp
g++ -c -Wall -pedantic -Wextra -Werror -I ~/include -O3 b32_eph.cpp
g++ -c -Wall -pedantic -Wextra -Werror -I ~/include -O3 bc405.cpp
g++ -c -Wall -pedantic -Wextra -Werror -I ~/include -O3 bias.cpp
bias.cpp: In function 'int find_fcct_biases(double, double, char, double, double*, double*)':
bias.cpp:85:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
85 | if( catalog == -1) /* free up internal data */
| ~~~~~~~~^~~~~
cc1plus: all warnings being treated as errors
make: *** [makefile:348: bias.o] Error 1
This is using g++ 11.3.0
on Ubuntu 22.04.
Here's the script I ran in a fresh ubuntu:22.04
Docker container:
apt update -y
apt install -y \
ncurses-dev \
libcurl4-openssl-dev \
build-essential \
g++ \
gcc \
git
git clone https://github.com/Bill-Gray/lunar.git
git clone https://github.com/Bill-Gray/sat_code.git
git clone https://github.com/Bill-Gray/jpl_eph.git
git clone https://github.com/Bill-Gray/find_orb.git
git clone https://github.com/Bill-Gray/miscell.git
cd lunar
make
make install
cd -
cd jpl_eph
make
make install
cd -
cd sat_code
make
make install
cd -
cd miscell
make
make install
cd -
cd find_orb
make
make install
cd -
This errors
It would be great if find_orb could export orbital elements in the astorb.dat format, which differs from the MPC Export Format for Minor-Planet Orbits (i created a separate issue for that here: #44).
My specific use case here would be the ability to track objects directly from observations using the Planewave PWI4 software:
Pressing S on the orbital elements+observations screen saves the orbital elements in this format:
Orbital elements: DRS044
Perihelion 2022 Oct 20.35345 +/- 535 TT = 8:28:57 (JD 2459872.85345)
Epoch 2023 Jul 14.0 TT = JDT 2460139.5 Ju: 0.4692 Find_Orb
M 8.47557165 +/- 60 (J2000 ecliptic)
n 0.03178579 +/- 0.0885 Peri. 93.43502 +/- 110
a 9.86992906 +/- 18.3 Node 122.98057 +/- 3.0
e 0.8012000 +/- 0.246 Incl. 15.61214 +/- 39
P 31.01 H 17.33 G 0.15 U 11.1 SR
q 1.96214092 +/- 1.38 Q 17.7777171 +/- 48.7
From 3 observations 2023 July 14 (98.8 min); mean residual 0".02
# State vector (heliocentric equatorial J2000):
# +1.795930046554 -2.595361725065 -1.115701474350 AU
# +11.779052930229 -0.061550516807 -2.839454952611 mAU/day
# MOIDs: Me 1.537060 Ve 1.270006 Ea 1.028439 Ma 0.584696
# MOIDs: Ju 0.469205 Sa 1.499598 Ur 5.325759 Ne 13.249515
# 1 oppositions
# Elements written: 15 Jul 2023 3:49:48 (JD 2460140.659590)
# Full range of obs: 2023 July 14 (98.8 min) (3 observations)
# Find_Orb ver: 2023 Jun 08
# Perturbers: 00000001 ; JPL DE-421
# Tisserand relative to Jupiter: 2.11468
# Diameter 1403.6 meters (assuming 10% albedo)
# Score: 0.406810
# $Name=DRS044 $Ty=2022 $Tm=10 $Td=20.353447 $MA=8.47557
# $ecc=0.8012001 $Eqnx=2000.
# $a=9.8699291 $Peri=93.43503 $Node=122.98057 $Incl=15.61215
# $EpJD=2460139.500 $q=1.962141 $T=2459872.853448 $H=17.3
# Sigmas avail: 3
Is it/would it be possible to save this information in the one-line MPC orbit format instead?
A use case for this would be being able to import these orbits into Stellarium via its Solar System Editor plugin:
Find_Orb currently has two magnitude models: a comet mag model, and the standard H/G asteroid model. There is yet another model, commonly used for artificial satellites, in which the magnitude just runs as the fraction of a sphere that would be illuminated at that distance and angle. It's not a great fit -- artsats obviously have a wide range of shapes and their magnitudes can be weird -- but that model is a lot better than the H/G one, which is really intended for rocks.
This proposed new format is described at
http://minorplanetcenter.net/iau/info/IAU2015_ADES.pdf
At some point, it may actually see some use, and Find_Orb will need to be able to load XML and PSV (Pipe-Separated Variable) versions of this format. I expect we'll still need to be able to read the 80-column punched-card data and the AstDyS/NEODyS data, and may want to have tools to go to and from these four formats.
Building fails to me on the current version:
ror -I ~/include -O3 runge.cpp
runge.cpp: In function ‘int calc_derivativesl(long double, const long double*, long double*, int)’:
runge.cpp:993:28: error: ‘jupiter_loc[0]’ may be used uninitialized [-Werror=maybe-uninitialized]
993 | coord = jupiter_loc[j] + planet_loc[12 + j] * JUPITER_R;
| ^
runge.cpp:839:25: note: ‘jupiter_loc[0]’ was declared here
839 | double lunar_loc[3], jupiter_loc[3], saturn_loc[3];
| ^~~~~~~~~~~
runge.cpp:993:28: error: ‘jupiter_loc[1]’ may be used uninitialized [-Werror=maybe-uninitialized]
993 | coord = jupiter_loc[j] + planet_loc[12 + j] * JUPITER_R;
| ^
runge.cpp:839:25: note: ‘jupiter_loc[1]’ was declared here
839 | double lunar_loc[3], jupiter_loc[3], saturn_loc[3];
| ^~~~~~~~~~~
runge.cpp:993:28: error: ‘jupiter_loc[2]’ may be used uninitialized [-Werror=maybe-uninitialized]
993 | coord = jupiter_loc[j] + planet_loc[12 + j] * JUPITER_R;
| ^
runge.cpp:839:25: note: ‘jupiter_loc[2]’ was declared here
839 | double lunar_loc[3], jupiter_loc[3], saturn_loc[3];
| ^~~~~~~~~~~
cc1plus: all warnings being treated as errors
make: *** [makefile:357: runge.o] Error 1
==> ERROR: A failure occurred in build().
Aborting...
My building system:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.1 20230429 (GCC)
Find_Orb has some good code for handling timing errors in astrometry, very useful for fast-moving objects. It also (as of mid-July 2016) has good code for handling the fact that astrometric errors are not necessarily circular; the uncertainty error can be elliptical, not necessarily aligned with RA/dec axes. If you have such an elliptical error, the effect of timing uncertainty is to "stretch" that ellipse along the direction of motion. I've figured out the resulting modified error ellipse, but don't have that code in Find_Orb yet. At present, therefore, timing errors are only applied to circular astrometric errors. This needs to be fixed.
Find_Orb can use the method of Encke when integrating an orbit. (In this method, a two-body orbit is computed analytically, and you integrate only the perturbations relative to that ellipse/parabola/hyperbola. It results in more complicated math and code, but can sometimes make the integration much faster. The alternative, in which you just treat the sun's gravity as you would that of any other object, is the method of Cowell, or the 'direct' method.) It can be turned on via a switch in 'environ.dat'.
The problem is that it sometimes leads to the orbit blowing up when you do a full step. This has to be fixed before the method of Encke has any hope of becoming the standard (and faster) way of doing things in Find_Orb.
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
?
Running find_orb in a linux terminal seems to mess up the terminal's colour map, in a way that persists after find_orb is no longer in use, persisting until the terminal is closed (fortunately it does not persist when a new terminal is opened). This is somewhat annoying when working on a small laptop monitor, as I don't really have screen real-estate enough to have multiple terminals up, so it's easiest to use one terminal for everything, but once the terminal has been used for find_orb, it's very straining on the eyes to try to use the terminal for other tasks (like browsing files, editing observations/scripts/commands, etc).
Here are a before and after screenshot from a test directory showing the change of colours:
Before:
After:
Is there some way to fix this so that the original colours return when find_orb is exited? Perhaps rather than changing the colour scheme of the terminal, find_orb just uses specific colours? Alternatively, when it changes the colour scheme, it could save the old settings in a backup somewhere and set them back when find_orb is exited.
I am getting a load_default_environment_file(): Assertion
!rval' failed.` error of a freshly compiled Find_Orb. Guessing from the code, I think it's complaining that environ.def/environ.dat somehow cannot be load, but environ.def is present so I don't understand why.
Is there anything that I should be looking into? The OS is RH 9.1 and the CPP compiler is 11.3.1.
When I try to run the most recent version of findorb and output the ephemeris
fo fubar.mpc -e new.ephem
I get the following error:
Error opening combined.json: No such file or directory
I'd like to link from our page (https://deeprandomsurvey.org/object/DRS044) directly to the https://www.projectpluto.com/fo.htm with observations already filled in.
Could you add a POST parameter so when https://www.projectpluto.com/fo.htm is opened and it is supplied, the TextArea element is already filled in?
Due to the character limit (~2048) of URLs a URL parameter approach would probably not work in situations with more than a few lines of observations.
Edit: On another note, the existing URL parameters don't seem to work anymore either - using the example from https://www.projectpluto.com/eph_expl.htm#hints
the fields are not filled in
I'm following the install instructions here: https://projectpluto.com/find_sou.htm .
On the steps for making and installing find_orb
, make
throws this error:
g++ -o find_orb findorb.o b32_eph.o bc405.o bias.o collide.o conv_ele.o details.o eigen.o elem2tle.o
elem_out.o elem_ou2.o ephem0.o errors.o gauss.o geo_pot.o healpix.o lsquare.o miscell.o moid4.o
monte0.o mpc_obs.o mt64.o nanosecs.o orb_func.o orb_fun2.o pl_cache.o roots.o runge.o shellsor.o
sigma.o simplex.o sm_vsop.o sr.o stackall.o -L ~/lib -lm -llunar -ljpl -lsatell -lncursesw
/usr/bin/ld: cannot find -lncursesw
collect2: error: ld returned 1 exit status
make: *** [find_orb] Error 1
Am I doing something wrong? I have ncurses-dev
and libcurl-dev
installed. I'm running Ubuntu 16.04 LTE.
It seems there is no curses.h file
findorb.cpp:40:13: fatal error: curses.h: No such file or directory #include "curses.h"
Ubuntu 184.4.
Hello! I was wondering if there was anyway to get the uncertainties for the the phase angle, delta, elongation angle and the asteroid earth distance R using find orb? I can't seem to see any outputs that correspond to that.
Many thanks.
At present, when using the H/G magnitude system, H is determined and G is left at 0.15. If the observations cover a large enough range of elongations, and the magnitudes aren't the usual garbage, it would be possible (and desirable) to determine G as well.
This may become more reasonable to do if the new astrometry format, which includes uncertainties, is implemented. At present, trying to determine G from a mix of well-determined and "wild guess" photometry would be pretty much of a fool's errand.
Incidentally, this also applies to some degree with comets: the dependence of magnitude upon distance from the sun is currently fixed, and could be instead a parameter to be determined from a fit to magnitude observations.
I have a suggestion for the online version (it may be applicable for the interactive version too). How do you find adding an option to post it into pastebin (or similar site)? I find it quite useful to share results.
Pastebin has an API https://pastebin.com/api . I imagine it as a button at the bottom part of the results website.
I'm working on an Apple Macbook M1 ("Apple Silicon") which is an ARM platform.
After resolving #36, g++
hits many errors in compiling lsquare.cpp
:
g++ -c -Wall -pedantic -Wextra -Werror -I ~/include -O3 lsquare.cpp
lsquare.cpp:48:20: error: '__float128' does not name a type; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:58:4: note: in expansion of macro 'ldouble'
58 | ldouble *wtw, *uw;
| ^~~~~~~
lsquare.cpp: In function 'void* lsquare_init(int)':
lsquare.cpp:69:10: error: 'struct lsquare' has no member named 'uw'
69 | rval->uw = (ldouble *)calloc( (n_params + 1) * n_params, sizeof( ldouble));
| ^~
lsquare.cpp:48:20: error: '__float128' was not declared in this scope; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:69:16: note: in expansion of macro 'ldouble'
69 | rval->uw = (ldouble *)calloc( (n_params + 1) * n_params, sizeof( ldouble));
| ^~~~~~~
lsquare.cpp:69:25: error: expected primary-expression before ')' token
69 | rval->uw = (ldouble *)calloc( (n_params + 1) * n_params, sizeof( ldouble));
| ^
lsquare.cpp:70:10: error: 'struct lsquare' has no member named 'wtw'
70 | rval->wtw = rval->uw + n_params;
| ^~~
lsquare.cpp:70:22: error: 'struct lsquare' has no member named 'uw'
70 | rval->wtw = rval->uw + n_params;
| ^~
lsquare.cpp: In function 'int lsquare_add_observation(void*, double, double, const double*)':
lsquare.cpp:48:20: error: '__float128' does not name a type; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:115:13: note: in expansion of macro 'ldouble'
115 | const ldouble w2_obs_i = (ldouble)( weight * weight * obs[i]);
| ^~~~~~~
lsquare.cpp:117:12: error: 'struct lsquare' has no member named 'uw'
117 | lsq->uw[i] += (ldouble)residual * w2_obs_i;
| ^~
lsquare.cpp:48:20: error: '__float128' was not declared in this scope; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:117:22: note: in expansion of macro 'ldouble'
117 | lsq->uw[i] += (ldouble)residual * w2_obs_i;
| ^~~~~~~
lsquare.cpp:119:15: error: 'struct lsquare' has no member named 'wtw'
119 | lsq->wtw[i + j * n_params] += w2_obs_i * (ldouble)obs[j];
| ^~~
lsquare.cpp:119:40: error: 'w2_obs_i' was not declared in this scope
119 | lsq->wtw[i + j * n_params] += w2_obs_i * (ldouble)obs[j];
| ^~~~~~~~
lsquare.cpp:120:12: error: 'struct lsquare' has no member named 'wtw'
120 | lsq->wtw[i + i * n_params] +=
| ^~~
lsquare.cpp:121:19: error: 'w2_obs_i' was not declared in this scope
121 | w2_obs_i * (ldouble)( obs[i] * levenberg_marquardt_lambda);
| ^~~~~~~~
lsquare.cpp:106:58: error: unused parameter 'residual' [-Werror=unused-parameter]
106 | int lsquare_add_observation( void *lsquare, const double residual,
| ~~~~~~~~~~~~~^~~~~~~~
lsquare.cpp:107:48: error: unused parameter 'weight' [-Werror=unused-parameter]
107 | const double weight, const double *obs)
| ~~~~~~~~~~~~~^~~~~~
lsquare.cpp: At global scope:
lsquare.cpp:48:20: error: '__float128' does not name a type; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:127:1: note: in expansion of macro 'ldouble'
127 | ldouble lsquare_determinant;
| ^~~~~~~
lsquare.cpp:48:20: error: '__float128' does not name a type; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:160:8: note: in expansion of macro 'ldouble'
160 | static ldouble pivot_value( const ldouble *line, const unsigned line_size)
| ^~~~~~~
lsquare.cpp:48:20: error: '__float128' does not name a type; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:172:8: note: in expansion of macro 'ldouble'
172 | static ldouble *calc_inverse( const ldouble *src, const int size)
| ^~~~~~~
lsquare.cpp:353:13: error: variable or field 'mult_matrices' declared void
353 | static void mult_matrices( ldouble *prod, const ldouble *a, const int awidth,
| ^~~~~~~~~~~~~
lsquare.cpp:48:20: error: '__float128' was not declared in this scope; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:353:28: note: in expansion of macro 'ldouble'
353 | static void mult_matrices( ldouble *prod, const ldouble *a, const int awidth,
| ^~~~~~~
lsquare.cpp:353:37: error: 'prod' was not declared in this scope
353 | static void mult_matrices( ldouble *prod, const ldouble *a, const int awidth,
| ^~~~
lsquare.cpp:353:43: error: expected primary-expression before 'const'
353 | static void mult_matrices( ldouble *prod, const ldouble *a, const int awidth,
| ^~~~~
lsquare.cpp:353:61: error: expected primary-expression before 'const'
353 | static void mult_matrices( ldouble *prod, const ldouble *a, const int awidth,
| ^~~~~
lsquare.cpp:354:19: error: expected primary-expression before 'const'
354 | const int aheight, const ldouble *b, const int bwidth)
| ^~~~~
lsquare.cpp:354:38: error: expected primary-expression before 'const'
354 | const int aheight, const ldouble *b, const int bwidth)
| ^~~~~
lsquare.cpp:354:56: error: expected primary-expression before 'const'
354 | const int aheight, const ldouble *b, const int bwidth)
| ^~~~~
lsquare.cpp:48:20: error: '__float128' does not name a type; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:385:8: note: in expansion of macro 'ldouble'
385 | static ldouble *calc_inverse_improved( const ldouble *src, const int size)
| ^~~~~~~
lsquare.cpp: In function 'int lsquare_solve(const void*, double*)':
lsquare.cpp:48:20: error: '__float128' was not declared in this scope; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:428:4: note: in expansion of macro 'ldouble'
428 | ldouble *inverse;
| ^~~~~~~
lsquare.cpp:428:13: error: 'inverse' was not declared in this scope
428 | ldouble *inverse;
| ^~~~~~~
lsquare.cpp:434:42: error: 'const struct lsquare' has no member named 'wtw'
434 | inverse = calc_inverse_improved( lsq->wtw, n_params);
| ^~~
lsquare.cpp:434:14: error: 'calc_inverse_improved' was not declared in this scope
434 | inverse = calc_inverse_improved( lsq->wtw, n_params);
| ^~~~~~~~~~~~~~~~~~~~~
lsquare.cpp:440:15: error: expected ';' before 'temp_result'
440 | ldouble temp_result = 0;
| ^~~~~~~~~~~
lsquare.cpp:443:10: error: 'temp_result' was not declared in this scope
443 | temp_result += inverse[i + j * n_params] * lsq->uw[j];
| ^~~~~~~~~~~
lsquare.cpp:443:58: error: 'const struct lsquare' has no member named 'uw'
443 | temp_result += inverse[i + j * n_params] * lsq->uw[j];
| ^~
lsquare.cpp:444:27: error: 'temp_result' was not declared in this scope
444 | result[i] = (double)temp_result;
| ^~~~~~~~~~~
lsquare.cpp: At global scope:
lsquare.cpp:48:20: error: '__float128' does not name a type; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:451:56: note: in expansion of macro 'ldouble'
451 | static double *convert_ldouble_matrix_to_double( const ldouble *matrix,
| ^~~~~~~
lsquare.cpp: In function 'double* lsquare_covariance_matrix(const void*)':
lsquare.cpp:48:20: error: '__float128' was not declared in this scope; did you mean '_Float128'?
48 | #define ldouble __float128
| ^~~~~~~~~~
lsquare.cpp:465:4: note: in expansion of macro 'ldouble'
465 | ldouble *lrval = NULL;
| ^~~~~~~
lsquare.cpp:465:13: error: 'lrval' was not declared in this scope
465 | ldouble *lrval = NULL;
| ^~~~~
lsquare.cpp:468:43: error: 'const struct lsquare' has no member named 'wtw'
468 | lrval = calc_inverse_improved( lsq->wtw, lsq->n_params);
| ^~~
lsquare.cpp:468:15: error: 'calc_inverse_improved' was not declared in this scope
468 | lrval = calc_inverse_improved( lsq->wtw, lsq->n_params);
| ^~~~~~~~~~~~~~~~~~~~~
lsquare.cpp: In function 'double* lsquare_wtw_matrix(const void*)':
lsquare.cpp:485:51: error: 'const struct lsquare' has no member named 'wtw'
485 | return( convert_ldouble_matrix_to_double( lsq->wtw, lsq->n_params));
| ^~~
lsquare.cpp: In function 'void lsquare_free(void*)':
lsquare.cpp:492:15: error: 'const struct lsquare' has no member named 'uw'
492 | free( lsq->uw);
| ^~
lsquare.cpp: In function 'double* lsquare_covariance_matrix(const void*)':
lsquare.cpp:467:30: error: control reaches end of non-void function [-Werror=return-type]
467 | if( lsq->n_params <= lsq->n_obs) /* got enough observations */
| ~~~~~^~~~~
lsquare.cpp: At global scope:
lsquare.cpp:451:16: error: 'double* convert_ldouble_matrix_to_double(const int*, int)' defined but not used [-Werror=unused-function]
451 | static double *convert_ldouble_matrix_to_double( const ldouble *matrix,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is after using same setup that I described in #36.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.