Most errors trace back to a quirk in the source data. A few checks and fixes cover the majority of cases.
Under the hood, NCToolkit uses Climate Data Operators (CDO) as its computational engine. By default, CDO uses the data type stored in the netCDF file, which is usually fine — but not always. Imagine calculating the fraction of time temperature exceeds 30 degrees, where the data is stored as an integer:
ds.assign(temperature=lambda x: x.temperature > 30) ds.tmean()
If the data is integer-typed, you'll end up with only 0 or 1 in the data rather than a genuine fraction. Force a higher-precision type first:
ds.set_precision("F64") ds.assign(temperature=lambda x: x.temperature > 30) ds.tmean()
NCToolkit warns you if a dataset has integer data types when you open it. To check what type each variable is at any point:
ds.contents
A built-in method checks whether a dataset's format is likely to be problematic:
ds.check()
This runs four checks: integer-typed variables, an integer-typed time dimension, CF-compliance, and whether all variables in the dataset share the same horizontal grid. Install cfchecker for check() to also verify CF-compliance.
A common problem with netCDF files is corruption — parts of the data become inaccessible. Check for it directly:
ds.is_corrupt()
Sometimes longitude and latitude are stored as plain variables rather than coordinates, which NCToolkit needs to work fully. Fix it with assign_coords:
ds.assign_coords(lon_name="lon", lat_name="lat")
where lon_name and lat_name are whatever the longitude and latitude variables are actually called in your file.
Still stuck? See the Q&A page, or open a discussion on GitHub.
