CelestialBody instances created from differently configured JPLEphemeridesLoader objects
When loading a celestial body from a JPL ephemerides file like in the following code example, different JPLEphemeridesLoader are used to load the data, resulting in potential mismatches of the bodies or even loading errors:
JPLEphemeridesLoader loader =
new JPLEphemeridesLoader("unxp2000\\.421", JPLEphemeridesLoader.EphemerisType.MERCURY, date);
CelestialBody body = loader.loadCelestialBody(CelestialBodyFactory.MERCURY);
This leads to the creation of a JPLCelestialBody for Mercury, which needs the Solar System barycenter:
return new JPLCelestialBody(supportedNames, name, gm, IAUPoleFactory.getIAUPole(generateType),
CelestialBodyFactory.getSolarSystemBarycenter().getInertiallyOrientedFrame(),
inertialFrameName, bodyFrameName);
To get the Solar System Barycenter, the CelestialBodyFactory creates a new JPLEphemeridesLoader (using default parameters for the supported ephemerides file names) as this body has not been loaded yet (see CelestialBodyFactory.getBody).
The requested body in turn needs another body, the Earth Moon Barycenter, which results in another loader to be created:
case SOLAR_SYSTEM_BARYCENTER :
return new JPLCelestialBody(supportedNames, name, gm, IAUPoleFactory.getIAUPole(generateType),
CelestialBodyFactory.getEarthMoonBarycenter().getInertiallyOrientedFrame(),
inertialFrameName, bodyFrameName) {
...
Observation:
The bodies are (potentially) loaded from different ephemerides files when using a different supportedName as the default in the JPLEphemeridesLoader: when using a non-default parameter, this should be used for all bodies to be loaded. This is tightly coupled with the way the CelestialBodyFactory is implemented right now and may change in the future anyway as resolution of multi-threading issues.
Edited: removed to problem wrt memory consumption as it was a wrong conclusion, in fact the way the data for different bodies is loaded is very clever and efficient.
(from redmine: issue id 75, created on 2012-01-30, closed on 2012-01-30)