[MITgcm-support] MITgcm density anomaly

[John Pender]

Hi Jean-Michel-

Thanks very much for getting back to me.  I'm a bit confused by the n+1/2 vs n-1/2 notation.  Does this suggest that some variables are calculated on the timestep and some variables are calculated on the half time step?  I can see how this would work:  

	a)  use density and other parameters to calculate pressure gradients, which accelerate matter
			gives new values to uvel, vvel, etc	
			* on time step
	b)  use the velocities to update density, etc (perhaps with a flux divergence)
			* on half time step
	c)  repeat

but when I do an ncdump on, for instance, UVEL and on RHOAnoma (which Martin says is well vetted) I see that the data appear to have been written for the same sets of times.

I have been tasked with calculating and writing diagnostic variables that use velocities (uvel and vvel) and the density anomaly.  I have already done this in
	code/diagnostics_fill_state.F
but I am getting rumblings from above as to whether I shouldn't take more care.  If the rhoInSitu numbers in diagnostics_fill_state.F are a half step out of date then would it make sense for me to bin these numbers in something like rhoInSituOld, and then move the diagnostic code to DIAGS_RHO_G.  rhoInSitu would have been updated (picture me waving my arms around a bit here) to a time a little later than uvel and vvel, but if I take the average of rhoInSitu and rhoInSituOld then (hopefully) I would have a quantity that sits on the same timestep as the other parameters.

Thanks very much,
John





On Sep 13, 2012, at 2:41 PM, Jean-Michel Campin wrote:

> Hi John,
> 
> Just for clarification regarding this:
>> That means that you get only the density of the previous time step, 
>> and that is inconsistent with T/S. So there is a time offset of one time step.
> 
> There should not be a 1 time-step offset between T/S and RHOAnom, since RHOAnom 
> is filled up from subroutine DIAGS_RHO_G, called from do_oceanic_phys.F just 
> after computing density from identical T/S fields than the one diagnosed in 
> diagnostics_fill_state.F. 
> 
> However, things are less clear regarding diagnostics of density transport
> [U,V,W]RHOMASS, because you can argue that when staggerTimeStep is used,
> it would be better to diagnose Rho^(n)*uVel^(n+1/2) (to be more consistent
> with T/S advection) instead of Rho^(n)*uVel^(n-1/2) as we currently do.
> And you should be careful when comparing
> URHOMASS with either UVELTH,UVELSLT (no hFac) 
>      or with UTHMASS,USLTMASS (computed using uVel^(n-1/2) if staggerTimeStep)
> 
> Cheers,
> Jean-Michel