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

20010622: Setting up redbook production

Glenn,

Alan downloaded the Solaris binary distribution for GEMPAK 5.6.C.1
yesterday. This binary distribution does have the dcredbook_vg executable.

The executables were compiled with Sun's WS6.0 compilers. Generally, if you keep
your OS and compilers up to date, then you can run the executables. You can 
verify 
that you have all the necessary system libraries on your computer to run the 
executables 
with the command:

ldd $GEMEXE/ldd dcredbook_vg

That will show you all the libraries which are being searched and whether they 
are found.
If you are missing any of the libraries on your system (which is possible if 
you 
have older F77 libraries), then you can download the sharable libraries
from the binary distribution directory.

So, assuming you can run the dcredbook_vg program on your system, here
are the steps to set up the LDM:

pqact.conf pattern I use:
HRS     ^P..... (K[^W]|KW[^A]|KWA[^L])
        PIPE    -close  util/dcredbook_vg.csh

Below is the csh script that the above pqact action runs. It is a very
simple script that sources the Gemenviron settings, then changes its
working directory to wherever you want the output files to go.
You can modify the output file name template as you need for your setup.
The output files I have use the name template: %P/YYYYMMDD_HHNN.vgf
This creates a subdirectory from the redbook product name (using the %P
template).

For example, for a RADAR summary product 90R, I have:
$GEMDATA/images/vg/90R-RDR_CONTRS_HH+35/20010622_1541.vgf

The redbook graphics product internally idenifies the product as 90R.
The dcredbook program looks up the 90R product in the 
$GEMTBL/nafos/redbook.tbl file to get the corresponding long
name used for the %P template.


#!/bin/csh -f
#
# Filename: dcredbook_vg.csh
#
# This script may be used as a pqact.conf action to automatically
# generate VG (vector graphics) from REDBOOK graphics found on NOAAPORT.
#
# pqact.conf usage:
#
# send all NOAAPORT graphic products (except those from KWAL) to this script
#HRS    ^P..... (K[^W]|KW[^A]|KWA[^L])
#       PIPE    -close  util/dcredbook_vg.csh
#
#
# source the GEMPAK environment so that table, mapfiles etc. are found
#
source /home/gempak/NAWIPS/Gemenviron

# Set a work directory and change directory to it
setenv OUTDIR $GEMDATA/images/vg
cd $OUTDIR

cat | dcredbook_vg -v 1 -d $GEMDATA/logs/dcredbook_vg.log 
'vg|%P/YYYYMMDD_HHNN.vgf'
exit 0



Steve Chiswell
Unidata User SUpport






>From: "Glenn Rutledge" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200106221521.f5MFL1103874

