Re: 20050705: 20041008: how to handle staggered U & V in IDV?

• Subject: Re: 20050705: 20041008: how to handle staggered U & V in IDV?
• From: John Caron <caron@xxxxxxxxxxxxxxxx>
• Date: Thu, 07 Jul 2005 11:56:47 -0700

Unidata Support wrote:

From: Rich Signell <rsignell@xxxxxxxxx>
Organization: USGS
Keywords: 200507051400.j65E0Bjo002656 IDV staggered grids

Hi Rich

I still cannot look at any of the 3D fields of U and V
in my model results using IDV.

This solution given in your previous message below
works for my 2D fields of U and V, but not for the 3D
fields of U and V.  I believe the problem is that the
vertical positions of the 3D U and V fields cannot be
determined, since the "ocean_s_coordinate" formula
which describes the vertical coordinate is only
defined at grid cell "centers" where elevation exists,

and the U and V points are on the "faces".

Yes, this is basically the problem.

Thus any attempt to display or regrid the 3D fields of
U and V fails.  I think what we need is a function
that *horizontally* averages the U and V fields at
each "s level" (or sigma level) without doing anything
to the vertical coordinate, and then assigning this
new variable the vertical coordinate at the grid cell

center.

Even just trying to display is problematic.  The code
that computes the sizes of the ocean_s_coordinate variable
ends up being diffferent than the number of points for
the variable bases on the dimension.  This is a problem
before it ever gets to the IDV.

We do something like what you suggest to support WRF

Eta coordinates, and we need to look at generalizing this.

The function would have three inputs: (1) the 3D U
field, (2) the 3D V field, (3) a 3D Temp or Salt field
(something that is at the grid cell centers, with an
existing vertical coordinate).   All of these fields
would have the same number of vertical levels, but not
necessarily the same horizontal dimensions.  In our
ROMS model, for example, the dimensions are

   K  J   I
U  (20,60,159)
V  (20,59,160)
T  (20,60,160)

So with M=160 and N=60, we just want a function that
does

U_at_T=T*NaN;
V_at_T=T*NaN;

U_at_T(:,2:(N-1),2:(M-1))=0.5*(U(:,:,1:(M-1))+U(:,:,2:M))
V_at_T(:,2:(N-1),2:(M-1))=0.5*(V(:,1:(N-1),:)+V(:,2:N,:))

This should be possible to implement in Jython, right?

I don't think so.  The problem is happening upstream of
where you can access it in VisAD/Jython.  We'll have to
look at solving it in the vertical transform code.

There is a ROMS output sample file at:

http://stellwagen.er.usgs.gov/rps/test/roms_cf.nc

that illustrates the problem.  Any attempt to do
something with the 3D U and V fields fails.

Thanks for the sample.  That will help.

Thanks for looking at this again,

We're currently in the process of preparing for the IDV

training workshop and I don't expect to get to look closely at this until after that.

I've cc'd a couple of others here who might have some input
on this.

Don Murray
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.

Russ told me that at the GO-ESSP meeting that discussed CF,

" Balaji's proposal for a way to handle staggered grids in CF (as
well as tripolar grids, cubed earth grids, the Japanese Yin-Yang grid,
and mosaic grids) was very popular, and it looks like a good way to
deal with all these problems."