Parallelized Function Proposal

[kjugalde]

Hello! @translunar suggested I file this. I want to propose adding support for parallelized Orbit constructors and lat/lon/alt extractors

Context

For ephemeris-scale Python workflows a typical caller around transform_many_to currently looks like this:

orbits_gcrf = []
for i in range(N):
	orbits_gcrf.append(Orbit.from_cartesian(
		pos_km[i, 0], pos_km[i, 1], pos_km[i, 2],
		0.0, 0.0, 0.0,
		epochs[i], Frames.GCRF,
	))
	
orbits_itrf93 = almanac.transform_many_to(orbits_gcrf, Frames.EARTH_ITRF93)

lons_rad = np.array([
	o.longitude_360_deg()
	for o in orbits_itrf93
])

Two Python for loops bracket the parallel call. These series of loops can prove slow for large enough ephemerides. The proposal below outlines some functions that might prove useful

API Surface

Batch Orbit constructors

@staticmethod
def from_cartesian_many(
	pos_vel: numpy.ndarray,     # shape (N, 6), units km / (km/s)
	epochs: list[Epoch],        # length N
	frame: Frame,
) -> list[Orbit]: ...

Mirrors the existing from_cartesian_npy precedent with _many suffix matching transform_many, solar_eclipsing_many, azimuth_elevation_range_sez_many.

@staticmethod
def from_position(
	x_km: float, y_km: float, z_km: float
	epochs: list[Epoch],      
	frame: Frame,
) -> Orbit: ...

@staticmethod(
	positions: numpy.ndarray,   # shape (N, 3), units km
	epochs: list[Epoch],        # length N
	frame: Frame,
) -> list[Orbit]: ...

Position-only constructors for callers whose state doesn't include velocity (typical when velocity is computed downstream from positions, or simply isn't needed for what's being measured). Velocity defaults to zero. Saves the zero-padding boilerplate at every position-only call site.

Batch lat/lon extractors on Orbit

@staticmethod
def longitude_360_deg_many(orbits: list[Orbit]) -> numpy.ndarray: ...

@staticmethod
def latitude_deg_many(orbits: list[Orbit]) -> numpy.ndarray: ...

@staticmethod
def latlongalt_many(orbits: list[Orbit]) -> numpy.ndarray: ...   # shape (N, 3)

latitude_deg_many is paired with longitude_360_deg_many so lat/lon extraction has the same vectorized shape; latlongalt_many mirrors the existing tuple-returning latlongalt() for callers that want all three components in one call.

[ChristopherRabotin]

Hi @kjugalde ,

The existing _many functions are computationally expensive. The position/velocity constructor is a simple copy; the orbital elements are not typically that computationally intensive either, though they may include several steps. This makes me lean toward avoiding these specific new _many functions.

Yet, I very much agree with your underlying thought: multi processing in python is less trivial than what it could be if exposed to Rust.

One option could be to expose a function that takes in a list of Orbit classes and a python function that returns a float, and applies that function in parallel. A usage example might be many_orbit_calc(my_list_of_orbits, lambda orbit: orbit.longitude_360_deg). That second parameter would be as complicated or simple as you'd need it to. It would also benefit from the rust type checking I think.

This approach does not solve the constructor problem though.

[ChristopherRabotin]

Hi @kjugalde ,

Have you had time to think more about how ANISE could solve your problem?

Thanks

[translunar]

I think probably we'd like to take as much advantage as possible of Python's broadcasting capabilities. It's not clear to me whether writing many methods in Rust helps with that, so I think that's our question. But we prefer to be able to batch these computations where it improves efficiency. Ideally we'd use Python overloads here so the method signatures are the same.