This document describes the general steps for installing an NCWF system that has already been configured. It is meant to be used by RAP engineers familiar with the RAP CVS setup. Note that the directory names and environment variables might be slightly different for different configurations. You should be able to look around and figure out the correct ones to use for your configuration. I'm trying to make things more consistent as we go along, but this takes time and sometimes we have to define the environment variables differently so that they don't conflict with other projects on the same host.

Check everything out from CVS

For each of the configured NCWF systems, there is a checkout script in the CVS "distribs" directory. We currently have the following checkout scripts in the distribs directory:

ncwf_checkout.kc

Current system running at the AWC in Kansas City.

rcwf_checkout.thorn

Current RCWF system (formerly called THOR-North) running in Lincoln (half of the system runs at Lincoln, the other half at RAP). This includes the setup for the communication machines (moonbow and zenith) that are shared with the AutoNowcaster and are used to push datasets throught the firewalls between the sites.

rcwf_checkout.thorn_rap

Current RCWF system running at RAP

rcwf_checkout.lincoln

Current RAP configuration that runs as a part of the Lincoln operational RCWF system. These are the products that we have transferred to Lincoln to run as a part of their system, rather than the processes that are running on RAP machines out at Lincoln. Currently, this includes the frontal likelihood field, the stability field and the Colide orientation field.

So, the first step is to check everything out from CVS. To do this, set your CVSROOT environment variable appropriately and log into CVS. Then create the directory in which you want all of the source and project files installed. For RAP-controlled systems, I usually install everything in a directory called $HOME/cvs since what is put in this directory mirrors what is in CVS. For transferred installations, this is usually a directory called $HOME/ncwf or $HOME/rap or something else that will be useful to the receiving organization. Then check out the appropriate script in the distribs directory. Before running the script, look at the first non-comment line in the script to see where the source and parameter files are expected to be installed. Usually, this is an environment variable that you will need to set to the directory you created above before running the script. Once your environment variable is set and that directory is created, run the script and you should get everything you need from CVS.

Create .cshrc link

Before doing anything else with the system, you need to install the appropriate .cshrc file so that needed environment variables are defined. I do this by creating a link to the appropriate .cshrc in the configuration directory. The .cshrc (and any other dot files) are found in the dotFiles subdirectory of the project directory. If you don't know the name of the project directory you can either look at the end of the checkout script to see which project directory is checked out or you can look in the source directory (the one you created above) until you find the dotFiles subdirectory. Once the file is found, create a link to the file using the following commands:

    cd
    ln -s /dotFiles/.cshrc .
    source .cshrc

If there are any other dot files in the dotFiles directory, you should also create links to those in the $HOME directory so that all of the hosts are configured consistently.

Build the executables

For all operational projects, we use locally built executables to prevent problems caused by executable changes in the nightly build. If this is a research setup used just by the engineers and you want to test the executables from the nightly build, you can use the executables on the /rap disk. However, in this configuration it's very difficult to track down problems with the system because you will never know which executable was running when the problem occurred. This happens because running executables are not updated when the underlying executable on disk is changed. Thus, if you executable has been running for several days and then core dumps, the core dump will be from an executable that has been overwritten several times.

To build the executables locally, look for a "make" script in the distribs directory. This script should have been checked out by the checkout script. Run this script and all of the executables should be compiled and installed into the appropriate install directory. I usually install executables in a directory called $HOME/rap/bin.

Create the data directory structure

Now that you have all of the executables, you can create the data directories. The first thing you need to decide is where do you have enough disk space for storing all of the NCWF datasets. It is best to store the datasets on a different physical disk or disk partition from the source files. This will reduce the risk of the entire system failing because the data disk has been filled up by an errant process that is either writing large log files or is dumping large core files. Once you have created a directory for storing the NCWF datasets, do the following:

    cd $PROJ_DIR
    ln -s  data

These commands tell the system where to put the data directories. Once this is done, you will need to install any needed parameter files in the data directories. Since each host in a system will have different datasets stored locally, the data directory parameter files are installed using a script with a configuration file specific to each host in the system. For example, to install the data directory parameter files on the anlab1 host in the RCWF Lincoln setup, the following command would be used:

    cd $DATA_HOME
    setupRapDataDirs.py -f data_lists/anlab1.data_list -p params

You should now have you data directory set up and ready to go.

Create host-specific links

The last step in setting up a system host is to create the host-specific links needed for the startup and shutdown scripts. These links are created in the $CONTROL/runtime directory. Generally, there is a process list link and a crontab link. Since each host in a system will usually have a different process list and crontab, these links are all host-specific. Using the anlab1 example above, the commands would be:

    cd $CONTROL/runtime
    ln -s $CONTROL/crontabs/anlab1.crontab CRONTAB_LIST
    ln -s $CONTROL/proc_lists/anlab1.process_list PROCESS_LIST

Start the system

You are now ready to start the system with the following command:

    host_startup

Note that this command only starts up the system on the current host. If the configuration consists of multiple hosts, this command will have to be entered on each host individually.

When you want to shut the system down, use the following command:

    host_shutdown

Again, this will only shut down the system on the current host.