NetCDF Multi-Variable Station File — Four Unit Systems (.nc)
Four physical quantities on one shared (time, station) grid, each with its own CF units string including the dimensionless '1' and the UDUNITS 'm s-1' spelling. It is the fixture for a unit-aware layer that has to keep four different unit systems straight in a single file.
| Variable | Units | standard_name | Nominal mean |
|---|---|---|---|
| air_temperature | K | air_temperature | 285.0 |
| air_pressure | Pa | air_pressure | 101325.0 |
| relative_humidity | 1 | relative_humidity | 0.62 |
| wind_speed | m s-1 | wind_speed | 5.4 |
Specifications
- Variables
- 4
- Units
- K, Pa, 1 (dimensionless), m s-1
- Feature Type
- timeSeries
- Stations
- 4
- Times
- 6
- Seed
- 20260807
- Generator
- numpy default_rng standard_normal
Testing contract
Expected to pass- Scenario
- Read all four data variables and their units attributes, then convert air_temperature to degrees Celsius.
- Expected result
- All four variables have shape (6, 4), the units strings read back exactly as 'K', 'Pa', '1' and 'm s-1', and the Celsius conversion shifts values by -273.15 without touching the other three.
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 Multi-Variable Station File — Four Unit Systems (.nc)” is a deterministic Novus Examples 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: seed 20260807. 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.
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.
Generated by generation/scientific.py. Free for any use, no attribution required — license.