Working With Nuclear Physics Schools Data
I ran into this while looking for nuclear structure datasets to benchmark some spectral analysis code. Nuclear Physics Schools refers to a collection of nuclear level schemes and transition data that has circulated through the computational nuclear physics community for a few years now. It's not a single unified package so much as a naming convention for different releases and derived datasets built from the National Nuclear Data Center and similar archives. The data is typically distributed in ENSDF (Evaluated Nuclear Structure Data File) format, which means you're going to need to do some parsing before it's actually usable. Most people convert it to something more manageable like YAML, JSON, or CSV. I've seen people roll their own converters, but the gnd2ensdf and ENSDF2XML utilities from NNDC will get you most of the way there if you have a POSIX environment. Here is where it gets tricky. The different "Schools" releases are not always internally consistent. One version might use a different convention for listing gamma-ray energies than another, and sometimes the same isotope appears with slightly different level energies across releases. I spent about three days tracking down a mismatch on Ni-68 between two versions before realizing one of them had a typo in the energy column that propagated through every derived quantity. The workaround was to cross-reference against the most recent published NuDat 3.0 values and flag any isotope where the discrepancy exceeded 1 keV.
How People Actually Use It
The main use cases I see are statistical spectroscopy research, level density model testing, and occasionally neutron capture cross-section work where you need experimental level schemes as input. If you're trying to use it for anything involving reaction modeling without first validating the levels against the current ENSDF evaluations, you're probably going to introduce errors that are hard to trace later. One thing beginners consistently miss is that the data includes both observed and assumed levels. Assumed levels are predictions inserted by evaluators to fill gaps, and they are not the same quality as measured ones. There is no reliable tag in the raw ENSDF that cleanly separates them without specialized parsing logic. I ended up writing a small filter that flags any level without an associated measurement reference and marks it separately. It cut my false-positive rate down significantly for whatever benchmark I was running.
Where to Get It
The dataset tends to live on academic FTP servers and GitHub mirrors rather than a single official distribution point. The most commonly referenced version circulates under names that include the release year, so you will want to check the date stamp on any mirror you pull from. Older versions have known issues with incomplete data for neutron-rich nuclei past the drip line. If you are working with isotopes beyond N=126, make sure you are pulling the latest available release or you will find entire regions simply missing. I also want to be straight about the limitations. The data quality is only as good as the underlying ENSDF evaluations, and those are uneven. Light nuclei tend to be well-covered. Mid-mass nuclei around the iron peak are reasonable. Very heavy or very neutron-rich nuclei have large gaps and occasional inconsistencies that are never going to be fully resolved without new measurements. If your work depends on accuracy in those regions, you are better off pulling directly from NNDC on a regular schedule rather than relying on a static dataset release.
Get the Full Details
Practical Setup Notes
If you're processing this at scale, converting ENSDF to a structured format upfront saves you enormous time later. A typical batch conversion from raw ENSDF to a queryable format on a decent workstation takes roughly 20 to 40 minutes depending on how many isotopes you are pulling in and what parser you use. From there, building a simple index by isotope and level energy lets you do lookups in under a second rather than rescanning files each time. The format you pick matters more than most people realize. If you're doing statistical analyses that require quick aggregation across many isotopes, a column-oriented format like Parquet or even a well-structured SQLite database will serve you better than nested JSON. I switched one of my projects from JSON to SQLite after it became unmanageable at around 5,000 isotopes. Query time dropped from several seconds per lookup to under 50 milliseconds. There is no single download link that covers everything because the dataset evolves and multiple research groups maintain their own derivatives. Your best move is to check the references in whichever paper first introduced the particular "Schools" version you plan to use, then trace forward to see if anyone has posted a more recent mirror or cleaned-up version on GitHub or institutional repositories.
