GRASS and Shell: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
Line 46: Line 46:
=== Example ===
=== Example ===


* GRASS shell script job to generate a [http://grass.itc.it/spearfish/grass_earthquakes.sh Recent Earthquakes Map]
* GRASS shell script job to generate a [http://grass.itc.it/spearfish/php_grass_earthquakes.php Recent Earthquakes Map] ([http://grass.itc.it/spearfish/grass_earthquakes.sh shell script])


=== Parallel GRASS jobs ===
=== Parallel GRASS jobs ===

Revision as of 14:52, 24 January 2007

It is fairly easy to write a GRASS job as Shell script which launches GRASS, does the operation and cleans up the temporary files.

Setting the variables

You have to set a couple of variables to enable GRASS command to run:

  # Example in bash shell syntax:

  # path to GRASS binaries and libraries:
  export GISBASE=/usr/local/grass60

  export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts
  export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GISBASE/lib

  # use process ID (PID) as lock file number:
  export GIS_LOCK=$$

  # settings for graphical output to PNG file (optional)
  export GRASS_PNGFILE=/tmp/grass6output.png
  export GRASS_TRUECOLOR=TRUE
  export GRASS_WIDTH=900
  export GRASS_PNG_COMPRESSION=1


The following variable defines where the GRASS settings file is stored. This can be anywhere on the system. You could also generate the '.grassrc6' on the fly in your script, even with different name. Just indicate it correctly:

  # path to GRASS settings file
  export GISRC=$HOME/.grassrc6

Now you can test:

  # this should print the GRASS version used:
  g.version
  # other calculations go here ...

You should cleanup internal tmp files like this:

  # run GRASS' cleanup routine
  $GISBASE/etc/clean_temp

  # remove session tmp directory:
  rm -rf /tmp/grass6-$USER-$GIS_LOCK

If this works, you can launch other GRASS commands. The approach works within Shell scripts and also in the command line terminal.

Example

Parallel GRASS jobs

If you want to launch several GRASS jobs in parallel, you have to launch each job in its own mapset. Be sure to indicate the mapset correctly in the GISRC file (see above). You can use the process ID (PID, get with $$) to generate a almost unique number which you can add to the mapset name.

Now you could launch the jobs on an openMosix cluster (just install openMosix on your colleague's computers...).

GRASS Batch jobs

There is (now) an alternative method to easily run jobs in GRASS from a collection of commands in a shell script file. Just define the environmental variable GRASS_BATCH_JOB with the shell script file containing GRASS (or whatever) commands, preferably with full patch. Then launch GRASS and it will be executed. Best is to launch GRASS in -text mode and to provide GISDBASE/location/mapset as parameters. The job scripts needs executable file permissions (chmod).

Example:

      chmod u+x $HOME/my_grassjob.sh
      export GRASS_BATCH_JOB=$HOME/my_grassjob.sh
      grass63 ~/grassdata/spearfish60/neteler/

The grass63 command starts GRASS, executes the contents of the job file and leaves GRASS. Since the normal startup/closure is used, all tmp files are properly removed.

To deactivate the batch job mode, run (bash example):

       unset GRASS_BATCH_JOB

Along with the "nohup" command you can login to your machine, launch it and leave the machine. Maybe put email notification at the end of 'my_grassjob.sh' using the "mail" or the "mutt" program, for example like this (enter in one line):

       echo "Finished at `date`" > /tmp/done.txt && \
       EDITOR=touch mutt -s "Job done" \
       me@mydomain.org < /tmp/done.txt && rm -f /tmp/done.txt

See also