Huon_eastward and Hvom_northward

[c.drinkorn]

Hi ROMS cummunity!

I am currently trying to make ROMS output the volume transport components as eastward and northward, too, as is being done for the 2D and 3D velocity fields. I was wondering, since the volume transports are Average out variables, why the rotation of u and v is only being conducted in the wrt_his routine. Does this mean, in order to output u_eastward and v_northward in the average file, one also needs to switch on the variable output for the history file? The reason why I am asking is that I am still unsure about how to implement this. I am delighted to put the rotation call into both, wrt_avg and wrt_his routines, in order to make them independent of each other. Then, I could easily add Huon_eastward and Hvom_northward to wrt_avg (and other routines). The way the routine is now, I might have to perform this in wrt_his and make them history output variables...
I hope I could clarify my question and thoughts. If everything works fine I could share the code, too. This may be useful for others, too...

[kate]

Rotating a velocity is easy while rotating flux through a cell face is less so. You'd have to think carefully about exactly what it is that you want to output, especially if dx and dy are not the same.

As for the averages, adding new things to the averages output typically depends on adding new variables to the averages data structure and keeping a running mean of the quantity during run-time.

[c.drinkorn]

Hi Kate, thank you for your helpful advice!
I want Huon and Hvom at rho-point locations (that is in the 3D sense) and then rotate them towards East or North, respectively. I am still a bit confused as to why on_u is used for the calculation of Huon and not on_p. Wouldn't the distance of the psi points framing the u-edge give the right measure for the u-face of the volume? Or maybe I misunderstood the way Huon is calculated. This is of course crucial for my plans to implement the output of the rotated variables...
Regarding the averaged variables this was are really helpful hint. I seem to have forgotten for a moment what the average output actually is!

[wilkin]

Huon and Hvom are defined at u and v points (cell faces) respectively. They are cell face average transports such that the time varying dz due to the time dependent s-coordinate is fully accounted for in the time average. The vertical *sum* of Huon is the vertical *integral* of u dz.

They, and especially their cell-face-weighted tracer associates, HuonT etc., were introduced to allow more precise tracer budget calculations for a control volume in cases where the sea level is strongly correlated with flow direction. In that situation, the time-average HuonT cannot be accurately recovered with dz calculated from time average zeta. The true tracer flux is average of the product of 3 time-varying quantities: u, tracer, and dz.

So Huon from history data, i.e. a time snapshot, is not a thing. You can get that exactly from other snapshot data by calculating dz with the actual zeta. Huon etc only make sense to bother with in time averages.

dx,dy are time invariant, so for your purposes you could do the transformation to rho-centered east/north components in post-processing. It's not necessary to do that online.

I'm not sure what the point of doing so would be because the averaging to rho-points and the rotation render the Huon no longer useful for precise budget calculations. For visualization purposes I think you could just use the quadratic average (u.tracer) quantities and dz based on average zeta.

[c.drinkorn]

Hi John,

thank you for the very comprehensive explanation! To be honest, many of those average flow variables confused me. I was looking for a variable to create a vertically integrated flow field, preferably in m3/s or Sv, respectively. I post-processed Huon and Hvom using NCL but I don't trust the output. I think the problem is in the rotation. I am rotating a volume being transported into another direction. I would have to interpolate to the new direction...
Then again, I hear what you say about the real purpose of Huon and Hvom. Maybe I really should calculate the flow fields from velocities instead. I tried that before but couldn't properly access or determine dz. I managed to output Hz as a variable but I am not too sure if zeta was handled in a right manner. I am basically calling for the Hz in the GRID type which is time invariant...
How would one calculate dz offline?

[wilkin]

The volume transport is the *sum* of Huon (in m^2/s) over the k index (that's the vertical integral) divided by pm (i.e. times dy). That gives you m^3/s. The "H" in Huon is really Hz which is what we call the elemental cell layer thickness.

Alternatively, for your purposes, calculate ubar times (h+zeta) divided by pm. Again, that's m^3/s.

There are plenty of codes out there in various Matlab, Python or whatever toolboxes that correctly compute dz (or "Hz") for the defined stretching parameters in the ROMS s-coordinate.

ROMS also gives you the option to output the 3-d z coordinates on rho and w points. If you difference the w-points z you get layer thickness.

[c.drinkorn]

Hi John,

these are really helpful explanations! Thank you!
Just one more confusion:
When I calculate the vertically integrated volume transport on the basis of the barotropic flow components, I can make use of the already interpolated and shifted eastward and northward components. However, then using pm or pn is somewhat incorrect, isn't it? I need the volume transport (component) into the eastward and northward direction, respectively. So I assume I'd also need the area facing that direction. The distances of dx and dy from pm/pn are oriented into the ROMS grid directions. Or am I getting this wrong?
Using the non-unstaggered and unrotated variables instead basically puts me into the situation I have with Huon and Hvom, too...

[kate]

If you want transport across some section not aligned with the grid, the proper thing to do is described here.

[wilkin]

Kate's point is quite correct. If you want to accurately compute volume flux through an arbitrary section you shouldn't separately rotate and interpolating the velocity components and grid metrics. The zig-zag path in the post Kate directs you to i(step [13]) illustrates the exact flux between two points. It's messy to do but exact. In principle, it doesn't matter what the actual path is between the two endpoints if only want the total volume flux. (Repeating the calculation for two paths is a good sanity check on your algorithm).

[c.drinkorn]

Thank you, Kate and John!
Yes, at some point I also want to calculate the transport across a transect and I already wrote a script for that. I will compare the procedure carried out in Oceanspy with mine! For now I am using the volume transport to depict a mean vertically integrated flow vector field. The field of transports calculated with ubar_eastward/vbar_northward look reasonable.