Loading Custom Gravity Field

I’m just getting started with Orekit and I’ve been trying to load a custom lunar gravity field. I came up with this based on looking at the discussions and tutorials, and I’m getting the output below:

import orekit
vm = orekit.initVM()
print ('Java version:',vm.java_version)
print ('Orekit version:', orekit.VERSION)

from orekit.pyhelpers import setup_orekit_curdir, absolutedate_to_datetime, download_orekit_data_curdir
from org.orekit.forces.gravity.potential import GravityFieldFactory, ICGEMFormatReader, PotentialCoefficientsReader

download_orekit_data_curdir()
setup_orekit_curdir()

GravityFieldFactory.clearPotentialCoefficientsReaders()
# AIUB-GRL350A.gfc downloaded from http://icgem.gfz-potsdam.de/tom_celestial
potentialCoefficientsReader = ICGEMFormatReader("C:\\FILE_PATH\\AIUB-GRL350A.gfc", True)
GravityFieldFactory.addPotentialCoefficientsReader(potentialCoefficientsReader)
moonHarmonicsProvider = GravityFieldFactory.getNormalizedProvider(350, 350)

Output:

Java version: 1.8.0_312
Orekit version: 11.0.2
Downloading file from: https://gitlab.orekit.org/orekit/orekit-data/-/archive/master/orekit-data-master.zip
---------------------------------------------------------------------------
JavaError                                 Traceback (most recent call last)
<ipython-input-19-3c37bf210590> in <module>
      3 potentialCoefficientsReader = ICGEMFormatReader("C:\\FILE_PATH\\AIUB-GRL350A.gfc", True)
      4 GravityFieldFactory.addPotentialCoefficientsReader(potentialCoefficientsReader)
----> 5 moonHarmonicsProvider = GravityFieldFactory.getNormalizedProvider(350, 350)

JavaError: <super: <class 'JavaError'>, <JavaError object>>
    Java stacktrace:
java.util.regex.PatternSyntaxException: Illegal/unsupported escape sequence near index 3
C:\FILE_PATH\AIUB-GRL350A.gfc
   ^
	at java.util.regex.Pattern.error(Pattern.java:1969)
	at java.util.regex.Pattern.escape(Pattern.java:2485)
	at java.util.regex.Pattern.atom(Pattern.java:2212)
	at java.util.regex.Pattern.sequence(Pattern.java:2144)
	at java.util.regex.Pattern.expr(Pattern.java:2010)
	at java.util.regex.Pattern.compile(Pattern.java:1702)
	at java.util.regex.Pattern.<init>(Pattern.java:1352)
	at java.util.regex.Pattern.compile(Pattern.java:1028)
	at org.orekit.data.DataProvidersManager.feed(DataProvidersManager.java:296)
	at org.orekit.forces.gravity.potential.LazyLoadedGravityFields.readGravityField(LazyLoadedGravityFields.java:227)
	at org.orekit.forces.gravity.potential.LazyLoadedGravityFields.getNormalizedProvider(LazyLoadedGravityFields.java:269)
	at org.orekit.forces.gravity.potential.GravityFieldFactory.getNormalizedProvider(GravityFieldFactory.java:227)

Both the AIUB-GRL350A.gfc and orekit-data.zip are in the same folder as the .ipynb file the code is in, and I’m running the code in Jupyter Notebooks. Reading this file from the notebook using open/readline works fine. I’d appreciate any insight on what to check next!

Hi,

This looks like an issue with the escape backslashes in the file path. As the gravity data file is located in the same folder as the notebook, try using a relative path instead, for instance potentialCoefficientsReader = ICGEMFormatReader("AIUB-GRL350A.gfc", True)

Otherwise the code looks correct. The code I have been using for importing a Moon gravity field looks similar:

potCoeffReader = ICGEMFormatReader("GL0660B.gfc", false )
GravityFieldFactory.addPotentialCoefficientsReader(potCoeffReader)
norm_provider_moon =  GravityFieldFactory.getConstantNormalizedProvider(64, 64)
holmesFeatherstone_moon = HolmesFeatherstoneAttractionModel(moonBodyFrame, norm_provider_moon)

Where in my case, the “GL0660B.gfc” file in located in a orekit-data folder, which I manage by myself instead of using the ZIP archive.

This is indeed the recommended way to store data. Using a zip archive directly works but is tremendously slow due to how the zip format works. It puts a central directory at the end of the file, so anytime you load something you have to read the full zip file, even if you just load 100 bytes at the beginning of the archive. It is also more straightforward to maintain a directory where a few files change often (EOP data and space weather data) and most of the files do not change at all.