diagnostics

General scientific issues regarding ROMS

Moderators: arango, robertson

Post Reply
Message
Author
winterbellgirl
Posts: 14
Joined: Wed Jun 30, 2010 2:58 pm
Location: Texas A&M University

diagnostics

#1 Post by winterbellgirl » Wed May 09, 2012 7:43 pm

Hi,

I'm trying to do some momentum balance analysis using ROMS. I output the 2D momentum terms into the diagnostic output files, but I'm not quite sure how the momentum balance is completed. I chose a point in the model, and added up all the terms (ubar_sustr+ubar_bustr+ubar_prsgrd+ubar_cor+ubar_hadv+ubar_accel+ubar_hvisc) in the xi-momentum equation at this point, but the result is not zero. Could anyone give some explanations on this? Thanks!

User avatar
wilkin
Posts: 510
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: diagnostics

#2 Post by wilkin » Thu May 10, 2012 1:30 am

I have not worked extensively with the momentum diagnostics, and certainly not the depth averaged terms. But with the tracer diagnostics the sign convention can be interpreted as the time rate of change being on the left hand side, and all other terms on the right hand side.

So in the case of salt we expect:

salt_rate = salt_hadv + salt_vadv + salt_hdiff + salt_vdiff

So if you are used to thinking of the two advection terms as div(u.salt) - because we usually write it on the left hand side - this is:

salt_rate = -div_h(u.salt) + salt_hdiff + salt_vdiff

Therefore my expectation would be that you get this balance:

ubar_accel = ubar_sustr + ubar_bustr + ubar_prsgrd + ubar_cor + ubar_hadv + ubar_hvisc

You might want to check that the sign of the sustr and bustr terms is consistent with the sense of ubar.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

winterbellgirl
Posts: 14
Joined: Wed Jun 30, 2010 2:58 pm
Location: Texas A&M University

Re: diagnostics

#3 Post by winterbellgirl » Thu May 10, 2012 3:04 am

Hi Dr. Wilkins, yes your suggestion works! This time I computed 'ubar_sustr+ubar_bustr+ubar_prsgrd+ubar_cor+ubar_hadv+ubar_hvisc-ubar_accel' and the result is zero. Thank you!

pmaccc
Posts: 39
Joined: Wed Oct 22, 2003 6:59 pm
Location: U. Wash., USA

Re: diagnostics

#4 Post by pmaccc » Fri Mar 29, 2013 12:39 am

I'm using the diagnostic feature for some budgets. In the course of some error checking I compared the field from salt_rate to the difference between salt fields from the history files saved at the beginning and end of the diagnostic averaging period. The shapes and magnitudes, e.g. of a vertical profile of salt_rate compared to (salt2-salt1)/3600, look very similar, BUT there is an OFFSET that is as big as the signal. Any clues? The sum of all salt diagnostic terms balances perfectly, as expected.

pmaccc
Posts: 39
Joined: Wed Oct 22, 2003 6:59 pm
Location: U. Wash., USA

Re: diagnostics

#5 Post by pmaccc » Fri Mar 29, 2013 6:43 pm

I did some more analysis on the problem of the salt_rate diagnostic. The plot shows the evolution of temperature and salt at a surface model location, both from history and average files. They look very similar. Then I calculate the time derivative of both and plot it on the bottom row, comparing it with the associated rate term from the diagnostics. As you can see, the salt-rate looks pretty bad. This pattern is similar at other model locations. Where is salt_rate calculated in the code?

Image

pmaccc
Posts: 39
Joined: Wed Oct 22, 2003 6:59 pm
Location: U. Wash., USA

Re: diagnostics

#6 Post by pmaccc » Fri Apr 12, 2013 9:51 pm

I wonder if the problem might arise in the two different versions of the calculation of DiaTwrk(i,j,k,itrc,iTrate) taken from step3d_t.F. I assume the first, active, version forces the salt_rate diagnostic to equal the sum of all the other terms. Then the second, commented out, version appears to calculate the salt_rate based on the difference of subsequent salt fields...

# ifdef DIAGNOSTICS_TS
!
! Compute time-rate-of-change diagnostic term.
!
DO k=1,N(ng)
DO j=JstrR,JendR
DO i=IstrR,IendR
DiaTwrk(i,j,k,itrc,iTrate)=t(i,j,k,nnew,itrc)- &
& DiaTwrk(i,j,k,itrc,iTrate)[/color]
!! DiaTwrk(i,j,k,itrc,iTrate)=t(i,j,k,nnew,itrc)- &
!! & t(i,j,k,nstp,itrc)
END DO
END DO
END DO
# endif

pmaccc
Posts: 39
Joined: Wed Oct 22, 2003 6:59 pm
Location: U. Wash., USA

Re: diagnostics

#7 Post by pmaccc » Thu May 02, 2013 6:22 pm

I figured out the problem with my salt_rate test. salt_rate is NOT <ds/dt>, where <> denotes averaging over the time period for which diagnostics are collected. Instead (I think) salt_rate = <d(s*v)/dt>/<v> where v is the (changing) volume of a given grid cell. When I use this interpretation to check salt_rate using values from the avg and his fields it works perfectly.

User avatar
arango
Site Admin
Posts: 1084
Joined: Wed Feb 26, 2003 4:41 pm
Location: IMCS, Rutgers University
Contact:

Re: diagnostics

#8 Post by arango » Thu May 02, 2013 8:24 pm

Yes, ROMS is formulated in flux form. See the governing equations in :arrow: WikiROMS. All the diagnostics are also in flux form. Notice that the time-averaged file has also all the fluxes and quadratic terms. This becomes very handy when doing all these analysis. We just set the time averaging window for both the diagnostic (NDIA) and average (NAVG) files to be the same.

Post Reply