ARSC T3E Users' Newsletter 159, January 8, 1999

Kerberos/SecurID At ARSC

The only access to ARSC systems will soon be via Kerberos/SecurID. This change will take place by next Tuesday, Jan 12, at 10pm at the earliest, and by next Friday at the latest.

We have begun a series of e-mail bulletins to all ARSC users regarding this. They're all available online at:

http://www.arsc.edu/support/news/bulletins/Krb5.html

and the most recent is posted as "news transition" on all ARSC systems.

We appreciate your patience as we proceed with this vital project.

Creating Your Own Libraries

[ Many thanks to Dr. Jeff Orrey of Ojo Solutions for this contribution. Jeff's contact info is given at the end of this article. ]

Do you find yourself frequently reusing code fragments to perform tasks that you do on a regular basis? If so, those code fragments are perfect candidates for a library. Creating you own library of routines makes your codes cleaner and more compact, and it encourages you to standardize certain operations that your codes frequently perform.

Creating and using a library on the ARSC Cray T3E is no different that doing so on other Unix machines. First, the source code for the library must be compiled into object code. Then the object files are linked together into an archive using ar(1). The archive is then passed to ranlib(1), which prepares the archive for linking. All of these steps are typically performed in the Makefile for the library. Once the library is prepared for linking, the routines in the library may be called from code which links the library.

Once libexample.c is compiled, it can be used by code which requires reading of data using the utility read_vgrid(), above. Following is a Makefile template, for a routine called mycode.c which incorporates the library libexample.a:

Specifying Number Of Processors

How do you tell Unicos/mk the number of processors (PEs) to use when it runs your application? It's a basic, and, for new users, a sometimes confusing, question. Here's a quick review:

Creating Malleable Executables

You should (probably) compile your application to be "malleable" so you may specify the number of PEs when you launch the executable. To create a malleable executable, omit the "-X" compiler option. E.g.:

f90 prog.f
cc prog.c

Running Malleable Executables Interactively

At ARSC, you may run interactive parallel jobs on up to 8 PEs. Assuming "a.out" was compiled to be malleable, you may launch it using the "mpprun" command, providing the "-n" option to specify the number of PEs. E.g.:

mpprun -n 5 ./a.out

(Remember, at ARSC you must specify an explicit path to the executable, even if it is the current default directory--otherwise known as ".".) The above command would tell Unicos/mk to launch "a.out" on 5 application PEs.

So far so good...

Running Malleable Executables In Batch

The batch scheduler on the T3E is "NQS." To use NQS, you write a script and submit it using the "qsub" command.

All qsub scripts have two parts: commands for NQS and command for the shell. With regard to the number of PEs, first you request them from NQS and then you request them from mpprun. All this is documented in:

Note: six PEs are requested of both NQS (#QSUB -l mpp_p=6) and the system (mpprun -n6).

Creating Non-Malleable Executables

You may hard-wire the number of processors required into an executable the "-X" compiler option. E.g.:

f90 -X 6 prog.f
cc -X 6 prog.c

We discourage you from doing this (or needing to do this)! If your program can only run on a fixed number of PEs, then it won't scale up to bigger machines and it won't squeeze into available partitions on the current machine.

Running Non-Malleable Executables

Whether running interactively or in batch, if your executable is non-malleable, you must NOT use the "-n" option to mpprun--even if you specify the same number of PEs for which the executable was compiled.

Either of the following commands will run the executable:

./a.out
mpprun ./a.out

Testing For Malleability

To determine if your executable is malleable or not, and if not, how many PEs it will run on, use the "file" command:

file a.out

More Information

See:

http://www.arsc.edu/support/howtos/usingt3e.shtml
,

past issues of this newsletter, man pages, etc.

Quick-Tip Q & A

A: {{ Will C correctly cast a pointer reference value? For instance,
given this declaration:
unsigned temp = *uint;
will "temp" be set as expected even if "uint" is an int pointer? }}
#
# Thanks to Shawn Houston of ARSC for both question and answer. Here's
# the answer as paraphrased from the ANSI C Standard:
#
# A pointer to an object may be converted to a pointer to a different
# object type. The resulting pointer might not be valid if it is
# improperly aligned for the type pointed to. It is guaranteed,
# however, that a pointer to an object of a given alignment may be
# converted to a pointer to an object of the same or less strict
# alignment and back again. The result shall compare equal to the
# original pointer.
#
# Here's a curious little test:
#
/*------------------------------------------------------------------*/
/* badcast.c */
unsigned badcast(unsigned* uint)
{
unsigned temp = *uint;
return temp;
}
int main(int argc, char* argv[])
{
int i;
for(i = -4; i < 5; ++i)
{
printf("%d ?= %u : %s\n",
i, badcast(&i), i == badcast(&i) ? "YES" : "NO");
}
return 0;
}
/*------------------------------------------------------------------*/
#
# The compiler issues warnings about "incompatible pointer type assignment,"
# but, at the default error levels, creates an executable. Here's a run:
#
yukon$ ./a.out
-4 ?= 18446744073709551612 : YES
-3 ?= 18446744073709551613 : YES
-2 ?= 18446744073709551614 : YES
-1 ?= 18446744073709551615 : YES
0 ?= 0 : YES
1 ?= 1 : YES
2 ?= 2 : YES
3 ?= 3 : YES
4 ?= 4 : YES
Q: To SecurID Card veterans: any advice? For instance, how do you
carry your card (without destroying it) so it's not at work when you
need it at home or vice versa?

The University of Alaska Fairbanks is an affirmative action/equal
opportunity employer and educational institution and is a part of the University
of Alaska system.
Arctic Region Supercomputing Center (ARSC) |PO Box 756020, Fairbanks, AK 99775 | voice: 907-450-8602 | fax: 907-450-8601 | Supporting high performance computational research in science and engineering with emphasis on high latitudes and the arctic.
For questions or comments regarding this website, contact info@arsc.edu