A question about the gridgen

[hbzong]

The output of gridgen contains 'nan' values when using gridgen to generate grid for the domain shown below. How to deal with these 'nan' value?

[jpringle]

I don't know if this is the issue, but when I was testing Pavel's gridgen, it occasionally threw up nan's if my domain was perfectly rectangular, but if I moved one of the corners by even an infinitesimal amount, the nan's went away. This was a flakey problem, that only occured for certain resolutions, but not for slightly different resolutions. I never dug into it, or complained to Pavel about it. I doubt it is your problem with you more complex domain, but just to see, try changing the position of your corner by a few meters.

I really ought to have documented the bug, and sent it to Pavel.

On another note, your grid is not going to be very orthogonal with those sharp corners (effectively capes in your domain). Unless you have the gridpoints in the vicinity of the capes masked as land, ROMS is unlikely to be accurate at those points.

Cheers
Jamie

[sak007]

The output of gridgen contains 'nan' values when using gridgen to generate grid for the domain shown below. How to deal with these 'nan' value?

Hi,

The question regarding NaNs in the output arises periodically. I will try to give a quick overview of what that means and what are the implications.

1. Typically, a multi-corner grid is a union of rectangles. The edges of these rectangles are oriented along I and J axis in the grid space. To store the grid, it is embedded into an outer rectangle, say 0 < i < IMAX, 0 < j < JMAX (or 1 <= i <= IMAX; 1 <= j <= JMAX, in the Fortran context). This embedding rectangle, or extent, contains nodes in (i,j) space that are outside the grid boundary. Such nodes do not have physical coordinates and appear in the output of gridgen as NaNs.

2. What to do with these NaNs. This depends on the context in which the grid is used. For example, if one needs to convert between grid and physical space, the mapping code has to be designed to handle multi-corner grids. In CSIRO's in-house model SHOC (former MECO) XY <-> IJ mapping code can handle multi-corner grids. The C code used is similar to the code in the grudutils library available at my home page.

My understanding is that ROMS does no perform XY <-> IJ conversions; all grid coordinates of interest are specified explicitely at the model setup. If so, one can use e.g. utilities from gridutils package to find grid coordinates of point sources etc.

How to make a model run on a multi-corner grid may be a different issue, as the model may require a number of metrics and be able to run without propagating NaNs from the boundary. I guess people who have run ROMS on multi-corner grids generated by gridgen may be able to share the know-how.

Hope this helps
Pavel

[hetland]

You need to specify values for everything where there is a NaN. Gridgen simply does not define the grid here, and they are not water points, so you just need to fill them in with values that do no harm.

First, you need to set your mask to include the NaNs (and possibly other points if you have a more detailed coastline than the edge of your grid.

Second, if you do not use horizontal mixing, you can just set h, pm, pn dnde and dmdx to the minimum values (for the first three) or zero. I have never been sure if these values don't bleed into the solution, though.

Does anybody have any comments on how values of pn and pm (or dmde and dndx) over masked points affect the solution?

An even more thorough solution is to extrapolate all of the values to the empty (NaN) grid points, making sure to keep the values within the ranges of the water cells. This does not need to be done in physical space -- you can just do it in grid space. My pyroms utility does all this (http://pyroms.googlecode.com) with the gridgen function and Grid class.

I'm not sure how Jamie's tool deals with empty cells.

-Rob

[jpringle]

As evidenced by my silly answer above, I had not run into this problem with the simple domains of my application, so I had not ever worried how to solve this problem. I have thus never implemented a solution. When I have to, I will, but if someone beats me to it, I would be happy to incorporate their solution.

Otherwise, when I run into this problem, I will bug Rob.

Jamie

[kate]

In the long run, we hope that ROMS will be able to handle such a grid as multiple patches, removing the need to mask out and compute all those non-water parts. We would then need a tool to take the output from Pavel's program and convert it into Ngrid smaller grids. But that's for another day.

[hetland]

Running a number of separate appendage grids may have advantages in some particular cases -- in particular, a long estuary attached to a coastal sea.

However, in the long run, I would rather see ROMS do something more like GETM. GETM allows you to ignore tiles that are completely land. Presently, ROMS needs to run all of the tiles all of the time. Which means that if you have the long estuary attached to a coastal sea, many of your tiles are simply wasting CPU time. It would be nice to be able to turn these tiles off.

I think that this would be a simpler solution that would also be more generally useful.

[hbzong]

Thanks everyone.
Rob, how did you extrapolate the values to the empty grid points. I read your pyroms code. Because I'm not familiar with python, I did found how you do it. I used the MATLAB griddata function, but the result doesn't seem good.