Thanks, that was enough for me to find it. It got past my unit tests for some
subtle reasons, and only a direct dods read (eg through the web interface, or
Bob's code) uncovered it.
New file at:
ftp://ftp.unidata.ucar.edu/pub/thredds/3.12/thredds.war
special thanks to Bob once again.
Roy Mendelssohn wrote:
Hi John:
Just to let you know the test URL's that Bob sent will not be available,
as we need to be able to access the data properly, so we are
reinstalling 3.10.
However, I did some more systematic testing on the new version. First,
we stopped THREDDS and cleared all the caches so that we knew exactly
what we were dealing with. Then we restarted THREDDS.
I systematically tried different things with various datasets. As Bob
did, I asked for the first time, and got zero. I also got all zeros if
I asked for the first 12 times (or several other numbers of time
values), and I could repeat doing this and still get zeros as long as I
was only requesting a subset of the time dimension. I also tried
accessing first something other than the time variable which is being
aggregated and then accessed various subsets of the time variable, and
time still came out zero. BTW when I make the request for the parameter
of interest everything else but time is correct - see below for an example.
Only when I accessed the entire time dimension (the dimension being
aggregated) did the problem go away - and then no matter how I sliced it
I always got the correct values.
I hope this information helps to isolate the problem. Sorry we can't
keep the new version running, but it is bringing to a halt a number of
our servers. We slowly are getting a second machine up that we can do
full testing without affecting our operations machine.
Regards,
-Roy
Dataset {
Grid {
ARRAY:
Float32 ATssta[time = 2][altitude = 1][lat = 3][lon = 3];
MAPS:
Float64 time[time = 2];
Float32 altitude[altitude = 1];
Float32 lat[lat = 3];
Float32 lon[lon = 3];
} ATssta;
} satellite/AT/ssta/3day;
---------------------------------------------
ATssta.ATssta[2][1][3][3]
[0][0][0], -1.0E32, -1.0E32, -1.0E32
[0][0][1], -1.0E32, -1.0E32, -1.0E32
[0][0][2], -1.0E32, -1.0E32, -1.0E32
[1][0][0], -1.0E32, -1.0E32, -1.0E32
[1][0][1], -1.0E32, -1.0E32, -1.0E32
[1][0][2], -1.0E32, -1.0E32, -1.0E32
ATssta.time[2]
0.0, 0.0
ATssta.altitude[1]
0.0
ATssta.lat[3]
22.0, 22.0125, 22.025
ATssta.lon[3]
215.0, 215.0125, 215.025
Thanks for reporting this. I probably wont be able to investigate
until tommorrow. Feel free to muck with it before then.
Bob Simons wrote:
Roy Mendelssohn wrote:
Is it the first value of the array, or is it the first time that the
variable has been accessed?
The problem is with accessing the first value of the array. (Or maybe
any single value? I don't know, because I don't want to use up test
cases for John.) You try to access that first value any number of
times and always get 0.
> What if the initial access is the whole
array, is the first value still incorrect?
Probably the answer will be correct. But I note that I have 2
browsers that are accessing the entire time array every hour (and
getting correct values), and yet I can still see errors when trying
to access the first element.
> I think this is tied into
needing to hit on the variable to get it into cache, though I am not
positive of this.
Yes, but it seems to be a specific type of hit that is needed. It
should be any hit.
-Roy
At 11:50 AM -0700 8/1/06, Bob Simons wrote:
My program gets the correct values when it asks for the entire time
array. It is this request for just the first value that returns a
wrong answer.
Lynn Dewitt wrote:
Hi Bob,
I just looked at my processes and they all SEEM to be getting
the correct times the first time right now, however the QN files
ran around midnight, so I don't think my scripts have run on them
since the new THREDDS version was installed. But so far I can't
find any trouble with GA, CM , etc., that have run recently. I
won't run any tests so as not to mess up any you are running.
Lynn
On Aug 1, 2006, at 11:21 AM, Bob Simons wrote:
I may be missing wrong, but there may be a very serious bug in
the new THREDDS.
I though maybe this was the bug that Lynn saw, but I think it is
new, because it appeared with the new version of THREDDS.
When I sent this query to THREDDS to get just the first time value
http://192.168.31.18:8081/thredds/dodsC/satellite/QN/ux10/1day.ascii?time[0:1:0]
I got the value 0.
If I sent this query to THREDDS to get all time values
http://192.168.31.18:8081/thredds/dodsC/satellite/QN/ux10/1day.ascii?time
The result was a list of time values, all around 10^9. Note that
the first value is not 0.
But when I asked for the first value again
http://192.168.31.18:8081/thredds/dodsC/satellite/QN/ux10/1day.ascii?time[0:1:0]
I got the correct value. Things seem to have gotten set right.
When I repeated the tests with uy10 instead of ux10, I got the
same sort of errors, then the correct values.
So I'll give the following 3 urls ***FOR JOHN'S USE ONLY***
(since they may only work the first time someone tries it):
http://192.168.31.18:8081/thredds/dodsC/satellite/QN/divw/1day.ascii?time[0:1:0]
returns 0?
http://192.168.31.18:8081/thredds/dodsC/satellite/QN/divw/1day.ascii?time
returns all the right values?
http://192.168.31.18:8081/thredds/dodsC/satellite/QN/divw/1day.ascii?time[0:1:0]
returns the right value?
and you can probably do similar tests by substituting (for "ux10"
or "divw") any of these: umod, taux, tauy, tmod, curl, wekm,
uekm, vekm, emod.
Please: THESE ARE FOR JOHN'S USE ONLY, since they right
themselves after the tests are run and are thus valuable test
cases that only fail for a short time.
Note that all examples are .ascii for simplicity of testing but
the original problem occurs with binary requests via the Java DAP
library.
John, can you reproduce the problem?
Am I doing something wrong?
Sincerely,
Bob Simons
Satellite Data Product Manager
Environmental Research Division
NOAA Southwest Fisheries Science Center
1352 Lighthouse Ave
Pacific Grove, CA 93950-2079
(831)648-0272
bob.simons@xxxxxxxx
<>< <>< <>< <>< <>< <>< <>< <>< <><
Lynn deWitt
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Ave
Pacific Grove, CA 93907
(831)648-9036
--
Sincerely,
Bob Simons
Satellite Data Product Manager
Environmental Research Division
NOAA Southwest Fisheries Science Center
1352 Lighthouse Ave
Pacific Grove, CA 93950-2079
(831)648-0272
bob.simons@xxxxxxxx
<>< <>< <>< <>< <>< <>< <>< <>< <><
