The U parameter appears to be a creation of the Minor Planet Center. They provide basic documentation of how it's computed. The MPC uses it for almost all elliptical heliocentric orbits. If it's not listed, that usually means the observed arc is too short for U to be reliably determined.
The meaning of U is somewhat slippery, but generally speaking, a value of 9 (the maximum) means a poorly determined orbit, and a value of 0 or 1 (minimum values) means the orbit is so well-determined that the object is not going to be lost, and can therefore be numbered.
Find_Orb also computes U. It displays U to a precision of 0.1, which is probably overkill. MPC caps the range to be from 0 to 9; Find_Orb will happily display negative values (for some objects that are really well-determined, mostly those that have been observed with radar at multiple oppositions) and values greater than 9 (generally meaning, "this is not a well-determined orbit".)
You may want to read my list of reasons to ignore the U parameter.
(The following is borrowed from the comments in monte0.cpp, part of the source code for Find_Orb.)
The MPC documentation of the U parameter states the following, slightly edited to fix an operator-precedence issue :
---------- (mostly) quoted begin ---------- The U value is calculated in the following manner. First, calculate: RUNOFF = (sigma_T * e + 10 * sigma_P / P) * GAUSS_K * (180. / PI) * 3600 * 3 / P = k * (sigma_T * e / P + 10 * sigma_P / P^2) where sigma_T is the uncertainty in the perihelion time (in days) e is the eccentricity P is the orbital period (in years) sigma_P is the uncertainty in the orbital period (in days) GAUSS_K = Gaussian constant = 0.01720209895 radians/day k is three times the Gaussian constant in arcseconds = 3. * GAUSS_K * (180. / pi) * 3600. = 3. * 360 * 3600 / 365.256897... 3600 converts to seconds of arc 3 is a empirical factor to make the formal errors more closely model reality and RUNOFF is the in-orbit longitude runoff in seconds of arc per decade ---------- (mostly) quoted end ----------
The existence of most of those constants has to do with a dog's breakfast of units being in use. sigma_T and sigma_P are in days, but the orbital period P is in years. The number of days in a year is 2 * pi / GAUSS_K = 365.256897; the main purpose of GAUSS_K appearing in the formula is to handle the days/year conversion. If the 'runoff' were in terms of complete revolutions and we used sigma_Ty = sigma_T / 365.256897 and sigma_Py = sigma_P / 365.256897 (i.e., sigmas in units of years rather than days), we'd get
runoff_in_revolutions_per_decade = 3 * (sigma_Ty * e / P + 10 * sigma_Py / P^2)
...with the factor of ten converting years to decades. Note also that sigma_nR, the uncertainty in the mean motion expressed in units of revolutions/year, is sigma_Py / P^2, making
runoff_in_revolutions_per_decade = 3 * (sigma_Ty * e / P + 10 * sigma_nR)
The sigma_Ty * e / P term is still rather mysterious to me. I think the U parameter is basically empirical, i.e., somebody at MPC played around with different formulae until they got something they liked. But no theoretical underpinnings are documented, so I don't actually know.
This obviously has issues for nearly-parabolic or hyperbolic orbits. However, we can get around that by switching from use of P to use of the semimajor axis a = P^(2/3), P = a ^ 1.5. So (allowing for the switch from years to days)
sigma_Py = sigma_a * da/dP = 1.5 * sigma_a * sqrt(a) RUNOFF = 3 * 3600 * 360 * (sigma_Ty * e + 10 * sigma_Py / P) / P = 3 * 3600 * 360 * (sigma_Ty * e + 10 * 1.5 * sigma_a / a) / P
To avoid singularities, we're actually calculating sigma(1/a) = sigma_a / a^2, so (all of the following are equivalent)
RUNOFF = 3 * 3600 * 180 * (sigma_Ty * e + 10 * 1.5 * sigma(1/a) * a) / P RUNOFF = 3 * 3600 * 360 * (sigma_Ty * e / P + 10 * 1.5 * sigma(1/a) / sqrt( a)) RUNOFF = 3 * 3600 * 360 * (sigma_Ty * e / a + 10 * 1.5 * sigma(1/a)) / sqrt( a)
Note that RUNOFF approaches zero as the semimajor axis approaches infinity (i.e., a parabolic orbit), and is a purely imaginary (i.e., no real part) number for hyperbolic orbits. It would be nice to have an 'orbit quality' code that would produce useful results for all orbits.
I hate the U parameter. I consider it to be somewhere between misleading and meaningless, and would happily never use it again. Just thought I'd start out letting you know where I stand here.
The main reason to ignore the U parameter is that it doesn't really tell you much about the uncertainty, because it tries to collapse a multi-dimensional problem into a single dimension. It's a bit as if someone told you that an object had an area of a square meter. Maybe it's a square with one-meter sides. Maybe it's a rectangle one millimeter wide and a kilometer high, or vice versa. Or a circle 1/sqrt(π) meters in radius. Or a Koch snowflake with an infinite perimeter. Or... you get the idea.
The parameter is defined, sort of, for heliocentric elliptical orbits. It's an imaginary quantity for hyperbolic orbits. At the very least, if we had to attempt to describe orbit quality as a single number, I'd prefer something that was mathematically continuous over e.
Usually, the thing we really really want to know is how uncertain the ephemeris is as a function of time, a much more complicated question, and not amenable to being reduced to a single quantity. Usually, the ephems are "pretty good" near the time of observations, and degrade for times in the past and future. If the observations consist of two close clusters (got it over a few days here and over a few days a year later), the uncertainty will be low for those two times, higher in between, and higher before and after. If the object comes close, the uncertainty may skyrocket, then drop back.
The logic behind the U parameter is, to put it mildly, unclear. I suspect MPC played around with various factors in orbital uncertainty until they got something that "looked good" to them for purposes of deciding when to number a minor planet. The lack of explanation is disturbing to me. Aside from providing a very rough indicator of orbit quality, I can't say that I see much value to this parameter. (In MPC's defense, I think they realized that it was, at best, a very rough indicator.)