[Met_help] soil verification in MET's point_stat

[John Halley Gotway]

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
>>>>>>>
>>>>>>>>>>>>> ***********************************************************
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>