[gradsusr] Confusiong about WEASDSFC, GFS

[Stephen McMillan]

Chris,

I suppose there are a number of vertical-temperature based
formulas/algorithms out there, one of which is the Kuchera method which
uses an algorithm based, in part, on the max temperature between 500mb and
the surface  It seems to work fairly well for most scenarios.   Here's a
link for more information:
http://www.wxcaster.com/gfssnow.txt

Hope that helps--
Stephen Mc

On Tue, Sep 29, 2015 at 9:11 AM, Christopher Gilroy <chris.gilroy at gmail.com>
wrote:

> Hey Stephen,
>
> Thanks for your response I figured that out after the fact. I appreciate
> the help you've given me with this the past few days. One last question I
> have to throw out there, what would your thoughts be on having a "dynamic"
> ratio based on vertical temperatures? Do you think it'd be wildly
> inaccurate or? I seen Ryan Maue make a comment one time about it causing
> confusing and/or being great for certain areas but terrible for other areas.
>
> On Tue, Sep 29, 2015 at 9:07 AM, Stephen McMillan <
> smcmillan at planalytics.com> wrote:
>
>> Chris,
>>
>> If you want to convert amounts in mm to in, you need to divide by 25.4,
>> not 2.54 (or, multiply by the 0.03937 you had in your example).    To go
>> the other way (in to mm), multiply in. amounts by 25.4.
>>
>> However, if you are converting mm to in. and using a 10:1 snow-liquid
>> ratio, then simply dividing the weasdsfc amounts by 2.54 should achieve the
>> same result as dividing by 25.4 (multiplying by 0.03937) then multiplying
>> result by 10.  Result would be in inches.
>>
>> Stephen Mc
>>
>>
>>
>> On Tue, Sep 29, 2015 at 8:41 AM, Christopher Gilroy <
>> chris.gilroy at gmail.com> wrote:
>>
>>> Alright, I have two primary questions, and if the answers are yes to
>>> both, the follow-up makes no sense to me.
>>>
>>> 1.) weasdsfc is water equivalent based in mm, correct?
>>> 2.) weasdsfc has no "default" liquid:water ratio, correct? A meteorology
>>> friend of mine said 'typically' 10:1 is a good standard, so I'm unsure if
>>> the model is based around that or not?
>>>
>>> I'm fairly certain I'm correct on #1. I'm unsure on the other 2 though,
>>> but here's my current situation. If I use the expression below:
>>>
>>> 'd
>>> const((sum(maskout(weasdsfc-weasdsfc(t-1),weasdsfc-weasdsfc(t-1)),t=2,t='%i%')/2.54),
>>> 0, -u)'
>>>
>>> I get an identical looking map as another well known sites 10:1 snow
>>> accum, in inchs. The confusion part of that equation should be converting
>>> (/2.54) IN to MM, no?
>>>
>>> Now, if on the other hand I do the (if I'm understanding this right)
>>> "correct" calculation to convert mm to in:
>>>
>>> 'd const((sum(maskout(weasdsfc-weasdsfc(t-1),weasdsfc-
>>> weasdsfc(t-1)),t=2,t='%i%')*0.039370), 0, -u)'
>>>
>>> I get very, very, very little snow plotted.
>>>
>>> Now, I am using the sflux files instead of the pgrb2.0p25 files, which I
>>> thought the flux files maybe used different units or something but they
>>> don't, weasdsfc is still [kg/m^2] which should mean (unless my
>>> expression is more of a hack than I would have imagine) I should be getting
>>> the opposite outputs of what each expression is actually producing?
>>>
>>> I don't know if I'm missing a parenthesis group somewhere and I'm
>>> somehow getting an inches, 10:1 snow accum plot with my code by "accident"
>>> or what? :-/
>>>
>>> _______________________________________________
>>> gradsusr mailing list
>>> gradsusr at gradsusr.org
>>> http://gradsusr.org/mailman/listinfo/gradsusr
>>>
>>>
>>
>> _______________________________________________
>> gradsusr mailing list
>> gradsusr at gradsusr.org
>> http://gradsusr.org/mailman/listinfo/gradsusr
>>
>>
>
>
> --
> -Chris A. Gilroy
>
> _______________________________________________
> gradsusr mailing list
> gradsusr at gradsusr.org
> http://gradsusr.org/mailman/listinfo/gradsusr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20150929/53b106e3/attachment-0001.html