Nitty-gritty Issues

Rotated Domain

1. Check velocities. Do we write true zonal/meridional velocities or those aligned with grid? This has implications for assimilation and verification.

Double Sigma

1. Consider redesigning the double sigma system to reduce "kinks" in the model levels.
   • Old paradigm was two flat interfaces over shelf & deep water, smoothly joined. This fails for 2 reasons
     1. In practice, the upper flat level was being forced much above sea-level to get smooth levels.
     2. Once we started "going ashore", the only possible shelf flat surface was being pushed to the surface.
   • New paradigm is a flat interface over deep water, a "sigma" interface over the shallower regions with a smooth joining. The proposed family of interface curves is: f(x,y) = z_const + ½{h_fn(x,y) + [ h_fn²ⁿ(x,y) + (2 f_off)²ⁿ ]^1/(2n)} where h_fn(x,y) = sig_fn[h(x,y)]*h(x,y) - z_const, sig_fn[h(x,y)] = { [h(x,y)-h_rfsh]*sig_dp + [h_rfdp-h(x,y)]*sig_sh } / (h_rfdp-h_rfsh)
     • z_const is the depth (m) of the flat interface over deep topography
     • h_rfdp is the deep reference depth (m) where the interface switches from "sigma" to flat
     • f_off is the vertical offset (m) of the curve from the sharp join.
     • n is the "order" of the interface
     • sig_sh is the desired "sigma" value of the interface over shallow water.
     • h_rfsh is the shallow reference depth (m) at which sig_fn[h(x,y)] = sig_sh
     • sig_dp = z_const/h_rfdp
     
2. An alternative approach (inspired by comment from HGA). One of the proposed updates in GRIDS is to remove all knowledge of the definition of the vertical grids from PE_initial and PE. This would just require the passing of 3D thickness fields. In this regime, it would be easy to introduce new paradigms for the vertical levels. One such:
   1. Abandon an analytic formulation. Define each column "independently"
   2. Set limits for the thicknesses of each level (or selected ones)
   3. Use even spacing over regions shallow enough that the constraints are trivially satisfied.
   4. Freeze the levels that reach their constraints. Impose a rule for distributing the remaining levels.
   5. Example:
      • 20 vertical levels. First 7 can be no more than 1 meter thick. Impose even sigma spacing below. Result: 20 evenly spaced levels over topography 20m or less. 7 flat levels over 13 evenly spaced sigma levels over deeper topography.
      • 20 vertical levels. First level can be no more than 2 meter thick. Geometric spacing (with bottom folding) below. Result: 20 evenly spaced levels over topography 40m or less. Over each remaining grid point, the polynomial problem is solved to obtain the lower 19 levels.

More General Domain

1. Look into bringing unstructured grids into HOPS. Consider the following example.

netCDF issues

1. make sure all netCDF files and units follow some standard convention
   • Some other thoughts
2. convert to netCDF 3.3, it supposedly has faster access than netCDF 2.x
3. look through the routines in the mexCDF directories (mods,distribution). Identify those pieces involved in getcdf. Extract them for the distribution, include them in the toolbox.

GNUmake issues

1. The directory paths (especially BINDIR) must be free of extraneous blanks. Look into stripping.

Bring the "system" up to date

1. simplify tracking of compatible components
2. Kill the hexadecimal format. Not only is it not generally supported, but the z descriptor is non-standard FORTRAN.
3. Consider moving all codes to V-grid based horizontal grid. (why?)
4. bring all components (FM, EVA, QG) we claim in system, fully in system
5. establish tests and make them part of distribution
6. make various operational tools part of release
   • Wayne's cast plotting
   • Larry's 1D bio-model
   • cat_nctime (unless netCDF new tools can replace this)
   • peout2in (needs to be able to handle more tracers)
   • fakenest (needs to be able to handle more tracers)
   • sample.m
     • needs to be in MATLAB form until another GUI can be found
     • needs to have shifted grids enabled
     • allow reading/writing of turning point data files. Use "none" as signal to not read/write. Choose format that is easily handed to ship's pilot.
     • MATLAB 5: work on color scheme. (messages, modify-markers)
     • MATLAB 4: when hitting Done or Abort, the current method (Modify, Add or Remove) is applied once more.
7. Consider "unifying" input file format style. PE/QG style makes it easier to "functionally group" parameters.

Improve interaction

1. probably want some kind of web page,
   • Use as an adjunct to E-mailings of updates
   • Point to these pages.
   • Point to references.
2. finally create documentation
   • Might also want a readme for HOPS as a whole.
3. emphasize, and keep current, address for questions
4. set up some kind of "electronic log-book" for easy in-house status.
5. set some standards for upgrades. One set of thoughts on this.

FORTRAN

1. make sure all code conforms to FORTRAN 77
2. look into converting/copying to FORTRAN 95
   • Warning: FORTRAN 95 does not retain all the "obsolete" features of FORTRAN 77.

Solve shitty coding

1. Set-up minimum standards for internal documentation
   • Document all input/output variables to a routine. Including those in common blocks. (For common block, only document those actually used by the routine in question.)
   • Document all routines/functions called by a routine.
   • Document all variables in an include file.
2. get_date.F is currently unprotected from zero length strings. (i.e. know no date info)
3. lnblnk.F alters the input string. Replace with length.F.

Improve ease of tailoring

1. insert a layer of "front end" routines between programs (e.g. GRIDS) and NCAR graphics. Possible one central location used by all HOPS codes. This would facilitate change to different graphics package.
   • How does this fit in with Carlos' request for simplifying plotting via EZMAP?
2. Perhaps do same for netCDF?

Code-by-code plans

• Datamng "To Do" List
  • AddSalt "To Do" List
• GRIDS "To Do" List
  • Atlas "To Do" List
  • PE_mask "To Do" List
  • Cond_Topo "To Do" List
• OA(G) "To Do" List
• Feature Model "To Do" List
• PE_forcing "To Do" List
• PE_initial "To Do" List
• PE "To Do" List
• Plot "To Do" List