NetCDF Unlimited Record Dimension (.nc)
A NetCDF-3 file with a genuine unlimited record dimension, so the record variable is stored interleaved rather than contiguously while the fixed-size station variable is not. It exercises the striding path that a reader written only against fixed dimensions gets wrong.
| Field | Value |
|---|---|
| Unlimited dimension | record (currently 5) |
| Fixed dimension | station = 3 |
| Record variable | air_temperature (record, station) float32 K |
| Non-record variable | station_id (station) int32 |
| Storage | record data is interleaved per record, fixed data is contiguous |
| air_temperature[0,0] | 281.150 K |
| air_temperature[4,2] | 285.550 K |
Specifications
- Record Dimension
- record (unlimited)
- Records
- 5
- Stations
- 3
- Layout
- record variables are interleaved, not contiguous
- Variable
- air_temperature float32 (K)
Testing contract
Expected to pass- Scenario
- Read air_temperature and station_id and confirm the record dimension is reported as unlimited with a current length of five.
- Expected result
- air_temperature has shape (5, 3) with [0,0] = 281.15 K and [4,2] = 285.55 K, and the reader flags 'record' as the unlimited dimension while station_id stays shape (3,).
What is a .nc file?
NetCDF (.nc, Network Common Data Form) is a binary, self-describing format for array-oriented scientific data. It stores multidimensional variables (like temperature over latitude, longitude, and time) with named dimensions, units, and metadata attributes, and is a standard in climate, ocean, and geoscience.
How to use this file
Use an example .nc file to test NetCDF readers (netCDF4, xarray, Panoply), CF-convention validators, and gridded-data pipelines, or to verify dimension and variable extraction.
How to use this file for testing
“NetCDF Unlimited Record Dimension (.nc)” is a deterministic Testaroo fixture for Scientific data, Serialization testing. Citation catalogs (BibTeX, RIS), chemistry structures (MDL Molfile, PDB), and gridded binary data (NetCDF, FITS), for testing reference managers, molecule viewers, and scientific-data loaders.
Documented properties for this file: 5 records. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
Scientific fixtures are small, valid, and fully synthetic, no real organism, patient, sample, or observation. Point your parser or loader at the file and check it reads the documented records, variables, or headers; binary formats ship a readable twin or metadata listing for comparison.
Generated by generation/scientific.py. Free for any use, no attribution required, license.
Related files
- ncNetCDF 64-bit Offset Format: CDF-2 (.nc)The same 4x5x6 temperature grid written in the 64-bit offset variant of NetCDF-3, whose only visible difference from the classic file is the fourth magic byte and the width of the header offsets. Use it to check that format sniffing looks at the version byte instead of stopping at the 'CDF' signature.
- ncNetCDF CF-1.8 Gridded Air Temperature (.nc)A NetCDF-3 classic file holding a 4x5x6 air-temperature field with full CF-1.8 coordinate metadata: standard names, axis attributes, units on every variable, and a declared _FillValue. Use it to check that a reader attaches units and coordinates to the array rather than returning bare numbers.
- ncNetCDF Packed int16 with scale_factor / add_offset (.nc)The same temperature field stored as int16 and recovered through the CF packing attributes scale_factor and add_offset. This is the failure that parses cleanly and is silently wrong: a reader that ignores the attributes returns values around -2000 instead of 260-292 K.
- binDICOM-Shaped Part 10 File: Explicit VR, Synthetic Phantom (.bin)A DICOM Part 10 file built byte by byte: 128-byte preamble, the DICM magic, an explicit-VR file meta group and a 27-element dataset ending in 16-bit pixel data. Every identifier is invented: the patient name is SYNTHETIC^PHANTOM, the instance UIDs sit under the unregistered 2.25 UUID arc, and the pixels are a generated pattern. There is no protected health information here and nothing in the file refers to a real person, device or study.
- binDICOM-Shaped Part 10 File: Implicit VR, Synthetic Phantom (.bin)The same synthetic phantom written with the implicit-VR transfer syntax, where element types never appear on the wire and a reader must consult a data dictionary to know that Rows is a 16-bit integer. The file meta group stays explicit VR, which is the mixed-mode detail parsers most often miss. Every identifier is invented: the patient name is SYNTHETIC^PHANTOM, the instance UIDs sit under the unregistered 2.25 UUID arc, and the pixels are a generated pattern. There is no protected health information here and nothing in the file refers to a real person, device or study.
- binDICOM-Shaped Stream: No Preamble, No DICM Magic (.bin)The identical element stream with the 128-byte preamble and the DICM magic stripped, which is how DICOM often arrives out of a network transfer or a database blob column. It is not a conformant Part 10 file and its content is entirely recoverable, so a reader should fall back rather than reject.
