[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] EGM96 vs. WGS84-EGM96


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