[MITgcm-support] MITgcm diagnostics for heat and salt budgets

Thu Feb 2 10:09:48 EST 2012

Chris, thank you for very helpful message.
I wish I had known about this a couple of days ago, as it would have saved me quite a few hours of head scratching!
I transfer the discussion to MITgcm_support so that it is available to the next poor soul who tries to close MITgcm heat and salt budgets offline.

A couple of comments and questions:

Your code for diagnosing the divergence terms, LATi_TAU, is it checked in on MITgcm CVS server somewhere?

I am curious.  Since the grid dimensions in your case (except for the surface level) are fixed,
and since the ADVi_TAU terms are defined at the cell edges,
can't you simply compute the divergence term as:
ADVx_TH(i,j,k) - ADVx_TH(i+1,j,k) + ...
ADVy_TH(i,j,k) - ADVy_TH(i,j+1,k) + ...
ADVr_TH(i,j,k+1) - ADVr_TH(i,j,k)

For the surface surface level, can't the divergence term be computed as:
ADVx_TH(i,j,1) - ADVx_TH(i+1,j,1) + ...
ADVy_TH(i,j,1) - ADVy_TH(i,j+1,1) + ...
ADVr_TH(i,j,2) - WTHMASS(i,j,1) * RAC(i,j)

The above seems to work, but I have only tried it on a baby, coarse-resolution configuration.
Is there something that I am missing?

Finally, do you have any experience with closing the budget when using z*, e.g.,
 select_rStar=2,
 nonlinFreeSurf=4,
 useRealFreshWaterFlux=.TRUE.,
The above offline divergence computation breaks down for z*.

Thanks

Dimitris Menemenlis

On Feb 2, 2012, at 5:14 AM, Christopher Piecuch wrote:

On 2/1/12 7:52 PM, Lee, Tong (Tony) (3248) wrote:
Hi Chris,

Hope all is well since the Denver WRCP OSC. I am following up with you about the status of the budget diagnostic output for the latest code. Dimitris is also looking into doing that with the code  that he used for assimilation, which I just realize today to be the same code being run at MIT. If that’s the case, Dimitris could just introduce your implementation.

Cheers,

Tony

From: Christopher Piecuch [mailto:cpiecuch at aer.com]
Sent: Tuesday, August 23, 2011 10:37 AM
To: Wang, Ou (3244)
Cc: Ponte, Rui; Fukumori, Ichiro (3244); Lee, Tong (Tony) (3248)
Subject: Re: ECCO v3.1 budgets

On 8/22/11 8:11 PM, Wang, Ou (3244) wrote:
Hi Chris,

I have done a one-year run with your data.diagnositcs. The result is http://ecco.jpl.nasa.gov/~owang/c62t_budget/iter0_forward_budget.tar<http://ecco.jpl.nasa.gov/%7Eowang/c62t_budget/iter0_forward_budget.tar>
The package and parameters related to surface forcing are set (see below) as you suggested.

Please let me know if there are any problems.

Thank,
Ou

     I. Packages
           #undef ALLOW_ADDFLUID --> TRUE
           #undef ALLOW_SHELFICE --> TRUE
           #undef ALLOW_ICEFRONT --> TRUE
           #undef SALT_PLUME      --> TRUE
     II. Free surface parameterizations
           linFSConserveTr                 = .FALSE.
           nonlinFreeSurf             = 0
           useRealFreshWaterFlux      = .FALSE.
           select_rStar                    = 0
           implicitFreeSurface = .TRUE.
           exactConserv                    = .TRUE.

From: Christopher Piecuch [mailto:cpiecuch at aer.com]
Sent: Friday, August 19, 2011 8:04 AM
To: Wang, Ou (3244)
Cc: Ponte, Rui; Fukumori, Ichiro (3244)
Subject: Re: ECCO v3.1 budgets

On 8/18/11 3:28 PM, Wang, Ou (3244) wrote:
Hello Chris,

Yes, please send me the list and subroutines. I’ll do a one-year run.

Thanks,
Ou

