[Met_help] statistical significane tests for MODE output
Tressa Fowler
tressa at ucar.edu
Fri Aug 28 15:34:50 MDT 2009
Jonathan,
This is kind of a hard question, but here's the simplest answer.
If you are comparing two models to each other on the same cases, then
you can do a student's t distribution confidence interval or
hypothesis test on the paired differences in areas (matched up by each
valid time). You can't actually do this in MET, but it should be
pretty easy to do even in a spreadsheet. Then your null hypothesis is
that the average difference in matched (or unmatched) area is zero. If
your 4% is significant, either you will reject your hypothesis or your
confidence interval will not include 0.
As for significance tests on the interest functions, we do not have
any methods for this. If we come up with something, it will take a
while.
Tressa
On Aug 24, 2009, at 12:13 PM, Case, Jonathan (MSFC-VP61)[Other] wrote:
> Hi Tressa,
>
> I found in my results with nearly 3 months of daily simulations that
> the experimental runs had an increase of about 4% in the matched
> area, with a simultaneous decrease in the unmatched area of about
> 4%. I believe this was for 10 mm/(1 h) precip threshold compared to
> Stage IV as a proxy for the obs.
>
> In addition, I was wondering if you recommend a method for comparing
> the statistical significance of different interest function
> distributions.
> I haven't looked at the median of maximum interest (as in Davis et
> al. submitted to WAF), but just the overall interest function values
> that's readily available using mode_analysis. I examined 3
> different precip intensities [5, 10, and 25 mm/(1h)] at the
> percentiles available in the mode_analysis output (I believe it's
> 10th, 25th, 50th, 75th, and 90th).
> I saw noticeable increases in the experimental interest functions
> above the 50th percentile and especially for the higher intensities
> (10 and 25 mm per hour).
>
> I value your input and appreciate how timely the MET group is in
> responding to inquiries. I wish all groups were as attentive as the
> MET team!
>
> Jonathan
>
>
> -----Original Message-----
> From: Tressa Fowler [mailto:tressa at ucar.edu]
> Sent: Monday, August 24, 2009 12:27 PM
> To: John Halley Gotway
> Cc: Case, Jonathan (MSFC-VP61)[Other]; met_help at ucar.edu
> Subject: Re: soil verification in MET's point_stat
>
> Jon,
>
> We don't have any scripts to do this. However, I can probably
> recommend some straightforward methods if you can be more specific
> about which MODE fields you are comparing. Also, it will probably
> matter if you are comparing paired quantities (like the difference in
> areas of paired objects) versus unmatched quantities (total forecast
> area vs total observed area), so please specify.
>
> So, if you send me a list of the fields you are looking at, I will
> send you some recommendations.
>
> Thanks,
>
> Tressa
>
>
> On Aug 24, 2009, at 9:19 AM, John Halley Gotway wrote:
>
>> Jon,
>>
>> I'm going to refer your question about statistical significance of
>> MODE
>> results to Tressa Fowler. She's the statistician who's leading the
>> MET
>> development effort. I've copied her on this message.
>>
>> Thanks,
>> John
>>
>>> No problem John,
>>>
>>> I just needed to know if it was necessary to code in the Claussius
>>> Clapeyron equation into my script. It should take just a little bit
>>> of
>>> time to implement.
>>>
>>> On another note, I was wondering what the MET team's recommendation
>>> might
>>> be to compute the statistical significance of different MODE
>>> results? At
>>> the WRF workshop, I had 3-4 people at my poster ask me what the
>>> statistical significance was of the improvement in the MODE output
>>> I saw
>>> for my 3 months of simulations of convective objects between the
>>> Control
>>> and experimental simulations. Do you have some sort of a script or
>>> recommended method for accessing the MODE output in order to
>>> compute a
>>> t-test statistic or something similar?
>>>
>>> All the best,
>>> Jon
>>>
>>> -----Original Message-----
>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>> Sent: Friday, August 21, 2009 4:43 PM
>>> To: Case, Jonathan (MSFC-VP61)[Other]
>>> Cc: met_help at ucar.edu
>>> Subject: RE: soil verification in MET's point_stat
>>>
>>> Jon,
>>>
>>> The ASCII2NC tool is just a basic data reformatting tool. We did
>>> not put
>>> any capability in there to derive new observation types. That
>>> capability
>>> does exist in the PB2NC tool, but not in ASCII2NC. In PB2NC it's a
>>> bit
>>> easier since the observation data is grouped together for each
>>> station.
>>> For example, when we have U, we know where to find V. With
>>> ASCII2NC, the
>>> observations could show up in any order. So to be able to derive
>>> things,
>>> we'd need to store them in memory and try to match them up based on
>>> location and level. So it'd be a lot messier.
>>>
>>> Similarly, Point-Stat doesn't do any derivation. So if you want
>>> dewpoint,
>>> you'll need to compute it.
>>>
>>> Sorry about that.
>>>
>>> John
>>>
>>>> Hi again John,
>>>>
>>>> I thought of one more question. I have RH has the humidity
>>>> variable at
>>>> most of these Soil Climate Analysis Network stations. (dewpoint
>>>> is rare
>>>> in the archives)
>>>>
>>>> Can I pass on the RH to ascii2nc, for use in point_stat, with the
>>>> assumption that point_stat will compute a dewpoint temperature
>>>> from the
>>>> RH
>>>> & Temp, or will I need to compute dewpoint, and pass that to
>>>> ascii2nc?
>>>>
>>>> Thanks once again,
>>>> Jon
>>>>
>>>> -----Original Message-----
>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>> Sent: Friday, August 21, 2009 3:51 PM
>>>> To: Case, Jonathan (MSFC-VP61)[Other]
>>>> Cc: met_help at ucar.edu
>>>> Subject: RE: soil verification in MET's point_stat
>>>>
>>>> Jonathan,
>>>>
>>>> If the observation data value is missing, I'd suggest leaving it
>>>> out of
>>>> the ASCII files. If MET encounters a missing observation data
>>>> value, it
>>>> should just skip over it anyway.
>>>>
>>>> John
>>>>
>>>>> Hello John,
>>>>>
>>>>> I think I'm finally getting closer to testing out the soil
>>>>> verification
>>>>> functionality. I'm still working on the script to reformat the
>>>>> data
>>>>> for
>>>>> ascii2nc.
>>>>>
>>>>> My question to you is regarding the ascii2nc input for missing
>>>>> data.
>>>>> Would it be best to simply leave out a measurement if it's
>>>>> missing, or
>>>>> assign it to a designated numerical value corresponding to
>>>>> missing data
>>>>> (e.g. -9999)?
>>>>>
>>>>> I'm leaning to leaving it out....
>>>>> Jonathan
>>>>>
>>>>> -----Original Message-----
>>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>>> Sent: Wednesday, August 05, 2009 11:06 AM
>>>>> To: Case, Jonathan (MSFC-VP61)[Other]
>>>>> Subject: Re: soil verification in MET's point_stat
>>>>>
>>>>> Jonathan,
>>>>>
>>>>> Yes, I'd try layering them on top of METv2.0. And no, they
>>>>> shouldn't
>>>>> be
>>>>> included in the patches since they aren't bug fixes. But they
>>>>> will be
>>>>> in
>>>>> the next official version.
>>>>>
>>>>> John
>>>>>
>>>>> Case, Jonathan (MSFC-VP61)[Other] wrote:
>>>>>> John,
>>>>>>
>>>>>> I tried implementing your code changes (from your 12 May email),
>>>>>> and
>>>>>> it
>>>>>> bombed in my METv2.0beta6 because there isn't a conversions.h in
>>>>>> my
>>>>>> verison.
>>>>>>
>>>>>> Do you think I should just put your modified code into the
>>>>>> official
>>>>>> METv2.0 and try it there?
>>>>>> Also, are your mods you sent me on 12 May for soil verification
>>>>>> also
>>>>>> included in the MET patches release from 1 July? I noticed 3 of
>>>>>> the
>>>>>> same files modified in that patches release.
>>>>>>
>>>>>> Thanks for the advice,
>>>>>> Jon
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>>>> Sent: Tuesday, August 04, 2009 5:05 PM
>>>>>> To: Case, Jonathan (MSFC-VP61)[Other]
>>>>>> Cc: met_help at ucar.edu
>>>>>> Subject: RE: soil verification in MET's point_stat
>>>>>>
>>>>>> Jon,
>>>>>>
>>>>>> Yeah, I think it'd work in ASCII2NC to use different message
>>>>>> types for
>>>>>> a
>>>>>> single location. Just give it a shot and let me know if you run
>>>>>> into
>>>>>> any
>>>>>> problems.
>>>>>>
>>>>>> John
>>>>>>
>>>>>>> John,
>>>>>>>
>>>>>>> This makes sense, I think. Does this mean that for the same
>>>>>>> observation
>>>>>>> site/ID, we can assign different message_types?
>>>>>>>
>>>>>>> Jon
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>>>>> Sent: Tuesday, August 04, 2009 2:41 PM
>>>>>>> To: Case, Jonathan (MSFC-VP61)[Other]
>>>>>>> Subject: RE: soil verification in MET's point_stat
>>>>>>>
>>>>>>> Jonathan,
>>>>>>>
>>>>>>> These other observations (2-m temp, RH, and MSLP) are surface
>>>>>>> observations, right? Therefore, if you assign them a message
>>>>>>> type of
>>>>>>> "ADPSFC" or "ADPSHP", they will be treated as surface obs. And
>>>>>>> in
>>>>>>> that
>>>>>>> case, setting the level value to -9999 would be the way to go I
>>>>>>> think.
>>>>>>>
>>>>>>> So I'd try using MSONET for your soil temp observations and
>>>>>>> ADPSFC
>>>>>>> for
>>>>>>> your other surface observations.
>>>>>>>
>>>>>>> Does that make sense?
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>> Hi John,
>>>>>>>>
>>>>>>>> I now have a script working now that re-formats/converts SCAN
>>>>>>>> data
>>>>>>>> to
>>>>>>>> the
>>>>>>>> 10 columns needed for ascii2nc.
>>>>>>>> I just have one additional question for you. Should I assign a
>>>>>>>> "Level"
>>>>>>>> for 2-m temp, RH, and MSLP, which are also available from the
>>>>>>>> SCAN
>>>>>>>> sites?
>>>>>>>>
>>>>>>>> Some BG info: I have assigned these data as
>>>>>>>> message_type=MSONET and
>>>>>>>> NOT
>>>>>>>> "ADPSFC" or "SFCSHP" as you recommended in your original email
>>>>>>>> to
>>>>>>>> me.
>>>>>>>> Initially, I was thinking of setting Level=-9999 for the
>>>>>>>> standard
>>>>>>>> above-ground measurements. But I'd like to run it by you for
>>>>>>>> your
>>>>>>>> recommendation.
>>>>>>>>
>>>>>>>> Thx,
>>>>>>>> Jonathan
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>>>>>> Sent: Thursday, July 30, 2009 3:53 PM
>>>>>>>> To: Case, Jonathan (MSFC-VP61)[Other]
>>>>>>>> Subject: RE: soil verification in MET's point_stat
>>>>>>>>
>>>>>>>> Jonathan,
>>>>>>>>
>>>>>>>> I believe you should set it as 10, and not -10. The
>>>>>>>> corresponding
>>>>>>>> GRIB
>>>>>>>> records for this would store the level value as 10 and one of
>>>>>>>> the
>>>>>>>> flags
>>>>>>>> would indicate that that's 10 cm BELOW ground. In MET, we'll
>>>>>>>> just
>>>>>>>> be
>>>>>>>> comparing to the level value for the GRIB record. We won't do
>>>>>>>> anything
>>>>>>>> fancy like seeing that it's below ground and expecting the
>>>>>>>> observations
>>>>>>>> to
>>>>>>>> be negative.
>>>>>>>>
>>>>>>>> Hopefully, that'll work.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>> Hello John,
>>>>>>>>>
>>>>>>>>> It was good to meet you at the WRF workshop. It's always
>>>>>>>>> good to
>>>>>>>>> place
>>>>>>>>> a
>>>>>>>>> face with the name!
>>>>>>>>>
>>>>>>>>> I'm finally beginning to work up a conversion script to re-
>>>>>>>>> format
>>>>>>>>> the
>>>>>>>>> SCAN
>>>>>>>>> soil temp/moisture data so that ascii2nc can process it for
>>>>>>>>> use in
>>>>>>>>> MET.
>>>>>>>>> I
>>>>>>>>> had a follow-up question for you regarding the observed soil
>>>>>>>>> data.
>>>>>>>>> How do you recommend I set the "level" (column 8 input to
>>>>>>>>> ascii2nc)
>>>>>>>>> parameter for the below ground soil obs?
>>>>>>>>> Should I set Level=-10 for 10 cm below ground?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Jon
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>>>>>>> Sent: Tuesday, May 12, 2009 1:31 PM
>>>>>>>>> To: Case, Jonathan (MSFC-VP61)[Other]
>>>>>>>>> Cc: Crosson, William L. (MSFC-VP61); Blankenship, Clay B.
>>>>>>>>> (MSFC-VP61)[University Space Research Association]; met_help
>>>>>>>>> Subject: Re: soil verification in MET's point_stat
>>>>>>>>>
>>>>>>>>> Jonathan,
>>>>>>>>>
>>>>>>>>> I took a look at your data, and after making a few code
>>>>>>>>> changes,
>>>>>>>>> was
>>>>>>>>> able
>>>>>>>>> to get Point-Stat to behave as we'd like - I think.
>>>>>>>>>
>>>>>>>>> Please take a look at the attached tar file. Copy it into
>>>>>>>>> your
>>>>>>>>> METv2.0
>>>>>>>>> directory, unzip and untar it. It'll overwrite 2 files in the
>>>>>>>>> "lib/vx_met_util" directory and 1 file in the "src/point_stat"
>>>>>>>>> directory.
>>>>>>>>>
>>>>>>>>> In METv2.0, we've only allowed verification on vertical
>>>>>>>>> levels to
>>>>>>>>> be
>>>>>>>>> at
>>>>>>>>> the surface. We inherited a very simple approach for matching
>>>>>>>>> observations to the surface from the NCEP verification tools,
>>>>>>>>> and
>>>>>>>>> that
>>>>>>>>> approach is based on message type. So any observations with a
>>>>>>>>> message
>>>>>>>>> type of "ADPSFC" or "SFCSHP" is considered to be at the
>>>>>>>>> surface and
>>>>>>>>> is
>>>>>>>>> matched to surface forecasts (really any forecast defined as a
>>>>>>>>> vertical
>>>>>>>>> level such as "TMP/Z2" - the Z means vertical level).
>>>>>>>>>
>>>>>>>>> Here's how I've modified this matching logic... If we are
>>>>>>>>> comparing
>>>>>>>>> a
>>>>>>>>> forecast on a vertical level to an observation with message
>>>>>>>>> type
>>>>>>>>> "ADPSFC"
>>>>>>>>> or "SFCSHP", do as before and match the observation to the
>>>>>>>>> forecast
>>>>>>>>> value.
>>>>>>>>> However, if we are comparing a forecast on a vertical level
>>>>>>>>> to an
>>>>>>>>> observation that is NOT one of those surface message types,
>>>>>>>>> check
>>>>>>>>> to
>>>>>>>>> see
>>>>>>>>> if the observation's level value falls within the specified
>>>>>>>>> range
>>>>>>>>> of
>>>>>>>>> levels. If so, use that observation, but if not, don't use
>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>> So in your case, you should use a message type that is not
>>>>>>>>> ADPSFC
>>>>>>>>> or
>>>>>>>>> SFCSHP. Not sure which one applies best from this list:
>>>>>>>>> http://www.emc.ncep.noaa.gov/mmb/data_processing/prepbufr.doc/table_1.htm
>>>>>>>>>
>>>>>>>>> When you set up your ASCII files as input to ASCII2NC, use
>>>>>>>>> that
>>>>>>>>> message
>>>>>>>>> type. And when you run Point-Stat, setup your configuration
>>>>>>>>> file
>>>>>>>>> to
>>>>>>>>> use
>>>>>>>>> that same message type. Also, select the forecast field to be
>>>>>>>>> verified
>>>>>>>>> with something like: fcst_field = [ "TSOIL/Z0-10" ]
>>>>>>>>>
>>>>>>>>> Now suppose you're verifying soil temperature between 0 and
>>>>>>>>> 10 cm.
>>>>>>>>> All
>>>>>>>>> observations with a level value between (and including) 0 and
>>>>>>>>> 10
>>>>>>>>> should
>>>>>>>>> match it, but one with a level value of 12, for example,
>>>>>>>>> should
>>>>>>>>> not.
>>>>>>>>> Please note that there is no vertical interpolation being done
>>>>>>>>> here.
>>>>>>>>> All
>>>>>>>>> observations falling within that range are used and compared
>>>>>>>>> against
>>>>>>>>> the
>>>>>>>>> single value defined for that forecast layer.
>>>>>>>>>
>>>>>>>>> Please try these changes out and see if it does what you'd
>>>>>>>>> like.
>>>>>>>>> If
>>>>>>>>> so,
>>>>>>>>> I'll need to do more testing to make sure I haven't broken
>>>>>>>>> anything
>>>>>>>>> else
>>>>>>>>> with these changes!
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> John
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Case, Jonathan (MSFC-VP61)[Other] wrote:
>>>>>>>>>> Hi John,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I uploaded to your ftp site a sample GRIB-1 file at the model
>>>>>>>>>> analysis
>>>>>>>>>> time of 03z 1 June 2008. I also uploaded 3 sample files of
>>>>>>>>>> the
>>>>>>>>>> SCAN
>>>>>>>>>> soil obs (sorry for the hideous way the data are stored!)
>>>>>>>>>> from
>>>>>>>>>> June
>>>>>>>>>> 2008. Unfortunately, instead of columns continuing into a
>>>>>>>>>> long
>>>>>>>>>> row,
>>>>>>>>>> the
>>>>>>>>>> OBS archive re-starts the data from obs#1 into a new set of
>>>>>>>>>> rows/columns. But don't worry -- I'll write a conversion
>>>>>>>>>> script
>>>>>>>>>> so
>>>>>>>>>> that
>>>>>>>>>> it can be shoved through ascii2nc.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I suppose for what you need to do, you can simply pull a
>>>>>>>>>> line of
>>>>>>>>>> data
>>>>>>>>>> valid at 03z 1 June 2008, and use those obs in ascii2nc and
>>>>>>>>>> point_stat
>>>>>>>>>> for testing your code changes.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The problem we're dealing with is to verify soil LAYER data
>>>>>>>>>> in the
>>>>>>>>>> model
>>>>>>>>>> (at 0-10cm, 10-40cm, 40-100cm, and 100-200cm) against data
>>>>>>>>>> valid
>>>>>>>>>> at
>>>>>>>>>> specific LEVELS in the OBS.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The variables we have from the obs are:
>>>>>>>>>>
>>>>>>>>>> * C1SMV = soil moisture percent at 2 cm depth
>>>>>>>>>>
>>>>>>>>>> * C2SMV = soil moisture percent at 4 cm depth
>>>>>>>>>>
>>>>>>>>>> * C3SMV = soil moisture percent at 8 cm depth
>>>>>>>>>>
>>>>>>>>>> * C4SMV = soil moisture percent at 20 cm depth
>>>>>>>>>>
>>>>>>>>>> * C5SMV = soil moisture percent at 40 cm depth
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Similarly,
>>>>>>>>>>
>>>>>>>>>> * C1TMP = soil temperature at 2 cm depth
>>>>>>>>>>
>>>>>>>>>> * C2TMP = soil temperature at 4 cm depth
>>>>>>>>>>
>>>>>>>>>> * C3TMP = soil temperature at 8 cm depth
>>>>>>>>>>
>>>>>>>>>> * C4TMP = soil temperature at 20 cm depth
>>>>>>>>>>
>>>>>>>>>> * C5TMP = soil temperature at 40 cm depth
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I might be inclined to average the 2, 4, and 8 cm obs either
>>>>>>>>>> straight
>>>>>>>>>> up, or in a weighted average to compare to the 0-10 cm model
>>>>>>>>>> layer
>>>>>>>>>> in
>>>>>>>>>> Noah/WRF. And similarly, I might average out the 20 cm and
>>>>>>>>>> 40 cm
>>>>>>>>>> OBS
>>>>>>>>>> to
>>>>>>>>>> compare to the model's 10-40 cm layer.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Let's see what we can best figure out because I'm sure there
>>>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>> others who would like to verify soil quantities using MET
>>>>>>>>>> (including
>>>>>>>>>> my
>>>>>>>>>> 2 co-workers whom I CC'd).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>>>>>>>>> Sent: Friday, May 08, 2009 2:00 PM
>>>>>>>>>>> To: Case, Jonathan (MSFC-VP61)[Other]; met_help
>>>>>>>>>>> Subject: Re: soil verification in point_stat
>>>>>>>>>>
>>>>>>>>>>> Jonathan,
>>>>>>>>>>
>>>>>>>>>>> Since I've never run MET on layers like this, I'm really
>>>>>>>>>>> not sure
>>>>>>>>>>> either.
>>>>>>>>>>
>>>>>>>>>>> Looking closer at the code, MET is only really set up to
>>>>>>>>>>> verify
>>>>>>>>>>> forecasts
>>>>>>>>>>> as the surface: precip at surface, 2-meter temp, 10-meter
>>>>>>>>>>> winds.
>>>>>>>>>>> And
>>>>>>>>>>> we're
>>>>>>>>>>> matching to observations based on message type -
>>>>>>>>>>> all observations with a level type of ADPSFC or SFCSHP are
>>>>>>>>>>> matched
>>>>>>>>>>> to
>>>>>>>>>>> those
>>>>>>>>>>> surface forecasts.
>>>>>>>>>>
>>>>>>>>>>> I think we'll need to modify the code slightly to handle
>>>>>>>>>>> your
>>>>>>>>>>> case.
>>>>>>>>>>> In
>>>>>>>>>>> particular, we'll need to adjust the logic in the
>>>>>>>>>>> "GCPairData::add_obs()"
>>>>>>>>>>> routine in the file METv2.0/lib/vx_met_util/met_stats.cc.
>>>>>>>>>>
>>>>>>>>>>> Would you be able to send me a sample GRIB1 file along
>>>>>>>>>>> with a
>>>>>>>>>>> handful
>>>>>>>>>>> - 10
>>>>>>>>>>> would be fine - of fake ASCII observations? I could take a
>>>>>>>>>>> look
>>>>>>>>>>> and
>>>>>>>>>>> see
>>>>>>>>>>> what changes would need to be made to get MET
>>>>>>>>>>> working the way you'd want.
>>>>>>>>>>
>>>>>>>>>>> You could post them to RAL's anonymous ftp site:
>>>>>>>>>>
>>>>>>>>>>> ftp ftp.rap.ucar.edu
>>>>>>>>>>> username = anonymous
>>>>>>>>>>> password = "your email address"
>>>>>>>>>>> cd incoming/irap/johnhg
>>>>>>>>>>> put "your files"
>>>>>>>>>>> bye
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> John
>>>>>>>>>>
>>>>>>>>>>> Case, Jonathan (MSFC-VP61)[Other] wrote:
>>>>>>>>>>>> John,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> I figured that the vertical interpolation would best be
>>>>>>>>>>>> handled
>>>>>>>>>>>> outside
>>>>>>>>>>> of MET, so that is what I plan to do. I will assign the
>>>>>>>>>>> OBS to
>>>>>>>>>>> the
>>>>>>>>>>> valid
>>>>>>>>>>> layer in the model.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> With that, I hinted at my WRF configuration. I'm running
>>>>>>>>>>>> with
>>>>>>>>>>>> the
>>>>>>>>>>>> Noah
>>>>>>>>>>> LSM with soil layers of 0-10, 10-40, 40-100, and 100-200 cm.
>>>>>>>>>>> Given
>>>>>>>>>>> those
>>>>>>>>>>> layers, how should I go about assigning the OBS to the model
>>>>>>>>>>> layer
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> ascii2nc process?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Here's what in the WRF GRIB-1 file:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> lc2:/usr/people/casejl/tmp/seus_2008062103/control > wgrib
>>>>>>>>>>> WRFPRS00.tm00.d01 | grep SOILW
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 86
>>>>>>>>>>> :
>>>>>>>>>>> 13184188
>>>>>>>>>>> :d=08062103:SOILW:kpds5=144:kpds6=112:kpds7=10:TR=0:P1=0:P
>>>>>>>>>>> 2=0:Ti
>>>>>>>>>>> meU=1:0-10 cm down:anl:NAve=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 88
>>>>>>>>>>> :
>>>>>>>>>>> 13482750
>>>>>>>>>>> :d
>>>>>>>>>>> =
>>>>>>>>>>> 08062103
>>>>>>>>>>> :SOILW:kpds5=144:kpds6=112:kpds7=2600:TR=0:P1=0:P2=0:
>>>>>>>>>>> TimeU=1:10-40 cm down:anl:NAve=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 90
>>>>>>>>>>> :
>>>>>>>>>>> 13781312
>>>>>>>>>>> :d=08062103:SOILW:kpds5=144:kpds6=112:kpds7=10340:TR=0:P1=
>>>>>>>>>>> 0:P2=0
>>>>>>>>>>> :TimeU=1:40-100 cm down:anl:NAve=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 92
>>>>>>>>>>> :
>>>>>>>>>>> 14079874
>>>>>>>>>>> :d=08062103:SOILW:kpds5=144:kpds6=112:kpds7=25800:TR=0:P1=
>>>>>>>>>>> 0:P2=0
>>>>>>>>>>> :TimeU=1:100-200 cm down:anl:NAve=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> lc2:/usr/people/casejl/tmp/seus_2008062103/control > wgrib
>>>>>>>>>>> WRFPRS00.tm00.d01 | grep TSOIL
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 85
>>>>>>>>>>> :
>>>>>>>>>>> 13005070
>>>>>>>>>>> :d=08062103:TSOIL:kpds5=85:kpds6=112:kpds7=10:TR=0:P1=0:P2
>>>>>>>>>>> =0:Tim
>>>>>>>>>>> eU=1:0-10 cm down:anl:NAve=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 87
>>>>>>>>>>> :
>>>>>>>>>>> 13303632
>>>>>>>>>>> :d=08062103:TSOIL:kpds5=85:kpds6=112:kpds7=2600:TR=0:P1=0:
>>>>>>>>>>> P2=0:T
>>>>>>>>>>> imeU=1:10-40 cm down:anl:NAve=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 89
>>>>>>>>>>> :
>>>>>>>>>>> 13602194
>>>>>>>>>>> :d
>>>>>>>>>>> =
>>>>>>>>>>> 08062103
>>>>>>>>>>> :TSOIL:kpds5=85:kpds6=112:kpds7=10340:TR=0:P1=0:P2=0:
>>>>>>>>>>> TimeU=1:40-100 cm down:anl:NAve=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 91
>>>>>>>>>>> :
>>>>>>>>>>> 13900756
>>>>>>>>>>> :d
>>>>>>>>>>> =
>>>>>>>>>>> 08062103
>>>>>>>>>>> :TSOIL:kpds5=85:kpds6=112:kpds7=25800:TR=0:P1=0:P2=0:
>>>>>>>>>>> TimeU=1:100-200 cm down:anl:NAve=0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> Thanks much!
>>>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>
>>>>>>>>>>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>>>>>>>>
>>>>>>>>>>>>> Sent: Friday, May 08, 2009 12:16 PM
>>>>>>>>>>
>>>>>>>>>>>>> To: Case, Jonathan (MSFC-VP61)[Other]
>>>>>>>>>>
>>>>>>>>>>>>> Cc: met_help
>>>>>>>>>>
>>>>>>>>>>>>> Subject: Re: soil verification in point_stat
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> Jonathan,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> As a short answer I'd say, yes, you could probably use
>>>>>>>>>>>>> Point-Stat
>>>>>>>>>>>>> to
>>>>>>>>>>> verify
>>>>>>>>>>
>>>>>>>>>>>>> soil moisture and temperature observations from WRF.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> ...BUT... I don't think you'll be able to do any vertical
>>>>>>>>>>>>> interpolation
>>>>>>>>>>
>>>>>>>>>>>>> without some code changes. Right now, Point-Stat is only
>>>>>>>>>>>>> set
>>>>>>>>>>>>> up
>>>>>>>>>>>>> to
>>>>>>>>>>>>> do
>>>>>>>>>>
>>>>>>>>>>>>> vertical interpolation for pressure levels... and that's
>>>>>>>>>>
>>>>>>>>>>>>> done linear in the log of pressure.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> Here's what I'd recommend...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> (1) Take a look at the soil moisture and temperature
>>>>>>>>>>>>> fields you
>>>>>>>>>>>>> have
>>>>>>>>>>> from
>>>>>>>>>>
>>>>>>>>>>>>> WRF. Depending on which "surface scheme" (I think that's
>>>>>>>>>>>>> right)
>>>>>>>>>>>>> you're
>>>>>>>>>>
>>>>>>>>>>>>> using, the soil moisture fields may be at a single
>>>>>>>>>>
>>>>>>>>>>>>> levels or a layer of levels. If it's in layers, you
>>>>>>>>>>>>> probably
>>>>>>>>>>>>> wouldn't
>>>>>>>>>>> want
>>>>>>>>>>
>>>>>>>>>>>>> to interpolate in the vertical. You'd just like to match
>>>>>>>>>>>>> the
>>>>>>>>>>> observation
>>>>>>>>>>
>>>>>>>>>>>>> to the forecast value for the layer in which the
>>>>>>>>>>
>>>>>>>>>>>>> observation falls. If it's single levels, you may want to
>>>>>>>>>>>>> consider
>>>>>>>>>>
>>>>>>>>>>>>> interpolating.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> (2) Take a look at the observation levels. Are they all
>>>>>>>>>>>>> at
>>>>>>>>>>>>> some
>>>>>>>>>>>>> set of
>>>>>>>>>>
>>>>>>>>>>>>> "standard" depths or do the depths vary greatly?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> Here's one approach that may be pretty easy:
>>>>>>>>>>
>>>>>>>>>>>>> - Assuming that your forecasts are in single levels.
>>>>>>>>>>
>>>>>>>>>>>>> - Assuming that your observations are at some set of
>>>>>>>>>>>>> "standard"
>>>>>>>>>>>>> depths.
>>>>>>>>>>
>>>>>>>>>>>>> - When you pre-process the observations to prepare them
>>>>>>>>>>>>> for
>>>>>>>>>>>>> ASCII2NC,
>>>>>>>>>>> just
>>>>>>>>>>
>>>>>>>>>>>>> round the level value for the observation to the nearest
>>>>>>>>>>>>> depth
>>>>>>>>>>>>> you
>>>>>>>>>>>>> have
>>>>>>>>>>> in
>>>>>>>>>>
>>>>>>>>>>>>> your model output.
>>>>>>>>>>
>>>>>>>>>>>>> - Then run Point-Stat to verify at each of your model
>>>>>>>>>>>>> depths
>>>>>>>>>>>>> (i.e.
>>>>>>>>>>>>> no
>>>>>>>>>>
>>>>>>>>>>>>> vertical interpolation).
>>>>>>>>>>
>>>>>>>>>>>>> - You could even dump out the matched pair (MPR) line
>>>>>>>>>>>>> type for
>>>>>>>>>>>>> all
>>>>>>>>>>>>> of
>>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>>>> levels and use the Stat-Analysis tool to aggregate across
>>>>>>>>>>>>> levels
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> I've never done this before, but you could *probably* do
>>>>>>>>>>>>> that
>>>>>>>>>>>>> approach
>>>>>>>>>>> with
>>>>>>>>>>
>>>>>>>>>>>>> no code changes. However, if you'd like to do more
>>>>>>>>>>>>> sophisticated
>>>>>>>>>>> vertical
>>>>>>>>>>
>>>>>>>>>>>>> interpolation, I may be able to point you in the
>>>>>>>>>>
>>>>>>>>>>>>> right direction as for what code to modify.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> Hope that helps.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> John
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>> Case, Jonathan (MSFC-VP61)[Other] wrote:
>>>>>>>>>>
>>>>>>>>>>>>>> Thank you John!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> I have another question for you regarding point_stat.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> I would like to use observations from SCAN (Soil Climate
>>>>>>>>>>>>>> Analysis
>>>>>>>>>>
>>>>>>>>>>>>> Network) to verify soil moisture and temperature
>>>>>>>>>>>>> observations
>>>>>>>>>>>>> in
>>>>>>>>>>>>> the WRF
>>>>>>>>>>
>>>>>>>>>>>>> model. Is there a way we could use point_stat for
>>>>>>>>>>> processing/interpolating
>>>>>>>>>>
>>>>>>>>>>>>> data for soil verification? I don't have the exact specs
>>>>>>>>>>>>> yet
>>>>>>>>>>>>> on
>>>>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>>>> observations, but it would probably require a vertical
>>>>>>>>>>>>> interpolation or
>>>>>>>>>>
>>>>>>>>>>>>> nearest-neighbor assignment of a soil layer to the sensor
>>>>>>>>>>>>> obs
>>>>>>>>>>>>> depth. I
>>>>>>>>>>
>>>>>>>>>>>>> figure that if could use ascii2nc to pre-process the data
>>>>>>>>>>>>> into
>>>>>>>>>>>>> a
>>>>>>>>>>>>> netcdf
>>>>>>>>>>
>>>>>>>>>>>>> file with the same variable naming convention as the WRF
>>>>>>>>>>>>> GRIB
>>>>>>>>>>>>> output,
>>>>>>>>>>> then
>>>>>>>>>>
>>>>>>>>>>>>> I might be able to pull it off.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>> Thanks in advance,
>>>>>>>>>>
>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>
>>>>>>>>>>>>>>> From: John Halley Gotway [mailto:johnhg at rap.ucar.edu]
>>>>>>>>>>
>>>>>>>>>>>>>>> Sent: Friday, May 08, 2009 8:47 AM
>>>>>>>>>>
>>>>>>>>>>>>>>> To: Case, Jonathan (MSFC-VP61)[Other]; met_help
>>>>>>>>>>
>>>>>>>>>>>>>>> Subject: Re: formatted output in mode_analysis
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>> Jonathan,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>> Take a look in METv2.0/lib/vx_analysis_util/
>>>>>>>>>>>>>>> mode_job.cc. In
>>>>>>>>>>>>>>> lines 458
>>>>>>>>>>
>>>>>>>>>>>>>>> to 485, change all instances of "%.2f" to "%.3f". That
>>>>>>>>>>>>>>> should
>>>>>>>>>>> increase
>>>>>>>>>>
>>>>>>>>>>>>>>> your precision by 1.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>>>>>>> John
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>> Case, Jonathan (MSFC-VP61)[Other] wrote:
>>>>>>>>>>
>>>>>>>>>>>>>>>> John,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> I would like to output an addition decimal place in the
>>>>>>>>>>>>>>>> mode_analysis
>>>>>>>>>>
>>>>>>>>>>>>>>> -summary output to have 3 decimal places.
>>>>>>>>>>
>>>>>>>>>>>>>>>> What line(s)/file(s) should I modify in order to get 1
>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>> decimal
>>>>>>>>>>
>>>>>>>>>>>>>>> point precision?
>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks much!
>>>>>>>>>>
>>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>> ***********************************************************
>>>>>>>>>>
>>>>>>>>>>>>>>>> Jonathan Case, ENSCO, Inc.
>>>>>>>>>>
>>>>>>>>>>>>>>>> Aerospace Sciences & Engineering Division
>>>>>>>>>>
>>>>>>>>>>>>>>>> Short-term Prediction Research and Transition Center
>>>>>>>>>>
>>>>>>>>>>>>>>>> 320 Sparkman Drive, Room 3062
>>>>>>>>>>
>>>>>>>>>>>>>>>> Huntsville, AL 35805-1912
>>>>>>>>>>
>>>>>>>>>>>>>>>> Voice: (256) 961-7504 Fax: (256) 961-7788
>>>>>>>>>>
>>>>>>>>>>>>>>>> Emails: Jonathan.Case-1 at nasa.gov
>>>>>>>>>>
>>>>>>>>>>>>>>>> case.jonathan at ensco.com
>>>>>>>>>>
>>>>>>>>>>>>>>>> ***********************************************************
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
More information about the Met_help
mailing list