problem in using Hvom and Huon

[javadi]

Hi all,

In my domain, I need to calculate some parameters enters to the my basin from the strait. v is northward.

v.dx.dz
v.T.dx.dz
v.S.dx.dz
v.rho.dx.dz

As I did not understand how can I calculate it after running, I decide to calculate them in running time.

My first question is Hvom. It gives me the volume of the water from surface to bottom for example, i=1 and after that I should sum them (along x)after running.
For others, how can I calculate them ?v.T.dx.dz I should multiple temperature to volume? is it possible to achieve them in running?

Best,

[jcwarner]

this can get complicated in the code. Suggest you use the diagnostics, they are set up to compute all this for you.

[javadi]

Thanks for your reply.

I have done some action for it.

1) .h
# undef DIAGNOSTICS_TS and
# undef DIAGNOSTICS_UV
# undef AVERAGES

2)NAVG = NDIA; should be the same
3).in, I activated this parameter

Dout(iTrate) == T F ! temp_rate, ... time rate of change
Dout(iThadv) == T F ! temp_hadv, ... horizontal total advection
Dout(iTvadv) == T F ! temp_vadv, ... vertical advection
Dout(iThdif) == T F ! temp_hdiff, ... horizontal total diffusion
Dout(iTvdif) == T F ! temp_vdiff, ... vertical diffusion
.......................................................................
Aout(idTsur) == T F ! shflux, ssflux surface net heat and salt flux
Aout(idUvel) == T ! u 3D U-velocity
Aout(idVvel) == T ! v 3D V-velocity
Aout(idTvar) == T F ! temp, salt temperature and salinity
Aout(idUTav) == T F ! utemp, usalt quadratic <u*t> T/S terms
Aout(idVTav) == T F ! vtemp, vsalt quadratic <v*t> T/S terms
.......................................................................
Aout(iHUTav) == T F ! Huontemp, ... T/S volume flux, <Huon*t>
Aout(iHVTav) == T F ! Hvomtemp, ... T/S volume flux, <Hvom*t>


But now I do not know what is the next step? Which parameter give me my needed information.

[jcwarner]

the wiki does not have a full explanation, but there are other sources to get the meaning of the diagnostics.
https://www.myroms.org/wiki/Model_Diagnostics

here is a list of the equations
https://www.myroms.org/wiki/Numerical_S ... _Technique

Kates manual has a nice more full expansion of the terms
https://www.boem.gov/sites/default/file ... 18-007.pdf
eq 18 19 20

then the diags are as expected
viewtopic.php?t=2597
'ubar_sustr+ubar_bustr+ubar_prsgrd+ubar_cor+ubar_hadv+ubar_hvisc-ubar_accel' and the result is zero.
similar for the 3d .

[javadi]

Excuse me.

This is true in my comments.

#define DIAGNOSTICS_TS
#define DIAGNOSTICS_UV
#define AVERAGES


not

# undef DIAGNOSTICS_TS and
# undef DIAGNOSTICS_UV
# undef AVERAGES

[jcwarner]

yes i figured that.
run the job for a short duration and look at the diagnositcs.nc file.
you will need to spend some time, start with the depth avg terms. they are easier to figure out.
try to add up the terms at one of the time steps:
ubar_accel = ubar_sustr+ubar_bustr+ubar_prsgrd+ubar_cor+ubar_hadv+ubar_hvisc
same for vbar

[wilkin]

You want ...

v.dx.dz
v.T.dx.dz

The diagnostics outputs Hvomtracer are exactly these terms. In "Hvom" the "H" does not refer to water depth, h, but to the "Hz" variable that is ROMS time-varying layer thickness, i.e., dz. (The sum k=1 to N of Hz equals h+zeta.) The "o" refers to "over", and "m" is pm the reciprocal of cell width, dx. So, HvomT is (Hz)(times)(v)(over)(m)(times)(tracer) = dz.v.dx.T.

Looking at the metadata attributes for these variables (or their entry in varinfo.yaml) we see this term is defined at v3dvar points, i.e. on the same points as v itself. So, "pm" (which is on the rho-points grid) has been interpolated to the v-point the same way as ROMS does internally for its flux divergence calculation, and this diagnostic term is as exact as it can be for tracer conservation analysis.

Since the dz is already in there, the vertical integral of the tracer flux, weighted by cell width, is simply the summation from k=1,N. To also integrate over "x", just take the sum over "i" because the dx is already in there.

