This page is intended to include a brief overview of the DCSA account and directories.  District servers include a few application accounts.  One of these accounts is intended for the OpenDCS application.  When on the servers, users must first become the shared DCSA user (by using the employees credentials and Unix password) to connect to the CWMS database.  After becoming the DCSA user, then the user can launch OpenDCS ( launcher_start ), and use the employees credentials and Oracle password.

/wm/yyy/xxdcsaxx

bin (DCSA)

This is typically where Boot and Stop scripts are located.  This is the folder where any continuous OpenDCS programs are started or stopped.  For example, if applicable, the LRGS is started or stopped here.  If applicable, the Routing Scheduler is started or stopped here.  If applicable, the Computation Processor is started or stopped here.  See the OpenDCS documentation for further background on the commands summarized below.  

BootDCS

The boot script is in the DCSA bin directory: /wm/yyy/xxdcsaxx/bin/BootDCS 

The boot script (BootDCS) is typically comprised of the following parts.   Typically the boot script will call a startCCP script that consists of the routing scheduler and/or computation processor parts outlined below.

  • Source the OpenDCS environment on the CWMS server
    • . /wm/yyy/xxdcsaxx/.bashrc
  • Start up the LRGS (if applicable)
    • To start the LRGS, use the OpenDCS command that is housed in the OpenDCS software bin directory
      • startLRGS 
  • Start up the Routing Scheduler (if applicable) or start up routing specs 
    • To start up the Routing Scheduler use the OpenDCS   
      • nohup routesched -a routsched-name -d3 -l $DCSTOOL_USERDIR/complogs/routesched-name.log > $DCSTOOL_USERDIR/complogs/nohup.routesched-name 2>&1 & 
    • If an office is not using the routing scheduler to run routing specs, then they may be running routing specs on a cron (i.e. the command rs -d3 routingspecname is called in some form from the cron).  Those routing specs will run regardless of whether the routing scheduler is started. 
  • Start up the Computation Processor (if applicable) 
    • Typically, these lines are to set up 
      • nohup comproc -a cpprocess-name -d3 -l $DCSTOOL_USERDIR/complogs/cpprocess-name.log  > $DCSTOOL_USERDIR/complogs/nohup.name 2>&1 
  • Start up the Comp Depends (if applicable)
    • nohup compdepends --d3 -l $DCSTOOL_USERDIR/complogs/compdepends.log > $DCSTOOL_USERDIR/complogs/nohup.compdepends 2>&1 

StopDCS

The stop script is in the DCSA bin directory: /wm/yyy/xxdcsaxx/bin/StopDCS 

The stop script (BootDCS) is typically comprised of the following parts.   Typically the boot script will call a startCCP script that consists of the routing scheduler and/or computation processor parts outlined below.

  • Source the OpenDCS environment on the CWMS server
    • . /wm/yyy/xxdcsaxx/.bashrc
  • Stop the LRGS (if applicable)
    • To start the LRGS, use the OpenDCS command that is housed in the OpenDCS software bin directory
      • rm $LRGSHOME/lrgs.lock 
  • Stop the Routing Scheduler (if applicable) or start up routing specs 
    • To stop
      • stopcomp -a routingshed name 
    • If an office is not using the routing scheduler to run routing specs, then they may be running routing specs on a cron (i.e. the command rs -d3 routingspecname is called in some form from the cron).  Those routing specs will run regardless of whether the routing scheduler is started. 
  • Stop the Computation Processor (if applicable) 
    • Typically, these lines are to set up
      • `stopcomp -a cpprocess-name`
  • Stop the Comp Depends (if applicable)
    • Typically this line is written as follows :
      • stopcomp -a compdepends

Unix Tip

After booting is stopping OpenDCS, it may be useful to check/verify that everything is turned off. A helpful Unix command can be pasted into a terminal session (as the DCSA user), and will return a list of OpenDCS continuous processes running.  

pgrep -fl /opendcs/ | sed 's/.*\///' | sort | uniq -c
BASH

LRGS

Purpose

The LRGS is a continuously running program on the CWMS servers.  The software is built for the purposes of gathering and storing messages from field equipment that gets transmitted via satellites and is retrieved/delivered at ground stations.  The USACE servers run the LRGS software to use one or more of the following features:

  1. Retrieve messages from a local ground station (i.e. your District has a local dish)
  2. Retrieve messages from another remote server where an LRGS is running and retrieving messages from its local ground station
  3. Send messages from a local server to a remote server where LRGS is running

