- Infos im HLRS Wiki sind nicht rechtsverbindlich und ohne Gewähr -

Difference between revisions of "CAE utilities"

From HLRS Platforms
Jump to navigationJump to search
Line 97: Line 97:
This approach is '''not''' secure, but better than the "open to all" approach.
This approach is '''not''' secure, but better than the "open to all" approach.
Looking at the help first:
Looking at the help first:

Revision as of 11:09, 18 October 2008

A collection of small helper scripts.

module load cae

will you take care that these are found when called through the commandline or e.g. a job script.


qgen will generate a job script based on a template.

qgen -h

will print some help and

qgen -l

will list all available templates found in the QGEN_TEMPLATE_PATH One of these templates is "test", which doesn't need any further arguments.

qgen test

A job file will be printed. Save this job file to "test.pbs" and compare it with the template:

qgen -o test.pbs test
tkdiff test.pbs /app/rus/struct/bin/qgen_templates/test

(If there's no X avaiable, replace tkdiff with e.g. sdiff)

qgen just replaces some placeholders within the template. Everyone can expand the system writing own templates. The default path for these files is ~/qgen_templates

Now the job script could be submitted with "qsub test.pbs", but... (approx.) the same (for 2 requested nodes) can also be achieved with:

qgen -n 2 --submit test

However, omitting the -o option, the executed job script will not be saved for the user.

In general, templates require additional options. The help might give you a hint at the end, e.g.

qgen -h abaqus
qgen    a tool to generate(&submit) pbs jobfiles        (author: Martin Bernreuther <bernreuther@hlrs.de>)
usage: qgen [-n|--nodes <nodes>] [-t|--walltime <walltime>] [-N|--jobname <jobname>] [-w|--workdir <workdir>] [-o <jobfile>] [--submit|--submitq <queue>|--execute] [-] [<template>] [<template_opt1> <template_opt2>...]
      -n|--nodes <nodes>       [default: 1]    number of nodes
      -t|--walltime <walltime> [default: 12:00:00]      walltime
      -N|--jobname <jobname>   [default: <template><datetime>] job name
      -w|--workdir <workdir>   [default: /scratch2/ws/hpcbern-dynatest-0]       working directory
      -o <jobfile>     [default: <stdout>]      jobfile output
      --submit         submit immediately (to standard queue)
      --submitq <queue>        submit immediately to queue
      --execute        execute on current host immediately
      -l               list system templates
      -h|--help                print help and exit
      <template>               template to use
      <template_options>       additional options depending on the template
qgen will create a pbs jobscript based on a template, substituting
$QGEN_NODES, $QGEN_WALLTIME, $QGEN_NAME, $QGEN_WORKDIR and $* (latter with template options)
Instead of setting the values with command line arguments,"
       echo "environment variables might be used (except for template options)
These environment variables might be also set in the configuration file
~/.qgenrc, which is sourced at the beginning.
Templates are searched for in $QGEN_TEMPLATE_PATH, actually set to:
~/qgen_templates /app/rus/struct/bin/qgen_templates

abaqus template_options: options for abaqus, e.g. job=<jobname>

Submitting an ABAQUS job on 4 nodes is as easy as executing

qgen -n 4 --submit abaqus job=<jobname>

with <jobname> as ABAQUS inputfile (absolute path or relative path to the current directory). Typically a workspace is used here. As mentioned before, more control is gained, if the PBS jobfile is generated first and submitted afterwards, like with this LS-Dyna example:

qgen -o lsdyna.pbs -n 8 dyna i=<inputfile>
qsub lsdyna.pbs

Before the submission with qsub, the jobfile might be changed/tuned.

There's also a simple template to execute a single command:

qgen -N cmdtoptest --submit cmd top -b -n 1

The -N option sets the jobname and affects the names of the stdout/stderr files. The output of the command "top -b -n 1" can thus be found in the cmdtoptest.o* file. The error output cmdtoptest.e* is hopefully empty...

ws_exchange procedure

Exchanging data between users who don't share a common group sometimes leads to creating an workspace with permissions set to read (or/and write) and execute to world (others). ws_exchange goes in that direction with a slight modification: the workspace directory permissions are set to execute for all, but doesn't allow reading its contents. A readable(/writable) subdirectory is therefore "invisble" to others. This approach is not secure, but better than the "open to all" approach.


Looking at the help first:

ws_exchange -h
/app/rus/struct/bin/ws_exchange: option requires an argument -- h
usage: ws_exchange [-s <secret subdirectory name>] [-d <workspace duration>] [-w <workspacename>] [-f <workspace filesystem>] [-p <permissions>]
       -s <secret subdirectory name> [default: random name]
       -d <workspace duration [d]>   [default: 0 days (24 hours)]
       -w <workspacename>            [default: exchange%Y%m%d%H%M%S]
       -f <workspace filesystem>     [default: default of ws_allocate]
       -p <permissions>              [default: go+rwx]
ws_exchange will create a workspace, which is executable but not readable for the world.
Its contents are hidden and a additional created subdirectory, which name serves as a password, could be open to the world.

Executing ws_exchange with default options will create a one-day workspace in the default file system with a name starting with "exchange" followed by the date and time and a subdirectory with random name and execute/read/write permissions:

Workspace created on gerris
exchange20081018113236                                      Oct 18 11:32:51  0 days 23 hours
 exchange directory ----------------------------------------
you might ws_cp2exchange to copy your files to exchange20081018113236

Concerned other user have to be notified about the path ("/scratch2/ws/hpcstruc-exchange20081018113236-0/Yj2mskvAuC6" in the example) e.g. by email.


Files also have permissions and especially copying files to a ws_exchange workspace these permissions are automatically set too restrictive. It's also a good idea first to change the current directory to the ws_exchange subdirectory and copy to this directory than in the other direction. To simplify this, "ws_cp2exchange" was created.

ws_cp2exchange -h
usage: ws_cp2exchange [cp|mv] [<options>] <src> <wsname>

To copy a file "testfile" to the ws_exchange workspace subdirectory created above simply write

ws_cp2exchange testfile exchange20081018113236
working directory: /scratch2/ws/hpcstruc-exchange20081018113236-0/Yj2mskvAuC6
cp  /DDN1/HLRS/hlrs/hpcstruc/testfile .
change permissions to g+rwx,o+rwx