These files contain scalar data values on a regular rectangular grid, either
in (x, y) or (longitude, latitude) space.
Such files may be displayed in maps created by FiniteMap and/or NeoKineMap,
and are also used in the OrbData step of adding nodal data (e.g., elevation, heat-flow) to finite element grids intended for use in Shells/Plates/Faults.
The first line of a .grd file has 3 numbers: x_min, d_x, x_max (or: lon_min, d_lon, lon_max);
The 2nd line of a .grd file also has 3 numbers: y_min, d_y, y_max (or: lat_min, d_lat, lat_max).
If the grid is defined in (longitude, latitude) then note:
Units of lon_min, d_lon, lon_max, lat_min, d_lat, lat_max are degrees (e.g., 24º17'5" should be converted to a decimal-fraction 24.2847 degrees).
East longitude is +, West is -. North latitude is +, South is -.
If the grid is defined in (x, y) space, the 6 grid parameters at the
top can be in units of: meters, kilometers, centimeters, miles, or feet.
(However, I strongly suggest using meters, because keeping all your data files and programs in SI units will always make them compatible!)
NOTE that these 6 x and y values MUST give the actual widths of features on the planet, NOT their reduced sizes on some map!
Any origin and any orientation of the (x, y) system is permissible, as long as the +y axis is 90 degrees counterclockwise from the +x axis,
and as long as you do NOT mix two or more different Cartesian coordinate systems in one modeling project.
The following lines give the gridded data in text order, i.e.,
beginning with the top-left (maximum y or latitude; minimum x
or longitude) corner,
going left to right along the top row (increasing longitude or x at constant latitude or y), then left to right along the 2nd row, etc.
The number and position of line breaks is not important in this part of the file.
You can even have a single value per line.
However, it is easier for humans to read these files if the number of columns is equal to 1 + (x_max - x_min)/d_x, as in the example below.
There is no restriction on the units of the gridded data values, except that
they should all be the same.
Personally, I would suggest using SI units (m for elevation, W/m2 for heat flow, etc.) in this file format, and in all other numerical work.
The small sample .grd file below gives an elevation grid around
Denali (Mt. McKinley) in Alaska, with the grid defined in (longitude,
latitude) space (152~151ºW, 63~64ºN), and the elevations reported in
It comes from the ETOPO5 data set, which has lateral resolution of 5' (0.08333º).
The summit (+6168 m) is located at (151º00'13"W, 63º04'10"N), so it falls between the last two entries in the right-most column.
The + signs on positive elevation values could have been omitted, but the negative signs for the West longitudes is critical,
as is their order within the first line of the file (more negative number on the left, more positive number on the right).
Following is some simple Fortran 90 code that could be used to read any .grd
file into a matrix.
Note that it would be trivial to change the REAL matrix to an INTEGER or DOUBLE PRECISION or LOGICAL matrix if appropriate.
Also, lon_min, d_lon, lon_max could be renamed as x_min, d_x, x_max for Cartesian-coordinate data.