esmg / pycnal_legacy Goto Github PK

Before changing any functionality, make sure it's tested

I just want to start a conversation about how this will go. Split out bathy_smoother and the toolbox(es) as their own repos? Leave the examples here? If the pycnal code becomes its own thing, is pycnal/PyCNAL going to be a problem?

@braney, would you like to do the conversion since you have a branch? I wouldn't want to mess you up.

/u1/uaf/kshedstrom/python/lib/python3.5/site-packages/pycnal_toolbox/BGrid_GFDL/flood.py:106: VisibleDeprecationWarning: using a non-integer number instead of an integer will result in an error in the future
  varz[bottom[j,i]:,j,i] = varz[bottom[j,i],j,i]

i and j come from the range function. Is there a better way?

I installed it on my mac with

conda create -n pycnal numpy scipy matplotlib basemap netcdf4 ipython
conda install -c conda-forge netcdf-fortran
git clone https://github.com/ESMG/PyCNAL_legacy.git
cd PyCNAL_legacy

Then followed most of the directions on the https://github.com/ESMG/PyCNAL_legacy page, but then needed these lines in my extern/scrip/source/makefile:

...
NC_CONFIG = nc-config
LIBDIR = $(shell $(NC_CONFIG) --prefix)/lib
INCDIR = $(shell $(NC_CONFIG) --prefix)/include
SRCDIR  = .
PREFIX  = /usr/local

COMPILE = gfortran
FLAGS = -g -fdefault-real-8 -ffixed-form -O2 -fPIC
LIB  =  $(shell $(NC_CONFIG) --flibs)
LIB  =  -L${LIBDIR} -lnetcdff -lnetcdf

The extra hard-coded flags on the main page do not apply to Mac OSX.

I've not tested it yet, but the thing seemed to compile OK.

Make Arctic domains a little more efficient through only using northern latitudes.

I've got a grid file in /Volumes/R1/ROMS/Arctic4 on alnilam.

The thing counts on the python 2 behavior for integer division. I threw in some int() around things and it still fails with:

File "/u1/uaf/kshedstrom/python/lib/python3.5/site-packages/pycnal_toolbox/jday2date.py", line 46, in jday2date
date.append(datetime(Y,M,D,h,m,s))
ValueError: day is out of range for month

Looking at the output, it never goes to day 31 of the relevant months. It died on June 30.

Replace SCRIP

The Bering example is supposed to show how to remap from ROMS to ROMS when the grids are aligned. This is from Ken Coyle who was trying it out:

could not get the make_weight_files.py program to accept irange and jrange values so I just ran it for the whole grid. Apparently, it does not appear to recognize those arguments. It seems to make the remap_weights_NEP5_to_CGOA...nc files OK without the ranges.
However, I did run into an issue when running the remapping_bound program. I was using the argument rotate_uv = False and ran into a problem because the if the rotate_uv is false, the code skips the part where dst_u and dst_v are defined (lines 423-423, 434-435, 443-444, 449-450) because they are in the if loop (if rotate_uv is True:, lines 239-457). There is no "else" option to define dst_v and dst_u when rotate_uv is False. Therefore, when it tries to define dst_ubar and dst_vbar, it returns and error message because it cannot get the dimensions for the arrays (lines 485-486):
dst_ubar = np.zeros((dst_u.shape[1], dst_u.shape[2]))
dst_vbar = np.zeros((dst_v.shape[1], dst_v.shape[2]))
So I have to either set rotate_uv = True, or come up with an alternative method to compute dst_u and dst_v. Do you have a suggestion? Should the u and v values be rotated when using the NEP5 average files to compute the boundaries for the CGOA grid?

I told him to rotate for now...

The examples/Beaufort files use u_eastward, v_northward for the source velocities because there's a bug in the rotation from u, v. I added the rotate_part option as a work-around.

I just want to get in writing somewhere a brief interaction from yesterday's meeting so we're all on the same page.

• In ROMS, the grid file has the computational domain plus one extra rho point all around.
• In MOM6, the land mask file has only the computational domain, no extra points.
• In MOM6, to determine the open boundary points around the edge, it would be convenient to use an exterior rho mask point. We therefore create the convention that the open boundary is one grid in from where it is in the ROMS grid.
• Alternately, we tell MOM6 that the computational grid is two grids bigger (one on each side) so that the boundary can be at the same place.
• Either way, MOM6 wants boundary tracer values at the corresponding u or v point along the edge of the grid.

Could you edit README.md to point towards the canonical projects this supercedes and may be superceded by? (if it is ready to supercede them yet?)

It is difficult to follow all the ROMS grid generation projects from easygrid, seagrid, pyroms, Octant, pyroms, PyCNAL_legacy, and maybe PyCNAL. If the ones in current development pointed at each other, it might help folks figure out which ones to try and how to use them best.

• https://www.myroms.org/wiki/easygrid
• https://www.myroms.org/wiki/seagrid https://github.com/sea-mat/seagrid
• https://github.com/hetland/octant
• https://github.com/ESMG/pyroms
• https://github.com/hetland/pygridgen
• https://phobson.github.io/pygridgen/ -- more developed fork
• http://austides.com/downloads/ -- GridBuilder
• https://github.com/ESMG/PyCNAL_legacy
• https://github.com/ESMG/PyCNAL

I started on the road to generate a grid for the supercritical problem via gridgen when I remembered:

• In Seagrid, the boundary you provide ends up going through the first round of halo T-points, not the edge of the computational domain.
• In pyroms gridgen, the boundary you provide ends up going through the first round of halo q-points, even farther from the computational domain.

Since this is being revisited, can I please (please???) have a tool in which the boundary I provide goes along the edge of the computational domain? Anything needed outside can be generated by extrapolating.

There's a flood_fast in pyroms_toolbox.Grid_HYCOM. There's also a flood in pyroms.remapping. It would be nice to have the faster flooding in a more generic place than Grid_HYCOM. There's nothing specific to HYCOM about it is there?

I created a flood2d for 2-D fields needing flooding - is there a better way to do it?

Let's build a wiki here on github of PyCNAL documentation.

From the pycnal_toolbox build, I get several of these:

/home/kate/anaconda3/lib/python3.5/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
#warning "Using deprecated NumPy API, disable it by "
^~~~~~~

Rename "pyroms" to "PyCNAL" everywhere within filenames, code, and documentation.