ARSC T3E Users' Newsletter 123, August 8, 1997

Ramesh Agarwal Seminar Schedule

[ The previous newsletter announced these talks. Here is the final schedule: ]



  "Toward Teraflop Architectures, Algorithms, and Applications"
      -- Weds, Aug. 13, 10 a.m.  UAF Natural Sciences Building, Room 202
  
  
  "Application of Computational Fluid Dynamics (CFD)
   Based Technology to Semiconductor-Device Simulation"
      -- Thurs., Aug. 14, 12 noon. Peking Garden, 1101 Noble Street
  
  
  "General Aviation:  Past, Present, and Future"
                     and
  "Status of PA-18 Supercub Tundra Tires Project"
      -- Thurs., Aug. 14, 7 p.m. UAF Natural Sciences Building, Room 202
  
  
    Presented by:
      Dr. Ramesh K. Agarwal, Wichita State University


F90 Modules and Include Files

Modules are a new feature added to the FORTRAN90 language primarily as an aid in program development. Modules provide a means for organizing global data, derived types and associated operations, interface blocks and namelists groups or other associated data and programming units.

Everything that is associated with a particular task may be contained in a single or group of related modules and accessed whenever it is needed. The internal parts that are of no immediate interest may be made invisible to application programmers using the module. This allows the internal design to be altered without the need to make changes to the program and also prevents accidental alternation of internal data.

The code below shows a simple module and its use:

All modules are contained in a single file, plib.f


cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
      module size

        integer, parameter:: ndim=256

      end module size

cccccc

      module reference_vectors

        use size
        real, dimension(ndim):: a1,a2
        common /filters/ a1,a2

      end module reference_vectors

cccccc

      module set_reference_vectors
      contains

        subroutine set_vectors
        use reference_vectors

          a1=1
          a2=2

        end subroutine set_vectors

      end module set_reference_vectors

cccccc

      module vector

      contains

        function dotpro(a,result)
        use size
        use reference_vectors

        real, dimension(ndim) :: a
        integer :: i
        do i=1,ndim
        result=result+a(i)*a1(i)
        enddo
        dotpro=result

        end function dotpro


        function sum(a,result)
        use size
        use reference_vectors

        real, dimension(ndim) :: a
        integer :: i
        do i=1,ndim
        result=result+a(i)+a2(i)
        enddo
        sum=result


        end function sum

      end module vector
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

In general a module consists of code which is surrounded by MODULE <x> and MODULE END <x> where <x> is the module name. Modules may reference other modules. If a module contains code this follows the CONTAINS statement.

The following is a description of the above modules and their purpose.

size:
Defines size of the data sets the program will work with. In
this case the size is fixed and not within the control of the user.
reference_vectors:
This module contains two reference vector
datasets. Note that it USEs module SIZE.
set_reference_vectors:
This module contains the subroutine to
SET_VECTORS which initializes the reference vectors.
vector:
This contains two utility routines, DOTPRO and SUM. These are
called by the user within the program to perform specific actions. Each
routine USEs the REFERENCE_VECTOR module.

Note in the above how the module VECTOR subprograms have exactly the same form as an external subprogram. This allows the rapid migration of existing general Program utilities into modules. Care however must be taken in the structuring of these modules if they are to be useful and provide data protection.

The user's program is shown below. Note each module is USEd at points where either data or code contained in the module is required.


cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
      program motest

      use set_reference_vectors

      call set_vectors
      call work

      stop
      end


      subroutine work

      use size
      use vector

      real, dimension(ndim) :: a,b
      integer :: n

      real :: r1,r2,r3

      do n=1,ndim
        a(n)=n
        b(n)=ndim-n
      enddo

      r2=0.0
      r3=0.0

      r1=dotpro(a,r2)
      r2=r2+sum(b,r3)

      write(6,*) ' result ',r1,r2,r3

      return
      end
cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

In the user's code the main program USEs SET_REFERENCE_VECTORS so the call to SET_VECTORS can be made to establish the supporting data structures. The user's routine WORK contains the main activity of the program. In WORK the module SIZE is USEd so the user can dimension vector A, VECTOR is used so the user can call DOTPRO and SUM routines. Note how the user has no access to the arrays A1 and A2.

  • Are modules a great improvement over the logical use of include files?