>Hello Steve-
>While I was alway at COLA the last several days (ethan was there- it was a goo
> d
>meeting)  NCDC had a power surge and we lost ALL of the n-awips changes I've m
> ade
>with you over the last 6 months.  I am really quite amazed that our systems fo
> lks
>did not backup the code at all, let alone on a regular basis!
>
>So yesterday , my team mate Alan Hall downloaded the binaries form your site. 
>  I
>think he got 5.6
>
>I have a #1 priroty for next wed- that's the redbook graphics.
>1) by not doing the make command here- will that impact our programs?
>2) I recall using a redbook_vg program along with a script to view real-time R
> BG
>files.  See below.
>
>Is this script appropriate- I recall runaway vg and gplt processes.  This is a
>general question but how should I best proceed?  You gave me a new redbook
>Makefile for this issue.  Should I run that?  Could you point me in the right
>direction for the proper pq-act entry?  Thx much, GLenn
>
>Michael Urzen wrote:
>
>> Mike,
>>
>> Anytime you see the MAILBOX read errors or ipchannel messages,
>> it is generally due to a "gplt" process that is hung, or wasn't ended with
>> gpend.
>>
>> Exit out of all GEMPAK programs. Then try running:
>> $NAWIPS/bin/scripts/cleanup -c
>>
>> The above may save some effort...but won't find everything.
>>
>> Run /bin/ps and look for any "gplt", "vg" or other gempak programs/device
>> drivers
>> and kill them.
>>
>> Then run "ipcs" to see if there are any message queues still open. If so,
>> close these with the "ipcrm" command.
>>
>> This is what the cleanup script tries to do, but not all OS's have the same
>> output from ps and ipcs, so the parsing in the script sometimes runs into
>> trouble.
>>
>> Once that is cleared up, you should be able to go again.
>>
>> Steve Chiswell
>> Unidata User SUpport
>>
>> >From: "Michael Urzen" <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200101112003.f0BK3Bo08314
>>
>> >This is a multi-part message in MIME format.
>> >--------------FB7A06BA5BFB0B635CB0BFDA
>> >Content-Type: text/plain; charset=us-ascii
>> >Content-Transfer-Encoding: 7bit
>> >
>> >Steve:
>> >
>> >Has anything changed with RedBook
>> >graphics?
>> >
>> >I had it working a few months ago, but
>> >not now.
>> >
>> >Everything looks OK, but my output file
>> >is always "gemglb.nts"
>> >
>> >
>> >Here is my script:
>> >#!/usr/bin/csh -f
>> >source /npfos/noaaport/nawips/Gemenviron
>> >
>> >setenv DISPLAY unix:0
>> >
>> >cd /npfos/noaaport/nawipsdata/redbook
>> >
>> >set DATE=`date -u '+%Y%m%d'`
>> >set
>> >LOGFILE=/npraid/noaaport/nawips/logs/${DATE}_dcredbook.log
>> >
>> >cat |
>> >/npfos/noaaport/nawips/bin/sol/dcredbook
>> >-v 1 -d $LOGFILE
>> >'vg|%P_YYYYMMDDHHNN.vgf'
>> >gpend
>> >exit 0
>> >
>> >Logfile =:
>> >[19191] 001230/1848 [DC 3]  Starting up.
>> >
>> >[19192] 001230/1848 [DC 3]  Starting up.
>> >
>> >[19192] 001230/1848 [GEMPLT -1]  NMBRER
>> >- Mailbox read.
>> >[19192] 001230/1848 [DCREDBOOK 1]
>> >90R-RDR_CONTRS_HH+35
>> >[19191] 001230/1848 [GEMPLT -1]  NMBRER
>> >- Mailbox read.
>> >[19191] 001230/1848 [DCREDBOOK 1]
>> >90S-RDR_LABELS_HH+35
>> >[19192] 001230/1848 [GEMPLT -1]  NMBRER
>> >- Mailbox read.
>> >[19192] 001230/1848 [GEMPLT -1]  NMBRER
>> >- Mailbox read.
>> >[19192] 001230/1848 [GEMPLT -1]  NMBRER
>> >- Mailbox read.
>> >[19192] 001230/1848 [GG -7]  No map
>> >drawn.
>> >[19192] 001230/1848 [DC 5]  Normal
>> >termination.
>> >[19192] 001230/1848 [DC 2]  Number of
>> >bulletins read and processed: 1
>> >[19192] 001230/1848 [DC 6]  Shutting
>> >down.
>> >
>> >
>> >Also, if I manually run "gpend" from the
>> >prompt I get:
>> >
>> >npfos:/npraid/noaaport/nawips/bin/scripts->gpend
>> >
>> >Error in message send = 22
>> >itype, ichan, nwords,1,-1,2
>> >Error in message send = 22
>> >Creating process: gplt for queue -1
>> >itype, ichan, nwords,1,-1,3
>> > [GEMPLT -1]  NMBRER - Mailbox read.
>> > [GPEND -3]  Fatal error initializing
>> >GEMPLT.
>> >npfos:/npraid/noaaport/nawips/bin/scripts->Error
>> >
>> >in message send = 22
>> >itype, ichan, nwords,1,-1,2
>> >
>> >npfos:/npraid/noaaport/nawips/bin/scripts->
>> >
>> >
>> >
>> >
>> >
>> >Thanks
>> >
>> >Mike
>> >
>> >--------------FB7A06BA5BFB0B635CB0BFDA
>> >Content-Type: text/x-vcard; charset=us-ascii;
>> > name="Michael.Urzen.vcf"
>> >Content-Transfer-Encoding: 7bit
>> >Content-Description: Card for Michael Urzen
>> >Content-Disposition: attachment;
>> > filename="Michael.Urzen.vcf"
>> >
>> >begin:vcard
>> >n:Urzen;Michael
>> >tel;work:(828) 271-4089
>> >x-mozilla-html:FALSE
>> >org:National Climatic Data Center;Climate Data Division
>> >adr:;;151 Patton Ave;Asheville;North Carolina;28801;
>> >version:2.1
>> >title:Computer Specialist
>> >fn:Michael Urzen
>> >end:vcard
>> >
>> >--------------FB7A06BA5BFB0B635CB0BFDA--
>> >
>> ==============================================
>>
>> Mike,
>>
>> First, does your LDM process have permission to connect to your X server?
>> The logs appear to show that the product is read in, bu the gif
>> is not created. As I mentioned before, the gf driver will require that
>> an X server be available. (you can create an alternate server with Xvfb
>> and a screen :1 as an alternative to drawing on your console).
>>
>> More importantly, NMAP does not view gifs. You can import these
>> products into NMAP as VGF files however. To create vgf files
>> >from the redbook graphics, you an use "dcredbook" as the
>> decoder in the script (instead of dcredbook_gf) and use the
>> gempak VG device, like 'vg|%P-YYYYMMDDHHNN.vgf', making sure to
>> run gpend within the script since a gplt process will be created.
>> You do not need an X server to create vgf files.
>>
>> To import vgf files into NMAP, you can use the pgpalette "Open" option and
>> Browse for the file in the data directory, or you can use the DATA menu and
>> select the VGF type. The data directory fore the vgf files for NMAP is
>> specified
>> in the $GEMTBL/nmap/vgf.nmap file. The "Local" directory is the current
>> working
>> directory, the other vgf classes have directory names defined in the vgf.nma
> p
>> file.
>>
>> For clarification, gif format files do not have any georeferencing
>> information.
>> They are just pictures woth lines etc. VGF files have lats and lons
>> associated with
>> the lines so that they can be edited, remapped, and reprojected.
>>
>> Steve Chiswell
>> Unidata User Support
>>
>> >From: address@hidden
>> >Organization: UCAR/Unidata
>> >Keywords: 200011211944.eALJibo18692
>>
>> >
>> >
>> >
>> >Steve:
>> >
>> >I did as you suggested and used your script.
>> >
>> >Here is my pqact entry:
>> >WMO     ^NOAAPORT\.NWSTG\.GRAPHIC\.P.*
>> >        PIPE    -close  /npfos/noaaport/nawips/bin/scripts/dcredbook_gf.csh
>> >
>> >
>> >Here is my dcredbook_gf.csh:
>> >#!/usr/bin/csh -f
>> ># the source line below will set the locations of your GEMMAPS and GEMTBL
>> ># directories from your Gemviron file
>> >source /npfos/noaaport/nawips/Gemenviron
>> >
>> ># To generate gifs using the gf device, you need permission to draw to
>> ># an X server. Otherwise, you could use the gif2 device or ps driver
>> ># as shown below.
>> >setenv DISPLAY unix:0
>> >
>> >cd /npfos/noaaport/nawipsdata/redbook
>> >
>> >set DATE=`date -u '+%Y%m%d'`
>> >set LOGFILE=/npraid/noaaport/nawips/logs/${DATE}_dcredbook.log
>> >
>> >cat | /npfos/noaaport/nawips/bin/sol/dcredbook_gf -v 1 -d $LOGFILE
>> >'gf|%P_YYYYMMDDHHNN.gif|1280;1024'
>> >exit 0
>> >
>> >Here is my Gemenviron settings:
>> >   setenv GEMTBL    $GEMPAK/tables
>> >   setenv GEMMAPS   $GEMPAK/maps
>> >
>> >
>> >I AM getting a logfile. (see below)
>> >I do not know what I am looking at, but I do not see any error messages.
>> >
>> >It looks like it ran OK, but all I get in the redbook directory is a core
>> >file.
>> >
>> >There are no messages relating to redbook in the pqact.log file.
>> >
>> >Any ideas?
>> >
>> >Also, I want to display this product using NMAP.
>> >Should I be trying to create a gif file?
>> >
>> >
>> >
>> >                         Thanks again
>> >                              Mike
>> >
>> >
>> >
>> >[6308] 001121/1350 [DCREDBOOK 1] 9JE-6HR_QPF_VALID_48-54HRS
>> >[17649] 001121/1355 [DC 3]  Starting up.
>> >[17649] 001121/1355 [DCREDBOOK 1] 98F-48H_FNT-MSL_PRS
>> >[17651] 001121/1355 [DC 3]  Starting up.
>> >[17651] 001121/1355 [DCREDBOOK 1] 96F-36H_FNT-MSL_PRS
>> >[19928] 001121/1355 [DC 3]  Starting up.
>> >[19931] 001121/1355 [DC 3]  Starting up.
>> >[19928] 001121/1355 [DCREDBOOK 1] L8P-48H_INSTAN_PCPN
>> >[19931] 001121/1355 [DCREDBOOK 1] L6P-36H_INSTAN_PCPN
>> >[20337] 001121/1355 [DC 3]  Starting up.
>> >[20337] 001121/1355 [DCREDBOOK 1] RP5-48H_WNDWAV_FCST_PAC
>> >[560] 001121/1401 [DC 3]  Starting up.
>> >[560] 001121/1401 [DCREDBOOK 1] RP3-24H_SURFACE_FCST_PAC
>> >[1182] 001121/1401 [DC 3]  Starting up.
>> >[1182] 001121/1401 [DCREDBOOK 1] HRY-SVR_TSTM_RPTS
>> >[13950] 001121/1409 [DC 3]  Starting up.
>> >[13950] 001121/1409 [DCREDBOOK 1] LP0-PAC_WIND_WAVE_ANALYSIS
>> >[18305] 001121/1411 [DC 3]  Starting up.
>> >[18306] 001121/1411 [DC 3]  Starting up.
>> >[18305] 001121/1411 [DCREDBOOK 1] THT-TEMP_WIND_THREAT
>> >[18306] 001121/1411 [DCREDBOOK 1] THS-SOIL_FIRE_THREAT
>> >[18390] 001121/1411 [DC 3]  Starting up.
>> >[18390] 001121/1411 [DCREDBOOK 1] THP-PRCP_THREAT
>> >[20090] 001121/1412 [DC 3]  Starting up.
>> >[20090] 001121/1412 [DCREDBOOK 1] 96P-DAY6_MXMN_POP_ANM
>> >[20089] 001121/1412 [DC 3]  Starting up.
>> >[20089] 001121/1412 [DCREDBOOK 1] 97P-DAY1_MXMN_POP_ANM
>> >[20705] 001121/1412 [DC 3]  Starting up.
>> >[20710] 001121/1412 [DC 3]  Starting up.
>> >[21494] 001121/1413 [DC 3]  Starting up.
>> >[21494] 001121/1413 [DCREDBOOK 1] RP1-MAR_ANLYS_PAC
>> >[21865] 001121/1413 [DC 3]  Starting up.
>> >[21865] 001121/1413 [DCREDBOOK 1] RA1-MAR_ANLYS_ATL
>> >[9545] 001121/1425 [DC 3]  Starting up.
>> >[9545] 001121/1425 [DCREDBOOK 1] P0W-OBS_WX_DPCN
>> >[10763] 001121/1426 [DC 3]  Starting up.
>> >[10763] 001121/1426 [DCREDBOOK 1] 90W-OBS_WX_DPCN_ANL
>> >[11507] 001121/1427 [DC 3]  Starting up.
>> >[15914] 001121/1429 [DC 3]  Starting up.
>> >[15889] 001121/1429 [DC 3]  Starting up.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >Mike,
>> >
>> >This is a new program I put together for automatically generating
>> >graphics from the redbook files, so its not a suprise that its
>> >not completely clear how to use it yet.
>> >
>> >Ok, so you want gif output. I'll start by suggesting that you use
>> >dcredbook_gf (eg this version is linked directly to the gif driver so you
>> >don't have to worry about running gpend to close the GPLT process).
>> >
>> >Second thing you need to generate gif displays is an X server to draw to
>> >(dcredbook_gf uses the gf driver which requires an X server, alternatively,
>> >it could be compiled to use the gif2 driver which doesn't use an X server
>> >but my experience is that the hgardware fonts supplied by the X server look
>> >much
>> >better than the software fonts that gif2 will have to use).
>> >
>> >Lastly, you will need the environmental variables GEMMAPS and GEMTBL for
>> >the mapfiles and tables that define the redbook products respectively.
>> >
>> >You'll see at:
>> >http://www.unidata.ucar.edu/packages/gempak/tutorial/manual/chap6/chap6.sht
>> >ml?dcredbook
>> >that the filename for the output is a GEMPAK DEVICE definition, not just
>> >a filename. The device, filename, geometry and color options are specified
>> >just as you would in a GEMPAK program.
>> >
>> >In order to specify the environmental variables and X server above, I'd
>> >suggest
>> >piping the output to a script, rather than directly to the decoder (unless
>> >you have these
>> >variables set in the environment of the LDM running process).
>> >
>> >So, here is an example of a pqact.conf line:
>> >
>> >WMO  ^NOAAPORT\.NWSTG\.GRAPHIC\.P.*
>> >     PIPE  -close   /npfos/noaaport/nawips/bin/scripts/dcredbook_gf.csh
>> >
>> >
>> >So, dcredbook_gf.csh will be a csh script that the graphics will be piped
>> >to.
>> >
>> >Here is an example of the dcredbook_gf.csh script that works for me.
>> >You can place it in your scripts directory (or wherever) and use
>> >"chmod a+x dcredbook_gf.csh" to make it executable.
>> >
>> >
>> ><<<<<<<<<<<<<<<---- script starts next line ---->>>>>>>>>>>>>>>>>>>>>>
>> >#!/bin/csh -f
>> >
>> ># the source line below will set the locations of your GEMMAPS and GEMTBL
>> ># directories from your Gemviron file
>> >source /npfos/noaaport/nawips/Gemenviron
>> >
>> ># To generate gifs using the gf device, you need permission to draw to
>> ># an X server. Otherwise, you could use the gif2 device or ps driver
>> ># as shown below.
>> >setenv DISPLAY unix:0
>> >
>> >cd /npfos/noaaport/nawipsdata/redbook
>> >
>> >set DATE=`date -u '+%Y%m%d'`
>> >set LOGFILE=/npraid/noaaport/nawips/logs/${DATE}_dcredbook.log
>> >
>> >cat | dcredbook_gf -v 1 -d $LOGFILE 'gf|%P_YYYYMMDDHHNN.gif|1280;1024'
>> >exit 0
>> >
>> ># The above uses dcredbook_gf. Alternatively, to produce postscript files
>> ># without an X server, you could use:
>> >cat | dcredbook_ps -v 1 -d $LOGFILE 'ps|%P_YYYYMMDDHHNN.ps|8.5;11|C'
>> >
>> >#or, to use the gif2 driver, just use the generic dcredbook program
>> >#and run gpend when finished:
>> >cat | dcredbook -v 1 -d $LOGFILE 'gif2|%P_YYYYMMDDHHNN.gif|1280;1024'
>> >gpend
>> ><<<<<<<<<<<<<<<---- script ends previous line ---->>>>>>>>>>>>>>>>>>>>>>
>> >
>> >
>> >
>> >In the above script, the %P in the output file name is replaced with the
>> >product
>> >name for each product decoded as defined in $GEMTBL/nafos/redbook.tbl
>> >since the WMO name really doesn't tell you much about what the product is.
>> >
>> >all three of dcredbook, dcredbook_ps, and dcredbook_gf are built and
>> >installed
>> >in your $GEMEXE directory when you built GEMPAK. When you use either of the
>> >_ps or _gf versions that are directly linked to the driver, you don't have
>> >to
>> >run gpend when finished.
>> >
>> >When using just the standard dcredbook program, a gplt process is created
>> >which allows
>> >you to specify any output device that you can normally use as DEVICE in
>> >gpmap for example.
>> >Just as with gpmap, you will have to run gpend to close the gplt and end
>> >the output
>> >file.
>> >
>> >The DEVICE options for the gif drivers are file output name and gif size.
>> >For the PS driver, you could specicy either 8.5;11 or 11;17 for
>> >8.5x11" or 11x17" paper respectively. The "C" for the postscript driver
>> >uses
>> >COLOR for the lines drawn. Alternately you could use "G" for grayshades or
>> >"M" for monochrome (always black for lines drawn).
>> >
>> >
>> >I hope this gives you a starting point.
>> >
>> >Steve Chiswell
>> >Unidata User Support
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> ==============================================
>> Mike,
>>
>> This is a new program I put together for automatically generating
>> graphics from the redbook files, so its not a suprise that its
>> not completely clear how to use it yet.
>>
>> Ok, so you want gif output. I'll start by suggesting that you use
>> dcredbook_gf (eg this version is linked directly to the gif driver so you
>> don't have to worry about running gpend to close the GPLT process).
>>
>> Second thing you need to generate gif displays is an X server to draw to
>> (dcredbook_gf uses the gf driver which requires an X server, alternatively,
>> it could be compiled to use the gif2 driver which doesn't use an X server
>> but my experience is that the hgardware fonts supplied by the X server look
>> much
>> better than the software fonts that gif2 will have to use).
>>
>> Lastly, you will need the environmental variables GEMMAPS and GEMTBL for
>> the mapfiles and tables that define the redbook products respectively.
>>
>> You'll see at:
>> http://www.unidata.ucar.edu/packages/gempak/tutorial/manual/chap6/chap6.shtm
> l?
>> dcredbook
>> that the filename for the output is a GEMPAK DEVICE definition, not just
>> a filename. The device, filename, geometry and color options are specified
>> just as you would in a GEMPAK program.
>>
>> In order to specify the environmental variables and X server above, I'd
>> suggest
>> piping the output to a script, rather than directly to the decoder (unless
>> you have these
>> variables set in the environment of the LDM running process).
>>
>> So, here is an example of a pqact.conf line:
>>
>> WMO ^NOAAPORT\.NWSTG\.GRAPHIC\.P.*
>>  PIPE  -close /npfos/noaaport/nawips/bin/scripts/dcredbook_gf.csh
>>
>> So, dcredbook_gf.csh will be a csh script that the graphics will be piped to
> .
>>
>> Here is an example of the dcredbook_gf.csh script that works for me.
>> You can place it in your scripts directory (or wherever) and use
>> "chmod a+x dcredbook_gf.csh" to make it executable.
>>
>> <<<<<<<<<<<<<<<---- script starts next line ---->>>>>>>>>>>>>>>>>>>>>>
>> #!/bin/csh -f
>>
>> # the source line below will set the locations of your GEMMAPS and GEMTBL
>> # directories from your Gemviron file
>> source /npfos/noaaport/nawips/Gemenviron
>>
>> # To generate gifs using the gf device, you need permission to draw to
>> # an X server. Otherwise, you could use the gif2 device or ps driver
>> # as shown below.
>> setenv DISPLAY unix:0
>>
>> cd /npfos/noaaport/nawipsdata/redbook
>>
>> set DATE=`date -u '+%Y%m%d'`
>> set LOGFILE=/npraid/noaaport/nawips/logs/${DATE}_dcredbook.log
>>
>> cat | dcredbook_gf -v 1 -d $LOGFILE 'gf|%P_YYYYMMDDHHNN.gif|1280;1024'
>> exit 0
>>
>> # The above uses dcredbook_gf. Alternatively, to produce postscript files
>> # without an X server, you could use:
>> cat | dcredbook_ps -v 1 -d $LOGFILE 'ps|%P_YYYYMMDDHHNN.ps|8.5;11|C'
>>
>> #or, to use the gif2 driver, just use the generic dcredbook program
>> #and run gpend when finished:
>> cat | dcredbook -v 1 -d $LOGFILE 'gif2|%P_YYYYMMDDHHNN.gif|1280;1024'
>> gpend
>> <<<<<<<<<<<<<<<---- script ends previous line ---->>>>>>>>>>>>>>>>>>>>>>
>>
>> In the above script, the %P in the output file name is replaced with the
>> product
>> name for each product decoded as defined in $GEMTBL/nafos/redbook.tbl
>> since the WMO name really doesn't tell you much about what the product is.
>>
>> all three of dcredbook, dcredbook_ps, and dcredbook_gf are built and install
> ed
>> in your $GEMEXE directory when you built GEMPAK. When you use either of the
>> _ps or _gf versions that are directly linked to the driver, you don't have t
> o
>> run gpend when finished.
>>
>> When using just the standard dcredbook program, a gplt process is created
>> which allows
>> you to specify any output device that you can normally use as DEVICE in gpma
> p
>> for example.
>> Just as with gpmap, you will have to run gpend to close the gplt and end the
>> output
>> file.
>>
>> The DEVICE options for the gif drivers are file output name and gif size.
>> For the PS driver, you could specicy either 8.5;11 or 11;17 for
>> 8.5x11" or 11x17" paper respectively. The "C" for the postscript driver uses
>> COLOR for the lines drawn. Alternately you could use "G" for grayshades or
>> "M" for monochrome (always black for lines drawn).
>>
>> I hope this gives you a starting point.
>>
>> Steve Chiswell
>> Unidata User Support
>>
>> =========================================================================
>