Hi all:
ok, i have found the problem and will get a fix out in the next few
days. its in the netcdf-java hd5 chunked data reader, but mostly
manifests in godiva because of their tiling algorithm. symptom is that
missing data is returned for some chunks of the data. non-missing data
is correct.
John
On 2/13/2014 3:15 PM, John Maurer wrote:
OK, when I convert our files from NetCDF-4 (Classic) to NetCDF-3, the
problem goes away. Could this be a bug in TDS/FMRC? Is there some
additional TDS configuration I can try to keep our files in NetCDF-4? We
are running TDS 4.3.20 - 20131125.1409.
Thanks,
John
On Thu, Feb 13, 2014 at 10:36 AM, John Maurer <jmaurer@xxxxxxxxxx
<mailto:jmaurer@xxxxxxxxxx>> wrote:
Hi TDS folks,
I'm seeing a strange problem with some of our new regridded ROMS
ocean forecast models that I'm hoping somebody can help me with. At
certain time steps, some regions are displaying values of
9.96921E36. From my understanding, this is the value assigned (by
NetCDF?, OPeNDAP?, TDS?) when there was no data value. However, I
can confirm in each of my NetCDF files that the same slices contain
valid data values. So the problem seems to stem from the TDS side of
things, where I am serving these as a Forecast Model Run Collection
(FMRC). Furthermore, I have already assigned a _FillValue and
missing_value of NaN, so the 9.96921E36 issue is something else.
More pieces to the puzzle are: (1.) no matter what file I test with,
it always occurs at the same time steps and regions; (2.) it shows
up in all variables (temp, salt, u, v); (3.) you can see this in
Godiva2/ncWMS, NetCDF Subset Service, and OPeNDAP. Ideas?? I'm stumped.
Here is my TDS testbed for this; I have been focusing specifically
on the Best Time Series:
http://oos.soest.hawaii.edu/thredds-test/catalog/hioos/roms_forec/hiig/catalog.html
Godiva2 will show you an example of the problem if you navigate to
sea_water_potential_temperature on Feb 19 2014 at 18:00 at 0.25
meters depth. As shown in the example image attached, there is a
black rectangle in the southeast corner where the values are all
9.96921E36. You can click there to confirm this value is returned.
(Strangely the "test image" for the same day does not have this
problem...)
Here is an OPeNDAP call within that same time/lat/lon/depth which
shows the 9.96921E36 values:
http://oos.soest.hawaii.edu/thredds-test/dodsC/hioos/roms_forec/hiig/ROMS_Hawaii_Regional_Ocean_Model_best.ncd.ascii?temp[14][0][0:1:10][284:1:294]
I have staged a gzipped NetCDF file (1.4 GB) and TDS catalog via ftp
for you to test with:
ftp.soest.hawaii.edu <http://ftp.soest.hawaii.edu>
user: anonymous
pass: <your e-mail address>
cd jmaurer/unidata/
get ocn_mod_hiig.xml
get hiig_forec_20140208.nc.gz
Thanks in advance for your time on this!
Cheers,
John Maurer
Pacific Islands Ocean Observing System (PacIOOS)
University of Hawaii at Manoa
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
