NCToolkit supports most netCDF data, but its computational backend imposes a few limits worth knowing about.
Most operations rely on Climate Data Operators (CDO) to do the heavy lifting. CDO requires that files have at most four dimensions — longitude and latitude, plus time and/or depth/height — and it supports structured grids (regular lon/lat, curvilinear) as well as unstructured grids.
NCToolkit works with more or less any structured horizontal grid that follows the GDT, COARDS or CF conventions.
Support for unstructured grids is more limited — these grids are often idiosyncratic and need special handling, so CDO's functionality for them is narrower. Nearest-neighbour interpolation is supported; in some cases a file's metadata may need adjusting before CDO can work with it. If you hit problems with unstructured data, reach out on the Discussions page.
spatial_mean and similar methods need to calculate grid-cell area, but some data providers omit that metadata. When this happens NCToolkit prints a warning — reach out if you need help getting an accurate answer for such a file.
NCToolkit supports vertical grids with either consistent or spatially-varying levels, so it works with the vast majority of ocean and atmospheric data. Fully accurate vertical averaging needs cell thickness; if a file doesn't provide it (and it can't be inferred), results may be less accurate. NCToolkit focuses on analyzing data as provided rather than correcting deficiencies in the raw files — reach out on Discussions if you hit this.
Any CF-compliant time axis should work without issue. CDO requires exactly one time axis per file — if a file has multiple, NCToolkit (via CDO) will pick one. This is rarely a problem except with unusually idiosyncratic time axes.
NCToolkit supports every data type CDO supports: 32- and 64-bit floating point, and 8-, 16- and 32-bit integers. By default, calculations use whichever data type the source file was stored in. This is usually fine, but integer-typed files can occasionally give surprising results for calculations that should be floating point — see Troubleshooting for how to force a higher-precision type with set_precision.
Poorly-defined netCDF files — for example ones with badly specified maximum/fill values — can occasionally cause computational errors even for otherwise simple calculations.
If you're unsure whether your files are CF-compliant, run them through the CF checker. An error there usually means CDO can't fully determine the file's structure, which will block some NCToolkit operations. Most such issues can be fixed with CDO or NCO directly — reach out if you get stuck.
NCToolkit's own check() method runs a lighter version of this alongside checks for integer data types and time axes — see Troubleshooting.
