Answers to the questions that come up most often. Can't find what you need? Ask on GitHub Discussions.
No, and it won't in future either — this is a hard limitation of NCToolkit's system dependencies (CDO, NCO), not something on the roadmap. Use Windows Subsystem for Linux (WSL) instead, and install as normal within it. See Installing.
Recent releases of geoviews and jupyter_bokeh have caused issues for some existing NCToolkit environments. Pin them:
conda install -c conda-forge geoviews=1.10.1 conda install -c conda-forge jupyter_bokeh=3.0.7
Fresh installs pin these automatically, so new environments shouldn't hit this. See Known issues.
Raise the core count used for multi-file processing:
nc.options(cores=6)It's almost always faster to process member files with a high core count before merging them with merge, rather than the other way round. See Ensembles & multi-file datasets.
Yes — set nc.options(parallel=True) first, so NCToolkit switches to a process-safe internal file list, then use multiprocessing as normal. Reset with nc.options(parallel=False) once you're done, particularly in interactive sessions. See Parallel processing.
NCToolkit evaluates lazily by default — operations are queued, not run, until a result is actually needed (an attribute access, plot(), or an explicit ds.run()). This lets a whole chain collapse into a single CDO command. See Lazy evaluation & chaining.
No — unlike pandas or xarray, NCToolkit's methods modify a dataset in place rather than returning a new object. Call them on separate lines:
ds.subset(year=2000)
ds.tmean()No — they're created and deleted automatically as operations run. If you ever need to clear them manually (e.g. after an interrupted session), use nctoolkit.cleanup() for the current session or nctoolkit.deep_clean() for all sessions. If space is tight, point temporary files somewhere with more room using nc.options(temp_dir="/foo").
After running (or forcing evaluation of) a chain of operations, check ds.history. This is handy for debugging, and for learning CDO if you're coming from that direction.
This usually means the variable is stored as an integer type in the source file, so an operation that should be evaluated as a float is being computed as an integer. Check with ds.contents, then force a higher precision before calculating:
ds.set_precision("F64")See Troubleshooting.
Run ds.check() for a general diagnostic (integer types, integer time axis, CF-compliance, grid consistency) and ds.is_corrupt() to rule out file corruption. If longitude/latitude were stored as plain variables rather than coordinates, fix that with ds.assign_coords(lon_name=..., lat_name=...). See Supported data and Troubleshooting.
Yes, to an extent — because plotting is built on hvplot, arguments such as title, logz and clim can be passed straight to plot() and are forwarded automatically. For a static, publication-ready figure instead, use pub_plot(). See Visualization.
Open an issue on GitHub, or start a discussion for anything more open-ended.