Hello Ryo, In addition to the response from Dennis, I think I can clarify the ncdump issue. The default precision (which I don't have off the top of my head) is causing the rounding/issue you have reported. You can correct this using the '-p' argument. For example, when I run the following on the file you've provided, I see more precise output: $ ncdump -p 20,20 -v Z_ISO ncdump-bug-precision.nc (...) Z_ISO = -9.9900000981736855962e+20, -9.9900000981736855962e+20, (...) So, the precision displayed can be modified. It's important to note that this is not affecting the underlying data in the file, it is only a cosmetic issue issue. I notice you are doing a straight equality check on your values in the sample file you provided; this is typically not a good idea, for the reasons outlined here: * http://floating-point-gui.de/errors/comparison/ * http://wiki.seas.harvard.edu/geos-chem/index.php/Floating_point_math_issues When comparing floating point values, you must often take additional steps to ensure a very small difference in values, such as you've observed here, due to rounding errors. Granted, I am coming at this from a C developer standpoint, as I am not a Fortran expert, but I believe the issue remains the same with programming in Fortran (as supported by the second link above). I hope this information is helpful, -Ward > Dear netCDF maintainers, > > I've found ncdump doesn't always display enough digits. If you display the > attached netCDF file, you'll see > > Z_ISO:_FillValue = -9.99000009817369e+20 ; > > and > > Z_ISO = > -9.99000009817369e+20, [ . . . elided . . .] > > How is that possible? _Fillvalue doesn't work. Actually the value of the > variable is -9.9900000981736856e+20 . > > This is confusing at least. Moreover, because the output from ncdump can > be used to generate another netCDF file, this problem can be the source of > a subtle bug. As the attached Fortran program demonstrates, gfortran is > designed in such a way that ascii output retains enough digits to exactly > recover the original value. > > The Fortran program also illustrates how I was hit by this problem. An > application program converted my original single-precision data to double > precision and as a result, it was difficult to set a correct fill value. > But that's an aside. > > Regards, > > Ryo > ------------------------------------------------------------ > ! The following program will print > ! > ! -9.9900000981736856E+020 -9.9900000000000000E+020 > -9.9900000000000000E+020 > ! d1 == d2 > ! > ! using gfortran 4.8 . > ! > program tmp > implicit NONE > real(8):: d, d1, d2 ! double precision variables > character(16):: str = "-9.99e20" > > d = -9.99e20 ! single-precision constant > d1 = -9.99d20 ! doulbe-precision constant > read(str, *) d2 ! double precision read > > write(*,*) d, d1, d2 > if (d1 == d ) write(*,*) "d1 == d" > if (d2 == d ) write(*,*) "d2 == d" > if (d1 == d2) write(*,*) "d1 == d2" > end program tmp > > Ticket Details =================== Ticket ID: DHW-277522 Department: Support netCDF Priority: Normal Status: Closed =================== NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.