Variables for Masked Grid Cells

[soilinkin]

Hi, I have a model run blow-up at the first time step. My first suspect is the grid file generated with Delft3D.

Variables like coordinates are all set to -999 or Nan for the masked grid cells when the grid is generated in Delft3D, while all the unmasked cells have normal values. So there is no way I can calculate the rest of the variables like dmde/dndx.

My question is whether this is a potential reason that results the blow up of the model?

If so, has anybody run into the same issue and got an advice on how to handle the masked cells?

Or does anyone know is there any kind of requirement from ROMS for the variables of the grid file?

Thanks ahead.

[wilkin]

Yes, that's a problem. ROMS computes on all cells and then applies the masks. So, NaN values just inside the coastline can propagate into the interior. Zero values of, say, depth (but also other grid metrics) can cause divide-by-zero.

Just fill the land with modest finite values and the masks should make things OK. ROMS does not actually use lon/lat while running unless you are using the regrid option for surface forcing.

[soilinkin]

Yes, that's a problem. ROMS computes on all cells and then applies the masks. So, NaN values just inside the coastline can propagate into the interior. Zero values of, say, depth (but also other grid metrics) can cause divide-by-zero.

Just fill the land with modest finite values and the masks should make things OK. ROMS does not actually use lon/lat while running unless you are using the regrid option for surface forcing.

Thanks a lot. But I am also seeing in the log file that spacing in x/y direction are calculated based on x_rho/y_rho (and also for psi and u/v points). Will this affect model runs in any way? By having -999 as coordinates will results in crazy spacing stats. I assume ROMS will still need X/Y coordinates (maybe not lon/lat?), at least for unmasked grid cells. Does assigning random values (-999, Nan or 0) for X/Y coordinates of masked cells also make a problem?

[wilkin]

The min/max grid spacings reported in the log ... e.g.

Code: Select all

 Metrics information for Grid 01:
 ===============================

 Minimum X-grid spacing, DXmin =  2.14507269E-01 km    Water points =  2.30213420E-01 km
 Maximum X-grid spacing, DXmax =  2.20401588E+00 km    Water points =  1.53947491E+00 km

are calculated from the grid Lamé coordinates (pm, pn), not x_rho etc. The values of pn,pn definitely have to be finite because metrics.F computes their reciprocal.

Don't use zeros or NaNs. Just fill the masked areas of all grid metrics (h, pn, pn, dmde, etc.) with finite positive values.

[wilkin]

Here for example is what NOAA NOS did to pad out cells in the land for their Chesapeake Bay CBOFS grid, which was computed with Delft tools.

This shows "dy" grid spacing (1/pn) plotted in the grid i,j coordinates, because the filled bogus lon/lats in the land mess up my plotting routines (if lon_rho,lat_rho are not defined in the mask, Matlab pcolor can't correctly color the cells along the coast). But this is of no consequence to ROMS, because ROMS doesn't use the lon/lat (except, as I said, you are regridding meteorology inputs)

[soilinkin]

Here for example is what NOAA NOS did to pad out cells in the land for their Chesapeake Bay CBOFS grid, which was computed with Delft tools.

This shows "dy" grid spacing (1/pn) plotted in the grid i,j coordinates, because the filled bogus lon/lats in the land mess up my plotting routines (if lon_rho,lat_rho are not defined in the mask, Matlab pcolor can't correctly color the cells along the coast). But this is of no consequence to ROMS, because ROMS doesn't use the lon/lat (except, as I said, you are regridding meteorology inputs)

cbofs_dy_ijcoords.png

Appreciate it. That definitely helps a lot. I will give it a try.