Contact:  Samar Khatiwala
Reviewers:  Rick Slater ,  Stephen M. Griffies ,  Jennifer Simeon
Change History: WebCVS Log

Transport Matrix Method, for use in finding an approximate steady state of tracers.

Ported to MOM4p0d by Samar Khatiwala spk@ldeo.columbia.edu June-July 2007

Ported to MOM4p1 by Stephen.Griffies@noaa.gov July 2007

Some code clean-up; increased conformity to tracer module standard jes.13JUN08

further code cleanup by Richard.Slater@noaa.gov Jan2009.

**Preliminary testing only.

This module saves out the components of the explicit and implicit transport matrix. spk uses the output from the transport matrix module to assemble the actual transport matrix with his matlab code.

In conjunction with the Newton-Krylov (NK) solver, the transport matrix is used to do an accelerated forward model in an iterative manner which allows the NK solver to reach solution convergence with greater efficiency.

To create the transport matrix building blocks, passive, prognostic "tracers" are simulated. These "tracers" are, in practice, dye tracers initialized to 1 at one or more grid points and initialized to 0 elsewhere. Since the "area of influence" of a tracer at a particular grid point is determined by the advection scheme, it becomes more practical to introduce a number of dye tracers at other grid points, such that the "tracers" are staggered and will have non-overlapping areas of influence. These non-overlapping regions are called by spk, "tiles". The total number of dye tracers needed is independent of the horizontal grid resolution, but rather dependent upon the advection scheme's area of influence, i.e. the total number of grid points contained in a "tile". For a simple linear advection scheme, the number of tracers needed is about 10 x (number of vertical levels). spk has some special matlab code that generates the initial condition for the "tracers", given the grid_spec of the model.

The behavior of the tracers' advection and diffusion is averaged over time (which the user may specify) and is saved out as a component of the later-to-be-assembled transport matrix.

To run the transport_matrix module, an initial condition must be created by spk.

Include the transport_matrix field_table and diag_table entries for the xml. Examples of these follow.

Sample field table. ------------------------------------------------- "tracer_packages","ocean_mod","transport_matrix"

names = '01', '02', '03' horizontal-advection-scheme = mdfl_sweby vertical-advection-scheme = mdfl_sweby /

--------------------------------------------------

Sample diag table entry: enter as many "tracers" as you need with the naming convention exp_tm_# and imp_tm_# where # is a string as given abaove in "names" -------------------------------------------------- "transport_matrix","exp_tm_01", "exp_tm_01" ,"ocean_transport_matrix","all",.false.,"none",1 "transport_matrix","imp_tm_01", "imp_tm_01" ,"ocean_transport_matrix","all",.false.,"none",1 "transport_matrix","exp_tm_02", "exp_tm_02" ,"ocean_transport_matrix","all",.false.,"none",1 "transport_matrix","imp_tm_02", "imp_tm_02" ,"ocean_transport_matrix","all",.false.,"none",1 "transport_matrix","exp_tm_03", "exp_tm_03" ,"ocean_transport_matrix","all",.false.,"none",1 "transport_matrix","imp_tm_03", "imp_tm_03" ,"ocean_transport_matrix","all",.false.,"none",1 --------------------------------------------------

SPK NOTES: 1) The calling sequence is as follows: Top level driver (e.g., ocean_solo) -> S/R ocean_model_init(Ocean, Time_init, Time_in, Time_step_ocean, ensemble_ocean) Time%init = Time_in .eq. Time_init Time%Time_init = Time_init Time%Time_step = Time_step_ocean Time%model_time = Time_in Time%itt = 0 -> S/R ocean_prog_tracer_init -> S/R ocean_tpm_init -> S/R transport_matrix_init -> S/R ocean_tpm_start -> S/R transport_matrix_start Start time stepping loop do nc=1, num_cpld_calls do no=1, num_ocean_calls ocean_seg_start = ( no .eq. 1 ) ocean_seg_end = ( no .eq. num_ocean_calls ) -> S/R update_ocean_model(Ice_ocean_boundary, Ocean_sfc, & ocean_seg_start, ocean_seg_end, num_ocean_calls) Time%model_time = Time%model_time + Time%Time_step Time%itt = Time%itt+1 -> S/R ocean_tracer, S/R update_ocean_tracer do explicit transport -> S/R transport_matrix_store_explicit (accumulate explicit matrix and reset tracer field to initial condition) do implicit transport -> S/R ocean_tpm_tracer -> S/R transport_matrix_store_implicit (accumulate implicit matrix and reset tracer field to initial condition) -> S/R transport_matrix_write(.FALSE.) (time average and write matrices) Time = Time + Time_step_ocean enddo enddo -> S/R ocean_model_end -> S/R ocean_tpm_end -> S/R transport_matrix_end -> S/R transport_matrix_write(.TRUE.) (time average and write matrices for multi year runs)

2) Time counters are incremented BEFORE calling S/R update_ocean_tracer, so the first time transport_matrix_store_explicit is called, itt (and hence myIter) will be 1. The namelist parameter matrixStoreStartIter indicating the iteration number to begin accumulating matrices at should be RELATIVE to the current model run start (unlike in the MIT GCM where it refers to an absolute counter. I am not entirely certain this is handled correctly below. Things might be off by 1 time step.

 field_manager_mod
           mpp_mod
  diag_manager_mod
ocean_tpm_util_mod
   ocean_types_mod

transport_matrix_init:

transport_matrix_start:

transport_matrix_store_explicit:

transport_matrix_store_implicit:

None.

None.

None.

1. Khatiwala, S., M. Visbeck, M.A. Cane, 2005. Accelerated simulation of passive tracers in ocean circulation models. Ocean Modelling, 9, 51-69.

None.

None.

None.

None.

None.

None.

None.

top