[netCDFJava #KUD-999886]: Inconsistent results from Array.getDouble()/Array.getFloat()

Added JIRA ticket

https://bugtracking.unidata.ucar.edu/browse/TDS-446

John


> Hi Aaron:
> 
> the problem is that the 2 files have different scale / offsets, and its 
> flipping between which one is being used. Problem is that scale/offset gets 
> applied after the aggregation is done. Not sure how to fix this problem, ill 
> let you know. In the meanwhile if you can write the files with same 
> scale/offset that would work.
> 
> John
> 
> 
> 
> 
> > Hi Aaron:
> >
> > Ive reproduce the problem and ill let you know when i figure out whats up. 
> > thanks for the test case.
> >
> > Jon
> >
> > > Hello,
> > >
> > > In some cases the netCDF API is returning one value (such as
> > > "17.699193954467773"), and at other times it is returning another (such
> > > as "17.000396728515625").  I created a Java main() to reproduce this
> > > problem independently of ncWMS:
> > >
> > > public static void main( String[] args ) throws Exception{
> > > //    GridDataset dataset = GridDataset.open(
> > > "/data/nssl2dMosaic/2013/20130619/v_020500/20130619_v_020500_l_0000000.nc"
> > > );
> > > GridDataset dataset = GridDataset.open(
> > > "/data/nssl2dMosaic/dataset.ncml" );
> > > GridDatatype grid = null;
> > > for( GridDatatype thisGrid : dataset.getGrids() ){
> > > if( thisGrid.getName().equals( "cref" )){
> > > grid = thisGrid;
> > > }
> > > }
> > > List<Range> ranges = new ArrayList<Range>();
> > > ranges.add( new Range( 0, 0 ) );
> > > ranges.add( new Range( 0, 0 ) );
> > > ranges.add( new Range( 638, 638 ) );
> > > ranges.add( new Range( 3750, 4622 ) );
> > > Array arr = grid.getVariable().read( ranges );
> > > Index index = arr.getIndex();
> > > index.set( new int[]{0,0,0,834} );
> > > System.out.println( arr.getDouble( index ) );
> > > dataset.close();
> > > }
> > >
> > > Running this program several times will return one of two values: either
> > > "17.000396728515625" or "17.699193954467773", depending on the run.
> > > This main() was derived from reverse-engineering the process used by
> > > ncWMS for accessing my data.  I first encountered this with netCDF API 
> > > 4.2.
> > >
> > > Another interesting wrinkle is that if I only have the single data file
> > > (the one with the value accessed by this test - commented out above) in
> > > the data directory it always returns the "17.0" value.  It is only when
> > > I have two or more files that match the NCML declaration that
> > > occasionally it will return different values. Based on this behavior it
> > > may be an NCML issue and it seems likely that the "17.0" is the correct
> > > data value.  I ran this with netCDF API 4.3.1.3 I downloaded a few
> > > minutes ago and it exhibited the same problem.
> > >
> > > The data for this test may be found under
> > > http://www.ral.ucar.edu/staff/braeckel/nssl2dMosaic/.  Any thoughts on
> > > what may be going on?
> > >
> > > Thanks,
> > > Aaron
> > >
> > >
> >> Hi Aaron:
> 
> the problem is that the 2 files have different scale / offsets, and its 
> flipping between which one is being used. Problem is that scale/offset gets 
> applied after the aggregation is done. Not sure how to fix this problem, ill 
> let you know. In the meanwhile if you can write the files with same 
> scale/offset that would work.
> 
> John
> 
> 
> 
> 
> > Hi Aaron:
> >
> > Ive reproduce the problem and ill let you know when i figure out whats up. 
> > thanks for the test case.
> >
> > Jon
> >
> > > Hello,
> > >
> > > In some cases the netCDF API is returning one value (such as
> > > "17.699193954467773"), and at other times it is returning another (such
> > > as "17.000396728515625").  I created a Java main() to reproduce this
> > > problem independently of ncWMS:
> > >
> > > public static void main( String[] args ) throws Exception{
> > > //    GridDataset dataset = GridDataset.open(
> > > "/data/nssl2dMosaic/2013/20130619/v_020500/20130619_v_020500_l_0000000.nc"
> > > );
> > > GridDataset dataset = GridDataset.open(
> > > "/data/nssl2dMosaic/dataset.ncml" );
> > > GridDatatype grid = null;
> > > for( GridDatatype thisGrid : dataset.getGrids() ){
> > > if( thisGrid.getName().equals( "cref" )){
> > > grid = thisGrid;
> > > }
> > > }
> > > List<Range> ranges = new ArrayList<Range>();
> > > ranges.add( new Range( 0, 0 ) );
> > > ranges.add( new Range( 0, 0 ) );
> > > ranges.add( new Range( 638, 638 ) );
> > > ranges.add( new Range( 3750, 4622 ) );
> > > Array arr = grid.getVariable().read( ranges );
> > > Index index = arr.getIndex();
> > > index.set( new int[]{0,0,0,834} );
> > > System.out.println( arr.getDouble( index ) );
> > > dataset.close();
> > > }
> > >
> > > Running this program several times will return one of two values: either
> > > "17.000396728515625" or "17.699193954467773", depending on the run.
> > > This main() was derived from reverse-engineering the process used by
> > > ncWMS for accessing my data.  I first encountered this with netCDF API 
> > > 4.2.
> > >
> > > Another interesting wrinkle is that if I only have the single data file
> > > (the one with the value accessed by this test - commented out above) in
> > > the data directory it always returns the "17.0" value.  It is only when
> > > I have two or more files that match the NCML declaration that
> > > occasionally it will return different values. Based on this behavior it
> > > may be an NCML issue and it seems likely that the "17.0" is the correct
> > > data value.  I ran this with netCDF API 4.3.1.3 I downloaded a few
> > > minutes ago and it exhibited the same problem.
> > >
> > > The data for this test may be found under
> > > http://www.ral.ucar.edu/staff/braeckel/nssl2dMosaic/.  Any thoughts on
> > > what may be going on?
> > >
> > > Thanks,
> > > Aaron
> > >
> > >
> >


Ticket Details
===================
Ticket ID: KUD-999886
Department: Support netCDF Java
Priority: Normal
Status: Closed