[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20001018: 20001018: METAR reports, cloud types and precip groups



Christian,

First, sfmap will plot the hourly observation for the top of the hour, 
not the SPECI. 

As shown below, KBTV shows in the RMKS section: AO2
This means that this station is automated, so without an observer
present, you probably wont get cloud types.

The METAR decoder follows FMH-1:
http://www.nws.noaa.gov/oso/oso1/oso12/fmh1/fmh1ch12.htm#ch12link

12.7.2 Additive and Automated Maintenance Data. Additive data groups are 
only reported at designated stations. The maintenance data groups are only 
reported from automated stations.

12.7.2  b. Cloud Types (8/CLCMCH).  At designated stations, the group,
     8/CLCMCH, shall be reported and coded in 3- and 6-hourly reports
     when clouds are observed.  The predominant low cloud (CL), middle
     cloud (CM), and high cloud (CH), shall be identified in
     accordance with the WMO International Cloud Atlas, Volumes I and II,
     or the WMO Abridged International Cloud Atlas or agency observing
     aids for cloud identification.  A 0 shall be coded for the low,
     middle, or high cloud type if no cloud is present in that classification.
     A solidus "/" shall be coded for layers above an overcast.  If no
     clouds are observed due to clear skies, the cloud type group shall not
     be coded.  For example, a report of "8/6//" would indicate an overcast
     layer of stratus clouds; a report of "8/903" would indicate cumulonimbus
     type low clouds, no middle clouds, and dense cirrus high clouds.

Since the CYUL report doesn't fit that format, that would explain why
they aren't decoded. The WMO 306 FM-15-IX doesn't provide for this
group (which I suppose is why it is reported in the
RMK section, national specific codes). Do you have a refernce for
Canadian METAR coding practices?

In regards to the accumulation of Precip, yes, it is only what is reported at 
the 3 
hourly intervals. It won't appear otherwise. The data is only what is reported,
and not calculated from other reports. The only way to sum these
accumulations would be to provide an external program (sfmap does not have this 
capability).

Steve Chiswell




>From: Christian Page <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200010181911.e9IJBD420625

>
>> >1- I am including cloud types in my parameters when using SFMAP :
>> >Example :
>> >SFPARM = skyc;tmpc;wsym;pmsl;ptnd;dwpc;p24m;csyh;brbk:.7:2;csyl;csym
>> >
>> >But the cloud type symbols only appears for very few stations (1 or 2) for 
> my
>> >Northeast plot. Why?
>> 
>> Can you provide me an example? Are you saying that the station is reporting
>> cloud types and not getting plotted- or, why don't stations report this
>> information.
>> 
>> The cloud type information is provided in the 8/ group of a metar remarks
>> section, for example:
>> 
>> SFPARM=csyl;csym;csyh;text
>> 
>>     STN    YYMMDD/HHMM      CSYL     CSYM     CSYH
>>     BUF    001018/1200      6.00     0.00     0.00
>> 
>> 
>> KBUF 181154Z 00000KT 3SM BR SCT007 OVC010 11/10 A3010 RMK AO2 SFC VIS 4 SLP1
> 94 8/6// 60001 70008 T01060100 10117 20100 51013
>> 
>> You see that the 8/6// group provides that CSYL=6. Cloud groups are
>> reported at 3 hourly intervals. Also, you have to have an observer 
>> to report those groups.
>> 
>
>I tried to look for that at, by example, KBTV, but couldn't find any. Also, fo
> r
>Canadian stations, it is not reported the same way... by example for CYUL. May
> be
>it is the same for European stations?
>
>KBTV:
>METAR KBTV 181654Z 17014KT 6SM RA BR FEW008 BKN034 OVC050 10/09 
>A3005 RMK AO2 SLP178 P0004 T01000089
>METAR KBTV 181754Z 17011KT 10SM FEW008 SCT029 OVC044 11/09 A3003 RMK 
>AO2 RAE38 SLP172 P0001 60027 T01060094 10106 20089 58018
>METAR KBTV 181854Z 16008KT 10SM FEW008 OVC038 11/10 A3002 RMK AO2 
>SLP169 T01110100
>
>CYUL:
>METAR CYUL 181600Z 17010KT 4SM -RA BR BKN005 BKN011 OVC022 10/10
>A3002 RMK SF5SC2SC2 SLP168=
>METAR CYUL 181700Z 17008KT 6SM -RA BR SCT005 BKN011 OVC020 11/11
>A3000 RMK SF3SC2SC2 SLP161=
>METAR CYUL 181800Z 18007KT 10SM -RA SCT005 BKN009 OVC020 11/11 A2999
>RMK SF3SC3SC2 SLP155=
>
>LFPG (Paris, France):
>LFPG 181600Z 18011KT 3500 -DZRA FEW002 SCT003 BKN005 13/12 Q1018
>NOSIG=
>LFPG 181700Z 19010KT 3500 -DZRA SCT003 BKN004 BKN006 13/12 Q1018
>NOSIG=
>LFPG 181800Z 19010KT 3000 -RA FEW002 OVC004 13/12 Q1018 NOSIG=
>LFPG 181900Z 19011KT 3000 -RA FEW002 OVC006 13/13 Q1017 NOSIG=
>
>Cloud types for CYUL are reported with SF5SC2SC2 by example. For France, I don
> 't
>know. For Burlington, Vermont, I don't know either. When I specify to GEMPAK t
> o
>plot 1500Z, by example, which time does it use? The closest one (by example if
>there are SPECI obs)?
>
>
>> >2- Is it possible to plot accumulation of precipitation in mm for the last 
> 24h
>> > ,
>> >as well as accumulation of precipitation since the last 12h?
>> 
>> The P03x and P06x groups provide 3 hourly and 6 hourly accumulation.
>> These are the fields provided in the METAR report using the 6RRRR group.
>> The 24 hour accumulation is given in the 7RRRR group.
>> Again, these groups will most likely be found every 3 hours of reporting.
>> 
>
>Thanks, I will try that. Is it possible to sum data with GEMPAK, or it is not
>possible? And if I try to plot accum with GEMPAK, since it is reported each 3
>hour, must I run GEMPAK exactly the hour of reporting?
>
>
>> >
>> >On Wed, 18 Oct 2000, Unidata Support wrote:
>> >
>> >> 
>> >> Christian,
>> >> 
>> >> No, its not possible to store ship/buoy in the same output file
>> >> as METAR observations using the real-time decoders for several reasons:
>> >> 
>> >> 1) The ship file format is different than standard surface files.
>> >> The decoded METAR file uses a station table of fixed locations,
>> >> where Montreal for example is in the same place at every time in
>> >> the file, so that information ins only stored once. A ship on the other
>> >> hand can have a different position for every time, so that position infor
> mat
>> > ion
>> >> is stored as variables along with the reported data at every time.
>> >> 
>> >> 2) If both dchrly and dcsynop try to write data to the same file at the
>> >> same time, the output file will become corrupted.
>> >> 
>> >> 3) The parameters reported by surface land stations are different than 
>> >> marine stations report.
>> >> 
>> >> What you can do is merge the decoded data into a common file for plotting
> .
>> >> 
>> >> Start by creating an empty standard surface file with enough space for yo
> ur
>> >> ship and metar data. You will want a different file for every hour you
>> >> merge since ships will move with time. Specify what parameters you want
>> >> in the merged file using SFPRMF:
>> >> 
>> >>  SFOUTF   = testsf.gem
>> >>  SFPRMF   = tmpc;dwpc;sped;drct;pmsl
>> >>  STNFIL   =  
>> >>  SHIPFL   = n
>> >>  TIMSTN   = 24/5000
>> >>  SFFSRC   =  
>> >>  GEMPAK-SFCFIL>r
>> >> 
>> >>  SFCFIL PARAMETERS: 
>> >> 
>> >>  New surface file:      testsf.gem                                       
>    
>> >         
>> >>  Parameter file:        tmpc;dwpc;sped;drct;pmsl                         
>    
>> >         
>> >>  Station file:                                                           
>    
>> >         
>> >>  Number of stations in STNFIL:       0
>> >>  Number of additional stations:   5000
>> >>  Total number of stations:        5000
>> >>  Total number of times:             24
>> >> 
>> >>  This file will be a standard surface file.
>> >> 
>> >> Enter <cr> to accept parameters or type EXIT:
>> >>  Parameters requested: SFOUTF,SFPRMF,STNFIL,SHIPFL,TIMSTN,SFFSRC.
>> >>  GEMPAK-SFCFIL>e
>> >> 
>> >> 
>> >> 
>> >> Then copy the metar data into the surface file (the parameters
>> >> found in the file that match those in the file you created with
>> >> sfcfil will be copied):
>> >> 
>> >>  SFFILE   = 20001018_sao.gem
>> >>  SFOUTF   = testsf.gem
>> >>  DATTIM   = 18/1200
>> >>  AREA     = dset
>> >>  GEMPAK-SFMOD>r
>> >> 
>> >>  SFMOD PARAMETERS: 
>> >> 
>> >>  Input file:        ./20001018_sao.gem
>> >>  Output file:       testsf.gem
>> >>  Area:              dset
>> >>  Date/time          001018/1200
>> >> 
>> >> Enter <cr> to accept parameters or type EXIT:
>> >>  Parameters requested: SFFILE,SFOUTF,DATTIM,DATOUT,AREA,SFPARM.
>> >>  GEMPAK-SFMOD>e
>> >> 
>> >> 
>> >> And copy the ship data into the file:
>> >> 
>> >>  SFFILE   = $GEMDATA/ship/2000101812_sb.gem
>> >>  SFOUTF   = testsf.gem
>> >>  DATTIM   = 18/1200
>> >>  AREA     = dset
>> >>  GEMPAK-SFMOD>r
>> >> 
>> >>  SFMOD PARAMETERS: 
>> >> 
>> >>  Input file:    $GEMDATA/ship/2000101812_sb.gem                          
>    
>> >             
>> >>  Output file:   testsf.gem                                               
>    
>> >             
>> >>  Area:          dset                                                     
>    
>> >             
>> >>  Date/time      001018/1200         
>> >> 
>> >> Enter <cr> to accept parameters or type EXIT:
>> >>  Parameters requested: SFFILE,SFOUTF,DATTIM,AREA.
>> >>  GEMPAK-SFMOD>
>> >> 
>> >> Now you can plot the data using sfmap etc from the common file.
>> >> 
>> >> Steve Chiswell
>> >> Unidata User Support
>> >> 
>> >> 
>> >> 
>> >> 
>> >> >From: Christian Page <address@hidden>
>> >> >Organization: UCAR/Unidata
>> >> >Keywords: 200010181407.e9IE7v406965
>> >> 
>> >> >
>> >> >Hi again, another question now : is it possible to store ship and buoy d
> ata
>> >  in
>> >> >the same gempak file as the hourly metar data and plot everything at onc
> e? 
>> > Can
>> >> >  I
>> >> >still use the same dcsynop command in pqact.conf (of course I substitute
>  th
>> > e
>> >> >output gempak filename with the one I use for hourly surface metar data)
> ? I
>> >> >tried and I get some error in the logs :
>> >> >
>> >> >DCSYNOP[17940445]: 001018/1400: [DCSYNOP -21] error writing data: 73502 
>   f
>> > or 
>> >> > 00
>> >> >1018/0900
>> >> >DCSYNOP[17940445]: 001018/1400: [DCSYNOP -21] error writing data: 73509 
>   f
>> > or 
>> >> > 00
>> >> >1018/0900
>> >> >DCSYNOP[17940445]: 001018/1400: [DCSYNOP -21] error writing data: 74531 
>   f
>> > or 
>> >> > 00
>> >> >1018/0700
>> >> >DCSYNOP[17940445]: 001018/1400: [DCSYNOP -21] error writing data: 73502 
>   f
>> > or 
>> >> > 00
>> >> >1018/0700
>> >> >DCSYNOP[17940445]: 001018/1400: [DCSYNOP -21] error writing data: 73509 
>   f
>> > or 
>> >> > 00
>> >> >1018/0700
>> >> >DCSYNOP[17940445]: 001018/1400: [DCSYNOP -21] error writing data: 17557 
>   f
>> > or 
>> >> > 00
>> >> >1018/1400
>> >> >DCSYNOP[17940445]: 001018/1401: [DCDOSY -1] SMVB14
>> >> >DCSYNOP[17940445]: 001018/1401: [DCDOSY -1] SMVD14
>> >> >DCSYNOP[17940445]: 001018/1401: [DCDOSY -1] SMVE14
>> >> >DCSYNOP[17940445]: 001018/1401: [DCDOSY -1] SMVX14
>> >> >
> >> >Christian Page      finger address@hidden => tel. + adresse
>> >> >address@hidden    http://www.sca.uqam.ca/
>> >> >
>> >> >Assistant de recherche / Research Assistant
>> >> >Universite du Quebec a Montreal / Universite McGill / McGill Radar
>> >> >
>> >> >On Wed, 18 Oct 2000, Christian Page wrote:
>> >> >
>> >> >> 
>> >> >> Thanks, it was only a problem of write permissions... there was a log 
> fil
>> > e
>> >> >> already there but with read-only permissions...
>> >> >> 
>> >> >> Thanks again for your support!
>> >> >> 
>> >> >> Christian Page      finger address@hidden => tel. + adresse
>> >> >> address@hidden    http://www.sca.uqam.ca/
>> >> >> 
>> >> >> Assistant de recherche / Research Assistant
>> >> >> Universite du Quebec a Montreal / Universite McGill / McGill Radar
>> >> >> 
>> >> >> On Tue, 17 Oct 2000, Unidata Support wrote:
>> >> >> 
>> >> >> > 
>> >> >> > Christian,
>> >> >> > 
>> >> >> > You will need to create the ~lmd/data/gempak/surface/sao directory
>> >> >> > if it doesn't already exist.
>> >> >> > 
>> >> >> > Also, your log file output is to: -d /io/gempak/nawips/dcsynop_sb.lo
> g
>> >> >> > That directory is probably in your GEMPAK tree....the LDM may
>> >> >> > not have write permission there. Do you see any log file output?
>> >> >> > 
>> >> >> > Check your ldmd.log file for errors from pqact. Make sure that
>> >> >> > the LDM use is allowed to look in the GEMPAK tree for the dcsynop
>> >> >> > executable and the packing file. And, make sure you have run
>> >> >> > ldmadmin pqactHUP to reread your pqact.conf file after
>> >> >> > making any changes. Verify that all your "Tabs" are correct in the f
> ile
>> >> >> > as well.
>> >> >> > 
>> >> >> > Steve Chiswell
>> >> >> > Unidata User Support
>> >> >> > 
>> >> >> > 
>> >> >> > 
>> >> >> > 
>> >> >> > >From: Christian Page <address@hidden>
>> >> >> > >Organization: UCAR/Unidata
>> >> >> > >Keywords: 200010171806.e9HI6u428133
>> >> >> > 
>> >> >> > >
>> >> >> > >Hi,
>> >> >> > >
>> >> >> > >I would like to add to my hourly surface METAR plots, other hourly 
> obs
>> > erv
>> >> > ation
>> >> >> > > s,
>> >> >> > >like SHIP, BUOY, etc. What should I have in pqact.conf? I have the 
> fol
>> > low
>> >> > ing a
>> >> >> > > nd
>> >> >> > >it doesn't work (I get no output file) :
>> >> >> > >
>> >> >> > >#
>> >> >> > ># buoy and ship reports in yymmdd.gem
>> >> >> > >#
>> >> >> > >WMO     ^S([INS]V.*|MV[^NS].*) .... ([0-3][0-9])([0-2][0-9])
>> >> >> > >        PIPE    /io/gempak/nawips/bin/irix/dcsynop -v 1
>> >> >> > >        -d /io/gempak/nawips/dcsynop_sb.log
>> >> >> > >        -p /io/gempak/nawips/gempak5.4/tables/pack/sfship.pack
>> >> >> > >        data/gempak/surface/sao/YYYYMMDD_buoy.gem
>> >> >> > >
>> >> >> > >Any hints?
>> >> >> > >
>> >> >> > >Thanks!
>> >> >> > >
>> >> >> > >Christian Page      finger address@hidden => tel. + adresse
>> >> >> > >address@hidden    http://www.sca.uqam.ca/
>> >> >> > >
>> >> >> > >Assistant de recherche / Research Assistant
>> >> >> > >Universite du Quebec a Montreal / Universite McGill / McGill Radar
>> >> >> > >
>> >> >> > >
>> >> >> > 
>> >> >> > ********************************************************************
> ***
>> > ***
>> >> >> > Unidata User Support                                    UCAR Unidata
>  Pr
>> > ogr
>> >> >> > (303)497-8644                                                  P.O. 
> Box
>> >  30
>> >> >> > address@hidden                                   Boulder, 
> CO 
>> > 803
>> >> >> > --------------------------------------------------------------------
> ---
>> > ---
>> >> >> > Unidata WWW Service                        http://www.unidata.ucar.e
> du/
>> >    
>> >> >> > ********************************************************************
> ***
>> > ***
>> >> >> > 
>> >> >> 
>> >> >> 
>> >> >
>> >> 
>> >> *************************************************************************
> ***
>> >> 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/     
>> ****************************************************************************
>> 
>