WebAssembly support

[TilBlechschmidt]

Hey 👋

I was trying to use nyx-space for propagating orbits in the browser using WebAssembly. The crate itself compiles just fine* for the wasm32-unknown-unknown target but using it reveals one slight issue: Some parts contain debug logs which rely on Instant::now() to print the elapsed duration. Unfortunately, this API is not available when compiling for the web.

Here are a couple of examples (more can be found by searching for uses of Instant::now()):

nyx/src/cosmic/mod.rs

Lines 183 to 191 in eec86a3

	let decode_start = Instant::now();
	match Self::decode(input_xb_buf) {
	Ok(xb) => {
	debug!("Loaded XB in {} ms.", decode_start.elapsed().as_millis());
	Ok(xb)
	}
	Err(e) => Err(NyxError::LoadingError(format!("Could not decode XB: {e}"))),
	}

nyx/src/mc/montecarlo.rs

Lines 128 to 155 in eec86a3

	// Generate all states (must be done separately because the rng is not thread safe)
	let start = StdInstant::now();
	init_states.par_iter().progress_with(pb).for_each_with(
	(prop, tx),
	|(prop, tx), (index, dispersed_state)| {
	let result =
	prop.with(dispersed_state.state)
	.until_nth_event(max_duration, event, trigger);
	// Build a single run result
	let run = Run {
	index: *index,
	dispersed_state: dispersed_state.clone(),
	result: result.map(|r| PropResult {
	state: r.0,
	traj: r.1,
	}),
	};
	tx.send(run).unwrap();
	},
	);
	let clock_time = StdInstant::now() - start;
	println!(
	"Propagated {} states in {}",
	num_runs,
	clock_time.as_secs_f64() * Unit::Second
	);

While it is possible to work around this issue by using js_sys::Date::now(), I would suggest either removing or feature gating these debug logs altogether. For benchmarking purposes, something dedicated like criterion.rs could be used which does not end up in regular binaries.

If the timing information should be retained in normal builds, it would be possible to add an additional log message as the calculation starts. That way, the time difference could be derived from the log message times when using a logger that prints them.

Currently, I am running off a local fork but would love to upstream these changes. If this is something you'd be interested in, let me know which variant would be preferred and I'll cook something up!

---

*It might be necessary to add the following two dependencies into the parent crate so that WASM related features in nyx deps are enabled:

# Use the JavaScript rng API
getrandom = { version = "0.2", features = ["js"] }

# Convenience overwrite to make nyx_space work in debug mode (assets can't be loaded from disk in WASM)
rust-embed = { version = "6.8.1", features = ["debug-embed"] }

[TilBlechschmidt]

While this might not be a full solution for WASM (I've seen some uses of e.g. file related APIs), it certainly is a first step and already allows for instantiating an Orbit, propagating it, and deriving information with a GroundStation.

Performance isn't quite as swift as locally (to be expected) but a 7-day propagation still completes in less than a second on average. Using WebWorkers to offload this to a secondary thread makes it quite usable for some applications (like plotting orbits and predicting passes).

[ChristopherRabotin]

Hi! Thanks for the info on this, I had no idea that it would be "this simple" to get Nyx working in WASM. I'll be happy to make somre changes to support WASM, and even happier to review a PR if you have some of those changes ready to review.

[TilBlechschmidt]

Hey Christopher, I was honestly surprised as well! Randomly had the idea of trying and it close to "just worked" 😬

I can definitely send a PR in the coming days. Let me know if you prefer to have the timing info:

1. Removed completely
2. Feature gated
3. Replaced by benchmarks (using e.g. criterion.rs)

---

P.S.: With the fixes mentioned above nyx-space runs in the browser like a charm. Here is something I've been cooking up over the past few days (uses nyx in the browser to propagate GP data from space-track and then calculates future passes over a location) 🙂

Orbcast.mp4

[ChristopherRabotin]

This looks super cool!

I think that the timing in the XB loading can be removed entirely: I added this very early on, but the Cosm stuff will be removed in favor of ANISE soon enough.

For the generation of states, could that be feature gated? A number of other products can generate states as well, but they tend to be surprisingly slow. You may find other timing things around, like in the Monte Carlos or the targeting I think, and I'd prefer these to be feature gated as well (since they're actually quite useful for tuning mission design work).

[TilBlechschmidt]

Thanks! 😊

Sounds like a plan to me. Sleepy me just realised that we can simply use #[cfg(target_arch = "wasm32")] to check for WASM and then blanket disable usage of std::Instant. Makes it even easier to integrate!

[TilBlechschmidt]

