Hi Ferreters -
I happened to look at our standard dynamic height script today.
(On my system it is .../opt/miniconda3/pkgs/pyferret-7.6.3-py37hfb0c5.1/go/dynamic_height.jnl)
(comments say "updated in 10/93" ... before some of you were even born ...)
(the script is also attached FYI)
I think there's a subtle error in this script, due to the upward indefinite integral.
Beyond dynamic height, the issue occurs anytime where @iin (or @rsum) is used.
The relevant parts of the dynamic_height.jnl algorithm are:
! Standard _expression_ for specific volume anomaly
let SVanom = 1/rho_UN(dyn_s,dyn_t,dyn_p) - 1/rho_UN(35,0,dyn_p) ! dyn_[s,t,p] are temp,salinity,pressure
! The _expression_ for the top-to-bottom integral is straightforward:
let/title="Dynamic Height(dyn-cm)" DYN_HT = 1E5 * dyn_mask * SVanom[z=@din] ! (dyn_mask excludes incomplete profiles)
! But for a z-dependent result, the direction of the z-axis and of integration must be considered.
! The z-axis is typically DOWNWARD (/DEPTH in the axis definition), but the intended integration is UPWARD.
! Thus the indefinite integral @iin needs to be reversed using @din minus @iin.
! In the script this is:
let/title="Dynamic Height(dyn-cm)" DYN_HTz = 1E5 * dyn_mask * (SVanom[z=@din]-SVanom[z=@iin])
! However, the user probably expects the value to be at the same depths as the density data, namely at the center of each grid cell.
! But the script's _expression_ integrates completely through each grid cell, giving the value of the integral at the TOP of the cell.
! - - - - - - - - -
! A simple way to see what's happening is with a simple example of the results of @din - @iin, defining an example that can be followed in your head:
define axis/z/depth zdep={1,2,3,4,5} ! simple downward z-axis
let zvals = 2*z[gz=zdep]
Attachment:
dynamic_height.jnl
Description: Binary data
[Thread Prev][Thread Next][Index]