The modules can be provided to a user as a compiled .o file or as a library/archive. Although similar results could be achieved with include files and libraries, the use of MODULEs has several advantages.

First, documentation need only reference those modules the user will need. In the above example this is SIZE, SET_VECTORS and VECTOR.

Second, modules provide information hiding. The user never directly references A1 and A2, which protects them against modification.

Third, Since MODULEs may reference other MODULEs programmers can build safe structures. This allows the users of libraries or complex data structures to avoid declaring any data structures except for local data within their own subroutines.

Modules can also be used to control which subroutines are available to the user at certain points within the program. For example, take the case of a parallel program where there are two different data distributions for a variable and the user is provided with a number of routines to update/enquire about this variable. The use of two modules named dist1 and dist2 might provide for an easy method of ensuring the user does not apply the wrong routines. Advanced cases dist1 and dist2 can contain version of routines with the same name which work with data in either dist1 and dist2 and the user can simple USE that which matches the data distribution. Again the usefulness of this feature requires careful design of code and structuring of the modules.

During the FORTRAN90 language creation process it was proposed that libraries would now consists of sets of modules.

For more information we recommend the following references:


  Fortran90/95 Explained. Metcalf and Reid. Oxford Science Publications.
  ISBN 0 19 851888 9
  
  Fortran 90 Programming. Ellis, Philips, Lahey. Adison-Wesley.
  ISBN 0-201-54446-6
  
  Programmers Guide to Fortran90. Brainerd, Goldberg, Adams. Unicomp.
  ISBN 0-07-000248-7

Modules and Apprentice on the T3D/E

To use modules, T3D users must first ensure they are using the PE 2 release of the Fortran90 compiler. To do this, run the UNICOS command:


  module list

If you see:


  cf90_m.0.1.3.0 

(which is the default T3D f90 compiler) then switch to version 2 by executing the command:


  module switch cf90_m.0.1.3.0 cf90_m.2.0.1.0

