Re: bug?

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
<>< <>< <>< <>< <>< <>< <>< <>< <><





  • 2006 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: