[MITgcm-support] [EXTERNAL] Re: Diagnostics package codes:: where are vertical flux and velocity fields?
Fenty, Ian G (US 329C)
ian.fenty at jpl.nasa.gov
Wed Jan 13 13:07:11 EST 2021
Jean-Michel,
Thank you for the clarification. In your reply to mitgcm-support some character codes turned into "???" so I am pasting my original question below your response.
>> The main problem here is that the letter "L" has been inherited from atmospheric set-up
in pressure coordinate where, in this case, k -1/2 is physically "lower" than level k.
Yes, I agree: the inherited "L" could be confusing for new users (and even not new users) when applied to ocean variables because k - 1/2 is physically "higher" than level k. For the sake of users, the documentation needs to be more clear about what the k - 1/2 and k + 1/2 mean in terms of the logical grid and physical grids for ocean and atmosphere setups. I can improve how we describe the variables in the ECCO output, and we've made some updates to xmitgcm to be more consistent.
>> Regarding 2-D diagnostics, I think this label "U" is not right (and mis-leading), and
we should either use nothing (blank) or a specific code (other than current L/M/U) if
it's physically located at model domain top or bottom.
Personally, I don't have any problem with some 2-D diagnostics with label "M1"
(e.g., MXLDEPTH) when they are associated with some column/domain interior property.
Instead of blank, how about "S" to denote that is physically located at the "surface", the first k index, at the model domain bottom ground surface when R is pressure or at the sea surface when R is depth?
============ old ==============
oceTAUX | 1 | 80 |UU U1|N/m^2 |zonal surface wind stress, >0 increases uVel
============ new ==============
oceTAUX | 1 | 80 |UU S1|N/m^2 |zonal surface wind stress, >0 increases uVel
Again, thanks for the quick and helpful reply. I'll open an 'issue' for the 9th character 2-D diagnostics.
-Ian
On 1/13/21, 7:22 AM, "Jean-Michel Campin" <jmc at mit.edu> wrote:
Hi Ian,
I am replying to support for now, but we will probably have to open an issue regarding
some of this confusing 9th character code.
1) You are right (and the documentation is not wrong here) that 3-D diagnostics with
label "L" in 9th position are supposed to be at the vertical interface between 2 levels
such as diagnostic level k would be between tracer level k-1 and level k ; describing
it's vertical position as "k -1/2" is not that wrong.
The main problem here is that the letter "L" has been inherited from atmospheric set-up
in pressure coordinate where, in this case, k -1/2 is physically "lower" than level k.
2) Regarding 2-D diagnostics, I think this label "U" is not right (and mis-leading), and
we should either use nothing (blank) or a specific code (other than current L/M/U) if
it's physically located at model domain top or bottom.
Personally, I don't have any problem with some 2-D diagnostics with label "M1"
(e.g., MXLDEPTH) when they are associated with some column/domain interior property.
Cheers,
Jean-Michel
=========================================================================================================
Hi JM,
I’m producing another set of ECCO NetCDF files for distribution and am hoping you can quickly help clarify something that came up between Ryan and I in his xmitgcm Python code.
As you know, the MITgcm diagnostics package uses several character ‘codes’ to describe where variables are with respect to the C-grid.
https://mitgcm.readthedocs.io/en/latest/outp_pkgs/outp_pkgs.html?highlight=wvelmass#diagnostic-parsing-array
All 3D vertical velocity and flux variables such as WVELMASS and ADVr_TH have the “LR” code in the 9 and 10 positions.
WVELMASS| 50 | |WM LR|m/s |Vertical Mass-Weighted Comp of Velocity
According to the documentation, “L” means “model level -1/2” and “R” means Nr levels. The confusion comes with the meaning of “model level –1/2”. I interpret that these variable should start counting DOWN from the TOP face of the tracer cells, which should make the first value of WVELMASS the vertical velocity of the ocean surface, wvel(k=1). Since k increases DOWN, model level – 1/2 should mean that the variable is located ABOVE the center of the tracer cell, UP towards to the surface.
It appears that at least superficially Ryan’s xmitgcm interprets the “LR” code to mean ‘lower’ face, meaning that the first wvel is the vertical velocity of the BOTTOM of the tracer cell at k=1.
Adding confusion is the “U” code in the 9 position for several 2D surface flux fields (e.g., oceTAUX), with “U” meaning “model level + 1/2 “. Since these are 2D surface fields, the “model level + 1 /2 “ strongly suggests that one should be counting UP by 1/2 from the tracer cell center to get to the surface. It kind of makes sense, but contradicts the interpretation of “L”.
I examined the DIAGNOSTICS_FILL call for WVELMASS: CALL DIAGNOSTICS_FILL(wVel, 'WVELMASS',0,Nr,0,1,1,myThid)
To me, this looks like the entire wVel field is passed, all 50 levels. None of the arguments suggest that WVELMASS starts from the BOTTOM of the tracer grid cell, wvel(k=2).
SUBROUTINE DIAGNOSTICS_FILL(
I inpFld, chardiag,
I kLev, nLevs, bibjFlg, biArg, bjArg, myThid )
kLev = 0 : fill-in in the same order as the input array
NLevs = Nr
Finally, I looked at the budget document that you put together with Abhishek. Consider the equation for temperature tendency from advection:
Adv_tend = - [ {ADVr_TH(ix,iy,iz) – ADVr_TH(ix,iy,iz+1)}/CellVol + {ADVx_TH(ix+1,iy,iz) – ADVx_TH(ix,iy,iz)}/CellVol + {ADVy_TH(ix,iy+1,iz) – ADVy_TH(ix,iy,iz)}/CellVol ]
The vertical flux divergence term is ADVr_TH(iz) – ADVr_TH(iz+1) and the horizontal flux divergence terms are on “iz”. Again, this suggests that for a tracer cell at vertical level k=iz, ADVr_TH(iz) is the TOP of the grid cell and ADVr_TH(iz+1) is at the BOTTOM of the grid cell.
Please help shed some light! Where is the first value in WVELMASS, ADVr_TH, etc? The top or bottom of the tracer grid cells? Does the first value correspond to the top or bottom of the uppermost grid cell? Is there an inconsistency between the “L” and “U” codes?
Thank you in advance.
-Ian
More information about the MITgcm-support
mailing list