December 15, 2012 (mlevy)

I don't know the best place to put these questions, but they fall under Requirements and Design so this is as good as any other. While working on the code (both the stand-alone aspect and integrating it in POP), I've had some design questions come to mind. These are all fairly trivial in the sense that the code will work whether we decide on answers or not, but it would probably be good to agree on coding standards anyway...

  1. Do we want to have a max line length? I like 78 characters because they don't wrap when I use enscript with two columns, but a few lines are 79 or 80-ish.
    1. If we do want a max line limit, should it be enforced at compile time?
    2. On a related aesthetic note, when continuing a line with an '&' should the ampersands all be in the same (78th?) column?
  2. We are at a point where all three standalone drivers can compile on a variety of compilers (GNU, IBM, Intel, nag, and PGI) without warnings. Should I incorporate a "warnings -> errors" flag to avoid warnings from creeping back in?
  3. I've been using the protex toolkit to create a PDF documenting the code. The default implementation is to provide a brief description of each module, including a list of all variables, datatypes, and functions / subroutines contained in the module (and a description plus list of intents-in and intents-out of each of these). I recently figured out how to include the full code in the PDF as well - would this be a useful feature in the documentation? It roughly doubles the length of the file (currently 24 pages without code or 49 pages with).
  4. Currently, all the files / data structures / variables are named vmix_*. Should this be changed to cvmix_*? I know it's trivial, but the sooner it gets done the less we'll need to change.
  5. Does anyone have any ideas on how to better organize the wiki? It would be nice to have some structure to how the pages are grouped, but I don't have a clear idea on how to do that.

August 14, 2012 (mlevy)

Formatting change: each topic will be its own child page broken into three sections - Requirements, Design Solutions, and Implementation. I have numbered each page so we have an idea of the order that these topics were added.

August 9, 2012 (mlevy)

I think this page is long over-due, let's start to make design decisions (or at least discuss them) in writing. The tone of this document is not "these are the decisions I have made," but rather "this is the direction I see the code going."

Summary

CVMix will be a time-independent library for computing vertical mixing diffusivity and viscosity coefficients on a single column of fluid. It will provide modules for background mixing, shear mixing, tidal mixing, double diffusion mixing, KPP mixing, and convective mixing. The goal is to provide a package that can be shared by MOM, POP, MPAS-O, and any other ocean model that is interested, as well as a stand-alone driver for testing each module.

  • No labels