New:
New FAQ about finding whether a file exists
http://ferret.pmel.noaa.gov/Ferret/faq/determining-if-a-dataset-exists
New Features:
1) NetCDF files that Ferret writes are now written to better comply with the CF conventions. The changes have to do with writing coordinate axis variables to netCDF files. Coordinate axes having geophysical units of longitude and latitude will always be written with the units "degrees_east" or "degrees_north". Also these axes, and also vertical and time axes, now automatically have a standard_name attribute with the appropriate value: "time", "altitude" or "depth", "degrees_north", "degrees_east".
In addition, there is a case-sensitivity in the udunits/NetCDF software libraries so that
% ncdump -ct dataset.nc
(to list formatted dates for time axes) does not work if the units string contains upper-case, e.g. TAX:units = "DAYS since 1901-01-15". So that this option can be used to examine Ferret-generated netCDF files, we now write time-axis units strings with lowercase spelling, TAX:units = "days since 1901-01-15" ;
Bug fixes:
1)The TAX_DATESTRING and other TAX_* functions have single-precision arguments, as do all Ferret functions. The first argument is a collection of coordinate values to be translated in some way. This means that we are passing a single-precision version of the underlying double-precision coordinate data, and for some axes the results were inaccurate. This is addressed within these functions by first translating values from argument 1 to their nearest value in the time axis of argument 2. If there are duplicate values in argument 1, this is taken to mean that there is too much truncation to return a valid result and an error message is returned. This fix is made in functions TAX_DATESTRING, TAX_DAY, TAX_DAYFRAC, TAX_JDAY1900, TAX_JDAY, TAX_MONTH, TAX_YEAR, and TAX_YEARFRAC. Previously the function did not check for this and results for some axes were inaccurate. This is not a complete fix - axis coordiantes that truly require double precision representation cannot be represented in single precision. (Note that there is plenty of precision in double-precision data to store seconds since year 0000 with accuracy, and that internally Ferret does computations with double-precision coordinates. It is only in putting coordinate values into a single-precision variable that we have this behavior.)
2) A longstanding bug has been corrected, where plotted lines ( as in go land ), that are overlaid on a 2D plot, and which lie near but outside the outer corners of the plot, either from the bottom to the left side of the plot, or from the top to the left, but not crossing any axis, may cause a stray line to be drawn outward from the corner.
3) internal gif file-name fix for LAS
4) Previously the output of SHOW DATA truncated the axis sizes if they needed more than 6 digits to represent them. This is fixed.
5) Previously the output of SHOW AXIS or SHOW GRID listed the axis size as ***** if it was too large. This is fixed.
6) The tic mark labels on some plot axes didn't have enough precision. When the size of the tic mark values lies between -1 and 1, but were not so small that they are drawn using scientific notation, there were labels with just one significant figure but which needed two. For instance,
yes? let v = {0.02, 0.047,0.007, 0.02}yes? set view leftyes? plot v ! The uppermost tic mark should be 0.45, but had just one digit.
yes? let v = {-0.023, -0.01, 0.007, 0.004}yes? plot v ! Had repeated labels -0.02, -0.02, -0.01, -0.01
This is fixed.