Hi Jon:
The bug is triggered when requesting certain subsets of data. The code
was trying to skip chunks it didnt need, but wasnt getting it quite
right. Your tiling algorithm was just the thing needed to stress test
that. Nothing you need to do in your code.
John
On 2/27/2014 6:31 AM, Jon Blower wrote:
Hi John, all,
Is there anything we need to do in the WMS or Godiva code here? Why does the
tiling algorithm make this problem appear more?
Cheers,
Jon
----------
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/R
OMS_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/
End of thredds Digest, Vol 61, Issue 6
**************************************
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
