Re: Possible Updraft Helicity Fix and CAPE Question

From: Dennis Shea <shea_at_nyahnyahspammersnyahnyah>
Date: Mon Dec 09 2013 - 17:21:17 MST

Hi Zachary,

This is being sent to

The WRF group wrote the functions to which you refer.

THX for sending the code to demo your idea.
On 12/9/13, 1:40 PM, Hargrove, Zachary wrote:
> Hello All,
> 1.
> I am still a bit green when it comes to efficient programming so bear with me!  A while back I was looking through the archives because when using the wrf_updraft_helicty function or when using wrf_user_getvar(a,"updraft_helicity",it), the values would be abnormally high, upwards of 10,000 m2/s2 sometimes.  Many others seemed to have this problem but it seemed no one had a solution.  I may have discovered something causing the problem, but I'm not sure.  When I wrote my own rough UH code, I was able to get more realistic results.  The difference was in the vorticity units.  I am wondering if NCL is still using vorticity units of *10^-5 s-1 in the UH calculation.  In order to get the correct UH value, the units of vorticity need to simply be in s-1. This would explain the extremely large values considering the values would be off by a factor of 4 or 5 at times.  Here is what I used in my UH code (basically, I used a wrf_user_getvar for absolute vorticity and earth vorticity 
 and subtr
acted the latter form the former to get my relative vorticity).  One problem with my code is that I interpolate to constant heights so in very mountainous areas, the calculation may be way off.  However, in the southern Great Plains, the numbers seem to work.  As you see, I multiply my absolute vorticity by 10^-5 before continuing:
> do it =0,ntimes-1
>      layer = 1750.
>      uh_temp = 0
>      uh = 0
>        do while(layer.le.4750.)
>          layer = layer+250.
>          avo = wrf_user_getvar(a,"avo",it)
>          cor = wrf_user_getvar(a,"F",it)
>          avo = avo*(10^(-5))
>          w = wrf_user_getvar(a,"wa",it)
>          z = wrf_user_getvar(a,"z",it)
>          win = wrf_user_intrp3d(w,z,"h",layer,0.,False)
>          avoin = wrf_user_intrp3d(avo,z,"h",layer,0.,False)
>          relv = (avoin-cor)
>          do i =0,ny-1
>            do j = 0,nx-1
>              if(win(i,j).gt.1.)then
>                uh_temp(i,j) = win(i,j)*relv(i,j)*dz
>                uh(i,j) = uh(i,j) + uh_temp(i,j)
>              end if
>            end do
>          end do
>        end do
> I am using NCL version 6.1.2 and running it on the supercomputer Lonestar at TACC/University of Texas Austin.  Is there anything to this?
> 2.
> When calling a wrf_user_getvar for CAPE (cape_2d), the documentation says this is maximum CAPE.  Is this max CAPE in the column?  I have access to another script a post doc here wrote to calculate SBCAPE.  The SBCAPE seems to be the same spatially, but the values are much higher.  My question is, if mcape is max cape, how can SBCAPE be so much greater?  The problem with the SBCAPE script is that it takes too long to run the calculation.  The canned NCL CAPE function is convenient because it calculates it so quickly, but I worry that it is too weak.  On the same token, I worry that our SBCAPE script is not right.  This may be beyond the scope of ncl-talk, but I thought I would at least see if there is any quick and easy feedback from those who have used the NCL CAPE function regularly.  The SBCAPE  script I have is way too long to copy and paste, but I will attach it just in case anyone would like to see it.  It is a function/call script.
> Regards,
> Zachary Hargrove
> Graduate Research Assistant
> University of North Dakota
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
Received on Mon Dec 9 17:21:29 2013

This archive was generated by hypermail 2.1.8 : Fri Dec 13 2013 - 11:39:30 MST