From: Christopher Piecuch [mailto:cpiecuch at aer.com]
Sent: Thursday, August 18, 2011 12:26 PM
To: Wang, Ou (3244)
Cc: Ponte, Rui
Subject: ECCO v3.1 budgets

Hello Ou,
Rui has informed me that you will be our person of contact at JPL with regard to ECCO version 3.1. I had spoken with Tony back in May and June; he sent me both the version 3.1 code that's being run at JPL (as of March) as well as some model output in order to see if temperature and salinity budgets could be closed using standard model output. After not too long, I realized that budgets cannot be closed using standard MITgcm output; this is due to a number of technical reasons, namely:

1. Because of the default form of the advection used in the tracer equations, T/S variations due to tropical instability waves and variability at frequencies higher than the dump frequency are not included in default diagnostic output; Tony is very familiar with this issue and has discussed it in a few papers, such as Kim, Lee, Fukumori 2007, J. Clim.

2. Also, version 3.1 uses implicit vertical advection in the tracer equations, for which there are no model diagnostics.

I've spent spent a bit of time working with our setup of version 2.216 and am confident that I understand the few changes that would need to be made to the c62t code in order to dump the necessary diagnostics for perfectly closing budgets using version 3.1. I am wondering if it would be possible for me to send you both a list of diagnostics that would need to be dumped as well as the few altered c62t subroutines and for you to run a 1 year run of 30.5-day output so I could do some budget closure tests. Thanks very much in advance.

Cheers,
Christopher

-------- Original Message --------
Subject:

contact at JPL for v3.1 budgets

Date:

Tue, 16 Aug 2011 15:00:50 -0400

From:

Rui Ponte <rponte at aer.com><mailto:rponte at aer.com>

To:

Piecuch, Christopher <cpiecuch at aer.com><mailto:cpiecuch at aer.com>

Chris,

I forgot to mention that from the JPL telecon the other day, if you need

to interact with JPL on the v3.1 budget diagnostics, you can bug Ou

(Ou.Wang at jpl.nasa.gov<mailto:Ou.Wang at jpl.nasa.gov>).

--

Rui M. Ponte

Atmospheric and Environmental Research, Inc.

131 Hartwell Avenue

Lexington, MA 02421-3126 USA

ph: 781-761-2288, fax: 781-761-2299, http://www.aer.com<http://www.aer.com/>

Hi Ou,

Thanks for being willing to perform the v3.1 runs. I have attached a few files here, specifically (1) the necessary modifications to three subroutines (all from the generic advection/diffusion package) that should be included in the MITgcm code folder, (2) a data.diagnostics file with the requested output, and (3) a text file giving a bit more detail regarding the requested output. I apologize in advance if the list of requested diagnostic output is a bit lengthy. Also, if its possible, I'd like to get the model geometry data files (e.g., the hFacs, DRs, DXs, DYs, etc.) along with the dumped diagnostic fields.

Concerning the code changes --- As I noted in the last email, code changes needed to be made in order to accommodate (1) high frequency co-variations of the velocity field with the T or S fields, and (2) implicit vertical advection. In my testing, I made code changes using AER setup for v2.216; these modifications were successful and I was able to close budgets. The code changes I've included here, though, are to the JPL March 2011 c62t code that I was sent some months ago, in order to be compatible with what you're running. For these subroutines, I have ``transferred'' over the changes from AER v2.216 code to the JPL v3.1 code. I have not been able to test these changes to the c62t subroutines, however. Although the MITgcm code updates that differentiate the AER subroutines from the current JPL ones are minor and you shouldn't run into any compiling errors, transferring the changes from AER- to JPL-code wasn't as simple as ``cutting and pasting''; please do let me know if you have any problems trying to get the modified code to compile.

Thanks very much, in advance.

Best,
Chris

--

Christopher G. Piecuch

Atmospheric and Environmental Research (AER), Inc.

131 Hartwell Avenue

Lexington, MA 02421 USA

phone: 781-761-2288

fax: 781-761-2299

