bill-gray / find_orb Goto Github PK

View Code? Open in Web Editor NEW

94.0 22.0 44.0 9.26 MB

Orbit determination from observations

Home Page: https://www.projectpluto.com/find_orb.htm

License: GNU General Public License v2.0

HTML 16.60% C++ 76.29% C 6.08% Makefile 0.88% Shell 0.14% Dockerfile 0.02%

orbit-determination astronomy

find_orb's Introduction

find_orb

Orbit determination from observations

More about Find_Orb (what it does, how to use it, pre-built Windows executables) at

https://www.projectpluto.com/find_orb.htm

This project includes code for building Linux, Windows, and BSD (and possibly OS/X) versions of the interactive Find_Orb orbit determination software, the non-interactive fo software, and the fo_serve.cgi program that underlies the on-line Find_Orb service. (For a lot of purposes, the on-line service or pre-built .EXEs may be all you really need.)

Right now, only the Linux and BSD versions can be built with what's posted here. (You can probably build for OS/X, too, but I've not heard any reports on that recently.) I've not gotten around to documenting the Windows build process yet; I just provide the aforementioned pre-built EXEs. Sadly, the Windows builds require the Microsoft compiler, due to an unfortunate early choice to use MFC.

You can click here for directions on building Find_Orb from the source in this repository..

As is described at the above link, this project depends on three of my other projects :

jpl_eph (code to read JPL ephemerides)
sat_code (code for Earth-orbiting satellite ephemerides)
lunar (basic astronomical ephemeris/time functions)

At some point, I'll probably document the build procedure for Windows, but it does appear that most Windows users just want pre-built executables.

find_orb's People

Contributors

Stargazers

Watchers

find_orb's Issues

Saving orbital elements in MPC format?

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:

Does 'fo' support Lat+Lon input?

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?

POST parameter for On-line Find_Orb page to prefill observations automatically

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

http://www.projectpluto.com/fo.htm?obj_name=Phreddo&mpc_code=J95&epoch=-11&year=2017%20jan%2019&n_steps=13&stepsize=10m

the fields are not filled in

Saving orbital elements in astorb.dat format?

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:

load_default_environment_file error

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.

Program won't run on Archlinux

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)

fo: Overriding the JSON output (folder) location specified in environ.dat(/.def) for a single request

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)

Finding the errors on the phase angle, object-sun dist(delta) and elongation angle???

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.

Improve handling of non-gravs

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).

Single-opposition sungrazers

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.

Evaluate and use chi-square test

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.

Find orb fails when outputting ephemeris

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

Error when running make? (maybe user error?)

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.

Use comet magnitude model for large eccentricities

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.).)

find_orb ephemeris just printing ................

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...

Not saving elements.txt file on Linux

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!

Option to post the results to a permanent link service (e.g., pastebin)

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.

Problems with orbit fitting when using Orbit Determination

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

Encke vs. Cowell fix

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.

Missing norad.h #included by elem2tle.cpp and eph2tle.cpp

Hallo,
I could not find norad.h in any of your source trees. Please kindly help with a respective pointer.
Cheers,
Steffen

find_orb messes up terminal colour map

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.

Multi-orbit computations

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.

fo64.exe runtime error

When try to run fo64.exe the following message error appeares and application can not be run. OS: Windows10 64-bit.

Artificial satellite magnitude model

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.

Setting specifc epoch using `fo`?

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

Request for copyright information for all *.{h,cpp} files

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

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

Use of new IAU2015 astrometry format

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.

ARM g++ unable to compile lsquare.cpp

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.

Better determination of magnitude parameters

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.

Orbital elements in JSON output not correctly normalized into correct range

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

unable to compile find_orb : no curses.h

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.

Unable to compile on Debian 10 (Buster)

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?

Add names for comets, asteroids, artsats

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.

File opening errors

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.)

g++ compile error due to warning in runge.cpp

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)

Timing on elliptical errors

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.

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

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?

ARM g++ compile error due to warning on signed char in bias.cpp

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

bill-gray / find_orb Goto Github PK

find_orb's Introduction

find_orb

Orbit determination from observations

find_orb's People

Contributors

Stargazers

Watchers

Forkers

find_orb's Issues

Recommend Projects

Recommend Topics

Recommend Org