[Met_help] soil verification in MET's point_stat

[John Halley Gotway]

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