Why are my boundaries flipped in my model?

[JDTilley]

I have been working on a model, but the output shows that my boundaries are swapped (north is south, east is west, etc). I have been unable to figure out what the root of the problem is whether it be a misspecified grid, a bad setting, something installed incorrectly, etc. If you look at my input files (temperature in the images), everything looks ok to me.

grid:

grid.png (41.36 KiB) Viewed 9530 times

climatology:

climatology.png (119.62 KiB) Viewed 9530 times

southern boundary (vertical cross-section):

s_boundary.png (42.1 KiB) Viewed 9530 times

ocean_his.nc (temperature):

ocean_his.png (65.81 KiB) Viewed 9530 times

Notice the water in the output image along the northern and western borders. I have latitude and longitude ascending in all my input files from an ncdump. Additionally, looking at the directional tracer variables (e.g 'temp_south'), the boundary information is correct. Everything in varinfo.dat looks as it should for the boundary variables. Does the order that the variables are in your boundary file matter? It seems if the data is associated with the correct variable name, things should work ok. I'm really at my wit's end, and I was hoping to include an example model in an upcoming presentation in three weeks. Is there a setting somewhere that I am missing that could cause this? I'm sure whatever mistake I have made is an obvious one, but I understand that having someone else figure out exactly what I did might not be so easy. Does anyone know why my boundaries are backward?

[JDTilley]

I guess what would be really helpful to know is whether it is possible that something in my netcdf configuration, build.bash, ocean.in, or my header file would cause this. Or is it something wrong in my grid, clim, bry, or ini file?

[kate]

If I knew, I'd tell you. You didn't set it to be doubly periodic, did you?

[JDTilley]

I'm not sure. That was not my intention, but it is possible something is set that shouldn't be since I used ocean_upwelling.in as a starting point to making my input file. How would I go about checking if my model is doubly periodic?

[kate]

It's in the ocean.in LBC variable. UPWELLING is periodic in the east-west direction, closed north and south:

Code: Select all

   LBC(isFsur) ==   Per     Clo     Per     Clo         ! free-surface
   LBC(isUbar) ==   Per     Clo     Per     Clo         ! 2D U-momentum
   LBC(isVbar) ==   Per     Clo     Per     Clo         ! 2D V-momentum

Here's an example with all four edges open:

Code: Select all

   LBC(isFsur) ==   Che     Che     Che     Che         ! free-surface
   LBC(isUbar) ==   Shc     Shc     Shc     Shc         ! 2D U-momentum
   LBC(isVbar) ==   Shc     Shc     Shc     Shc         ! 2D V-momentum
   LBC(isUvel) ==   RadNud  RadNud  RadNud  RadNud      ! 3D U-momentum
   LBC(isVvel) ==   RadNud  RadNud  RadNud  RadNud      ! 3D V-momentum
   LBC(isMtke) ==   Clo     Clo     Clo     Clo         ! mixing TKE

   LBC(isTvar) ==   RadNud  RadNud  RadNud  RadNud \    ! temperature
                    RadNud  RadNud  RadNud  RadNud      ! salinity

[JDTilley]

OK. I have this:

Code: Select all

   LBC(isFsur) ==   Che     Che     Che     Che         ! free-surface
   LBC(isUbar) ==   Shc     Shc     Shc     Shc         ! 2D U-momentum
   LBC(isVbar) ==   Shc     Shc     Shc     Shc         ! 2D V-momentum
   LBC(isUvel) ==   RadNud  RadNud  RadNud  RadNud      ! 3D U-momentum
   LBC(isVvel) ==   RadNud  RadNud  RadNud  RadNud      ! 3D V-momentum
   LBC(isMtke) ==   Per     Per     Per     Per         ! mixing TKE

   LBC(isTvar) ==   RadNud  RadNud  RadNud  RadNud \    ! temperature
                    RadNud  RadNud  RadNud  RadNud      ! salinity

Mine doesn't look like either of your examples. Have I done something terribly wrong?

[kate]

I'd change your Mixing TKE from Per to Clo, but I doubt that's the problem.

It's not some ancient ROMS code with PERIODIC_EW defined?

[JDTilley]

I'll give it a shot. It's not ancient code. I even created a new folder with the ROMS source pulled fresh with svn and the problem remains. My best guesses so far are problems in the code I wrote to create my climatology or possibly the way SeaPy handles importing grids from netcdf. In SeaPy, flipping the sign for depth_rho will flip the data. So if using depth is the convention for finding grid orientation, it's possible I made a mistake somewhere with my depths. Still, I've looked real hard at my input files, and haven't seen anything that points to that being the issue. I appreciate your help.

EDIT: so far a model blowup, I will update if I have any success

[JDTilley]

Something that may help me would be a better understanding of sigma coordinates and array index order in the netcdf files. I'm noticing that in my climatology that the surface is at the 0 index and the bottom is at the highest index. However, if I check my grid, I see that s_w[0] is -1 and 0 at the highest index. Yet I see s_rho:positive = "up" in my boundary header info. I also find that s_rho is not in my varinfo.dat, so I assume that ROMS has no way of knowing up from down and assumes you have the data ordered properly. This seems like a potential cause for my latest blowup, which is reporting nans on the first iteration. Should my variables be at index 0 at the surface or is the other way around? I imagine this should stay consistent for all my input files, but please correct me if I'm wrong.

[kate]

It sounds like your vertical coordinate is upside down. The i,j,k coordinates are in a right-handed system with the origin at the bottom of the SW corner. Whatever direction i goes in, that's "east", j goes "north" and k goes up. There are plenty of models with k going the wrong way.

[JDTilley]

They were indeed upside down, and I'm happy to report I worked past my boundary issue! Turns out I had some nans in ubar and vbar that I had carelessly not dealt with. Once I fixed those the model would run with TKE mixing boundary conditions set to closed. The model still looks like it could use some help, but its much better than anything I've made so far. August 15 – September 15, 2015. Thank you so much for your help!

ms_sound_3d_model_surface.gif (8.87 MiB) Viewed 9451 times