Doubts about grid creation using mk_grid

[mariale33@gmail_com]

Hi!Sorry, for this topic is related to one we posted previousy but here we are trying to be more specific...We have some questions about the script mk_grid:(1) values shown in the mk_grid script (provided with the paleo-toolkit) are for an example using a gx3v5 grid. For some input variables, specifically nx, nz, dyeq, dsig and jcon it is recommended not to change the proposed values unless for a good reason. My question is mostly about the variables referring to the equatorial enhancement for the POP grid. Specifically, for a gx3v5 grid (or a gx3v7) grid shouldn’t dyeq (the grid box length at the equator) be equal to 0.9 instead of 0.6 as in the original script?Also, I haven’t found more information about variables dsig and jcon so I cannot evaluate if the values shown are adequate or not for our grid. Does somebody know where I can find more information about these parameters?(2) Using a gx3v5 or a gx3v7 grid, we should have a grid 100 lon x 116 lat, right? For this reason, we choose values of nlatn and nlats (number of j grid lines in each hemisphere) summing up 116 lines. However, the resulting kmt file has 117 j grid lines instead of 116. Is this difference due to an “extra” j line always created at the equator? Or, maybe, is this related to the difference between the grids formed by tracer and velocity grid points? Should we change the script in order to nlatn + nlats be equal to 115 instead of 116?(3) We have tested several different pole locations following the criteria suggested in the Technical Note (Using “CCSM3 for Paleoclimate Applications)”. We read a recommendation somewhere else saying that, if possible, we should place the poles on the same longitude. In order to have a more regular grid, wouldn’t it be better to place the poles in opposite longitudes and latitudes?(4) Also, regarding the pole location, should the values coincide with actual points from the input grid, i.e. the 0.5degree-grid or the location is independent from the grid nodes of the input grid?(5) Finally, mk_grid.csh seems to be running fine and it does provide a gridkmt.nc file with the kmt data as expected. However, other output variables such as ULON, HTN, HTE, HUS, HUW and ANGLE have problems (in most cases, all values for these variables are equal to zero). In the Technical Note it says “Other than the KMT values, all other information in the netCDF file are for viewing purposes only. Only the KMT values will be used in the POP model”. However, how does the POP model know the exact location of the bathymetry (kmt) values without these parameters? I find this confusing….I appreciate in advance any answer, to any of these questions. Thank you very much!!!Maria 

 

[nanr]

Hi Maria - I will try to answer a few of your questions here:1)  dyeq is ~0.6 degrees in the CESM default gx3v[5,7] grid, and ~0.26 degrees for gx1v6.  'dsig' and 'jcon' vary the shape of the grid.  'dsig' sets the efold scale for the Gaussian, and jcon sets the number of cells with constant grid size close to the poles.   Creating a new ocean grid is a delicate balance between placing the grid poles close to the edge of the polar land mass, without creating new land, and without creating very small grid cells near the poles that adversely affect ocean model stability.  Increasing 'jcon' helps avoid very small polar grid cells, by forcing a constant grid size on the last jcon number of grid cells.2)  The gx3vX grid should be 100x116.  The mk_grid.csh program produces an extra latitude that used to be required for kmtED.  This legacy gridrow can be ignored, and is not present in the actual binary grid.3)  Placing the pole points on the same meridion for northern and southern hemisphere may not be desirable for your land distribution. 4)  The pole locations do not need to coincide with actual input grid nodes.5)  I haven't seen this problem before.  You may have another problem with your script if you are getting zeros as output in gridkmt.ncI realize this is a very confusing and iterative process.  Let me know if you have more questions, and good luck!Nan 

 

[mariale33@gmail_com]

Thank you very much, Nan!!! I will try again taking into account all this information.

 

[mariale33@gmail_com]

Hi Nan,We have tried several different configurations and still, we keep having the same incomplete output from mk_grid….We believe the problem might be related to the ns_dipole version we are using. It seems to be running ok, but some (most) of the output variables are zeroed.The ns_dipole script (downloaded with the paleo-toolkit) has several parts commented. I wonder if somebody else has used this version as it is. Maybe some of thee comments are affecting the output.Also, we've seen there is a new version of mk_grid.csh called mk_grid_cesm.csh. (https://www2.cesm.ucar.edu/working-groups/pwg/documentation/cesm1-paleo-ug/deep-time/ocean/build-ocean-grid). Is this a renamed version of the original mk_grid or is it a modified version?. If it is different, where can we download it from?Thank you very much in advance!Maria

 

[nick]

Hi Maria I can report that I've used the ccsm3 and ccsm4 tools to get the model going in a f19g16 configuration (having problems at f09g16). I don't get zeroed out data in my kmt file. I assume you have no problems compiling ns_dipole?I've attached my mk_grid script if it helps (though as you know my settings will be a little different because of the difference in resolution).

Also pasted my Makefile for some of those fortran tools (FYI if you're using intel compilers). The only other thing I could recommend is triple checking your input .nc topo file for correct lat/lons etc.
Cheers
Nick. FC = ifort -O0 -assume byterecl -convert big_endian
INCS  = -I/apps/rhel5/graphics/x86_64/intel/12.0.084/netcdf-4.0.1/include
LIBS = -L/apps/rhel5/graphics/x86_64/intel/12.0.084/netcdf-4.0.1/lib -lnetcdf
TARGETS = ns_dipole paleotopo grid_bin2nc gridkmt_nc2bin #gridkmt_bin2nc

all: $(TARGETS)

ns_dipole : ns_dipole.f
        $(FC) -o ns_dipole ns_dipole.f $(INCS) $(LIBS)

paleotopo : paleotopo.f90
        $(FC) -o paleotopo_ibm paleotopo.f90 $(INCS) $(LIBS)

grid_bin2nc : grid_bin2nc.f90
        $(FC) -o grid_bin2nc_ibm grid_bin2nc.f90 $(INCS) $(LIBS)

gridkmt_nc2bin : gridkmt_nc2bin.f90
        $(FC) -o gridkmt_nc2bin gridkmt_nc2bin.f90 $(INCS) $(LIBS)

 

[mariale33@gmail_com]

Thank you very much, Nick!!!After months struggling with this problem we finally succeeded.Our executables seeemed to run ok, so we assumed the compilation was ok, too. However, now we've compiled again all the executables using the first line you used (FC = ifort -O0 -assume byterecl -convert big_endian), and finally, our output is complete!Do you use the same ifort arguments (-O0 -assume byterecl -convert big_endian) when compiling executables of other setup tools por deep-time paleoclimate? Thank you very much again, Maria    

 

[nick]

Great that it works. I won't pretend to be an expert on all this but I think it would be the -assume byterecl that fixed it. I only turn off optimisations (-O0) out of paranoia and I don't think -convert big_endian should be needed for files written on most machines (most in my experience are little endian), but is something the model needs. I imagine all my paleo tools include these flags as a minimum. Good luck!

 

[nanr]

Hi Nick -  Thanks for posting your makefile and mk_grid script for other people to share! In answer to Maria's question about big vs little endian flags, the only compile that cares about endianness is mk_grid since the ocean still uses binary.  All other tools read/write netcdf. 

 

[mariale33@gmail_com]

Thank you very much, Nan!