Re: vcMapDirection resource

Hi TJ,

I am not sure if WRF stores the vector components using earth-relative or grid-relative rotation. The formulas look like they are correct for converting from earth-centered to grid-centered assuming COSALPHA and SINALPHA have radians as units (otherwise you need to supply a conversion factor for degrees to radians). They are similar to the formulas that we supply as metadata for GRIB files with earth oriented vector components, e.g.:

 float gridrot_0 ( ygrid_0, xgrid_0 )
         long_name : vector rotation angle
         GridType : Lambert Conformal (secant, tangent, conical or bipolar)
         units : radians
         formula_u : Ugrid = cos(rot)*Uearth - sin(rot)*Vearth
         formula_v : Vgrid = sin(rot)*Uearth + cos(rot)*Vearth
         note1 : u and v components of vector quantities are resolved relative to earth
         note2 : apply formulas to derive u and v components relative to grid

To go the other way you can use the same rotation values, but the formulas are different, e.g.:

float gridrot_0 ( ygrid_0, xgrid_0 )
         long_name : vector rotation angle
         GridType : Lambert Conformal (secant, tangent, conical or bipolar)
         units : radians
         formula_u : Uearth = sin(rot)*Vgrid + cos(rot)*Ugrid
         formula_v : Vearth = cos(rot)*Vgrid - sin(rot)*Ugrid
         note1 : u and v components of vector quantities are resolved relative to grid
         note2 : apply formulas to derive u and v components relative to earth

I have not looked myself, but what makes you think that the wrf_user_getvar does not already use similar formulas? I agree that if you are doing a small subset of the grid points it could be faster to do it yourself in a loop. However, if you need more information about wrf_user_getvar or want to make a suggestion, I think you should write to wrf help yourself. WRF does not have a mailing list like ncl-talk, just a help desk.
  -dave

On Aug 8, 2011, at 7:25 PM, wxtofly wrote:

> Dave,
>
> Thanks for the clarification.
>
> Andrea Barcellona, a fellow also running the windgrams I have designed noted that the wrf_meteo4 and wrf_meteo5.ncl at least gets around the issue by using uvmet.
> uvmet = wrf_user_getvar(a,"uvmet",-1) ; get rotated u and v comp of wind
>
> He has suggested that rather than using uvmet as above, we only do the calculations at the single points of interest using the COSALPHA and SINALPHA variables already in the wrf output files.
> b is a wrf output file.
> cosalpha = b->COSALPHA(0,:,:)
> sinalpha = b->SINALPHA(0,:,:)
>
> u_point = u_point*cosalpha(locY,locX) - v_point*sinalpha(locY,locX)
> v_point = u_point*sinalpha(locY,locX) + v_point*cosalpha(locY,locX)
>
> Unfortunately my trig is so rusty as to be irreparable and I don't know if those are equivalents to the calculations in wrf_user_getvar. If they are, then much computation is saved by doing only single points with existing COSALPHA and SINALPHA.
>
> Does this seem to make sense to you? If it does, then the wrf people might consider substituting his formula in wrf_user_getvar if the COSALPHA and SINALPHA variables are always part of the WRF output.
>
> If this makes sense, please forward it to someone on the wrf/ncl team as I don't want to subscribe to another list to do that.
>
> TJ
>
> On 08/08/2011 03:08 PM, David Brown wrote:
>>
>> Hi TJ,
>>
>> Your description is basically correct, although it might be more precise to say that when vcMapDirection is False the horizontal direction (left to right) represents the positive U component and the vertical direction (bottom to top) represents the positive V component (since U and V do not necessarily have to represent Eastward and Northward components). In retrospect, it might have been better to have vcMapDirection default to False unless the data is overlaid on a map. It is quite possible there are some examples that should have this resource set differently. We will investigate and make changes where needed.
>> -dave
>>
>> On Aug 4, 2011, at 11:33 AM, wxtofly wrote:
>>
>>> Does this mean that with vcMapDirection=True, the coordinate space acts the same as the projection used in the underlying data and with it False it uses up as North and right as East? That would fit with the slight differences that I checked from a point near the center of a Lambert conformal projection. I tried it with points from a larger domain where I would expect larger deviations if it were the case, but the results were inconclusive. It does appear that no matter which point I have chosen, the vcMapDirection=False --> vcMapDirection=True causes barbs to change as if they were on a Lambert conformal surface with horizontal and vertical barbs not changing at all. I guess this means that I should be using vcMapDirection=False.
>>>
>>> Fortunately, my domains are small enough that the distortion doesn't matter much to people who are using the Windgrams.
>>>
>>> Perhaps the wrf_meteo1-5.ncl scripts should be amended...
>>>
>>> TJ
>>>
>>> On 08/04/2011 07:28 AM, Mary Haley wrote:
>>>>
>>>> Hi TJ,
>>>>
>>>> I admit I've never understood this resource very well. Dave Brown is out of the office, but here's an explanation from him (modified slightly to make sense in this context) that he sent to another user:
>>>>
>>>> By default, the vector direction is mapped into the coordinate space defined by the coordinate variables. This is appropriate for horizontal vectors drawn on a map, but not for vectors in a vertical space where the Y axis and the X Axis have completely unrelated units. To fix this you should set the resource vcMapDirection to False. However, it also has the effect of always making the positive Y direction from bottom to top. If the vertical component is positive from top to bottom of the atmosphere, then you will need to multiply the vertical component by -1.0 to get the result you are looking for.
>>>>
>>>> --Mary
>>>>
>>>>
>>>> On Aug 3, 2011, at 11:54 PM, wxtofly wrote:
>>>>
>>>>>
>>>>> I am confused by this resource as the examples are not consistent with its use and I don't really understand what it does in the absence of an underlying map as on the attached windgram plots.
>>>>>
>>>>> I have attached two of my windgrams, one produced without any mention of vcMapDirection which therefore would use the true default, and the other with
>>>>> uv_res@vcMapDirection=false. As you can see they are nearly but not exactly identical. (gwenview or something similar next prev to rock between them)
>>>>>
>>>>> On the NCAR site, the 1 special example meteo.ncl uses uv_res@vcMapDirection=false. The 5 wrf_meteo(1-5).ncl omit the resource. Which is "correct."
>>>>> What would I expect the effects to be?
>>>>>
>>>>> Thanks for you help.
>>>>>
>>>>> TJ Olney
>>>>>
>>>>> --
>>>>> Abbreviated current observation pages for mobile devices.: Blanchard North | Tiger | Ft Ebey | East Side
>>>>> Full Blanchard Page | Full FtEbey Page | <Mail Attachment.png>ASP | All Windgrams | Blipspots
>>>>> <2011-08-04_Black_windgram_vcfalse.png><2011-08-04_Black_windgram_vctrue.png>_______________________________________________
>>>>> ncl-talk mailing list
>>>>> List instructions, subscriber options, unsubscribe:
>>>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>>
>>>
>>> _______________________________________________
>>> ncl-talk mailing list
>>> List instructions, subscriber options, unsubscribe:
>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk

_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Tue Aug 9 12:17:41 2011