Periodic boundary overlap in input grid

[k.alexander]

Apologies if the answer to this is obvious somewhere. A quick search on this forum, the wiki, and a browse through the source code didn't yield any obvious answers...

I have a periodic boundary (east-west) and as Kate points out, the sea ice coupling I am using (MetROMS) may not support this properly. So I am carefully unpicking all of that.

The first step is to confirm that my ROMS grid file treats the periodic boundary correctly, and I'm not sure that it does. This is a grid file that someone else made (and it's passed through so many hands I'm not even quite sure who), and until now I have just trusted their Matlab code when I remake the grid with eg. extra smoothing.

In this grid, the x, y, lat, lon fields show an overlap of 3 points at the periodic boundary - i.e. the first 3 columns are identical to the last 3. Is it just me, or is this weird? Why should there be so much overlap if ghost points etc. are taken care of at run time (and the value of NghostPoints depends on other things such as mixing parameterisations?)

This grid is quarter-degree, and 360*4 = 1440. But Lm=1441, meaning there are 1443 rho-points in the x direction. I am wondering if these values should be 1440 and 1442, or even 1439 and 1441, with just one cell overlap in the input grid.

Many thanks, and sorry again if I am missing something obvious!

[kate]

You should have Lm=1440. Once long ago there was a model which needed an extra point for periodic boundary conditions - hence the value of Lm=41 instead of 40 for the UPWELLING problem. That model has gone away and ROMS has not needed that extra point for a good many years now.

[k.alexander]

Ok that makes sense. I will regenerate that grid. Do you happen to know how CICE handles the periodic boundary conditions? I assume from your previous emails that it doesn't want any overlap cells, i.e. it should be 1440 cells in the x-direction for both the CICE t-grid and u-grid.

Dealing with this in the coupler will be a bit finicky but I will sort it out and send you the MetROMS updates when I am finished (hopefully next week sometime? I have a bunch of things on this week....)

[k.alexander]

PS Thank you for spotting this. It's interesting (and a bit dangerous) how geometric errors like this can still compile and run just fine.

[kate]

Every t-point you give CICE is a computational point, so yes, there should be 1440 of them. Same for the u-points.