OpenMC and Snapdragon: Investigating an Unexpected Incompatibility

Like many people, I recently upgraded my laptop. I chose a machine with a Snapdragon processor—one of those new-generation ARM-based Windows PCs that promise long battery life, quiet operation, and performance on the go.

On paper, everything seemed perfect.

Except that one detail had escaped my notice: I also wanted to use OpenMC, a Monte Carlo simulation code widely used for particle transport simulations in nuclear physics.

And that's where the adventure began.

When "Windows" Doesn't Mean "Compatible"

My initial reasoning was simple:

  • OpenMC runs on Windows;

  • My new PC runs on Windows;

  • So OpenMC will run on my new PC.

That makes sense.

Well... almost.

What I hadn't looked at closely enough wasn't the operating system, but the processor's hardware architecture.

My old computer used a standard AMD Ryzen processor based on the x86_64 architecture, which has been used in the vast majority of scientific PCs for years. It is also the architecture for which most of the scientific packages available via Conda are currently compiled and tested.

My new Snapdragon PC, on the other hand, is based on an ARM64 architecture.

For the average user, this distinction is virtually invisible. For certain scientific software, it is fundamental. Looking back, I realized that I had been implicitly confusing the operating system with the hardware architecture. For many users, “Windows” is a sufficient category. In reality, two Windows PCs can have very different levels of compatibility depending on whether they are based on x86_64 or ARM64 architecture.

The Start of the Domino Effect

The installation seemed simple, though. The OpenMC documentation recommends:

  • Install Conda;

  • set up a Python environment;

  • Install OpenMC via conda-forge.

So I followed the steps.

First hurdle: The OpenMC package was not available for the linux-aarch64 architecture used in my ARM environment.

Second obstacle: Some installation attempts resulted in errors such as "Exec format error," a classic symptom of an executable compiled for a different architecture.

Third obstacle: Docker, which is often used as a workaround, turned out to be more complicated than expected in my Windows ARM environment.

Then came WSL, virtualization issues, Windows components that needed to be enabled, version incompatibilities...

In short, I ended up troubleshooting the system, even though my original goal was simply to run a few neutron simulations.

The processor wasn't bad

I'd like to clarify one important point. The problem isn't that Snapdragon processors are bad.

On the contrary. Whether for office work, web browsing, online meetings, light development, or battery life, these machines are often excellent.

The problem lies elsewhere.

The scientific ecosystem today remains largely built around the x86_64 architecture. Numerous code bases, libraries, and computing environments have been developed, tested, and distributed over the years for this architecture.

The arrival of ARM-based devices in the Windows world is relatively recent, and the entire ecosystem has not yet caught up.

The lesson: look deep into the inner workings of the machine

This experience reminded me of something important. When we buy a computer for scientific or technical use, we often look at:

  • memory;

  • the disk capacity;

  • range and weight;

  • the price;

But rarely:

  • processor architecture;

  • the availability of scientific libraries;

  • the compatibility of computing environments;

  • the availability of precompiled packages.

However, it is sometimes these criteria that truly determine whether a machine will be suitable for our business.

A Few Things to Check Before Buying

If you use scientific or technical tools, I recommend that you check the following from now on:

  • the processor architecture (x86_64 or ARM64);

  • the availability of compatible versions of your key software;

  • the availability of Conda packages;

  • possible Docker compatibility;

  • feedback from the community.

A few minutes of checking can save you several days of troubleshooting.

Epilogue

Finally, OpenMC now runs perfectly on my x86_64 Linux computer. My Snapdragon computer, on the other hand, remains an excellent mobile device.

The moral of the story?

When you buy a computer for scientific work, the most important specifications aren't always the ones listed on the label. Sometimes, the answer lies much deeper: in the inner workings of the processor.

OpenMC and Snapdragon: Investigating an Incompatibility

OpenMC and Snapdragon: Investigating an Incompatibility

Previous
Previous

My new coworker's name is Claude

Next
Next

The CIR: Two Sides of the Same Coin