ARSC T3D Users' Newsletter 110, November 1, 1996

PE2.0 at ARSC

PE2.0 on denali has been available for user testing since 9/11, was made the default environment on 9/24, and will soon be the ONLY environment. As noted in news pe2.0 , ARSC will remove Programming Environment 1 as early as test time next week (11/5).

This will have a positive effect on T3D users, but as noted in the following news pe2.0 item, may require some changes:

Programming Environment 1 To Be Removed

On or after November 5th, PE 2.0 will become the only programming environment available on denali. As soon as we determine the exact date on which the previous environment will be removed, we will post this date via the motd and news.

PE 2.0 was made the default environment on Sept 24. However, it is possible that many users are still using PE 1. Here are three ways that this could occur:

  1. If makefiles specify explicit paths to PE1 compilers, libraries, includes, and other programming tools.
  2. If the user manually reverts the environment.
  3. If the user has not recompiled his or her programs since Sept 24.

We encourage all users to verify that they are using the new environment:

  • The PE2.0 compilers, libraries, and includes are all under the /opt subdirectory. Thus, if used, explicit paths in makefiles should start with /opt . In general, however, explicit paths are unnecessary, and should be avoided.

  • The command module load modules PrgEnv was appended to every user's .profile or .cshrc file as part of the Sept. 24 installation. This command loads PE2.0, making it your default programming environment.

    You can unload PE2.0 using the command "module unload modules PrgEnv." If you have removed the load command from your .cshrc or .profile file, or if you manually unload PrgEnv before compiling your programs, then you may not have tested PE2.0.

    For more information on the module command, see:

    1. man module
    2. documents in: /opt/ctl/doc
    3. the postscript paper: /opt/modules/modules/doc/Modules-Paper.ps
  • If you are running executables compiled before Sept 24th, then you may not have tested PE2.0.

Point number 1, above, may apply to many T3D users. In many of my own makefiles, for instance, I have defined:

F77=/mpp/bin/cf77

or

CC=/mpp/bin/cc

These explicit paths are unnecessary, as by targeting the T3D, you get the correct compiler anyway. Here are targeting options:


  cf77: cf77 -C cray-t3d

  cc:   cc -T cray-t3d

  any:  export TARGET=cray-t3d
        f90
        cf77
        cc

The best approach is to remove the explicit paths, and trust the targeting. If you leave explicit paths, to /mpp/bin/mppld, for instance, then when PE 1 is removed, the shell will no longer be able to find mppld, and your makefile will fail.

Modules

A nice feature of PE2.0 is a new package called Modules and the user command, module . As upgrades come in, this command will allow you to switch to a new programming environment and back again very easily. >From the documentation, "the modules package is a database and set of scripts that simplify shell initialization and lets users easily modify their environment during the session."

As noted in the next article, you MUST use modules to use PE2.0.

Accessing Programming Environment Software

Here is Cray's readme on PE2.0 and Modules (/opt/ctl/doc/README). Point 2.1 is already done for ARSC users, as the required commands were appended to all users' .cshrc and .profile files as part of the installation on 9/24.



                                   Accessing
                         Programming Environment Software

1.0     Introduction

Cray Research combines compiler and supporting application tools (CrayTools) 
and libraries (CrayLibs) into programming environment releases, providing an 
integrated environment.

Beginning with the following releases:

    o - CF90 Programming Environment 2.0 for PVP systems

    o - C++ Programming Environment 2.0 for PVP systems 

    o - *C++ MathPack 2.0 for PVP and MPP systems 

    o - *C++ ToolLib 2.0 for PVP and MPP systems 

    o - Standard C Programming Environment 1.3 for MPP systems 

    o - CF90 Programming Environment 1.3 for MPP systems

    o - CF77 6.3 Programming Environment for MPP systems

    o - *CAL 10.0 (available only for Cray T90 series with IEEE floating-point 
        arithmetic)

    o - *Pascal 4.2.4

    o - *CAM 2.1.1

    o - *MPT 1.0

the assembler, compilers, CrayTools and CrayLibs are now located in 
/opt/ctl/product/version directories. On PVP systems these products are no 
longer located in /bin, /usr bin, /lib, or /usr/lib and on Cray MPP systems 
these products are no longer located in /mpp/bin, or /mpp/lib.  The 
installation and configuration process has been changed to work in conjunction 
with the Modules package created by John L. Furlani.

* These products are not packaged as part of a programming environment, 
but are referenced here because they are also installed in 
/opt/ctl/product/version directories and also work in conjunction with the 
Modules package.


