In general the coordinate axes that are used when defining curvilinear coordinate variables and data fields are just indices X=1:m, Y=1:n, and the curvilinear coordinate variables are all that define longitude and latitude. Below we will specify new coordinate axes with longitude and latitude units, which the product scripts can use in portions of the world where the grid is rectilinear.
For some grids, the underlying axes are not simple index axes, but instead they define the longitudes and latitudes of the rectilinear grid - that is, if you look at a data field in the portion of the grid that is not curvilinear, the correct world coordinates are present. For a grid like this, simply specify in the dataset configuration xml file the ferret properties linear_lat_max, for the highest latitude at which the grid is rectilinear, and linear_coords_file, which for this case should be set to the string same_as_infile.
<properties>
<ferret>
...
<linear_lat_max>47.0</linear_lat_max> <!-- Curvilinear above lat = 47 -->
<linear_coords_file>same_as_infile</linear_coords_file>
...
<ferret>
</properties>
<variables>
...
For other grids, the underlying x and y axes are just I and J index values, and do not describe the longitudes and latitudes in the rectilinear portion of the grid. Here we need to define a longitude and a latitude axis which have the correct values in the rectilinear portion of the grid, and which are the same length as the x and y axes. When the data request is for data in this part of the grid, the product scripts will switch axes and then it will be able to use simpler logic for the dataset which now appears as if it is on a rectilinear grid.
You MAY be able to run Ferret and define these axes directly, by using values from the LONGITUDE and LATITUDE variables. If the curvilinear coordinate variables for the grid are called LONGITUDE and LATITUDE, then:
> ferret
yes? USE my_curvilinear_data_file.nc
yes? DEFINE AXIS/X/MODULO/UNITS="`LONGITUDE,RETURN=units`" RECT_LON_AXIS = LONGITUDE[j=2]
yes? DEFINE AXIS/Y/UNITS="`LATITUDE,RETURN=units`" RECT_LAT_AXIS = LATITUDE[i=2]
yes? LET ax = x[gx=RECT_LON_AXIS]
yes? LET ay = y[gy=RECT_LAT_AXIS]
yes? SAVE/FILE=my_linear_coords_file.nc ax, ay
yes? exit
> ncdump my_linear_coords_file.nc > my_linear_coords_file.cdl
Now edit my_linear_coords_file.cdl and remove all references to the variables ax and ay.
The file should contain only the axis definitions.
> ncgen -o my_linear_coords_file.nc my_linear_coords_file.cdl
However if the grid is so fine that it must be defined using double precision, you will get error messages when making the above DEFINE AXIS commands. Ferret variables are single precision, so the expression inside the DEFINE AXIS commands,
RECT_LON_AXIS = LONGITUDE[j=2]
will convert the values in LONGITUDE to single precision. If the coordinates must be represented in double precision you will need to look at the curvilinear coordinate variables and write DEFINE AXIS commands based on what you see. Check the Ferret documentation under DEFINE AXIS for the details (http://ferret.pmel.noaa.gov/Ferret/documentation/users-guide/commands-reference/DEFINE#_VPINDEXENTRY_1299). and once you have defined the axes in Ferret, save varaibles defined on the axes and edit the linear_coords_file as above. Remember that the axes will be used only in the region south of the latitude you set in the property linear_lat_max.
Now, in the Ferret properties in the xml configuration for the dataset, include the linear_lat_max value, and the name of the file (where the specification will include its path).
<properties>
<ferret>
...
<linear_lat_max>47.0</linear_lat_max> <!-- Curvilinear above lat = 47 -->
<linear_coords_file>my_linear_coords_file.nc</linear_coords_file>
...
<ferret>
</properties>
<variables>
...
The product scripts will use this file and get the s
Note that thus far we have addressed grids where the curvilinear portion of the grid is in the north, and the grid is rectilinear in some part of the globe south of some particular latitude. If other kinds of grids exist where this feature would be useful, the capability can be expanded to deal with them.