AWIPS Programming Tips and Tricks by wuzhenguang

VIEWS: 47 PAGES: 38

									             AWIPS Programming

                   Tips and Tricks




27 November 2011
                    Overview
   Preferred locations for installing applications
   Best practices for code writing
   Use of environmental variables
   Creating install scripts
   Logging
   Error handling
   Documentation


27 November 2011
    Preferred locations for installing
              applications
   Place your code in NFS mounted directories so
    that it is available from all workstations and
    servers
     • /awips/dev/
     • /data/local
     • /home
   Do not place code in baseline directories
     • /awips/fxa
     • /data/fxa

27 November 2011
    Preferred locations for installing
              applications
   /awips/dev/bin
     • Good place to store small scripts or other simple
       utilities
     • Currently in the fxa environment search path
   /awips/dev/data
     • Good location for temporary files, data files, and
        program output
   /awips/dev – the preferred location for local
    applications
27 November 2011
  Preferred locations for installing
            applications
   /data/local
     • Also available for storing local applications
     • Ample file space (8.2 GB) for large files
     • Create sub directories to contain your local
       applications
     • Not in the default fxa search path




27 November 2011
  Preferred locations for installing
            applications
   /home
     • Use mostly for early coding development
     • Not a good place to install local applications




27 November 2011
          Best Practices for Coding
                  (textdb)
   textdb
     • If your program is launched from a trigger,
       have it copy the product from the
       /data/fxa/trigger directory rather than requesting
       it from the text database
     • If your program needs access to a regularly
       scheduled product, consider creating a
       background script to gather the data. Launch
       the script from a text trigger or from the cron.

27 November 2011
          Best Practices for Coding
                  (textdb)
textdb examples:
 textdb [options]
options:
 –r AFOSCmd (database read)
     • e.g. textdb –r ALL:BOSMRTBOS
   –w productID < product (write product to
    database)
     • e.g. textdb –w TOPMISTOP < someFile

27 November 2011
          Best Practices for Coding
                  (textdb)
textdb examples:
 textdb [options]
options:
 -A productID (gets all storage times for
  productID)
     • e.g. textdb –A TOPAFDTOP
   The textdb utility will write any product to the
    database that has a CCCNNNXXX ID between
    6 and 9 characters, whether or not that ID is a
    valid ID in a product table.
27 November 2011
          Best Practices for Coding
                  (textdb)
Check return value of textdb:
write mode                read mode
0 : successful              0 : successful
1 : database error          1 : database error
2 : IPC time out            2 : IPC time out
3 : IPC send error          3 : no data found
4 : no data to be written
5 : duplicated data
6 : file I/O error
7 : no AFOS or WMO ID
8 : textdb server killed
9 : unknown

27 November 2011
               Best Practices for Coding
                    (handleOUP.pl)
Syntax of handleOUP.pl :

handleOUP.pl [options] AWIPS_ID Product_Path

options:
 -w wmo_message_type (BBB field in WMO header)
        e.g.: AAx, CCx. AMD, COR, RTD are also supported
    -r AFOS_routing_code
        e.g. 000, ALL, LOC, DEF, CEN, EAS, SOU, WES
    -d ddHHMM ( Specify WMO message time stamp)
    -m (test mode)
    27 November 2011
           Best Practices for Coding
                (handleOUP.pl)
Check return value of handleOUP.pl :
0 : successful
1 : one or more tasks failed

Check log files for details :
/data/logs/fxa/<YYMMDD> on servers
/data/logs/fxa/dislpay/<DISPLAY>/<YYMMDD> on the
  workstations

 27 November 2011
          Best Practices for Coding
             (distributeProduct)
Syntax of distributeProduct :

distributeProduct [options] AWIPS_ID Product_Path
options:
 -a <address1, address2, …>
  ( 3-letter AWIPS site IDs or address keywords:
   DEFAULT(default), DEFAULTNCF, NWWSUP )
see distribution lists in /awips/ops/data/mhs folder
 -p priority ( 0 - 2 where 0 is lowest/default)
   -s „subject‟ ( 40 characters max)

27 November 2011
               Best Practices for Coding
                  (distributeProduct)
Syntax of distributeProduct (continued):
distributeProduct [options] AWIPS_ID Product_Path

options :
 -c <action1,action2…>
    e.g. TEST_ECHO,AWIPS_STORE_TEXTDB, NWWS_UPLINK
    see complete list of action codes in
    /data/fxa/workFiles/wanMsgHandling/rcv_action2codes.txt
   -t WMO_message_type
    e.g. Routine(default), Supplement, Amendment, Command, Correction
   -d ddHHMM ( Specify WMO message time stamp)


     27 November 2011
              Best Practices for Coding
                 (distributeProduct)
Syntax of distributeProduct (continued) :

distributeProduct [options] AWIPS_ID Product_Path

options :
 -e Attachment_File_Paths (paths to attachment)
Example - sending message to multiple WFO and store it in the
  respective database of the receiving sites:
distributeProduct -a EAX,GLD –c AFOS_STORE_TEXTDB
 -s TOPVERGLD KTOPVERGLD /data/fxa/hwr/TOPSWRKS.dat


   27 November 2011
             Best Practices for Coding
                (distributeProduct)
Check return value of distributeProduct :
0 : successful
-1 : error
> 0 : number of failed messages

Log file :
/data/logs/fxa/<YYMMDD> on servers
/data/logs/fxa/dislpay/<DISPLAY>/<YYMMDD> on
  workstations
   27 November 2011
                   fxaAnnouce
 Use fxaAnnounce to create fxa red banner
  messages to alert users
 Usage:
  fxaAnnounce “Your Message” SYSTEM
  URGENT soundFile.au
 System sound files (*.au) can be found in
  /awips/fxa/data/sounds

