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