You may want to run the PEvers utility (See the "Quick-Tip", newsletter #117 ), which lists all installed versions of the programming environment tools.

On the current release of Apprentice on the ARSC T3D, modules are treated in a similar manner to library routines and no information is collected. This is corrected on the T3E apprentice version, where information is displayed as if modules were subprograms. All features such as source display and investigation work correctly with the added value of a link directly to the entire module.

PGHPF Evaluation Program for CRAY T3E

ARSC will install HPF_CRAFT on yukon, and hopes that users will take advantage of it during the evaluation period. At the end of September, we must decide whether or not to purchase a license: your feedback will carry a lot of weight in this decision.

The following press release is a follow-up to last week's article:


> In mid-July, SGI/Cray and the Portland Group, Inc. (PGI) announced the
> availability of HPF_CRAFT for the CRAY T3E.  HPF_CRAFT delivers the
> CRAFT capabilities introduced on the CRAY T3D within the context of the
> industry standard language, HPF.  The HPF_CRAFT implementation for the
> CRAY T3E was developed through a joint agreement between the two
> companies.
> 
> See http://www.cray.com/news/9707/HPFCRAFT.html for more detail.
> 
> HPF and CRAFT provide powerful capabilities for the rapid development
> and checkout of parallel applications.  Functionality and performance
> continue to improve with each successive release of PGHPF, and PGHPF
> 2.3 has even exhibited performance on some of the NAS Parallel
> Benchmarks that exceeds that achieved by the portable MPI
> implementations developed at NASA Ames (NPB 2.2).  (See
> http://www.pgroup.com/npb_results.html for details.)
> 
> To mark the release of HPF_CRAFT, PGI is offering free evaluation
> copies of the PGHPF 2.3 compiler, which includes support for HPF_CRAFT,
> to all CRAY T3E sites, for use through September 30, 1997.  Customers
> can download the compiler and license directly over the Internet.
> 
> 
http://www.pgroup.com/T3E/HPF_eval.htm

> 
> The 3.0 release of the CF90 Programming Environment must be installed
> in order to use PGHPF 2.3.  For more information on this release, see
> the June 1997 issue of the Cray Research Service Bulletin.
> 
> Customers who wish to use PGHPF after September 30, 1997, will need to
> purchase a license by contacting SGI/Cray.

ARSC is currently performing internal evaluation of PGHPF. Users interested in participating should contact Guy Robinson ( robinson@arsc.edu ).

ARSC Users: Dot to be Removed from Default PATH

In order to improve system security, ARSC will remove the current directory, specified by a "." or dot, from the system supplied default PATH on all ARSC systems. Schedule for removal:


        yukon:          [Never did have dot in default PATH.]
        SGI's:          [Was removed on 8/4/97.]
        denali:         To be removed on 8/18/97.

WARNING:

This change may cause scripts, including NQS scripts, to fail! In particular, if your script includes something like this:


  cd ~/project/progs
  a.out

then a.out will not be found. The preferred way for users to adjust to this change is to specify all paths explicitly. For instance:


  cd ~/project/progs
  ./a.out

For details and more examples, see "news dotinpath" on denali, the SGIs, or yukon, or read:


  http://www.arsc.edu/user/policy/DotInPath.html

ARSC Users: Reminder of seven day purge on /tmp

The purge policy on yukon has been in place since June 13. This is from "news purge":


      /tmp and core files subject to automatic purging
      ================================================
  
  Effective immediately, all files in /tmp, or named 'core' or
  'mppcore', will be automatically deleted seven days following their
  last access time. These steps are being taken to conserve limited
  storage resources, and are subject to change. If oversubscription
  persists, this interval may be reduced to fewer than 7 days. Users
  who attempt to circumvent this policy by "touching" files will be
  detected and may lose their account privileges.

Quick-Tip Q & A


A: {{ If you have a few heavily used directories and "cd" back and forth
     between them often, what shortcut will save you from typing the
     entire path each time? }}
  # 
  # Here are a couple of methods:
  # 
  # 1)  For users of csh, tcsh, and other derivatives, a couple of 
  #     readers suggested pushd and popd.  Readers also suggested 
  #     aliases similar to these (for C-shell):
  #
            alias sv1 'setenv wd1 $PWD'   
            alias sv2 'setenv wd2 $PWD'   
            alias cd1 'cd $wd1'           
            alias cd2 'cd $wd2'           
            alias sv  'echo \$wd1= $wd1\\n\$wd2= $wd2'
  #  
  #     "sv1" would save the current directory to the variable "wd1"; 
  #     "cd1" would return to it later; and "sv" would list the saved 
  #     directories.  
  # 
  # 
  # 2)  CDPATH is a useful tool for users of POSIX shells (Korn, sh, 
  #     etc...).  Like PATH, you set CDPATH to a list of directories.
  #     Then, when you execute a "cd", the shell searches those direct-
  #     ories, in order, for the requested directory.  Using last week's
  #     example, if Armadillov defined his CDPATH environment variable 
  #     as follows:
    
             yukon$   CDPATH=":/tmp/armadill/meltdown/data/1997_06:"
             yukon$   CDPATH="$CDPATH:~/meltdown/results"
  #  
  #     Then he could issue these commands:
  #      
             yukon$   cd 1
             yukon$   run_em
             yukon$   cd 1997
             yukon$   store_em
  #  
  #     Instead of these:
  #  
             yukon$   cd /tmp/armadill/meltdown/data/1997_06/1
             yukon$   run_em
             yukon$   cd ~/meltdown/results/1997
             yukon$   store_em
    

Q: How can you merge two versions of a C or Fortran source into a
   single file so that you may compile either version by simply
   defining (or undefining) a preprocessor variable?  For example:

   -- version 1 -- 
   #include <stdio.h> 
   main () {
     printf ("Hello world...\n"); 
   }


   -- version 2 -- 
   #include <stdio.h> 
   main () {
     printf ("Hello from: FILE:%s LINE:%d\n", __FILE__, __LINE__); 
   }


   -- merged version -- 
   #include <stdio.h> 
   main () { 
   #ifndef DEBUG
     printf ("Hello world...\n"); 
   #else /* DEBUG */
     printf ("Hello from: FILE:%s LINE:%d\n", __FILE__, __LINE__);
   #endif /* DEBUG */ 
   }

[ 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