Configurations

Setting up the LRGS is typically a one time task.  However, occasionally a Sys Admin may need to update a host IP address or perhaps update a password.  It is ideal to be familiar with LRGS configurations on your server.

Information about your LRGS configuration is defined in the following files:

  • /wm/yyy/xxdcsaxx/opendcs_user/lrgs/lrgs.conf
  • /wm/yyy/xxdcsaxx/opendcs_user/lrgs/ddsrecv.conf
  • /wm/yyy/xxdcsaxx/opendcs_user/lrgs/drgsrecv.conf
  • /wm/yyy/xxdcsaxx/opendcs_user/lrgs/drgsconf.xml
  • /wm/yyy/xxdcsaxx/opendcs_user/lrgs/lrgslog

To learn more about the OpenDCS LRGS software and variables, see the online documentation.

Tips

When the LRGS is running on the server, the folder /wm/yyy/xxdcsaxx/opendcs_user/lrgs/archive will populate with messages.  So one method to check if the LRGS is running is to see if messages are populating in the archive folder.

Another method to check if the LRGS is running is to run the following Unix command. `tail -f $LRGSHOME/lrgslog`

It is the Districts responsibility to maintain any accounts and passwords for cdadata and lrgsedd1 LRGS.  

Routing Specs

Purpose

The DECODES part of the OpenDCS software is used for creating routing specs.  Routing specs are in a nutshell a set of instructions for data collection.  Typically routing specs include information about a source type, the method to decode the messages, the look back window, and a list of sites or locations for which the data shall be retrieved from.    The USACE servers routing specs are typically either scheduled jobs from either the T7's cron or from the OpenDCS routing scheduler.  At USACE the following routing specs are common.

  1. Routing specs that decode data from field data from iridium equipment
  2. Routing specs that decode data from data collection platforms
  3. Routing specs that decode data from files that get dropped into folders in the DCSA user
  4. Routing specs that decode data from the web (AKA web scrapping) 

Configurations

Regardless of the method in which the routing specs are called, the logs will populate in the routing directory.

  • /wm/yyy/xxdcsaxx/opendcs_user/routstat

To find out more information about the routing specs on your server, launch the GUI and navigate through the DECODES database tabs.  This is where information about routing specs is stored.  

Tips

It is good practice to know which routing specs listed on the GUI are active.  It is possible for there to be outdated routing specs, or perhaps seasonal routing specs, or backfilling routing specs.  In some cases there may be a good rational reason for keeping the routing specs present in the GUI.  When troubleshooting a routing specs and data retrieval, it is common sense to first check if the data at the source is available. For example, if the source is the web, check to see if the data is online.  If the source is an LRGS, check to see if messages are available or have any garbage by using the DCP Message Browser.  When there is an issue with the source, there will be issues with the routing spec and data retrieval process.  Know what CWMS pathnames populate from which routing specs.  

Computations

Purpose

The Computational Processor part of the OpenDCS software is used for running automated computations.  OpenDCS is capable of doing simple arithmetic or time series transformations.  In addition it also has the capability of doing common hydrologic computations such as precipitation computations and stage-flow computations.  

Computations are started up in boot scripts, by technically booting up the defined processes.  One can think of the processes as groups of computations.  Each computation called has an algorithm defined, and a specified input and output time series, in addition to any other properties applied.

Some common computations or uses of the Computational Processor are listed below.

  1. Using rating curves to output a flow
  2. Calculating  daily precipitation totals
  3. Converting higher resolution time series to lower resolution time series and visa versa (using subsampling and resampling)
  4. Applying an office specific algorithm or rules using a custom python or java algorithm

Configurations

The location of the computation logs is defined in the boot script.  However, the default location is the complogs folder.

  • /wm/yyy/xxdcsaxx/opendcs_user/complogs

To find out more information about the algorithms and computations set up on your server and in relation to the database, launch the GUI and navigate through the Computation Editor tabs.  This is where information about the computations is stored.  

Tips

It is good practice to know which computations are potentially triggered by the output of other computations.