2.0     How to access 2.0, and later, programming environment products

Installation of the programming environments into /opt/ctl requires users of 
these releases to use the Modules software provided in the release package.  
Modules manipulates your environment including search paths(ie PATH, MANPATH).  
Using hard-coded paths can cause you to get an incorrect version of software or 
to not find the software at all.  Once your environment is set up and you have 
executed the module load PrgEnv statement, defaults of all programming 
environment products on the system are loaded as a complete environment. 
Changes made to your environment by typing modules load PrgEnv can be undone 
by typing module rm PrgEnv.

Note: since programming environment 2.0, and later products are no longer 
installed into /bin, /usr/bin, /lib, /usr/lib, /mpp/bin, or /mpp/lib, 
hard-coded references to these directories will fail, including hard-coded 
references in nmake files, make files and scripts.

2.1      Setting up your user environment

The releases listed in the beginning of this document make use of AND rely on 
the Modules package. To access these programming environment packages YOU 
MUST ADD the following statements to either your .cshrc or .profile files 
(the statements must follow all other path setting code):

.cshrc (for c shell users) enter following code:

if (-f /opt/modules/modules/init/csh) then

                 # Initialize modules

        source /opt/modules/modules/init/csh 
        module load modules PrgEnv

endif


.profile (for sh and ksh shell users) enter following code:

if [ -f /opt/modules/modules/init/ksh ] ; then

        # Initialize modules

        . /opt/modules/modules/init/ksh 
        module load modules PrgEnv

fi


You are now ready to compile, load and execute your programs.


3.0     Multiple version levels of programming environments

If the site has installed multiple version levels of one of the programming 
environments listed in the Introduction (for example, the product has been 
updated and the earlier update versions are still available) you may want to 
switch from one level of a specific product to another

3.1     How to see which product levels are available

To see which levels of compilers, craylibs and craytools are available type   
"module avail". 

Following is a sample list. Note the products listed without version numbers 
are the defaults.  These are loaded by the PrgEnv modulefile and are links to 
one of the products listed with a version number.

--------- /opt/modules/modules/modulefiles ---------

CC              cf90.2.0.0.0    craylibs.2.0.0.0 

CC.2.0.0.0      cf90.2.0.0.1    craytools

CC.2.0.0.1      cf90.2.0.0.2    craytools.2.0.0.1

CC.2.0.0.2      cf90.2.0.0.3    craytools.2.0.0.2

PrgEnv          craylibs        modules

cf90

3.2     How to switch from one product level to another

The statement "module switch cf90 cf90.2.0.0.2" changes the default compiler 
accessed by the f90 command from cf90 (the default) to the compiler in 
cf90.2.0.0.2.

To restore the previous default version type "module switch cf90.2.0.0.2 cf90". 

Note: the craylibs and craytools version levels were not affected with the 
      compiler specific switch. The defaults for these products are still 
      used.


4.0     Impact to existing programming environment installed on the system

Since the installation process is in transition from the former installation 
method to the new method, programming environments installed on the system with 
the former method are impacted when a user executes the module load PrgEnv 
statement. Driver scripts have been installed that interface with the 
existing products installed in /bin, /usr/bin, /lib, /usr/lib, /mpp/bin and 
/mpp/lib directories. These scripts are called instead of the product. The 
scripts interface with the environment such that compilers installed in /bin 
interface with the libraries and loaders loaded with the module load PrgEnv 
statement. 

For example, the script /opt/bin/cf77 is invoked when the user types cf77. This
script will use environment variables set by the module load commands and then 
invoke /bin/cf77 for compilation with PE 2.0 craylibs. Similar scripts are 
provided for cft77, fort77, gpp, cc, cpp, c89, ld, and segldr. All of these 
driver scripts will make use of the PE 2.0 components if the PrgEnv modulefile 
is loaded.

4.1     How to access products currently installed in root (/bin, /lib, etc.)

One of the following programming environments may already exist on your system 
and may still reside in root directories (/bin, /usr/bin, /lib/, and /usr/lib).

    o - CF77 Programming Environment 

    o - Standard C Programming Environment 

    o - previous release[s] of CF90 programming environment

    o - previous release[s] of the Cray C++ compiling system

4.1.1   Remove the PrgEnv environment

