20000804: DATTIM when plotting NGM MOS

Chris,

Quick question here...
Did you need to copy your dcnmos into ~ldm/decoders or somewhere 
to update your runnig copy- just to check to make sure you aren't 
still using the old copy. The first time should be 6Z or 18Z.

Steve Chiswell


>From: address@hidden (Chris Hennon)
>Organization: UCAR/Unidata
>Keywords: 200008050034.e750YfT20302

>Steve -
>
>I may be screwing something up, but I installed your patch and I'm getting
>the same error. When I run sflist on the nmos file, I get:
>
> SFFILE    Surface data file                 2000080200_nmos.gem
> AREA      Data area                         dset
> DATTIM    Date/time                         list
> SFPARM    Surface parameter list            text
> OUTPUT    Output device/filename            t
> IDNTYP    STNM or STID                      STID
> Parameters requested: SFFILE,AREA,DATTIM,SFPARM,OUTPUT,IDNTYP.
> GEMPAK-SFLIST>sffile = 2000080412_nmos.gem
> GEMPAK-SFLIST>r
>
> List of times: 
>
> 000804/1200       000804/1800       000804/2100       000805/0000    
> 000805/0300       000805/0600       000805/0900       000805/1200    
> 000805/1500       000805/1800       000805/2100       000806/0000    
> 000806/0300       000806/0600       000806/0900       000806/1200    
> 000806/1500       000806/1800       000806/2100       000807/0000    
>
>
>Enter a time or type EXIT:
>
>Should the first time still be the analysis time?  Thanks.
>
>Chris 
>
>
>On Mon, 31 Jul 2000, Unidata Support wrote:
>
>> 
>> Chris,
>> 
>> The reason that you are having trouble with dattim=all is that
>> the TEXT is being stored in the file as the initial time, whereas the foreca
> st 
>> data start at the 6 hour offset.
>> 
>> So, when oabsfc gets the list of times in the file, the first time has no
>> data (only the TEXT of the mos bulletin which you can list out with sflist).
>> In the new release of GEMPAK, this has been changed so that the TEXT is stor
> ed 
>> with the data of the FIRST time- which is 6 or 18Z.
>> 
>> You can see this, if you use sflist with dattim=list. The list of times
>> currently will have the bulletin time (0 or 12Z with only the TEXT sfparm).
>> You can use sfdelt to delete this time out of the file if you desire.
>> Then the gridding will work for dattim=all. I give you that solution if you
>> need to use any old data you have already decoded. 
>> 
>> To fix this in your copy of dcnmos to match the way the data will be stored 
> in the 
>> new version, I have posted a patch to $GEMPAKHOME/source/programs/dc/dcnmos/
> dcnmdc.f
>> in ~gbuddy/nawips-5.4/patches/.
>> 
>> You can download the dcnmdc.f into your $GEMPAKHOME/source/programs/dc/dcnmo
> s/
>> directory, then rebuild your dcnmos with:
>> 
>> cd $GEMPAKHOME/source/programs/dc/dcnmos/
>> make clean
>> make all
>> make install
>> make clean
>> 
>> Steve Chiswell
>> Unidata User Support
>> 
>> 
>> 
>> 
>> >From: address@hidden (Chris Hennon)
>> >Organization: UCAR/Unidata
>> >Keywords: 200007282124.e6SLOqT13406
>> 
>> >Steve -
>> >
>> >I put the file 'chris_osu.tar' in the incoming directory.
>> >
>> >Chris
>> >
>> >================================================
>> >| Chris Hennon             Ohio State University   |
>> >| Tropical Meteorology      address@hidden   |
>> >|                                              |
>> >| Dept of Geography   Office: 1155 Derby Hall  |
>> >| 1036 Derby Hall     Phone : (614) 292-2704   |
>> >| Columbus, OH 43210  Fax   : (614) 292-6213   |
>> >================================================
>> >
>> >On Thu, 27 Jul 2000, Unidata Support wrote:
>> >
>> >> 
>> >> Chris,
>> >> 
>> >> This is strange. I ran this on SOlaris which I believe you are too, and e
> ver
>> > ything
>> >> worked. Normally, with that error, I would suspect that the station table
>  fo
>> > r
>> >> the lat/lon information for all the decoded surface data was missing, so 
> tha
>> > t
>> >> the too few stations wouldactually be true....but, since it works for a s
> ing
>> > le time,
>> >> then that means that there should be lat/lon info in it.
>> >> 
>> >> Can you ftp to ~gbuddy/incomin your ngm file, the grid file you are attem
> pti
>> > ng
>> >> to write to, and your oabsfc executable?
>> >> 
>> >> Thanks,
>> >> 
>> >> Steve Chiswell
>> >> Unidata User Support
>> >> 
>> >> 
>> >> >From: address@hidden (Chris Hennon)
>> >> >Organization: UCAR/Unidata
>> >> >Keywords: 200007271435.e6REZQT17298
>> >> 
>> >> >Steve -
>> >> >
>> >> >My input to OABSFC looks like:
>> >> >
>> >> > GEMPAK-OABSFC>l
>> >> > SFFILE   = 2000072700_nmos.gem
>> >> > GDFILE   = $HOME/grids/ngmmos.grd
>> >> > SFPARM   = sknt
>> >> > DATTIM   = all
>> >> > DTAAREA  = dset
>> >> > GUESS    = 
>> >> > GAMMA    = 0.3
>> >> > SEARCH   = 20
>> >> > NPASS    = 2
>> >> >
>> >> >When I run it like that, I get back:
>> >> >
>> >> >GEMPAK-OABSFC>r
>> >> > [OABSFC 6]  WARNING:  Area is not DATA area in file.
>> >> > [OABSFC -7]  There are too few stations in data subset area.
>> >> > [OABSFC 9]  No data from 2000072700_nmos.gem will be used.
>> >> > [OABSFC -9]  No valid parameters have been entered.
>> >> > Parameters requested: SFFILE,GDFILE,SFPARM,DATTIM,DTAAREA,GUESS,GAMMA,
>> >> > SEARCH,NPASS.
>> >> >
>> >> >When I change dattim to 000727/06, it runs normally and performs the
>> >> >analysis.  Sorry I wasn't as specific last time.
>> >> >
>> >> >Chris
>> >> >
>> >> >================================================
>> >> >| Chris Hennon          Ohio State University   |
>> >> >| Tropical Meteorology      address@hidden   |
>> >> >|                                              |
>> >> >| Dept of Geography   Office: 1155 Derby Hall  |
>> >> >| 1036 Derby Hall     Phone : (614) 292-2704   |
>> >> >| Columbus, OH 43210  Fax   : (614) 292-6213   |
>> >> >================================================
>> >> >
>> >> 
>> >> *************************************************************************
> ***
>> >> Unidata User Support                                    UCAR Unidata Prog
> ram
>> >> (303)497-8644                                                  P.O. Box 3
> 000
>> >> address@hidden                                   Boulder, CO 80
> 307
>> >> -------------------------------------------------------------------------
> ---
>> >> Unidata WWW Service                        http://www.unidata.ucar.edu/  
>    
>> >> *************************************************************************
> ***
>> >> 
>> >
>> 
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>