Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Hi again Ed You must be getting sick of me! I'd like to make another point about fill values. We store digitizer data as shorts, with a scale and offset, potentially covering the full bit range from 0h to FFFFh. We need to know if the digitizer data is stuck at the top or bottom of the range so we can detect hardware faults. I've confirmed that we can write the fill value (eg FFFFh) as a valid data value, and read it back. But because it's a valid application value, we really don't want to see it as a generated fill value. The data and nothing but the data! A related point for John: ncdump handles unsigned short values correctly (eg FFFFh is 65535), but the Java tool treats them as signed shorts (eg FFFFh is shown as -1). Regards John -- John Storrs, Experiments Dept e-mail: john.storrs@xxxxxxxxxxxx Building D3, UKAEA Fusion tel: 01235 466338 Culham Science Centre fax: 01235 466379 Abingdon, Oxfordshire OX14 3DB http://www.fusion.org.uk
netcdfgroup archives: