![[Menu Bar]](/images/header.gif)
| Newsletter Index | Quick-Tip Index | Search Newsletters |
[ 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
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.
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.
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
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.
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 (
).
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.
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
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.
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. ]
Contact:
Thomas J. Baring ARSC Web Specialist ph: 907-450-8619 Donald Bahls ARSC User Consultant ph: 907-450-8674 Arctic Region Supercomputing Center University of Alaska Fairbanks PO Box 756020 Fairbanks AK 99775-6020
Send comments and questions to the current editors using this Contact Form.Email Subscriptions:
| Newsletter Index | Quick-Tip Index | Search Newsletters |
Arctic Region Supercomputing Center
PO Box 756020, Fairbanks, AK 99775 | voice: 907-450-8600 | email: 
home | search | about | support | news | science | resources