ROMS C-grid indices and NetCDF file indices

Message

arango · #1 Unread post by **arango** » Sat Dec 10, 2011 5:19 pm

I am re-posting this answer to a more visible place in this forum since it is very important and all ROMS users need to be aware of it.

It was reported in this forum about an inconsistency between the station locations and data stored in the NetCDF files. The issue is related with the station locations (Ipos,Jpos) in ROMS fractional coordinates and the values of array(Ipos,Jpos) written in the output stations NetCDF file. The code is correct as it is. However, it seems that there is a problem of interpretation about station locations and how NetCDF files stores array data. The positions (Ipos, Jpos) specified in the input script file stations.in are all assumed to be located at RHO-points. That is, if Ipos and Jpos are whole numbers and not fractions, the station is located at the center of grid cell (RHO-point) defined by Ipos and Jpos in ROMS native index coordinates and not NetCDF indices in the file. Recall, that ROMS uses a staggered Arakawa C-grid discretization. This is a numerical artifact and nothing to do with geography. If you put an instrument in the ocean, you specify its location by the (lon,lat) coordinates and you never take into consideration if this is a B-grid or C-grid when deploying the instrument. Now, ROMS is a finite volume model and we assume that any data (scalar or vector) that it is measured in the real world is located at RHO-points (center of the finite volume cell). As a matter of fact, we use this assumption routinely in bathymetry, preparing initial conditions and climatology, data assimilation, model-data comparisons, etc.

If you check wikiROMS, you will find a

diagram of the horizontal index discretization in ROMS. You will notice the following (I,J) ranges for ROMS variables:

Code: Select all

RHO-points  0:L  0:M
PSI-points  1:L  1:M
  U-points  1:L  0:M
  V-points  0:L  1:M

Now if you carefully examine the NetCDF file, you will discover that there is no zero neither negative indices in the NetCDF variable dimension. This doesn't means that we cannot store such arrays in a NetCDF file. There is always a linear re-map of indices in each dimension. The data is always offset by the amount required so the fist value of the array is always written at the (1,1,...) location in the NetCDF file. We don't have control about this.

Therefore, ROMS arrays at RHO-points are always shifted by 1 in the I- and J-indices when processing NetCDF data. Notice that at U-points the one-shift is in the J-index whereas at V-points the one-shift is in the I-index. This is the reason why we always recommend the users to use the software that it is distributed from our repositories. This is always a problem in Matlab since it cannot handle zero or negative indices. We are not responsible neither can check the software developed for ROMS from third parties.

So it makes a lot of sense that if we have Ipos=10 and Jpos=20, the information stored in a RHO-point variable in the NetCDF file is located at array(11,21) and not at array(10,20).

The C-preprocessing option STATIONS_CGRID can be used to write into the station NetCDF files the data at its C-grid native locations instead of the RHO-points default locations. In this case, the interpretation is different for U- and V-point variables and vectors are staggered.

I hope that this clarifies well this issue. It is important for each user to understand clearly this aspect about ROMS and NetCDF files. It is very important when pre- or post-processing ROMS data. If you are developing software to process ROMS data you need to take this into consideration.