email: cpiecuch at aer.com<mailto:cpiecuch at aer.com>
Hello Ou et al.,
I wanted to give an update regarding T and S budgets for ECCO version 3.1, for everyone's general information. It would appear that the modified code and diagnostics I sent to Ou allow for near-perfect closure of T and S budgets for v3.1.

For absolute clarity and transparency, I use ``near-perfect'' to mean that there is a mostly vanishingly small residual error that remains due to the fact that I have not accounted for discrepancies owing to Adams-Bashforth (ABII) time stepping of the model output. This is precisely the issue (and error incurred) in a much older version of the JPL code (c19), which was used for closed budget studies and with which both Tony and Ichiro are familiar. (This is the ``GSGT'' package developed by Moto Nakamura.) In a bit of detail, with reference to the active tracer equations (equation 2.166 in section 2.16 of the MITgcm user's manual), MITgcm's prognostic output for T and S tendencies (TOTTTEND and TOTSTEND) are output after the application of ABII time stepping (hence are properly understood to be defined on half-integer time steps) whereas all of the ``right-hand-side'' G-terms (i.e., advection, diffusion, and surface exchanges) are output before the application of ABII-stepping (an are understood to be defined on whole-integer time steps). (See also section 2.5 of the manual.) While this discrepancy is important for short-period output (i.e., hourly or daily averaged output), it becomes increasingly less relevant for longer-period output generally used in analyses (i.e., monthly or yearly output).

To be a bit more concrete, I computed local grid cell budgets for all levels for T and S using the 12 months of 30.5-day output provided by Ou. Generally it is the case that more than 99.9% of the local variance in either TOTTTEND or TOTSTEND can be accounted for offline using model-diagnosed advection, diffusion, and surface forcing output. There are extremely rare exceptional cases (specifically, a hand full of grid cells very deep in the Southern Ocean about the Antarctic Peninsula) where only ca. 90--95% of the variance in TOTSTEND can be explained; in these limited cases, TOTSTEND variations are very small (order 10e-6 PSS) and unavoidable issues of machine precision come into play. In terms of values averaged globally over particular layers, unexplained variances in TOTTTEND and TOTSTEND are even smaller ... typically of order 0.001%.

In essence and in sum, the machinery is in place to produce essentially-perfectly closed budgets for T and S using the version 3.1 solution.

Cheers,
Chris

--

Christopher G. Piecuch

Atmospheric and Environmental Research (AER), Inc.

131 Hartwell Avenue

Lexington, MA 02421 USA

phone: 781-761-2288

fax: 781-761-2299

email: cpiecuch at aer.com<mailto:cpiecuch at aer.com>

Good morning Tony, and thanks for following up,

After WCRP in November, Rui and I had a meeting with Patrick, Jean-Michel, et al., at MIT about incorporating the new budget diagnostics for T and S (i.e., the volume divergence term in the advection and implicit vertical advection) into current versions of the MITgcm code; from what I recall, they also intended on incorporating a diagnostic accounting for the very small error owing to the Adams-Bashforth time stepping as well as  similar diagnostics to close momentum budgets. But since that meeting I haven't heard any word from the MITgcm development team as to whether these diagnostics have indeed been incorporated officially. If not, and if I understand your purposes correctly, I would imagine Dimitris should be able to use my implementation (i.e., the S/R's I sent to Ou back in August). In the case it is helpful, I have attached here a memo I wrote up in November up for Patrick and Jean-Michel on closing the T and S budgets for v3.1, which explicitly mentions the new diagnostics I added. Please let me know if this helps or if I can offer any other information or direction.

Best,
Chris

--
Christopher G. Piecuch
Atmospheric and Environmental Research (AER), a Verisk Analytics company
131 Hartwell Avenue, Lexington, MA 02421 USA
p: +1.781.761.2349 | email: cpiecuch at aer.com<mailto:cpiecuch at aer.com> | www.aer.com<http://www.aer.com/>

<memo_tracer_budget_20111103.pdf>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20120202/5b2116cb/attachment-0001.htm>