The diagnostics calculate the true time average of this tracer flux, accounting for the time variability (with a ') of the triple product <dz' v' T'>.

The quadratic averages outputs, e.g. <v'T'>, are also available (and were long before we added Huon ... terms), but calculating a vertical integral using dz based on zeta averaged over the same interval only gets you to <dz><v'T'> and part of the true flux is missing. This might seem unlikely to be significant, but if, say, a tidal current is strongly correlated with sea level in the presence of a horizontal tracer gradient (not unusual at all), the dz will be consistently greater (or lesser) during a phase of the tide and <dz'v'> is sizeable. It was the analysis of heat budgets in Wilkin (2006) that prompted introducing these diagnostics into ROMS.

Wilkin, J. (2006), Modeling the summertime heat budget and circulation of southeast New England shelf waters, Journal of Physical Oceanography, 36, 1997-2011

[javadi]

Hi wikin

Thanks for your response.

I was waiting for running to see outputs.

Now there are many new products in average file. I am a little
confused.

The first thing is that the outputs is based on layers. So, I should sum of them for all layers. and then for transects I should sum along longitude(j=cte, i=variable).To achieve total volume from each transects. Is it right?

secondly, here are new variables

1) Hvom

this shows the volume passing from each cell m3/s.it it right?

2)temp_2 and salt_2
I do not understand what are them.

3) Hvom temp
this would be temp* volume? (deg*m3/s)

4)Hvom salt
this would be salt* volume?(psu*m3/s)
5) v_temp and v_salt
speed* (temp or salt)(m/s m3/s

Thanks!

[wilkin]

Yes, as I noted previously

Since the dz is already in there, the vertical integral of the tracer flux, weighted by cell width, is simply the summation from k=1,N. To also integrate over "x", just take the sum over "i" because the dx is already in there.

so you should sum over layers to get a vertical integral. Likewise Hvom has a "over m" meaning "times dx" so an integral in the "x" , actually i, direction is again simply a summation.

If you want to integrate along a line that is not constant i or j, then that is a whole other issue.

Read the global attributes of the new variables in your netcdf output file. They document a short description of the variable and its units.

[fabeobd]

Hi all,

I'm using Huon_temp/Hvom_temp to calculate the cross-1500m isobath heat transport around the Antarctica continent, and I have a question about the reference temperature. Are the temperature in these diagnostics just the potential temperature in degree Celsius (as temp times u/v . Hz . pm/pn)? There is any way to change that to use a reference temperature when calculating these diagnostics online (without changing the code)? Or if needs code changes, any tips on the specific routines to look for?

The issue is that we don't really want to reference these calculations to the temperature in degC as it makes the interpretation harder when temperatures are fluctuating around zero degC (+/-), as is the case for Antarctica shelf waters.

Appreciated any guidance in advance!

Cheers,
Fabio

[wilkin]

Isn't is just ...

<u (T-Tref)> = <u T> - <u Tref> = < u T > - Tref < u > because Tref is constant.

You have Huon_temp and Huon, so calculate Huon_temp - Tref*Huon.

[fabeobd]

Hi John,

Thanks for your response. Yes, that's true! I have done exactly that, but I wanted to look at the mean and eddy components (defined as below), and the T_ref*Huon seems to be so dominant that the eddy term become nearly insignificant (i.e. the total heat transport across my 1500m isobath is nearly all due to the mean heat transport).

MEAN = < Huon > < T > - < Huon > T_ref (annual avg)
EDDY = (Huon_temp - < Huon > T_ref)_daily - MEAN

Figure 1

If I look at these terms without subtracting the T_ref < Huon >, the eddy term seems to be more significant:

MEAN = < Huon > < T > (annual avg)
EDDY = (Huon_temp)_daily - MEAN

Figure 2

My thoughts were that if I apply the T_ref online while computing Huon_temp (so avoiding subtracting the "reference temperature transport" offline), my decomposition would be more consistent.

Just to give a bit more of background, I'm looking at a ROMS setup w/ ice shelves in a circum-Antarctic domain (WAOM, https://www.frontiersin.org/articles/10 ... 27704/full). I extract my exact contour along my 1500m isobath following this (https://github.com/COSIMA/cosima-recipe ... port.ipynb) adapted to the WAOM grid.

Much appreciate any insights!

Best,
Fabio

[wilkin]

Something to check is whether your circumpolar integral of Hvom in the long term mean is zero (volume conservation). Then for a closed volume Tref doesn't matter because < Hvom > Tref = 0. It's a sanity check on your methods and a possible indicator of accumulated errors associated with the calculation of velocity normal to your 1500 m isobath contour.

[fabeobd]

Thanks John for the suggestion. We've checked the circumpolar integral of the volume transport and that looks good: