Nest 3.4 | Release Changes You’ll Actually Use

tech Logic / By

Nest 3.4 is a NEST Simulator release that refreshes the docs, adds spatial source-query tools, and tweaks defaults like the NEST Server port.

If you run spiking-network models, small version bumps can still bite: a renamed model here, a changed default there, a new helper that replaces a hand-rolled snippet you’ve copied for years. Nest 3.4 is one of those releases that’s easy to “just install,” yet worth reading about first so you don’t burn an afternoon chasing a silent mismatch.

This guide walks through what changed, what you’ll notice right away, and how to upgrade cleanly. It stays on practical outcomes: getting your scripts running, confirming results, and taking advantage of the new tools without rewriting your whole workflow.

Nest 3.4 release overview and who it fits

Nest 3.4 refers to version 3.4 of the NEST Simulator, a simulator for spiking neural network models. The release includes user-facing changes plus fixes, with a clear emphasis on documentation structure and spatial-network tooling. The official “What’s new” page and the GitHub release notes are the best primary sources for the full changelog.

  • Upgrade safely — Treat 3.4 as a “read the notes, then bump” release: not scary, yet not a blind update.
  • Expect better docs flow — The documentation got a new theme and reorganized navigation, which matters when you’re hunting a model parameter late at night.
  • Get new spatial helpers — PyNEST adds functions that make it easier to ask “who connects into this neuron?” in spatially structured networks.

For the authoritative summaries, see the official What’s new in NEST 3.4 page and the NEST 3.4 release notes on GitHub.

Changes you’ll notice first after upgrading

Most upgrades feel “fine” until you open your old notebook, rerun a familiar script, and spot a warning or a slightly different output shape. With Nest 3.4, the early signals tend to fall into a few buckets: documentation paths, spatial APIs, and defaults.

Change in Nest 3.4 Where you feel it What to do
Docs restructuring and new theme Searching model pages, install steps, tutorials Bookmark the new “What’s new” entry and update internal links
Spatial source-query helpers in PyNEST Debugging connectivity into a neuron Swap custom queries for GetSourceNodes/GetSourcePositions/PlotSources
Layer extent/center behavior for free positions Scripts that rely on implicit padding Set extent explicitly when you need fixed margins
Disconnect with SynapseCollection Pruning synapses during sweeps Pass a SynapseCollection to disconnect() instead of rebuilding selectors
NEST Server default port changed Client scripts, Docker setups, firewall rules Update port from 5000 to 52025 when you rely on defaults

The table above is not meant to replace the full notes. It’s a “what breaks a flow” list: things you’ll hit during setup, troubleshooting, or code maintenance.

Installing or upgrading to Nest 3.4 without surprises

Before you change anything, get one clean baseline run on your current version. Save your logs. Keep a record of the exact commit or version string you used to generate any published figure. That’s your sanity anchor.

  1. Record your current build — In a terminal or notebook, capture your NEST version string, Python version, and OS details in one place.
  2. Clone a fresh test script — Use a tiny script that creates a network, runs a short simulation, and prints one measurable value you can compare later.
  3. Upgrade in a clean env — Use a new virtualenv or Conda env so dependency changes don’t spill into other projects.
  4. Run your baseline test first — Confirm Nest 3.4 installs and runs before you touch your main codebase.
  5. Move one project at a time — Upgrade the project with the simplest dependency set first. Keep momentum.

If you compile from source, pay attention to build messages and toolchain versions. The 3.4 release includes maintenance work around build tooling and documentation generation, so a noisy build log can often tell you a lot.

Quick check for reproducibility after the upgrade

Do one short run where you can compare a stable output: spike counts, mean firing rate, or a fixed-seed statistic. Don’t chase a perfect match on floating-point jitter across compilers. Chase “same pattern, same scale.”

  • Fix seeds explicitly — Set the RNG seeds in code, not in your head.
  • Keep runtime short — A 100 ms test can still reveal a broken connection rule.
  • Log one metric — Print one scalar you can paste into git commits as a check value.

Using the new spatial source-query tools in PyNEST

Spatially structured networks can be tricky to debug. When a target neuron spikes oddly, the question is often “who is driving it?” Until now, many users built custom queries: filter synapses, map back to presynaptic nodes, then plot positions. Nest 3.4 adds direct helpers that shorten that loop.

According to the NEST 3.4 “What’s new” notes, PyNEST now provides functions named GetSourceNodes(), GetSourcePositions(), and PlotSources() for querying or plotting the source neurons of a given target neuron in spatially structured networks.

  1. Pick a target neuron — Start with a single neuron that shows the behavior you want to explain.
  2. Pull its source nodes — Use the source-node helper to retrieve the presynaptic set that connects into your target.
  3. Inspect positions — Grab the source positions and check if they match your expected geometry.
  4. Plot the sources — Use the plotting helper to see clustering, holes, or edge effects.

This shift is small in code, big in workflow. It replaces glue code you might have copied into each project, with a stable API that moves with NEST.

When these helpers save the most time

You’ll feel the gain most in three situations: diagnosing an unexpected boundary effect, verifying a distance-dependent rule, and double-checking a rewiring step in a parameter sweep.

  • Spot boundary bias — If edge neurons behave oddly, the plot often shows a lopsided source set.
  • Verify distance kernels — A quick map can confirm that near sources dominate when they should.
  • Audit pruning — After removing synapses, the source set should shrink in a way that matches your rule.

Spatial layers with free positions: extent and center behavior

NEST lets you create spatial layers where node positions come from spatial distributions in nest.spatial. When you create a layer using free placement, the layer needs an extent and a center so later calls can reason about spatial boundaries.

The NEST 3.4 notes state that when you use spatial.free and omit the layer’s extent, the extent will be derived from the lower-leftmost and upper-rightmost node positions. Earlier versions added a hard-coded padding; 3.4 uses the node positions only. The center is also computed as the midpoint between those corner nodes. A layer with only one node still needs an explicit extent.

If your code relied on that older padding, you might see subtle shifts in plots or in any logic that uses the layer boundary. The fix is simple: set the extent yourself when you want stable margins.

  • Set extent explicitly — Use a known bounding box when you want consistent padding across runs.
  • Check single-node layers — Add extent in those cases, since it’s required.
  • Re-check boundary logic — If you clip or wrap positions, verify behavior after the change.

Disconnecting with SynapseCollection: cleaner pruning loops

When you’re iterating on plasticity rules, pruning steps, or structural sweeps, you often end up with a SynapseCollection you want to remove. Before 3.4, disconnect patterns could push you into reselecting endpoints, or rebuilding connect arguments just to undo a subset.

Nest 3.4 adds the ability to disconnect nodes using a SynapseCollection passed to disconnect(), either as a function argument or by calling disconnect() as a member of the SynapseCollection itself. That’s a small API addition that keeps your intent clear: “remove these synapses,” not “reconstruct a selection that hopefully matches these synapses.”

  1. Store the SynapseCollection — Keep the handle returned from your connection call.
  2. Filter it when needed — Slice or select within the collection to isolate a subset.
  3. Disconnect that exact set — Call disconnect on the collection so you remove precisely what you targeted.

This also makes parameter sweeps easier to audit, since you can print collection sizes before and after pruning and catch a bad selector early.

NEST Server port change and what it means for scripts

If you use NEST Server, default values matter. A port change can cause “it worked yesterday” moments: the server starts, your client tries the old port, and you get a connection failure that looks like a firewall issue.

The NEST 3.4 “What’s new” notes say the default port for NEST Server changed from 5000 to 52025 to avoid conflicts with other services. If you always set an explicit port in your server and client config, you won’t notice. If you rely on defaults, update your configs and any container mappings.

  • Update default port references — Replace 5000 with 52025 in client config where you depend on defaults.
  • Adjust Docker mappings — Change your -p mapping or compose file to match.
  • Check local conflicts — If you had something else on 5000, this change can remove a silent collision.

Deprecated and removed models: spotting breakage fast

Model removals are the kind of change that turns into a late-night bug hunt if you don’t scan the notes. Nest 3.4 removes models that have been deprecated for a long time. If your scripts still reference them, you’ll see errors at model creation time.

The NEST 3.4 “What’s new” page lists two removed models: iaf_psc_alpha_canon and pp_pop_psc_delta. It points to replacement models with similar functionality, and it also mentions that spike_dilutor is now deprecated and only usable in single-threaded mode, with bernoulli_synapse suggested for fixed-probability spike transmission.

Practical way to catch this early: run a simple “create every model I use” smoke test before your full simulation. It fails fast and tells you exactly which name is stale.

  1. List your model names — Put them in one small array in a test file.
  2. Create each model once — Stop on the first error and fix naming before you run anything big.
  3. Re-run with threads on — If you use multithreading, confirm your model set behaves under the same mode.

Workflow notes that keep your upgrade calm

Nest 3.4 comes with a long changelog that includes documentation work, build tooling, and a pile of bug fixes. You don’t need to read every line to upgrade well. You do need a repeatable process that catches the handful of changes that touch your code.

  • Pin versions per project — Treat NEST like any other dependency and pin the version in your setup docs.
  • Write a one-page upgrade log — Track what changed, what you updated, and what tests you ran.
  • Keep a rollback path — Save your old env spec so you can revert in minutes, not hours.
  • Retest plots you publish — Rerun the exact figure scripts and compare images side by side.

If you share code with lab mates or collaborators, bundle these notes into the repo README. It saves the “works on my machine” ping-pong later.

What to try next once you’re on Nest 3.4

After your old scripts run cleanly, take one small step into the new features so the upgrade pays you back. Start with spatial source queries if you use spatial networks. If you do structural pruning, switch your disconnection logic to SynapseCollection. If you use NEST Server, lock in explicit port settings so future defaults don’t surprise you.

  1. Replace one custom spatial query — Swap it for the new helper and delete the glue code.
  2. Swap one pruning block — Use SynapseCollection disconnect and confirm the synapse counts match.
  3. Set explicit server ports — Bake the value into config and docs so teammates match your setup.

That’s it. Nest 3.4 is a practical update: less friction in docs, cleaner spatial debugging, and small API and default tweaks that can save time once you know they’re there.