@aeroflightlabs/native-eph-reader
v0.0.4
Published
Currently only 440 version is supported, tested with `linux_p1550p2650.440` and works fine. Last time I downloaded the eph file it was available under this link: https://ssd.jpl.nasa.gov/ftp/eph/planets/Linux/de440/linux_p1550p2650.440
Downloads
6
Readme
Fast node-gyp reader for JPL planetary ephemeris
Currently only 440 version is supported, tested with linux_p1550p2650.440
and works fine.
Last time I downloaded the eph file it was available under this link: https://ssd.jpl.nasa.gov/ftp/eph/planets/Linux/de440/linux_p1550p2650.440
How to use
First, be sure to call loadEph440
globally with path to linux_p1550p2650.440
before doing anything else with the library
Planetary mapping is as follows:
1 = mercury barycenter
2 = venus barycenter
3 = earth
4 = mars barycenter
5 = jupiter barycenter
6 = saturn barycenter
7 = uranus barycenter
8 = neptune barycenter
9 = pluto barycenter
10 = moon
11 = sun
12 = solar-system barycenter
13 = earth barycenter
After that, following functions are available:
getBulk
getBulk(input: GetBulkInput[], output: number[]): void
Gets positions of elements in relation to other elements.
The result is stored in the output
parameter as series of 3d vectors,
interleaved position and velocity, which are stored as 3 numbers,
so the output array must have size equal to input.length * 6.
For example in case of input having 2 inputs A and B, the output
format will be:
[
A.position.x, A.position.y, A.position.z,
A.velocity.x, A.velocity.y, A.velocity.z,
B.position.x, B.position.y, B.position.z,
B.velocity.x, B.velocity.y, B.velocity.z
]
The format is clear, but it's pretty strange, it's all because of performance, as the main reason of this library existence is performance. The position returned is in AU and velocity in AU/Day, to have the most raw data.
getGravityFlux
getGravityFlux(where: ephvec3, whenTimestamp: number, output: ephvec3): void
output
must be an array of 3 numbers and result stored in it will be in format:
[
acceleration.x, acceleration.y, acceleration.z
]
where
is expected to be in meters,acceleration
returned is in meters/seconds^2,whenTimestamp
is a unix timestamp with fractions support
integrateGravity
integrateGravity(startPosition: ephvec3, startVelocity: ephvec3, startTime: number, endTime: number, timeStep: number, outputPosition: ephvec3, outputVelocity: ephvec3): void
outputPosition
must be an array of 3 numbers and result stored in it will be in format:
[
position.x, position.y, position.z
]
outputVelocity
must be an array of 3 numbers and result stored in it will be in format:
[
velocity.x, velocity.y, velocity.z
]
startPosition
andstartVelocity
are expected to be in metersstartTime
andendTime
are unix timestamps with fractions supporttimeStep
is the time resolution to use in seconds, higher means faster but lower precisionoutputPosition
is saved as metersoutputVelocity
is saved meters/second
generateTrajectoryForecast
generateTrajectoryForecast(startPosition: ephvec3, startVelocity: ephvec3, startTime: number, endTime: number, timeStep: number, outputPositionArray: number[]): void
outputPositionArray
must be an array of numbers with count equal((endTime-startTime) * 3) / timeStep
and result stored in it will be in format:
[
position.x, position.y, position.z,
...
]
startPosition
andstartVelocity
are expected to be in metersstartTime
andendTime
are unix timestamps with fractions supporttimeStep
is the time resolution to use in seconds, higher means faster but lower precisionoutputPositionArray
is saved as meters