Aug 7, 2012 (mlevy)

Gokhan, Steve, and I met again, and Todd called in. Lots of things came up:

• I'll create a design document so we can all iterate on the coding criteria
• After I create a new tag, I'll attach a tarball to the wiki
  • Once the repository is moved to a vmix-specific site, rather than a branch of the POP repository, I imagine this practice will stop
• Updated timeline:
  • The next goal will still be a stand-alone driver
  • After that, I'll work on comparing the memory-copy vs pointer technique
  • After that, I'll put together an error-processing module
  • After all that, I'll move on to the next mixing module (shear? double diffusion?)
• An open question: should CVMix allow for different types of mixing on different columns? Is it something we should include?

Two administrative things:

1. We are going to meet again at 2p on Monday (Aug 13). If anyone would like to call in, let us know... if you'd like to call in but 2p is a bad time, we can try to reschedule - Monday afternoon is still the goal.
2. I'll bug CISL and get more LANL people (Mark P, Phil J) added to the wiki. I requested an account for Doug J last week and am still waiting to hear, so I'll ask about him as well.

Aug 1, 2012 (mlevy)

Gokhan, Steve, and I sat down for a progress report / update, and I realized it would be smart to let everyone else know what we talked about. Our plan is to meet once or twice a week for the last two weeks that Steve is visiting, and then turn the meetings into a weekly telecon once Steve is back in Princeton.

My goal for this meeting was to develop a roadmap for the next month or two. We decided that my focus should be on the following (in this order):

1. Finish working on the vmix_background module
   1. Right now it can only handle a constant background field, it needs to be robust enough to handle fields that vary in depth, lat-lon, or both.
      1. Support reading in a file containing diffusivities (well, the file would be read by the module and then passed to vmix).
      2. Support Bryan-Lewis diffusivity, passing the proper parameters when requested.
   2. The in-code documentation (using protex) needs to be flushed out / cleaned up.
   3. There are still a few places in vmix_background.F90 that use POP names (km instead of nlev, for example) that I want to clean up.
2. Work on a stand-alone driver so that the package can be run without a full ocean module -- time-stepping a single column with specified forcing.
   1. Among other things, this will provide a good blueprint for how to add vmix to other packages -- everything that happens in vmix_driver needs to be done in MOM, POP, MPAS-O, etc.
   2. This might prove a little clunky until we get the vmix package in a repository of its own, but I do have a vision for how things will look once vmix is out of the POP repository.
   3. For starters, I'll try to make a very generic Makefile... the goal with the stand-alone work will be to aid in testing until the package is more flushed out
3. Move on to the next type of mixing, which will either be shear or double diffusion

Steve has been working on a PDF guide for the package. It will eventually have details on every mixing package we include, and it is also guiding us to naming conventions for files. All files will use the vmix_ prefix, and for now we are leaning towards the following module names (files will just have .F90 appended, not _mod.F90):

vmix_background
vmix_shear
vmix_tide
vmix_double-diffusion (note: I assume the '-' sign is okay in a module name, but if it isn't we'll go with vmix_doublediffusion)
vmix_kpp
vmix_convection
vmix_dissipation

The was also some talk about an "official" name for the project. Right now, we are leaning towards

Community ?Ocean Vertical Mixing (CVMIX) Parameterizations

If we stick with that, the vmix_ prefix mentioned above will be replaced with cvmix_; we intentionally avoided COVMIX because that is apparently a statistical function dealing with the "covariance matrix of the parameter estimates for a fitted mixture of linear regressions." Other suggestions would be welcomed, the earlier we come up with an acronym the less code we need to change.