Hank Grabowski <hank@applieddefense.com> a écrit :
Hello all,
Hi Hank,
I'm in the process of doing a V&V suite of the Orekit numerical
integration
and force modeling system. I'm comparing this against a data set we
generated for validating one of my company's products, SDT. In that
process I've run into a subtly that comes up periodically but that is not
directly addressed by Orekit right now. Orekit has coded up the EGM96
reader to assume the EGM96 constants for ae and mu as defined by this
site:
http://cddis.nasa.gov/926/egm96/getit.html
However a second version of this, the so-called WGS84 EGM96 model, has a
slight different ae and mu. The rest of the coefficients are the same.
You would get that model from this site:
http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/egm96.html
Because the geopotential model is the same the big difference are these
two
slight differences in ae and mu, but that's enough to throw things off if
you are using a different model.
It is really a pity mu and ae are not in the header of the file ... This
EGM
peculiarity always bugged me.
Also from a physical point of view, I don't understand how the
coefficients could be
the same if the scaling factors change: they should all have been scaled
according
to mu / ae^n to get the same field ... Are you sure the coefficients from
the NGA
site are really intended for space dynamics computation? The page states:
The WGS 84 constants used to define the geometry and the normal field of
the
reference ellipsoid in the calculation of this geoid height
Maybe this could be interpreted only as an hint to use these coefficients
only for
geoid computations (as in the new class Evan committed recently)?
In the EGM96FormatReader code we have a
note that reads, "both EGM96 and EGM2008 use the same values for ae and
mu.
if a new EGM model changes them, we should have some selection logic.
based
on file name (a better way would be to have the data in the file...)" For
my tests I simply added an argument that let me override the ae and mu
with
the WGS84 versions. However that would mean that in order to use the
WGS84
coefficients the user has to manually override that behavior. Would it
maybe be better for us to include an "egm96" and a "wgs84egm96" file, both
identical, and add the logic to search for the override the coefficients
with the WGS84 coefficients when that occurs?
If we can be sure the second set of coefficients are really meaningful for
flight dynamics, then for sure some logic has to be added. As the
constructor
is called automatically by
GravityFieldFactory.addDefaultPotentialCoefficientsReaders,
adding the mu and ae coefficients to the constructor would only move the
problem from
one class to another class. So your idea of relying on file name is fine
to me. If the
name contains "wgs84" or "WGS84", use the corresponding constants, in all
other cases
use the regular constants. Note that we should also adjust the regular
expression
EGM_FILENAME in GravityFieldFactory.
However, I strongly advise *against* providing both files in the
orekit-data or
suggesting the user to do so. In fact, the loading mechanism is probably
too smart
here: for any data set, it will pick up the first chunk of data among the
several
formats that are supported by default, except if user explicitly taylored
the default
loaders. This is true for EOP, for ephemerides and also for gravity
fields. This means
that having both egm96 and wgs84egm96 would not be reliable as in some
cases the library
would find one file or the other as the first one and pick it up. The
reason for this
behavior is found in the javadoc specification of the listFiles method
from java.io.File
that is used in DirectoryCrawler:
There is no guarantee that the name strings in the resulting array will
appear
in any specific order; they are not, in particular, guaranteed to appear
in
alphabetical order.
Even on the same operating system, with identical JVM, identical files
layout the
order was different. We were hit several time by this feature in the unit
tests. At
least on Linux the order seems related to inode numbers, which are almost
random and
depend on the file system state when you create the file, typically by
unzipping an
archive or copying them.
So I'm +1 for a coefficient selection based on the found file name, but -1
to put
several gravity fields in orekit-data.
Thank you for spotting this subtle issue.
Luc
Hank