Was scrolling through the list of commits to see if there is any pattern when I found this gem — made me laugh way harder than it should have 👀

Either way, I have submitted PR #205 for review 🙂

[ChristopherRabotin]

Thanks for implementing this, @TilBlechschmidt !

Keep me posted on your project that uses Nyx, I'm always excited to see what others use it for.

#205

[TilBlechschmidt]

You're welcome and thank you for making this library accessible 🙂

I'll keep you posted on the project, I might create a dedicated "Show & Tell" post once it reaches a presentable state.

[TilBlechschmidt]

Quick follow-up questions regarding the embedded Xb files

The issue

I noticed that the resulting WASM binaries are ~30MB in size. Digging deeper, it seems that pruning unused files embedded by rust-embed does not work on wasm32 (I could not reproduce the same behaviour for aarch64 using the same codebase).

nyx/src/cosmic/cosm.rs

Lines 46 to 48 in 80bbdce

	#[derive(RustEmbed)]
	#[folder = "data/embed/"]
	struct EmbeddedAsset;

Consequently, the derive macro above includes everything inside the data/embed folder regardless of whether it is used or not.

This includes the ~20MB de438.xb file which I am assuming is the non-bounded version of de438-00-50.xb. However, I could not find any references to that file in the code and moving it out of that folder does not appear to impact the functionality.

Additionally, I looked into the structure of that file and it seems to contain data for all planets. At least for my use-case this is totally overkill and I'd rather save the bandwidth for the user by just including Earth (given that the naiive approach of simply removing the irrelevant ephemeris children works — my understanding of this data is very rudimentary :D).

Proposed solution

• I'd suggest making the embedding of files and thus Cosm::try_de438 & friends a default feature so that end-users of the library can disable it and instead load custom files with Cosm::try_from_xb while not changing the behaviour for existing users.

• Additionally, moving the unused de438.xsb file up into data/ is probably a good idea as to not bloat binary sizes with unused data by default

Again, happy to provide a PR 🙂

_{Side-note: If you want me to put this into an issue instead, let me know!}

[ChristopherRabotin]

You raise a good point: the Cosm xb is embedded regardless of whether it's used. Most astrodynamics tools rely on SPICE files, like the DE440s file. Nyx will soon enough use that as well once I wrap up the orientation / rotation work in ANISE : https://github.com/nyx-space/anise. I was hoping to finish this before my vacation, but I didn't. More realistically, it'll start to be used in Nyx around September. This will allow users to load a specific set of data or not depending on their use case. Hence, unless the 30 MB size is a non starter for you even now, then it's probably simplest to wait a few weeks if that works for you. Cheers,

…

On Fri, Jul 28, 2023, 05:37 Til Blechschmidt ***@***.***> wrote: Quick follow-up questions regarding the embedded Xb files The issue I noticed that the resulting WASM binaries are ~30MB in size. Digging deeper, it seems that pruning unused files embedded by rust-embed does not work on wasm32 (I could not reproduce the same behaviour for aarch64 using the same codebase). https://github.com/nyx-space/nyx/blob/80bbdce28532228e55b9f3537446b3d37634b871/src/cosmic/cosm.rs#L46-L48 *Consequently, the derive macro above includes everything inside the data/embed folder regardless of whether it is used or not.* This includes the ~20MB de438.xb file which I am assuming is the non-bounded version of de438-00-50.xb. However, I could not find any references to that file in the code and moving it out of that folder does not appear to impact the functionality. Additionally, I looked into the structure of that file and it seems to contain data for all planets. At least for my use-case this is totally overkill and I'd rather save the bandwidth for the user by just including Earth (given that the naiive approach of simply removing the irrelevant ephemeris children works — my understanding of this data is very rudimentary :D). Proposed solution - I'd suggest making the embedding of files and thus Cosm::try_de438 & friends a default feature so that end-users of the library can disable it and instead load custom files with try_from_xb while not changing the behaviour for existing users. - Additionally, moving the unused de438.xsb file up into data/ is probably a good idea as to not bloat binary sizes with unused data by default Again, happy to provide a PR 🙂 Side-note: If you want me to put this into an issue instead, let me know! — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEZV2CMIKF6SI64AYGVOQLXSOQA3ANCNFSM6AAAAAA2UN66QA> . You are receiving this because you commented.Message ID: ***@***.***>

[TilBlechschmidt]

Ah, that makes sense. I wasn't aware that the ANISE support is close to being integrated. In that case no worries, that totally suffices as long as it will be possible to inhibit any embedding of default files in the end 👌

Thanks!