Scientist working in the Center for Computational Science & e-Systems, Japan Atomic Energy Agency.

Spotted an error on this site?
Corrections appreciated, please email alex (at) alexmalins.com or leave a comment.

Archive by category "Uncategorized"

Installing PyNE on Windows via WSL

Although PyNE is officially only supported for Linux and Mac, it is possible to build and use it on Windows using the Windows Subsystem for Linux (WSL) and the Ubuntu terminal app from the Microsoft Store. These instructions describe how to install a basic PyNE build (no MOAB, DAGMC or OpenMC interfaces) on Windows via WSL. They presume only some basic knowledge on using Linux and Windows command lines. They were written for Windows 10 (1909), Ubuntu 20.04 and PyNE 0.7.3 – mileage for other releases may vary.

Step 1 – Enable WSL in Windows

Open Windows PowerShell with administrator privileges (right click: Run as administrator) and run:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

This enables WSL 1 in Windows. Now restart your PC.

(Or you could continue to update to WSL 2 at this point by following these instructions. WSL 2 offers more advanced features that might be useful to you, such as GPU support, but they are not necessary for PyNE).

Step 2 – Install Ubuntu 20.04 LTS from the Microsoft Store

From the Microsoft Store app, search for Ubuntu and install the Ubuntu 20.04 LTS app.

Step 3 – Run Ubuntu 20.04 LTS and install libraries needed by PyNE

Run the Ubuntu 20.04 LTS app for the first time from the Windows Start menu, wait for it to set itself up, then enter a UNIX username and a password. Run the following commands in the terminal:

sudo apt update
sudo apt upgrade
sudo apt install python3-pip build-essential cmake gfortran libblas-dev liblapack-dev libeigen3-dev libhdf5-dev hdf5-tools
pip3 install --user numpy==1.17.4 scipy cython nose tables matplotlib future

This will install the libraries needed for a basic build of PyNE.

Now edit the .bashrc file using a text editor (nano, emacs, vim etc.) and add the following commands to the end of the file:

alias pip=pip3
alias python=python3
export PATH="$HOME/.local/bin:$PATH"
export LD_LIBRARY_PATH="$HOME/.local/lib:/usr/lib/x86_64-linux-gnu/hdf5/serial:$LD_LIBRARY_PATH"

Close the Ubuntu terminal.

Step 4 – Download the PyNE source code

Open your favourite browser in Windows and download a .tar.gz file containing the PyNE source code from https://github.com/pyne/pyne/releases. The latest release at the time of writing is 0.7.3.

Step 5 – Copy the source code to Ubuntu, unpack, and build PyNE

Reopen a Ubuntu 20.04 LTS terminal window and copy the source tarball into the Ubuntu WSL file system via:

cp /mnt/c/DOWNLOAD_DIR/pyne-0.7.3.tar.gz .

Edit the drive letter and DOWNLOAD_DIR as appropriate to match where you downloaded the source file to. Unpack the source code and navigate into the source directory via:

tar -xf pyne-0.7.3.tar.gz
cd pyne-0.7.3/

Now build PyNE and install locally:

python setup.py install --user

Subject to build being successful, you can now run the following commands to make the nuclear data:


An optional final step here is to run the tests:

cd pyne-0.7.3/tests/
Step 6 – Using PyNE in Python on WSL

You should now be able to use PyNE within Python on the Ubuntu 20.04 LTS app, e.g.:

>>> from pyne import data
>>> data.half_life("H-3")

These instructions were based on the PyNE Ubuntu Install Scripts from https://github.com/pyne/install_scripts. An alternative starting from Step 3 onwards would be to download and run the ubuntu.sh install script available from that repository. This will install MOAB, DAGMC and OpenMC as well.

Another alternative that might work well, although I have not tested it, is to install Anaconda on WSL, then install PyNE from conda-forge.

PyNE can be a little finicky to install, but persistence pays off. If you encounter any errors during builds, the Issues and PR sections of the PyNE Github repo, and the pyne-dev and pyne-users mailing lists are great sources of information.

Interactive rebase to switch base branches mid GitHub pull request

A situation occurred the other week that I had not encountered before when working on a GitHub pull request for the PyNE Python package. The PR (#1270) added a new function to initialize materials by supplying activities of radionuclides. This was to complement existing methods to create materials using masses or atom fractions.

The new lines of code were in my branch for the PR which was forked from the default develop branch on PyNE’s GitHub repository. Unbeknown to me at the time, the PyNE team were undertaking a hackathon to prepare for a new PyNE release, and active development was ongoing on a separate branch in the main repository (0.7.0-rc). Normally everything would be brought in line easily by rebasing the branch for PR (#1270) to the 0.7.0-rc branch ready for merging the PR.

In this instance, however, there had previously been another PR (#1264) merged into the develop branch subsequent to 0.7.0-rc being branched off. This meant that after rebasing my branch to 0.7.0-rc, the new PR (#1270) branch contained both the commits for the new activity-based material initializations and the irrelevant PR (#1264) commits. Schematically it looked like this:

origin develop branch: A---C
                        \   \
new PR (#1270) branch:   \   C-D
                          \   /
origin 0.7.0-rc branch:    A-B

After rebasing to 0.7.0-rc, the head branch for PR (#1270) presented both the C commits from PR (#1264) and the D commits associated with the new activity-to-material functionality.

The way to tidy this up so that only the relevant D commits for the new functionality were part of PR (#1270) was to perform a git interactive rebase:

git rebase -i HEAD~x

Interactive rebase, among other things, lets you track back and delete previous git commits from the code lineage. Note x here is the number of commits you choose to track back and process during the interactive rebase. With interactive rebase, the C commits could be deleted from the head branch for PR (#1270), leaving only the relevant D commits, thus tidying everything up.

Credit goes to Paul Wilson and Baptiste Mouginot from the University of Wisconsin-Madison for guidance on how to use git interactive rebase to perform this fix.