Overflow in GravityFieldFactory.getUnnormalizationFactors(...)
Using the snapshot that updated the potential provider interface I found that I could not load the eigen-5c.gfc gravity field (360x360) provided in the orekit-data zip due to the exception:
org.orekit.errors.OrekitException: missing gravity field coefficient C(171, 1) in file .../src/test/resources/orekit-data/orekit-data.zip!orekit-data/Potential/eigen-5c.gfc
at org.orekit.forces.gravity.potential.PotentialCoefficientsReader.setUnNormalizedC(PotentialCoefficientsReader.java:208)
at org.orekit.forces.gravity.potential.PotentialCoefficientsReader.setNormalizedC(PotentialCoefficientsReader.java:193)
at org.orekit.forces.gravity.potential.ICGEMFormatReader.loadData(ICGEMFormatReader.java:322)
I beleive this is due to the calculations in
GravityFieldFactory.getUnnormalizationFactors() as n increases.
mfactNPlusM
overflows at n=86
and causes many computed factors to be
zero. At n=171
, factN
overflows and the factors become NaNs.
I did not have this problem under the old api because I could request normalized coefficients.
IMHO since the API is still new it would make sence to switch it to use fully normalized coeffiects in order to support gravity fields with a high degree and order. Rearanging the math would help some, but degree and order would still be limited. For example, in the eigen-5c gravity model the C_360,360 ~ 2e-15 and the unnormalization factor is ~ 1e-1740. Of course the result cannot fit in a double and all the information is lost if unnormalized coefficients are used.
In my application I am trying to use high order fields as in this paper by Holmes and Featherstone (2002): http://cct.gfy.ku.dk/publ_others/ccta1870.pdf
(from redmine: issue id 126, created on 2013-01-09, closed on 2013-01-09)