Limit on Storage for Coordinates
How do I get around the Ferret error message:
**TMAP ERR: limit on storage for coordinates has been reached: MAX= 750000 ?
> Does FERRET have limitation on storage for coordinate? I have a netCDF
> file containing a time series with a large number of time steps. When I tried
> to use FERRET, use metero.cdf, I got " **TMAP ERR: limit on storage for
> coordinates has been reached MAX= 750000". Then I made a test by cutting
> the data down to 5000 time levels, FERRET is OK to work on this short time
> Can somebody tell me how to go around this problem?
Previous to Ferret v7.3, there was a fixed set of internal storage dedicated to storing all of the data for the coordinate axes available to the current Ferret session. This includes data being read from netCDF or OPeNDAP datasets and from DEFINE AXIS definitions. In Ferret v7.3 and higher this limitation is lifted. Storage for handling coordinate data is handled with dynamic allocation of memory. As before, if the coordinates for an axis are determined to be regularly-spaced, they are not all stored; only the start, count and cell size are needed in that case.
Upgrade to Ferret/ PyFerret v7.3 or higher.
Discussion, Previous to v7.3:
Yes, Ferret did have a limit of 750000 coordinate points; and note that this includes storage both for the coordinate points and the edges of the grid cells. But generally this limit need not get in your way. It is only really a limit if you have 750K unevenly spaced coordinate points -- this is rarely the case. Your NetCDF file needs to TELL Ferret that the time points are regularly spaced. Ferret is attempting to read them so it can check the spacing. Having determined that the points were evenly spaced it would retain only the start,end, and delta values (freeing up the space), but it isn't getting that far.
There are two solutions to this. If the axis is in fact regularly spaced, add information to the netCDF file to tell Ferret this. Or, if this is a time axis, you can just open the file with a qualifier which tells Ferret to treat the axis as a regularly-spaced axis.
1) From Chapter 10 in the Ferret Users Guide:
10.3.5.4 Evenly spaced coordinates (long axes), see "memory, NetCDF" in the Users Guide index.
If the coordinate axes are evenly spaced, the attribute "point spacing" should be used:slat: point_spacing = "even" ;
When used, this attribute will improve memory use efficiency in Ferret. This is especially important for very large axes--10,000 points or more.
You can use the Ferret function NCO_ATTR to add this attribute to an axis of your file.If the axis also has bounds then you will also need to remove the bounds attribute from the axis. Or use NCO operators from the Unix command line. See the NCO_ATTR function in the Ferret documentation. Ferret Users Guide. The documentation includes references to the NCO operators.
TEMP:point_spacing = "even" ;
to your file dat.nc, just
yes? show grid var ! see what the axis is called yes? cancel data/all yes? let status = NCO_ATTR ("dat.nc", "TEMP", "point_spacing", "c", "o", "even") yes? load status yes? use dat.nc yes? show grid var ! see the grid. yes? show data/att ! Lists all the attributes for the variables.
If the axis has a "bounds" attribute then the axis may still be seen by Ferret as irregular. To delete the bounds attribute,
yes? cancel data/all yes? let status = NCO_ATTR ("dat.nc", "TEMP", "bounds", "c", "d", " ") yes? use dat.nc
This will leave the bounds coordinates listed in the file, but they will be ignored by Ferret when using the axis.
2) If it is a time axis that's missing a point_spacing = "even" attribute, (or if it is actually irregularly spaced), you can have Ferret treat the axis as being regularly spaced, by opening it with the /REGULART qualifier:
yes? USE/REGULART dat.nc yes? show grid var
This also speeds up the initialization step for a file, if this time axis is the record axis for the file and the axis is long - a common situation.