27 November 2011
                     Guardian
 Guardian can be used to send alert messages to
  the Guardian console on a specific workstation
 Usage
sendMsgToGuardian ANNOUNCER priority
  LOCAL “Your Message” lx2-top
 Message Priority can be 1, 2 or 4
     • 1 results in a popup message
     • 2 and 4 result in a text message on Guardian

27 November 2011
          Best Practices for Coding
                  (netCDF)
   netCDF files
     • Contain already decoded data (METAR, RAOB
       and Models)
     • Perl contains modules for easy access netCDF
       files
     • Tim Barker (SOO BOI) has written several Perl
       modules (AGRID) that greatly simplify reading
       netCDF model data

27 November 2011
 Best Practices for Coding (IFPS)
   IFPS
     • Can use the IFPS utilities to interact with the
       IFPS database
     • runIFPtext and ifpIMAGE are the most popular
     • ifpIMAGE can be used to create images for a
       web page or Situational Awareness display
     • runIFPtext could be used to pull meteorological
       parameters from the IFPS database for use in a
       local application

27 November 2011
              Best Practices for Coding
                   (PostgreSQL)
   PostgreSQL Database
     • The PostgreSQL psql command replaces the sqlcmd
       command of Informix
     • psql -t -U pguser -d hmdb < top.sql > records.top
     • SELECT day_of_year, max_temp_record,
       max_temp_rec_yr1, min_temp_record, min_temp_rec_yr1
       FROM day_climate_norm
       WHERE station_id=19820
       ORDER BY 1
     • http://www.nws.noaa.gov/oh/hrl/hseb/postgreSQL/

    27 November 2011
Best Practices for Coding (crons)
   Crons
     • Workstation cron jobs
             Create a separate user to run the cron jobs
             Run the jobs on a workstation that is not normally used for
              severe weather operations
             No automatic failover for workstation cron jobs
     • Server cron jobs
             Created by adding entries to the SITE cron files on dx1, dx2,
              dx3, dx4, px1, or px2
             Automatic failover if properly configured
             Consult AWIPS SMM for full details on adding server cron
              jobs

27 November 2011
       Best Practices for Coding
   Remember to check file permissions and
    ownership after creating/installing a local
    application.
     • Make all applications owned by fxa:fxalpha
     • This will need to be done as the user root on
        one of the dx servers



27 November 2011
       Best Practices for Coding
   Don‟t reinvent the wheel - utilize AWIPS
    meta files
     • MTR.goodness
     • afos2awips.txt
     • raob.goodness




27 November 2011
       Best Practices for Coding
   Use descriptive variable names
     • FileToSend
     • ProductPIL
 Make liberal use of comments and
  indentations
 Use procedures and functions as much as
  possible to “reuse” code
 Write programs that flow top to bottom

27 November 2011
           Best Practices for Coding

Goal – Limit system impact by utilizing proper
coding techniques.




27 November 2011
    Using Environmental Variables
 env – command to return the current user‟s
  environment variables
 Environmental variables will vary
  depending on the user (fxa‟s are different
  then oper‟s)
 Environment variables can be used to limit
  the amount of initial configuration that will
  need to be done by the user

27 November 2011
    Using Environmental Variables

   Examples
     • FXA_LOCAL_SITE – for the site ID
     • FXA_LOCAL_TZ – for the local time zone
     • HOSTNAME – what machine you are currently
       on
     • NODE – the state node identifier for your
       office


27 November 2011
   Using Environmental Variables
                   **** Caution ****
    If running your application from a cron or from a
    text trigger make sure you source the AWIPS
    environment.

    C-Shell
    source /awips/fxa/readenv.csh

    Bourne and Korne
    . /awips/fxa/readenv.sh
27 November 2011
      Creating Install Scripts
   When possible, develop installation scripts
    for applications you plan on distributing.
     • Reduces the possibility for installation errors
     • Allows you to enforce file permissions,
       ownership, and the installation location.
     • A good practice is to deliver the program as
       gzipped tar file containing the program files
       and the install script.

27 November 2011
                   Log Files
   Why write log files?
     • Useful for program debugging
     • Provides a record of program usage




27 November 2011
                      Log Files
   Suggested Log File locations:
     • Create a logs (or LOGS) sub directory
     • Write log information to the /data/logs/ tree
         AWIPS Baseline applications write their output to

          the /data/logs/ tree
         The directory is machine specific, so you may have

          to review several machines to view all of the log
          files


27 November 2011
                      Log Files
   What to log?
     • Program start
     • Program stop
     • Error messages
     • Data file access
     • Products read
     • You can never log too much information


27 November 2011
                   Error Handling
 When possible, use GUI based applications
  when human input is required
 Validate all user input before proceeding to
  eliminate erroneous entries that could crash
  a program
 Try to trap common errors (like file not
  found) so your program can shut down in an
  orderly manner.

27 November 2011
                   Error Notification
   Error notification methods
     • fxaAnnounce red banner messages for critical
         errors
     •   Guardian Alerts
     •   Application pop up windows
     •   Log file entries
     •   E-mail notifications to IT support staff


27 November 2011
         Program Documentation
   What to document
     •   Contact information
     •   Installation procedures
     •   Configuration steps
     •   How to run the program
     •   Locations of files (data files, log files, program scripts,
         etc)
     •   System files or environmental variables used
     •   Error conditions
     •   Any known bugs
     •   Version change information

27 November 2011
             Program Documentation

 Thorough documentation is key to any
 successful local application.

 Your application is only as good as its
 documentation.

27 November 2011
                   Questions??




27 November 2011

								
To top