First of all, we are only going to re-factor the computation of vertical mixing coefficients -- calculating the tendencies will be left to the dynamics package. The goal with this decision is to have a completely time-independent package handling the mixing.

Secondly, since this package should be handling all the vertical mixing, we'll include several different options. For simplicity's sake, we'll start with constant mixing before moving to tidal, Richardson, and KPP.

Additionally, we will create vmix_diags_input_type and vmix_diags_output_type to give users the option of passing diagnostics between the physics package and the ocean module. I think we'll need to see what the package actually looks like before we start talking about specifics for the diagnostics, but it's important to note that we will be including these options.

Lastly, we talked about what basic coding decisions. The users will need to know:

  1. Units will be meters / kilograms / seconds
  2. z will be positive-up while k will be positive-down, and depth = -z.

There is also a pretty long list of what we consider "good" software engineering practices:

  1. Comments will be clear / concise, and we'll use protex to allow for latex comments directly in the code.
  2. Variables names will be descriptive, and we'll format variable names in a consistent manner -- MOM uses Single_cap for derived types and all_lowercase for everything else; we will use something like that rather than ALL_CAPS
  3. Everything brought in via a use command will be explicitly specified with "use, only:"
  4. We will loop through all array indices (putting a(i)=b(i)+c(i) in a do-loop rather than a(:) = b(:) + c(:)) and avoid using "where" statements.

At Breckenridge, several ideas came up that I wanted to address.

Todd Ringler asked for a brief document outlining inputs and outputs for the module. What Steve and I have talked about doing is creating two data types: vmix_input_type and vmix_output_type. Both of these would contain a column of data, so variables would be declared

type(vmix_input_type),  allocatable :: vmix_inputs(:)
type(vmix_output_type), allocatable :: vmix_outputs(:)

where the unknown dimension is a single index for the x-y plane (1:ncol or something). It seems over-ambition to produce a complete listing of each type before actually starting to separate files, but the basic gist would be

type, public :: vmix_input_type
        Vertical coordinate information
        Density information
        Velocity information
        Indication of what type of vertical mixing to use
        Namelist variables associated with that mixing
        A handful of parameters (Richardson number, etc etc)
end type vmix_input_type

type, public :: vmix_output_type
        Tracer diffusivity
        Momentum viscosity
end type vmix_output_type

In the time-stepping loop, the code would look something like this (and there'd be a similar initialization call):

! User responsible for packing data into vmix_inputs(:)
call calc_vmix_coeff(vmix_inputs, vmix_outputs)
! User responsible for unpacking data from vmix_outputs(:)

I imagine we might decide to loop over ncol outside the calc_vmix_coeff routine and only pass it a single input / output type rather than an array.

Todd also asked about making the code available, along with some documentation. To start, I'm just going to work out of a branch of NCAR's POP repository (I still need to create it, but I'm also bringing in some source changes from another project and am just waiting for that to be ready). Once we have something that is ready for more testing, I'll look into moving to sourceforge or googlecode or something similar. For the documentation, I tried to start a latex document with notes twice but somehow ended up with this email instead. At the moment, I'm hoping the protex comments in the code itself will lead to a useful document, but if that doesn't work out I'll start a separate document.

  • No labels