[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>From: Rich Signell <address@hidden>
>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.