NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>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.