To use a pre-2.0 version of the CF90 environment and/or C++ compiling system 
installed in the root directories or to over-ride the PE 2.0 defaults for CF77 
and Standard C environments type "module rm PrgEnv" to restore your environment 
to the pre-2.0 state. You can now access all pre-2.0 compilers, libraries and 
tools installed in the root directory.  Entering the command module rm PrgEnv 
will undo all changes made by module load PrgEnv. To restore the PrgEnv
environment type "module load PrgEnv".

4.1.2   Retain the PrgEnv environment, access pre-2.0 compilers, loader and 
        libraries directly

As noted above, once the "module load PrgEnv" statement (or any other module
load statement) is executed, when a program is compiled or loaded with
the cf77, cft77, fort77, cc, c89, CC, ld, segldr, mppldr, or mppld  commands,
the craylibs and/or craytools libraries installed in /opt/ctl are used (not
the pre 2.0 libraries and loader installed in /usr/lib,/lib,/mpp/lib and
/usr/bin,/bin,/mpp/bin).
If you do not want to totally remove the PrgEnv environment, but want cf77 or
cc commands to link with the libraries in /lib, invoke the cf77 and cc commands
with the root path (e.g. /bin/cf77 or /bin/cc). Also, if you want to use the
pre-2.0 cf90 compiler installed in root, invoke the f90 command directly with
the root path /bin/f90.

If you invoke the cf77, f90 and cc commands with the root path, /bin/cf77, 
/bin/f90 or /bin/cc and:

    o - Your site has NOT un-installed the root (/lib, /usr/lib) versions of 
        the old libraries, you must also select the loader with the root paths. 

        For example:

        /bin/cft77 file.f       /bin/cc -C file.c

        /bin/segldr file.o      /bin/ld file.o

    o - Your site HAS un-installed the root (/lib, /usr/lib) versions of the 
        old libraries and you invoke the compilers with the root path you will 
        get undefined entry names, as the compiler will not be able to find the 
        library and loader. In this case you should discontinue invoking the 
        compiler with the root path and invoke the compilers as either cf77 and         cc or /opt/ctl/bin/cf77 and /opt/ctl/bin/cc.


5.0     Additional Documentation

For more information about the Modules program type man module and man 
modulefile. The module command also has sub-commands, following are some useful 
sub-commands:

    o - module list - Lists all loaded modules

    o - module avail - List all available modulefiles in the current MODULEPATH

    o - module display - Display changes modulefile will make to the
                         environment.

    o - module switch oldmodulefile newmodulefile - Switch loaded oldmodulefile 
                                                    with newmodulefile. 

    o - module rm modulefile - Remove modulefile from the shell environment.

    o - module help modulefile - Prints the module specific help information for
                                 the modulefile. 

For more information about the PrgEnv module type "module help PrgEnv".

The document Modules: Providing a Flexible User Environment describes modules in
more detail. A post- script version of this document is available in:

        /opt/modules/modules/doc/Modules-Paper.ps.

A Very Sad Note

Every week, a few newsletters come back to me. Last week, a note came back that Dr. Clive Baillie of the University of Colorado, Boulder and his wife Julie had been killed in a climbing accident on October 12. I would like to extend my sympathy to the families and friends of Clive and Julie, and to the CS department at CU. Dr. Baillie was a researcher on ARSC's T3D and member of this group. If you would like to learn more about Clive and Julie, a web site has been created to honor them:

http://wwwmcb.cs.colorado.edu/home/mcbryan/clive/Home.html

Correction

In last week's CUG summary, I mentioned the bchop utility written by Dr. R. K. Owen. Dr. Owen is no longer at NAS as I stated, and the correct URL for bchop is:

http://www.kudonet.com/~rkowen/sources/apps/bchop.html

Quick-Tip Q & A


A: {{ You telnet to a remote site, and suddenly your backspace key
      produces funny text instead of spacing back.  How do you fix 
      this? }}

   # Assuming you find yourself on a unix system, try the following 
   # command (where "<BKSP>" means, "the backspace key"):

   stty erase <BKSP>

Q: You're using the "make" utility while developing some code, and
   changing the "Makefile" itself as part of the process (to try
   different compiler paths, for instance).  Do you need to "make
   clean" every time you update the Makefile?  or is there an easier
   way to tell "make" that you want to recompile everything?

[ Answers, questions, and tips graciously accepted. ]


Current Editors:
Ed Kornkven ARSC HPC Specialist ph: 907-450-8669
Kate Hedstrom ARSC Oceanographic Specialist ph: 907-450-8678
Arctic Region Supercomputing Center
University of Alaska Fairbanks
PO Box 756020
Fairbanks AK 99775-6020
E-mail Subscriptions: Archives:
    Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.
Back to Top