? HTML.index
? arrays-arrays.html
? arrays-arrays_declarations.html
? arrays-arrays_use.html
? arrays-containers.html
? arrays-domains.html
? arrays-dynamic_arrays.html
? arrays.html
? concepts-computation_environment.html
? concepts-computation_modes.html
? concepts-containers.html
? concepts.html
? data_parallel-implementation.html
? data_parallel-multiple_values.html
? data_parallel-use.html
? data_parallel.html
? differences-2002Feb26
? engines-concept.html
? engines-types.html
? engines.html
? genindex.sgm
? glossary.html
? initial-compile.html
? initial-compile_programs.html
? initial-distributed_computing.html
? initial-obtain.html
? initial-quick_start.html
? initial.html
? introduction-goals.html
? introduction-open_source.html
? introduction-pooma_history.html
? introduction.html
? manual-2002Feb26.ChangeLog
? manual-2002Jan31.ChangeLog
? manual-2002Jan31.patch
? pooma-html.manifest
? pooma.aux
? pooma.dvi
? pooma.html
? pooma.log
? pooma.out
? pooma.pdf
? pooma.ps
? pooma.tex
? preface-acknowledgements.html
? preface-downloading.html
? preface-pooma_history.html
? preface-reading_book:.html
? preface.html
? preface.pdf
? preface.ps
? sources-conventions.html
? sources-structure.html
? sources.html
? template_programming-compile_time.html
? template_programming-pooma_implementation.html
? template_programming-template_use.html
? template_programming.html
? tutorial-array_data_parallel.html
? tutorial-array_distributed.html
? tutorial-array_elementwise.html
? tutorial-array_stencil.html
? tutorial-field_data_parallel.html
? tutorial-field_distributed.html
? tutorial-hand_coded.html
? tutorial.html
? uml-arrays.html
? uml-domains.html
? uml-engines.html
? uml.html
? views.html
? wrap-programlisting.pl
? figures/array-uml.1
? figures/array-uml.2
? figures/array-uml.3
? figures/concepts.101
? figures/concepts.111
? figures/concepts.log
? figures/concepts.mpx
? figures/data-parallel.101
? figures/data-parallel.212
? figures/data-parallel.log
? figures/data-parallel.mpx
? figures/distributed.101
? figures/distributed.log
? figures/distributed.mpx
? figures/domain-uml.1
? figures/doof2d.201
? figures/doof2d.202
? figures/doof2d.203
? figures/doof2d.210
? figures/doof2d.211
? figures/doof2d.log
? figures/doof2d.mpx
? figures/engine-uml.1
? figures/engine-uml.2
? figures/engine-uml.3
? figures/engine-uml.4
? figures/explanation-uml.1
? figures/explanation-uml.log
? figures/explanation-uml.mpx
? figures/foo.1
? figures/foo.mp
? figures/introduction.101
? figures/introduction.log
? figures/introduction.mpx
? figures/mproof-array-uml.ps
? figures/mproof-concepts.ps
? figures/mproof-data-parallel.ps
? figures/mproof-distributed.ps
? figures/mproof-domain-uml.ps
? figures/mproof-doof2d.ps
? figures/mproof-engine-uml.ps
? figures/mproof-explanation-uml.ps
? figures/mproof-introduction.ps
? figures/mproof.dvi
? figures/mproof.log
? figures/mproof.ps
? figures/prev
? programs/Doof2d/Doof2d-Array-distributed-annotated.cpp
? programs/Doof2d/Doof2d-Array-element-annotated.cpp
? programs/Doof2d/Doof2d-Array-parallel-annotated.cpp
? programs/Doof2d/Doof2d-Array-stencil-annotated.cpp
? programs/Doof2d/Doof2d-C-element-annotated.cpp
? programs/Doof2d/Doof2d-Field-distributed-annotated.cpp
? programs/Doof2d/Doof2d-Field-parallel-annotated.cpp
? programs/Sequential/array-copy-annotated.cpp
? programs/Sequential/array-size-annotated.cpp
? programs/Sequential/dynamicarray-annotated.cpp
? programs/Sequential/initialize-finalize-annotated.cpp
? programs/Sequential/pairs-templated-annotated.cpp
? programs/Sequential/pairs-untemplated-annotated.cpp
Index: Makefile
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/Makefile,v
retrieving revision 1.7
diff -c -p -r1.7 Makefile
*** Makefile 2002/02/01 17:43:13 1.7
--- Makefile 2002/02/27 03:44:23
***************
*** 7,22 ****
TEX= latex
# Definitions for Jade.
! JADEDIR= /usr/share/sgml/docbook/dsssl-stylesheets-1.64
PRINTDOCBOOKDSL= print.dsl # print/docbook.dsl
HTMLDOCBOOKDSL= html.dsl # html/docbook.dsl
XML= dtds/decls/xml.dcl
INDEXOPTIONS= -t 'Index' -i 'index' -g -p
MANUALNAME= pooma
! XMLSOURCES= $(MANUALNAME).xml introduction.xml template.xml tutorial.xml \
concepts.xml arrays.xml data-parallel.xml glossary.xml \
! bibliography.xml
# Create all versions of the manual.
all: $(MANUALNAME).ps $(MANUALNAME).pdf $(MANUALNAME).html
--- 7,23 ----
TEX= latex
# Definitions for Jade.
! JADEDIR= /usr/lib/sgml/stylesheets/docbook # /usr/share/sgml/docbook/dsssl-stylesheets-1.64
PRINTDOCBOOKDSL= print.dsl # print/docbook.dsl
HTMLDOCBOOKDSL= html.dsl # html/docbook.dsl
XML= dtds/decls/xml.dcl
INDEXOPTIONS= -t 'Index' -i 'index' -g -p
MANUALNAME= pooma
! XMLSOURCES= $(MANUALNAME).xml preface.xml starting.xml \
! introduction.xml tutorial.xml \
concepts.xml arrays.xml data-parallel.xml glossary.xml \
! bibliography.xml template.xml code.xml
# Create all versions of the manual.
all: $(MANUALNAME).ps $(MANUALNAME).pdf $(MANUALNAME).html
Index: code.xml
===================================================================
RCS file: code.xml
diff -N code.xml
*** /dev/null Fri Mar 23 21:37:44 2001
--- code.xml Tue Feb 26 20:44:23 2002
***************
*** 0 ****
--- 1,814 ----
+
+ &danger;: Overview of &pooma; Sources
+
+ In this chapter, we outline the &pooma; source code structure
+ and coding conventions for those who are interested in reading the
+ code.
+
+
+ Structure of the Files
+
+ The &poomatoolkit; files are divided into directories
+ according to their purposes. See . In that
+ table, directories and files are categorized:
+
+
+ use
+
+ introductions to the &toolkit;, its installation, and its
+ use
+
+
+
+ user code
+
+ source code for &pooma; programs. &pooma; users can
+ read these programs as examples how to use the &toolkit;.
+
+
+
+ documentation
+
+ user-level explanations of how to use the &toolkit;'s features
+
+
+
+ source code
+
+ &cc; files implementing the &toolkit;. In their
+ programs, users may need to refer to header files. Otherwise,
+ these files are mainly read by developers. Source code
+ subdirectories are described in .
+
+
+
+ development
+
+ used by &pooma; developers when writing and
+ preparing &toolkit; files
+
+
+
+ installation
+
+ used when converting the &toolkit; source code into an
+ executable library. This process can involve architecture- and
+ machine-dependent code.
+
+
+
+ The src directory,
+ containing source code, contains many files so it is described in
+ the separate table .
+ CVS subdirectories are
+ scattered throughout the source code. The Concurrent Versions System is a
+ version control system. The subdirectories have files storing the
+ CVS state. Ignore
+ these subdirectories.
+
+
+ &toolkitcap; Directories and Files
+
+
+
+
+ directory or file
+ type
+ contents
+
+
+
+
+ Not all directories and files are listed.
+
+
+
+
+ benchmarks
+ user code
+ source code for programs used to test the &toolkit;'s speed
+
+
+ bin
+ development
+ scripts useful for creating releases
+
+
+ config
+ installation
+ files used to configure the library
+
+
+ config/arch
+ installation
+ machine- and compiler-specific configuration files
+
+
+ config/Shared
+ installation
+ machine-independent configuration and make files
+
+
+ configure
+ installation
+ script used by user to configure the library
+
+
+ docs
+ documentation
+ documentation describing using the &toolkit;
+
+
+ docs/manual
+ documentation
+ documentation describing using the R2.4 &toolkit;
+
+
+ examples
+ user code
+ source code for programs used to illustrate using the &toolkit;
+
+
+ ide
+ development
+ files to support using integrated development
+ environments to develop &pooma;
+
+
+ lib
+ installation
+ directory where &pooma; library is placed
+
+
+ LICENSE
+ use
+ description of rules for using the &poomatoolkit;
+
+
+ makefile
+ installation
+ makefile rules to create the &toolkit;
+
+
+ README
+ use
+ release notes for various versions
+
+
+ scripts
+ installation
+ scripts to install &pooma; and related libraries
+
+
+ src
+ source code&toolkit; source code. See
+ .
+
+
+
+
+
+
+ Source Code Directories (Within <filename class="directory">src</filename>)
+
+
+
+
+ src subdirectory
+ contents
+
+
+
+
+ Not all directories and files are listed.
+
+
+
+
+ arch
+ files necessary for using specific architectures or
+ compilers. Some replace missing header files. Others modify
+ &pooma; files.
+
+
+ Array
+ declaration and implementation of the &array; container
+ class
+
+
+ Array/tests
+ programs testing the &array; code and features
+
+
+ CoordinateSystems
+ Cartesian, cylindrical, and spherical coordinate system
+ classes useful with meshes
+
+
+ Domain
+ &domain; declarations and implementations
+
+
+ Domain/tests
+ programs testing the &domain; code and features
+
+
+ DynamicArray
+ declaration and implementation of the &dynamicarray;
+ container class
+
+
+ DynamicArray/tests
+ programs testing the &dynamicarray; code
+ and features
+
+
+ Engine
+ declarations and implementations of the &engine; classes
+
+
+ Engine/tests
+ programs testing the &engine; code and
+ features
+
+
+ Evaluator
+ classes evaluating expressions quickly. For example,
+ one Evaluator evaluates data-parallel expressions.
+
+
+
+ Evaluator/tests
+ programs testing the Evaluator code
+
+
+ Field
+ declaration and implementation of the &field; container
+ class
+
+
+ Field/DiffOps
+ implementation of &field;stencils
+
+
+ Field/Mesh
+ declarations and implementations of meshes, which
+ specify a field's spatial extent
+
+
+ Field/Relations
+ declarations and implementations of relations among
+ &field;s, supporting automatic computation of field values
+
+
+ Field/tests
+ programs testing the &field; code and features
+
+
+ FileTemplates
+ files illustrating the usual structure of source code files
+
+
+ Functions
+ unsupported files currently under development
+
+
+ IO
+ declarations and implementation of input-output classes
+ to store containers in files
+
+
+ IO/tests
+ programs testing the input-output (IO) code
+
+
+ Layout
+ declarations and implementations of the &layout; classes, which
+ specify the mappings between processors and container
+ values
+
+
+ Layout/tests
+ programs testing the &layout; code and features
+
+
+ Particles
+ declares and implements the Particles
+ class, which is not currently supported
+
+
+ Particles/tests
+ programs testing the unsupported Particles
+ class code and features
+
+
+ Partition
+ declares and implements partitions, which
+ specify how a container's domain is split into patches for
+ distributed computation
+
+
+ Partition/tests
+ programs testing partition code and features
+
+
+ PETE
+ implements the &pete; framework
+
+
+ Pooma
+ header files declaring all user-level classes
+
+
+ Pooma/PETE
+ input files integrating &pooma; containers into the
+ &pete; framework for fast data-parallel expressions
+
+
+ Pooma/tests
+ programs testing simple &pooma; programs
+
+
+ Threads
+ classes integrating &smarts; threads into &pooma;
+
+
+ Tiny
+ declarations and implementations of &matrix;, &tensor;,
+ and &vector;
+
+
+ Tiny/tests
+ programs testing &matrix;, &tensor;,
+ and &vector; classes
+
+
+ Tulip
+ interface between &pooma; and the &cheetah; messaging library
+
+
+ Tulip/tests
+ programs testing the interface between &pooma; and the
+ &cheetah; messaging library
+
+
+ Utilities
+ declarations and implementations of classes used
+ throughout the &toolkit;
+
+
+ Utilities/tests
+ programs testing utility classes
+
+
+
+
+
+ A filename's suffix indicates its purpose. See .
+ Implementations of template classes are usually stored in header
+ files so the &cc; compiler can instantiate the classes. Sometimes
+ some of the implementation of longer functions is stored in
+ .cc files, which are
+ included by the preprocessor in the corresponding header files.
+ When &cc; compilers and linkers fully support template class
+ compilation, the inclusion will no longer be necessary.
+
+
+ Filename Suffixes
+
+
+
+
+ filename suffix
+ meaning
+
+
+
+
+ Source Code Files
+
+
+ .c
+ &c;-language file, usually containing an entire &c; program
+
+
+ .cpp
+ &cc;-language file, frequently containing an entire &cc;
+ &pooma; program. Sometimes these illustrate using &pooma; or
+ test the source code. Others contain long definitions of
+ template class functions.
+
+
+ .cmpl.cpp
+ &cc; class implementation file to be compiled and
+ included in the &pooma; library. Only non-templated classes
+ occur in these files.
+
+
+ .h
+ &cc; header file. Some are included directly in user
+ programs. Others declare and implement classes, particularly
+ templated classes. A few are &c; header files.
+
+
+ .in
+ &pete; input file
+
+
+ .inst.cpp
+ preinstantiations of templated &cc; classes.
+
+
+
+ Compilation and Execution Files
+
+
+ .a
+ &pooma; library
+
+
+ .mk
+ file containing &make; rules, typically included within
+ another makefile
+
+
+ .info
+ log file created when compiling &pooma; source
+
+
+
+ Documentation Files
+
+
+ .dsl
+ DSSSL stylesheet used to convert documentation in
+ DocBook format into other formats
+
+
+ .gif
+ Graphics Interchange Format file containing a figure
+ suitable for display via the WWW
+
+
+ .html
+ HTML documentation file suitable for display via the WWW
+
+
+ .mp
+ MetaPost source code for manual illustrations.
+
+
+ .pdf
+ Portable Document Format (PDF) file, usually containing
+ &toolkit; documentation
+
+
+ .png
+ Portable Network Graphics file suitable for display via
+ the WWW
+
+
+ .xml
+ eXtended Markup Language (XML) file, usually containing
+ &toolkit; documentation
+
+
+
+
+
+
+
+
+ &pooma; Coding Conventions
+
+ &pooma; has been written by several different sets of
+ developers. We describe the coding conventions generally used
+ throughout the code, but there are, of course, exceptions. To see
+ the coding conventions in practice, view random files in the
+ src subdirectory. The
+ src/FileTemplates
+ subdirectory contains very short files illustrating some of the
+ coding conventions.
+
+
+
+ &pooma; Namespace
+
+ Most implementation functions and classes are placed within
+ the Pooma namespace. Some user-level functions
+ are also within this namespace, e.g.,
+ Pooma::initialize and
+ Pooma::finalize. This is incompletely
+ implemented because some &cc; compilers did not correctly
+ implement namespaces.
+
+
+
+
+ Formatting
+
+ Indentation follows the GNU
+ Emacs's &cc; mode guidelines. Most increases in
+ indentation levels starts two characters to the right.
+
+ Most brackets, e.g., in function definitions, occur on
+ separate lines. Exceptions are for very short functions.
+
+ There is no space between a function's name and the left
+ parenthesis starting its parameter list.
+
+
+
+
+
+ Preprocessor
+
+
+ Comments
+
+ Almost all comments begin with //.
+ /* … */ comments occasionally occur
+ when commenting an intraline value.
+
+ &c; files, including header files, exclusively use
+ /* … */ comments.
+
+
+
+ Preprocessor Symbols
+
+ Preprocessor symbols are used only for preprocessor
+ conditional expressions, not to define constants. Such symbols
+ consist of all capital letters with underscore symbols separating
+ words. They begin with a POOMA_ prefix. For
+ example, if POOMA_BOUNDS_CHECK represents a
+ true value, then conditionally included code to check that
+ indices are within a domain should be included.
+
+ Header guards also consist of all capital letters with
+ underscore symbols separating words. They begin with
+ POOMA_, continue with names of directories and
+ files, and end with _H. For example,
+ POOMA_UTILITIES_MODELELEMENT_H guards
+ src/Utilities/ModelElement.h.
+
+
+
+ Preprocessor Macros
+
+ Inline functions are preferred over preprocessor macros.
+ The latter do occasionally occur. Usually their scope is quite
+ limited (sometimes to just one file), and their purpose is to
+ avoid writing repetitive code. For example, src/PETE/PETE.h defines
+ PETE_EMPTY_CONSTRUCTORS(CLASS) as the three
+ types of constructors for classes with parameterless
+ constructors.
+
+ The main other use is to define macros that need access to
+ the __FILE__ and __LINE__
+ preprocessor symbols to produce error messages. For example,
+ CTAssert in src/Utilities/PAssert.h uses
+ this.
+
+
+
+
+
+ Global Variables
+
+ Global variables are avoided whenever possible.
+
+
+
+
+ Classes
+
+ In this section, we describe coding conventions for classes,
+ both templated and not templated.
+
+ In files declaring classes, the comments near the beginning
+ frequently begin with a listing of the classes followed by a
+ high-level explanation of the classes' public interface. A longer
+ explanation including implementation details usually precedes the
+ class declaration.
+
+ Class names tend to be concatenations of capitalized words
+ without underscores, e.g., Field and
+ RefCountedPtr.
+
+ Most classes are declared using class,
+ not struct. The latter is frequently used for
+ implementation and compile-time classes that have only public
+ members.
+
+ Template parameters are declared using the
+ class keyword, rather than the
+ typename keyword. The latter is used when
+ required by &cc; to resolve parsing problems.
+
+ Default template parameters are sometimes used.
+
+ The order of class members is usually:
+
+
+ public
+
+
+
+ internal types
+
+ Usually end with _t. Name
+ consists of the concatenation of capitalized words without
+ intervening underscores.
+
+
+
+ constructors
+
+
+
+
+
+ destructors
+
+
+
+
+
+ member functions
+
+ Usually named by the concatenation of capitalized
+ words without intervening underscores but having an
+ uncapitalized first word.
+
+
+
+
+
+
+ protected
+
+ This section is frequently empty. If so, do not list
+ the protected tag.
+
+
+
+ private
+
+ This section contains private data members and less
+ frequently private functions. If this section is empty, do not
+ list the private tag.
+
+
+
+
+ The order sometimes changes if required to be correct &cc; or
+ eases the ordering. Two different sections are frequently
+ separated by a one-line comment with seventy-six hyphens. An
+ explanatory comment usually precedes each member.
+
+ Member data is almost always private or protected. Function
+ accessors permit access.
+
+ Names of internal types usually are formed by the
+ concatenation of capitalized words without intervening underscores
+ followed by _t. Names of member functions are
+ similar except the first word is not usually capitalized and they
+ have no suffix. Names of member data are similar to names of
+ member functions except they end with
+ _m.
+
+ Most functions are defined directly in the class
+ declaration. Functions with long function bodies are defined in
+ .cpp files for templated
+ classes and in .cmpl.cpp
+ files for untemplated classes.
+
+ Functions make liberal use of const both
+ to modify parameters and member functions.
+
+ Templated member functions are permitted.
+
+ Overloaded member functions are permitted. Operator
+ overloading is permitted.
+
+ Default arguments are permitted.
+
+ Many functions are marked inline. This
+ assumes the optimizer can handle a large number of inlined
+ functions. Even functions defined inside class declarations are
+ marked inline even though the &cc; standard
+ requires them to be inlined if possible even if not so marked.
+ This is because some optimizers attempt more aggressive inlining
+ for explicitly marked member functions.
+
+ The &pooma; inheritance hierarchy is quite shallow, both
+ from the user's and from the implementation point of view. A
+ majority of the uses of inheritance are to factor out a common
+ implementation and reduce coding.
+
+ Virtual functions are usually avoided because they can
+ execute slowly.
+
+
+
+
+
+ Functions
+
+ Class member functions are preferred over global functions
+ when they achieve the same purpose. Guidelines for global
+ functions are the same as for class member functions: A function
+ name is a concatenation of capitalized words without underscores
+ and with the first word not capitalized.
+ inline and const are
+ aggressively used. Templated member functions, overloaded member
+ functions, operator overloading, and default arguments are
+ permitted.
+
+ Functions return references and constant references when
+ appropriate.
+
+
+
+
+
+ Friends
+
+ Friend functions are rare and are usually defined directly
+ within the class of which they are a friend. Friend class
+ declarations do occur.
+
+
+
+
+ Compile-Time Programming
+
+ Compile-time structures and static functions occur
+ throughout the code. Most of the classes are
+ structs since they have only public members.
+ The coding conventions follow those for run-time code.
+ Enumerations are a preferred way to declare integral constants.
+
+
+
+
+ Constants
+
+ Enumerations are preferred over declaring constant
+ integers.
+
+ Use the const keyword, not preprocessor
+ definitions, to define constants.
+
+
+
+
+ Type Casting
+
+ Type casting usually indicates a design flaw so it is rarely
+ used. When it is used, use static_cast,
+ dynamic_cast, or
+ reinterpret_cast.
+
+
+
+
+ Errors and Exceptions
+
+ &pooma; code uses very few exception since not all &cc;
+ compilers adequately support exceptions. Thus, all uses must also
+ have corresponding code not using exceptions. See, e.g.,
+ POOMA_EXCEPTIONS in the code.
+
+
+
+
Index: concepts.xml
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/concepts.xml,v
retrieving revision 1.12
diff -c -p -r1.12 concepts.xml
*** concepts.xml 2002/01/30 23:51:45 1.12
--- concepts.xml 2002/02/27 03:44:24
***************
*** 633,639 ****
Communications Library
and the &mm; Shared Memory Library. See for
details.
--- 633,639 ----
Communications Library
and the &mm; Shared Memory Library. See for
details.
Index: pooma.xml
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/pooma.xml,v
retrieving revision 1.3
diff -c -p -r1.3 pooma.xml
*** pooma.xml 2002/02/01 17:43:13 1.3
--- pooma.xml 2002/02/27 03:44:27
***************
*** 37,42 ****
--- 37,45 ----
+
+
+
***************
*** 50,55 ****
--- 53,60 ----
Make">
+ MetaPost">
+
MM">
MPI">
***************
*** 77,82 ****
--- 82,89 ----
+ UML">
+
***************
*** 175,181 ****
! g++">
KCC">
--- 182,190 ----
! gcc">
!
! g++">
KCC">
***************
*** 201,206 ****
--- 210,218 ----
+
+
+
***************
*** 213,218 ****
--- 225,231 ----
+
***************
*** 220,225 ****
--- 233,240 ----
+
+
***************
*** 228,235 ****
!
!
--- 243,254 ----
!
!
!
!
!
!
***************
*** 296,412 ****
!
! Preface
!
! FINISH: Describe the target audience for &pooma; programs and
! for this manual: &cc; programmers writing scientific code, possibly
! parallel execution.
!
! Assume familiarity with &cc; template programming and the
! standard template library. FIXME: Remove this index
! entry.Oldham,
! Jeffrey D.
!
!
! Notation
!
! UNFINISHED
!
!
!
!
! How to Read This &bookcap;
!
! FINISH: Write this section in a style similar to Lamport's
! LaTeX section 1.2. FINISH: Fix the book title and the section
! number.
!
!
!
!
! Obtaining &pooma; and Sample Programs
!
! Available for free from what WWW site? Include what portions
! of LICENSE? Be sure to
! include CVS instructions as well.
!
! Which additional packages are necessary and when?
!
!
!
!
!
! Using and Modifying &pooma;
!
! &pooma; is available under open source license. It can be
! used and modified by anyone, anywhere. Can it be sold? Include
! LICENSE.
!
! QUESTION: How do developers contribute code?
!
!
-
-
- Acknowledgements
- ]]>
-
-
- Acknowledgements
- ]]>
-
- This &book; would not have been completed without the help
- and encouragement of a lot of people and organizations. Los Alamos
- National Laboratory funded the writing of this manual and the
- development of the &poomatoolkit;. John Reynders conceived,
- advocated, and headed &pooma; development in its early days, and
- Scott Haney continued the leadership. Susan Atlas, Subhankar
- Banerjee, Timothy Cleland, Julian Cummings, James Crotinger, David
- Forslund, Salman Habib, Scott Haney, Paul Hinker, William Humphrey,
- Steve Karmesin, Graham Mark, Jeffrey D. Oldham, Ji Qiang, John
- Reynders, Robert Ryne, Stephen Smith, M. Srikant, Marydell
- Tholburn, and Timothy Williams all helped develop &pooma;. Rod
- Oldehoeft and Jeff Brown of Los Alamos National Laboratory
- supported CodeSourcery's and Proximation's work, including the
- development of this manual. John Hall, Don Marshall, Jean
- Marshall, and the rest of the BLANCA team at Los Alamos worked
- closely with the developers and provided valuable suggestions for
- improvements.
-
- I am grateful to James Crotinger, Mark Mitchell, and Stephen
- Smith who answered my many questions during the writing of this
- &book;.
-
-
-
- Jeffrey D. Oldham, 2002 January
-
-
-
-
- ]]>
-
-
-
- ]]>
-
-
-
Programming with &pooma;
]]>
! &introductory-chapter;
! &template-chapter;
&tutorial-chapter;
--- 315,332 ----
! &preface-chapter;
Programming with &pooma;
]]>
! &starting-chapter;
! &introductory-chapter;
&tutorial-chapter;
*************** a(I,J) = (1.0/9.0) *
*** 828,833 ****
--- 748,754 ----
+
Writing Sequential Programs
*************** a(I,J) = (1.0/9.0) *
*** 1081,1086 ****
--- 1002,1009 ----
architecture-specific initialization. The function always
returns &true;.
+ HERE
+
initialize's alternative form
assumes the &pooma;-specific and architecture-specific
command-line arguments have already been removed from
*************** UNFINISHED
*** 2395,2405 ****
ADD: Check that the operations on dynamic arrays are
actually the same as for &array;. See src/DynamicArray/DynamicArrayOperators.h,
src/DynamicArray/PoomaDynamicArrayOperators.h,
and src/DynamicArray/VectorDynamicArrayOperators.h.
--- 2318,2328 ----
ADD: Check that the operations on dynamic arrays are
actually the same as for &array;. See src/DynamicArray/DynamicArrayOperators.h,
src/DynamicArray/PoomaDynamicArrayOperators.h,
and src/DynamicArray/VectorDynamicArrayOperators.h.
*************** UNFINISHED
*** 3754,4032 ****
]]>
!
! Obtaining and Installing &pooma;
! In , we described
! how to install &pooma;. In the following section, we describe how
! to install &pooma; to support distributed computation.
! ]]>
- ADD: Write this section, including extensive instructions
- for Unix-like, MS Windows, and MacOS. List the configuration options.
- Be sure to describe configuring for parallel execution.
- ]]>
!
! Supporting Distributed Computation
! To use multiple processors with &pooma; requires installing
! the &cheetah; messaging library and an underlying messaging library
! such as the Message Passing Interface (&mpi;) Communications
! Library or the &mm; Shared Memory Library. In the following
! section, we first describe how to install &mm;. Read it only if
! using &mm;, not &mpi;. Then we describe how to install &cheetah;
! and configure &pooma; to use it.
!
!
! Obtaining and Installing the &mm; Shared Memory Library
!
! &cheetah;, and thus &pooma;, can use Ralf Engelschall's &mm;
! Shared Memory Library to pass messages between processors. For
! example, the &author; uses this library on a two-processor
! computer running &linux;. The library, available at http://www.engelschall.com/sw/mm/,
! is available at no cost and has been successfully tested on a
! variety of Unix-like platforms.
!
! We describe how to download and install the &mm; library.
!
!
! Download the library from the &pooma; Download page
! (&poomadownloadpage;) available off the &pooma; home page
! (&poomahomepage;).
!
!
! Extract the source code using tar xzvf
! mm-1.1.3.tar.gz. Change directories into the
! resulting source code directory mm-1.1.3.
!
!
! Prepare to compile the source code by configuring it
! using the configure command. To change
! the default installation directory /usr/local, specify
! &dashdash;prefix=directory
! option. The other configuration options can be listed by
! specifying the &dashdash;help option. Since the
! &author; prefers to keep all &pooma;-related code in his
! poomasubdirectory, he
! uses
!
! ./configure &dashdash;prefix=${HOME}/pooma/mm-1.1.3
!
!
!
! Create the library by issuing the
! make command. This compiles the source
! code using a &c; compiler. To use a different compiler than
! the &mm; configuration chooses, set the CC
! environment variable to the desired compiler before
! configuring.
!
!
! Optionally test the library by issuing the make
! test command. If successful, the penultimate line
! should be OK - ALL TESTS SUCCESSFULLY
! PASSED.
!
!
! Install the &mm; Library by issuing the make
! install command. This copies the library files to the
! installation directory. The mm-1.1.3 directory containing the
! source code may now be removed.
!
!
!
!
!
! Obtaining and Installing the &cheetah; Messaging Library
- The &cheetah; Library decouples communication from
- synchronization. Using asynchronous messaging rather than
- synchronous messaging permits a message sender to operate without
- the cooperation of the message recipient. Thus, implementing
- message sending is simpler and processing is more efficiently
- overlapped with it. Remote method invocation is also supported.
- The library was developed at the Los Alamos National Laboratory's
- Advanced Computing Laboratory.
-
- &cheetah;'s messaging is implemented using an underlying
- messaging library such as the Message Passing Interface (&mpi;)
- Communications Library
- )
- ]]>
- or the &mm; Shared Memory Library. &mpi; works on a wide variety
- of platforms and has achieved widespread usage. &mm; works under
- Unix-like operating systems on any computer with shared memory. Both libraries are
- available at no cost. The instructions below work for whichever
- library you choose.
-
- We describe how to download and install &cheetah;.
-
-
- Download the library from the &pooma; Download page
- (&poomadownloadpage;) available off the &pooma; home page
- (&poomahomepage;).
-
-
- Extract the source code using tar xzvf
- cheetah-1.0.tgz. Change directories into the
- resulting source code directory cheetah-1.0.
-
-
- Edit a configuration file corresponding to your operating
- system and compiler. These .conf files are located in the
- config directory. For
- example, to use &gcc; with the &linux; operating system, use
- config/LINUXGCC.conf.
-
- The configuration file usually does not need
- modification. However, if you are using &mm;, ensure
- shmem_default_dir specifies its location.
- For example, the &author; modified the value to
- "/home/oldham/pooma/mm-1.1.3".
-
-
- Prepare to compile the source code by configuring it
- using the configure command. Specify the
- configuration file using the &dashdash;arch option.
- Its argument should be the configuration file's name, omitting
- its .conf suffix. For
- example, &dashdash;arch LINUXGCC. Some other
- options include
-
-
- &dashdash;help
-
- lists all the available options
-
-
-
- &dashdash;shmem &dashdash;nompi
-
- indicates use of &mm;, not &mpi;
-
-
-
- &dashdash;mpi &dashdash;noshmem
-
- indicates use of &mpi;, not &mm;
-
-
-
- &dashdash;opt
-
- causes the compiler to produce optimized source code
-
-
-
- &dashdash;noex
-
- prevents use of &cc; exceptions
-
-
-
- &dashdash;static
-
- creates a static library, not a shared library
-
-
-
- &dashdash;shared
-
- creates a shared library, not a static library. This
- is the default.
-
-
-
- &dashdash;prefix directory
-
- specifies the installation directory where the
- library will be copied rather than the default.
-
-
-
- For example, the &author; uses
-
- ./configure &dashdash;arch LINUXGCC &dashdash;shmem &dashdash;nompi
- &dashdash;noex &dashdash;static &dashdash;prefix ${HOME}/pooma/cheetah-1.0
- &dashdash;opt
- The
- &dashdash;arch LINUXGCC indicates use of &gcc;
- under a &linux; operating system. The &mm; library is used,
- but &cc; exceptions are not. The latter choice matches
- &pooma;'s default choice. A static library, not a shared
- library, is created. This is also &pooma;'s default choice.
- The library will be installed in the ${HOME}/pooma/cheetah-1.0.
- Finally, the library code will be optimized, hopefully running
- faster than unoptimized code.
-
-
- Follow the directions printed by
- configure: Change directories to the
- lib subdirectory named
- by the &dashdash;arch argument and then type
- make to compile the source code and create
- the library.
-
-
- Optionally ensure the library works correctly by issuing
- the make tests command.
-
-
- Install the library by issuing the make
- install command. This copies the library files to
- the installation directory. The cheetah-1.0 directory containing
- the source code may now be removed.
-
-
-
-
!
! Configuring &pooma; When Using &cheetah;
! To use &pooma; with &cheetah;, one must tell &pooma; the
! location of the &cheetah; library using the
! &dashdash;messaging configuration option. To do this,
!
!
! Set the &cheetah; directory environment variable
! CHEETAHDIR to the directory containing the
! installed &cheetah; library. For
! example,
!
! declare -x CHEETAHDIR=${HOME}/pooma/cheetah-1.0
! specifies the
! installation directory used in the previous section. If using
! the csh shell, use setenv
! CHEETAHDIR ${HOME}/pooma/cheetah-1.0.
!
!
! When configuring &pooma;, specify the
! &dashdash;messaging option. For example,
! ./configure &dashdash;arch LINUXgcc &dashdash;opt
! &dashdash;messaging configures for &linux;, &gcc;, and an
! optimized library using &cheetah;.
!
!
!
!
--- 3677,3914 ----
]]>
! &template-appendix;
! &code-appendix;
!
! ¨ Class Diagrams
! In this chapter, we present Unified Modeling Language (¨)
! class diagrams. These are created at the
! specification level, which indicates the
! software interface, not its implementation. Readers interested in
! the implementation are encouraged to read the corresponding source
! code. More extensive explanations of these classes appear in the
! main chapters of this &book;.
!
!
! Explanation of ¨ Class Diagrams
!
!
!
!
!
!
!
!
! An Explanation of UML Class Diagrams
!
!
!
!
! illustrates a typical
! ¨ class diagram. The diagram has three classes:
! Classname1, Classname2, and
! Classname2<1>. Most classes are represented by
! three-part boxes. The top part lists the class's name. The middle
! part lists public data members, if any. Few &pooma; classes have
! public data members so this section is frequently empty. The bottom
! part lists public member functions, if any.
! Classname2<1> has only one part, not three. Its
! three-part box appears in another diagram, presumably because there
! is not enough room in this one. Both Classname1 and
! Classname2 have template parameters, each named
! T. These occur in dashed boxes at the upper-right
! corner of the class boxes. Files implementing a class are listed at
! the lower, right corner of the class's box; this is not standard UML
! notation.
!
! Lines connect classes. The solid arrow with large triangular
! arrowhead indicates that Classname2 is a subtype of
! Classname1. Since this diagram represents the
! specification level, subtyping does not necessarily correspond to
! &cc; type inheritance. Also, subtype class boxes need only list
! members not available in the supertype. For this case,
! Classname2 has no new members not provided by
! Classname1. A dashed arrow indicates a class formed by
! a template instantiation. The class name indicates which template
! parameters are bound. For example, Classname2<1>
! instantiates Classname2 with T equal
! to 1.
!
! These diagrams omit a lot of details. Private and protected
! data members are not listed. Compile-time types and values are not
! listed. No indication is given of the actual implementation.
!
+
+ &array;s
+
+
+ Relationship Between &array; and &dynamicarray;s
+
+
+
+
+
+
+
+
+ &dynamicarray;s are subtypes of &array;s
+
+
+
! Both &array;s and &dynamicarray;s have so many member
! functions that their class boxes appear in separate diagrams.
! indicates that
! &dynamicarray;s are subtypes of &array;s. Both have value type and
! engine tag template parameters but &dynamicarray;'s dimension must
! be one.
!
!
! &array; Diagram
!
!
!
!
!
!
!
!
! &array; Class Diagram
!
!
!
!
!
! &dynamicarray; Diagram
!
!
!
!
!
!
!
!
! &dynamicarray; Class Diagram
!
!
!
!
!
! &domain;s
! &domain;s and its subtypes are shown in . All classes are instantiated
! from or subtypes of &domain;. As mentioned in , the Domain<1>
! template instantiation has additional member functions. It uses
! the Domain<1>::iterator. The four &domain;
! subtypes appear in the bottom half of the figure. Each requires
! the same template parameter as &domain;. Each of these has a
! template instantiation for the one-dimensional case. We omit
! listing their additional member functions since these are the same
! as for Domain<1>.
!
!
! &domain;s
!
!
!
!
!
!
!
!
! &domain;s
!
!
!
!
+
+
+
+ &engine;s
+
+ &engine;s and its subtypes are shown in . Five subtypes of &engine;s
+ are shown. Details appear in subsequent diagrams. The
+ Engine class box shows no members because it has no
+ members. Only subtypes have members. More explanation of these
+ classes can be found in . The
+ implementation files in use the
+ [1-7] regular expression to indicate 1, 2,
+ …, or 7.
+
+
+ &engine;s
+
+
+
+
+
+
+
+
+ Relationships among &engine;s
+
+
+
+
+
+ &brick; and &compressiblebrick; &engine;s
+
+
+
+
+
+
+
+
+ &brick; and &compressiblebrick; &engine;s
+
+
+
+
+
+ &dynamic; and &multipatch; &engine;s
+
+
+
+
+
+
+
+
+ &dynamic; and &multipatch; &engine;s
+
+
+
+
+
+ &remote; &engine;s
+
+
+
+
+
+
+
+
+ &remote; &engine;s
+
+
+
+
+
+
Index: preface.xml
===================================================================
RCS file: preface.xml
diff -N preface.xml
*** /dev/null Fri Mar 23 21:37:44 2001
--- preface.xml Tue Feb 26 20:44:27 2002
***************
*** 0 ****
--- 1,384 ----
+
+ Preface
+
+ The &poomatoolkit; enables scientists and engineers to quickly
+ translate scientific algorithms into efficient programs. The
+ &toolkit;'s containers facilitate storing and computing arrays of
+ values by supporting element-wise, data-parallel, and stencil-based
+ computations. The &toolkit; automatically handles all
+ interprocessor communication so the same &pooma; program can
+ efficiently execute on a uniprocessor workstation or a supercomputer
+ with thousands of processors. Thus, its creator can concentrate on
+ the algorithms rather than their implementation details.
+
+ &pooma; programs are written in &cc;. Scientists and
+ engineers can use their existing knowledge of &cc; and need only
+ learn a few &pooma; concepts rather than having to learn a whole new
+ language. The easy-to-use &pooma; interface hides sophisticated
+ &cc; code. For example, a &pooma; programmer can use a simple
+ data-parallel statements such as
+ &initialspace;double x; vector<1> v1(10000), v2(10000), v3(10000);
+ &initialspace;x = sum(v1 * sin(v2) - exp(v3));
+
+ and expect them to run efficiently without ever being aware of the
+ underlying state-of-the-art expression template technology.
+
+ This &book; is aimed at scientists and engineers who want to
+ quickly translate scientific algorithms into efficient programs
+ running on one or thousands of processors. Although we will outline
+ some scientific algorithms, no scientific background is required.
+ Readers will need to be familiar with &cc;, the language in which
+ &pooma; programs are written. Classes, objects, function objects,
+ template classes, and template functions will all be used. Appendix
+ FIXME contains a short
+ introduction to template programming. Readers needing more
+ background material might want to read Koenig and Moo's
+ Accelerated &cc;, Stanley Lippman's
+ &cc; Primer, Bjarne Stroustrup's The
+ &cc; Programming Language, or the first half of Barton
+ and Nackman's Scientific and Engineering &cc;.
+
+
+
+ Readers of this book will learn how to use the &poomatoolkit;
+ to implement scientific algorithms. Since &pooma; offers classes
+ and functions corresponding to common scientific concepts, &pooma;
+ users will
+
+
+ spend significantly less time programming,
+
+
+ write programs that are typically one-tenth the length of
+ comparable &c; and &fortran; programs,
+
+
+ require much less time to debug programs, and
+
+
+ will be able to port their programs to a wide variety of
+ platforms without changing them.
+
+
+ Those wishing to learn how to write parallel or distributed programs
+ will learn the fundamental concepts and see how easy it is to write
+ the programs. Readers interested in advanced &cc; techniques will
+ see how these techniques, theoretically presented elsewhere, are
+ actually used in practice. We hope all our readers will be
+ intrigued by the power of &pooma;'s technology they will peek under
+ the hood to see how the &toolkit; uses &cc;'s features.
+
+
+
+ How to Read This &bookcap;
+
+ Each chapter of this book introduces a new concept, using it
+ to convert an algorithm into a program. It continues by describing
+ the concept's interface, illustrating these with code fragments or
+ short programs, and concludes with a detailed listing of the
+ classes, functions, member functions, etc. All too frequently in
+ &cc;, two concepts are interrelated so describing one also requires
+ describing the other. Thus, these detailed listings may refer to
+ material presented in future chapters.
+
+ A few sections marked with dangerous bend
+ signs contain advanced material not necessary to understand when
+ initially learning &pooma;. I recommend skipping these sections on
+ your first reading of this &book;.
+
+ One need not read every chapter to write sophisticated
+ &pooma; programs. Here is a brief sketch of what is in the
+ remaining chapters and appendices:
+
+
+ Getting Started with &pooma;
+
+ describes how to download and compile the
+ &poomatoolkit;. It then presents a Hello, &pooma;
+ program, explaining how to compile and run it.
+ Impatient readers who already have a working &poomatoolkit; may
+ wish to skip this chapter.
+
+
+
+
+ &array; Containers
+
+ implement the concept of a mathematical array which is a
+ map from indices in a domain to values. This container is
+ the most fundamental &pooma; type. We explain how to
+ create and use these maps. All subsequent chapters depend on
+ understanding &array;s.
+
+
+
+ &vector;s, &matrix;s, and &tensor;s
+
+ are three classes implementing the corresponding
+ mathematical concepts. If your algorithm uses these
+ mathematical concepts, read this chapter.
+
+
+
+ Data-Parallel Expressions
+
+ operate on multiple values. Many scientific algorithms
+ use these concepts so all &pooma; containers support them. For
+ example, values in two &array;s a and
+ b can be added element-wise using an
+ expression as simple as a+b, omitting the
+ need for any indexing or loops. A dangerous-bend section
+ describes the underlying &pete; technology making this
+ possible.
+
+
+
+ Domains
+
+ specify containers' sets of permitted indices. They are
+ used when creating new containers and taking views of existing
+ containers.
+
+
+
+ Container Views
+
+ are themselves containers having domains that are subsets
+ of other containers' domains. Combining them with
+ data-parallel programs yields &pooma;'s powerful notation to
+ implement algorithms.
+
+
+
+ &engine;s
+
+ store and compute data for containers. If containers are
+ like cars, engines are the things that make them go. Most
+ &pooma; users need not look under the hood at &engine;s, but
+ those interested in optimizing their use of &pooma; or seeing
+ one of the fundamental &pooma; concepts will be interested.
+
+
+
+ Distributed Computation
+
+ involves distributing a program's data and computation
+ among all available processors, ranging in number from one to
+ thousands. We present the &pooma; concepts of partitioning and
+ distributing data while relying on the &toolkit; and a
+ communication library to automatically move all data among
+ processors. We show that converting a sequential program into
+ a distributed program can be as easy as adding three lines of
+ code.
+
+
+
+ &field; Containers
+
+ extend the concept of an &array; to three-dimensional
+ space. This is the most powerful &pooma; abstraction.
+ Multiple values can be treated as residing at the same
+ location, and relations support lazy evaluation, where one
+ field's values can be automatically updated whenever another
+ field's values change.
+
+
+
+ Appendix: Template Programming
+
+ describes using &cc; templates in &pooma; programs. &cc;
+ programmers with little experience in using templates will want
+ to read this appendix before reading about &array;s. A
+ dangerous-bend section will interest &cc; programmers desiring
+ an overview of all the template programming ideas used to
+ implement &pooma;.
+
+
+
+
+
+
+
+
+
+ Obtaining, Using, and Modifying &pooma;
+
+ The &poomatoolkit; is open-source software. Anyone may
+ download, read, redistribute, or modify the &pooma; source code.
+ Here we briefly describe how to download, configure, and compile
+ the &poomatoolkit; for UNIX operating systems. Instructions for
+ Microsoft Windows and Mac users as well as more details appear in
+ the subsequent chapter. Those wanting to run distributed &pooma;
+ programs should also read the subsequent chapter.
+
+ Obtain the &pooma; source code &poomasourcefile;
+ from the &pooma; download page (&poomadownloadpage;) available off
+ the &pooma; home page (&poomahomepage;). The tgz
+ indicates this is a compressed tar archive file. To extract the
+ source files, use tar xzvf &poomasourcefile;.
+ Move into the source code directory &poomasource; directory; e.g.,
+ cd &poomasource;.
+
+ Configuring the source code determines the file and program
+ names needed for compilation. First, determine a configuration
+ file in the config/arch/
+ directory corresponding to your operating system and compiler. For
+ example, LINUXgcc.conf
+ supports compiling under a &linux; operating system with &gpp;,
+ while SGI64KCC.conf
+ supports compiling under a 64-bit SGI
+ Irix operating system
+ with &kcc;. Next, configure the source code:
+ &initialspace;./configure &dashdash;arch LINUXgcc &dashdash;opt &dashdash;suite LINUXgcc-opt
+ . The architecture argument to the
+ &dashdash;arch option is the name of the
+ corresponding configuration file, omitting its .conf suffix. The
+ &dashdash;opt indicates the &poomatoolkit; will
+ contain optimized source code, which makes the code run more
+ quickly but may impede debugging. Alternatively, use the
+ &dashdash;debug option which supports debugging.
+ The suite name
+ can be any arbitrary string. We chose
+ LINUXgcc-opt to remind us of the architecture
+ and optimization choice. configure creates subdirectories
+ named LINUXgcc-opt for use when compiling the source
+ files. Comments at the beginning of lib/suiteName/PoomaConfiguration.h
+ record the configuration arguments.
+
+ To compile the source code, set the POOMASUITE
+ environment variable to the suite name and then type
+ make. To set the environment variable for the
+
+ bash shell use
+ &initialspace;export POOMASUITE=suiteName
+ substituting the suite name's suiteName.
+ For the
+ csh shell, use
+ &initialspace;setenv POOMASUITE LINUXgcc-opt
+ Issuing the
+ make command compiles the &pooma; source code
+ files to create the &pooma; library. The &pooma; makefiles assume
+ the GNU &make; is available so substitute
+ the proper command to run GNU &make; if
+ necessary. The &pooma; library can be found in, e.g., lib/LINUXgcc-opt/libpooma-gcc.a.
+
+ Anyone may modify the &pooma; source code. If an application
+ requires a specialized container not already available, any
+ programmer may add it. Any programmer can extend it to solve
+ problems in previously unsupported domains. Companies using the
+ &toolkit; can read the source code to ensure it has no security
+ holes. It may be downloaded at no cost and used for perpetuity.
+ There are no annual licenses and no on-going costs. Users are
+ guaranteed the software will never disappear. In summary, the
+ &poomatoolkit; is low-risk software.
+
+
+
+
+ History of &pooma;
+
+ The &poomatoolkit; was developed at Los Alamos National
+ Laboratory to assist nuclear fusion and fission research.
+ In 1994, it grew out of the Object-Oriented Particle Simulation
+ Class Library developed for particle-in-cell simulations. The
+ goals of the Framework, as it was called at the time, were driven
+ by the Numerical Tokamak's Parallel Platform
+ Paradox:
+ The average time required to implement a moderate-sized
+ application on a parallel computer architecture is equivalent to
+ the half-life of the latest parallel supercomputer.
+
The framework's goal of being able to quickly write efficient
+ scientific programs that could be run on a wide variety of platforms
+ remains unchanged today. Development, mainly at the Advanced
+ Computing Laboratory at Los Alamos, proceeded rapidly. A matrix
+ solver application was written using the framework. Support for hydrodynamics, Monte
+ Carlo simulations, and molecular dynamics modeling soon
+ followed.
+
+ By 1998, &pooma;
+ was part of the U.S. Department of Energy's Accelerated Strategic
+ Computing Initiative (ASCI). The Comprehensive
+ Test Ban Treaty forbid nuclear weapons testing so they were instead
+ simulated using computers. ASCI's goal was to
+ radically advance the state of the art in high-performance
+ computing and numerical simulations so the nuclear weapon
+ simulations could use 100-teraflop parallel computers. The linear
+ accelerator code linac
+ and the Monte Carlo neutron transport code MC++ were among the codes written.
+
+
+ &pooma; 2 involved a new conceptual framework and a
+ complete rewriting of the source code to improve performance. The
+ &array; class was
+ introduced with its use of engines, separating container use from
+ container storage. A new asynchronous scheduler permitted
+ out-of-order execution to improve cache coherency. Incorporating
+ the Portable Expression Template
+ Engine (PETE) permitted faster
+ loop execution. Soon, container views and
+ ConstantFunction and IndexFunction
+ &engine;s were added. Release 2.1.0 included &field;s with
+ their spatial extent and &dynamicarray;s with the ability to
+ dynamically change domain size. Support for particles and their
+ interaction with &field;s were added. The &pooma; messaging
+ implementation was revised in release 2.3.0. Use of the
+ &cheetah; Library separated &pooma; from the actual messaging
+ library used, and support for applications running on clusters of
+ computers was added. CodeSourcery, LLC, and
+ Proximation, LLC,
+ took over &pooma; development from Los Alamos National Laboratory.
+ During the past two years, the &field; abstraction and
+ implementation was improved to increase its flexibility, add
+ support for multiple values and materials in the same cell, and
+ permit lazy evaluation. Simultaneously, the execution speed of the
+ inner loops was greatly increased.
+
+
+
+
+ Acknowledgements
+
+ This &book; would not have been completed without the help
+ and encouragement of a lot of people and organizations. Los Alamos
+ National Laboratory funded the writing of this manual and the
+ development of the &poomatoolkit;. John Reynders conceived,
+ advocated, and headed &pooma; development in its early days, and
+ Scott Haney continued the leadership. Susan Atlas, Subhankar
+ Banerjee, Timothy Cleland, Julian Cummings, James Crotinger, David
+ Forslund, Salman Habib, Scott Haney, Paul Hinker, William Humphrey,
+ Steve Karmesin, Graham Mark, Jeffrey D. Oldham, Ji Qiang, John
+ Reynders, Robert Ryne, Stephen Smith, M. Srikant, Marydell
+ Tholburn, and Timothy Williams all helped develop &pooma;. Rod
+ Oldehoeft and Jeff Brown of Los Alamos National Laboratory
+ supported CodeSourcery's and Proximation's work, including the
+ development of this manual. John Hall, Don Marshall, Jean
+ Marshall, and the rest of the BLANCA team at Los Alamos worked
+ closely with the developers and provided valuable suggestions for
+ improvements.
+
+ I am grateful to James Crotinger, Mark Mitchell, Amit Patel,
+ and Stephen Smith who answered my many questions during the writing
+ of this &book;. Thanks to Deborah Lafferty of Addison-Wesley
+ Longman, who encouraged me and guided me throughout writing and
+ publishing this &book;.
+
+
+
+ Jeffrey D. Oldham, 2002 February
+
+
+
+
+
+
Index: starting.xml
===================================================================
RCS file: starting.xml
diff -N starting.xml
*** /dev/null Fri Mar 23 21:37:44 2001
--- starting.xml Tue Feb 26 20:44:27 2002
***************
*** 0 ****
--- 1,941 ----
+
+ Getting Started with &pooma;
+
+ In this chapter, we describe how to obtain &pooma;, prepare it
+ for use, and then compile a Hello, &pooma;
+ program. Impatient readers will find the first section helpful.
+ Those desiring more details will find this section provides a useful
+ overview of the chapter.
+
+
+
+ Getting Started for Impatient Users
+
+ This section is designed for impatient, UNIX-literate readers
+ who wish to start using &pooma; as quickly as possible. We
+ describe how to obtain, configure, compile, and use the
+ &toolkit; with a minimum of explanation.
+
+
+
+ Download
+
+ Download &poomasourcefile;
+ from the &pooma; download page (&poomadownloadpage;).
+ Uncompress and extract the source code:
+ &initialspace;tar xzvf &poomasourcefile;
+ Move into the directory containing the source code:
+ &initialspace;cd &poomasource;
+
+
+
+
+ Configure
+
+ To create files necessary for compiling, use
+ &initialspace;./configure &dashdash;arch architecture &dashdash;opt
+ where architecture
+ indicates the operating system and compiler. Permitted choices
+ are the names of files in the config/arch/ subdirectory omitting
+ the .conf suffix.
+
+
+
+ Compilation of the Library
+
+ Create the &pooma; library file by first setting the
+ POOMASUITE environment variable to the
+ architecture's name and then compiling the source code:
+ &initialspace;export POOMASUITE=architecture
+ &initialspace;make
+
+
+
+
+ Compiling Programs
+
+ We illustrate compiling the Hello, &pooma;
+ program available at examples/Manual/Sequential/initialize-finalize.cpp:
+ &initialspace;export POOMAHOME=/home/oldham/pooma/pooma1
+ &initialspace;g++ -I${POOMAHOME}/src -I${POOMAHOME}/lib/${POOMASUITE} initialize-finalize.cpp -o initialize-finalize -L${POOMAHOME}/lib/${POOMASUITE} -lpooma-gcc
+
+ The environment variable indicates the location of the &toolkit;
+ header files and the library.
+
+
+
+
+
+
+
+ Obtaining &pooma;
+
+ &pooma; is open-source software, freely available via the
+ Internet or perhaps packaged with this &book;. CodeSourcery, LLC,
+ currently hosts the &poomatoolkit; source code. Download the the
+ &pooma; source code &poomasourcefile;
+ from the &pooma; download page (&poomadownloadpage;) available off
+ the &pooma; home page (&poomahomepage;). The tgz
+ indicates this is a compressed tar archive file. For a UNIX
+ operating system, one can extract the source files using the
+ command tar xzvf &poomasourcefile;.
+
+
+
+
+
+
+
+ Compiling the &pooma; Library
+
+ Most of the &poomatoolkit; source code is available in header
+ files containing template class definitions. A few files are
+ compiled and collected together into the &pooma; library.
+
+ Before the &pooma; &toolkit; may be compiled, it must be
+ configured. Configuration creates files
+ used during compilation that are specific to the particular
+ operating system, compiler, and available libraries that are to be
+ used. The configuration files in the config/arch/ directory correspond to
+ supported operating systems and compilers. For example, LINUXgcc.conf supports compiling
+ under a Linux operating system with &gcc; (really &gpp;).
+ SGI64KCC.conf supports
+ compiling under a 64-bit SGI Irix
+ operating system with &kcc;.
+
+ To configure the source code, use a command
+ like &initialspace;./configure &dashdash;arch
+ LINUXgcc &dashdash;opt &dashdash;suite LINUXgcc-opt
+ The architecture argument to the
+ &dashdash;arch option is the name of the
+ corresponding configuration file, omitting its .conf suffix. The
+ &dashdash;opt indicates the &poomatoolkit; will
+ contain optimized source code, which makes the code run more
+ quickly but may impede debugging. Alternatively, use the
+ &dashdash;debug option which supports debugging.
+ The suite name
+ can be any arbitrary string. We chose
+ LINUXgcc-opt to remind us of the architecture
+ and optimization choice. configure creates subdirectories
+ named LINUXgcc-opt for use when compiling the source
+ files. Comments at the beginning of lib/suiteName/PoomaConfiguration.h
+ record the configuration arguments.
+
+ To create the &pooma; library, the &toolkit; source files
+ need to be compiled. Specify the desired suite by setting the
+ POOMASUITE environment variable to the appropriate
+ value. For example, if using the bash
+ shell, use &initialspace;export
+ POOMASUITE=suiteName
+ substituting the suite name's suiteName.
+ If using the csh shell,
+ use &initialspace;setenv POOMASUITE
+ suiteName In the
+ previous paragraph, the suite name is
+ LINUXgcc-opt so we would issue the
+ statement &initialspace;setenv POOMASUITE
+ LINUXgcc-opt
+
+ Issuing the make command compiles the
+ &pooma; source code files to create the &pooma; library. The
+ &pooma; makefiles assume the GNU &make; is
+ available so substitute the proper command to run
+ GNU &make; if necessary. As each source
+ file is compiled, a line is printed. If the compilation succeeds,
+ the &pooma; library can be found in, e.g., lib/LINUXgcc-opt/libpooma-gcc.a. If
+ it fails, the makefiles will print a line indicating which file
+ failed to compile. Reading the corresponding .info may indicate what
+ failed.
+
+ The same &pooma; source code can support multiple suites as
+ long as different names are used. For example, we could have
+ LINUXgcc-opt and
+ LINUXgcc-debug suites. Both of these might
+ specify use of the Linux operating system and &gcc;, but one could
+ have optimized code corresponding to the configuration option
+ &dashdash;opt and the other could have
+ debuggable code corresponding to the configuration option
+ &dashdash;debug. When compiling both the
+ library and user code, the POOMASUITE environment
+ variable indicates which suite to use.
+
+
+
+ &danger;: Configuration Options
+
+ (Are you sure you should be reading this section? The
+ &danger; in the title is meant to warn you about material that
+ ought to be skipped on the first reading. And maybe also on the
+ second reading. The reader-beware paragraphs sometimes refer to
+ concepts that aren't explained until later chapters. (Thanks to
+ Donald E. Knuth for the concept of &danger; sections and for
+ the preceding text.))
+
+ The configuration script supports many more command-line
+ options than the two used above, but few &pooma; users need use
+ them except those using distributed &pooma;, which are described
+ below. /configure -h yields a complete list.
+ We describe also describe them here.
+
+
+ Configuration Options
+
+
+
+
+ option
+ description
+
+
+
+
+ Architecture and Installation Choices
+
+
+ &dashdash;arch architecture
+ specify the desired operating system and compiler.
+ architecture should correspond to
+ a file in config/arch/
+ omitting the .conf suffix.
+
+
+ &dashdash;suite
+ suite
+ specify a name for the this particular configuration.
+ The environment variable POOMASUITE's value
+ should equal suite when compiling
+ the library. suite can be any
+ string that an serve as a filename. If this option is
+ omitted, the &dashdash;arch architecture
+ is used.
+
+
+ &dashdash;prefix
+ directory
+ indicates the directory where files are installed.
+ make install should be invoked after
+ compiling the library.
+
+
+ Debugging and Optimization Choices
+
+
+ &dashdash;opt
+ causes an optimized library to be built. Optimized
+ code typically runs faster than unoptimized code, but
+ debugging can be inhibited.
+
+
+ &dashdash;debug
+ causes an debuggable library to be built. That is, a
+ debugger will be able to traverse library code.
+
+
+ Compiler Choices
+
+
+ &dashdash;cpp compiler
+ specifies the &cc; compiler to use. The default value
+ is specified by the architecture configuration file.
+
+
+ &dashdash;c compiler
+ specifies the &c; compiler to use when compiling &c;
+ executables. Such executables usually are example programs.
+ The default value is specified by the architecture
+ configuration file.
+
+
+ &dashdash;f77 compiler
+ specifies the &fortran;77 compiler to use. The default value
+ is specified by the architecture configuration file.
+
+
+
+
+ &dashdash;ar
+ archiver
+ specifies the library archiver to use when creating a
+ static library. The default value is specified by the
+ architecture configuration file.
+
+
+ &dashdash;link linker
+ specifies the linker to use when creating &pooma;
+ executables. The default value, usually the same as the &cc;
+ compiler, is specified by the architecture configuration
+ file.
+
+
+ Compiler Options
+
+
+ &dashdash;static
+ creates a static library that will be directly linked
+ into executables, rather than loaded dynamically. Compare
+ with the &dashdash;shared option. This
+ option is a default.
+
+
+ &dashdash;shared
+ creates a library that will be dynamically loaded when
+ a &pooma; executable starts. It is the executable user's
+ responsibility to configure the operating system so the
+ library will be found, e.g., by setting the
+ LD_LIBRARY_PATH environment variable.
+
+
+ &dashdash;v
+ enables verbose output from the compiler and linker.
+
+
+ &dashdash;q
+ disables verbose output from the compiler and linker.
+
+
+ &dashdash;strict
+ enables ANSI &cc; conformance checking by the compiler.
+
+
+ &dashdash;inc
+ directory
+ causes
+ -Idirectory
+ options to be passed to the compiler. These indicate
+ directories where header files are located. This option may
+ be specified repeatedly.
+
+
+ &dashdash;def definition
+ causes
+ -Ddefinition
+ options to be passed to the compiler. These define
+ preprocessor symbols. This option may be specified
+ repeatedly.
+
+
+ &dashdash;cpparg
+ arguments
+ specifies &cc; compiler options. This option may be
+ specified repeatedly.
+
+
+ &dashdash;carg
+ arguments
+ specifies &c; compiler options. This option may be
+ specified repeatedly.
+
+
+ &dashdash;f77arg
+ arguments
+ specifies &fortran;77 compiler options. This option may be
+ specified repeatedly.
+
+
+ &dashdash;ararg
+ arguments
+ specifies archiver options. This option may be
+ specified repeatedly.
+
+
+ &dashdash;linkarg
+ arguments
+ specifies linker options. This option may be
+ specified repeatedly.
+
+
+ &dashdash;oneper
+ enables the one-per-template-instantiation compiler
+ option. The &kcc; compiler requires this option to avoid
+ problems from instantiating the same template class
+ repeatedly.
+
+
+ &dashdash;noonper
+ disables the one-per-template-instantiation compiler
+ option. See &dashdash;oneper
+ description.
+
+
+ Code Checking
+
+
+ &dashdash;bounds
+ turns on bound checking for indexing operations. That
+ is, indexes into a &container; (a(3,4)) are
+ checked to be in the domain. This option is not the default
+ because it slows each access but is useful when checking
+ program correctness.
+
+
+ &dashdash;insure
+ enables Insure++ code checking.
+
+
+ &dashdash;purify
+ enables Purify code checking.
+
+
+ Language Choices
+
+
+ &dashdash;ex
+ enables use of exceptions if available. Only one of this
+ xor the &dashdash;noex option should be
+ specified.
+
+
+ &dashdash;noex
+ disables use of exceptions. Only one of this
+ xor the &dashdash;ex option should be
+ specified.
+
+
+ &dashdash;arch-specific-functions
+ enables the use of architecture-specific initialization
+ functions.
+
+
+ Library Options
+
+
+ &dashdash;preinst
+ causes preinstantiated versions of several templated
+ classes to be included in the library. This may reduce the
+ time to compile executables.
+
+
+ &danger;: Option for Distributed Computation
+
+
+ &dashdash;messaging
+ enables creation of distributed &pooma; executables by
+ enabling use of the &cheetah; communications package. See
+
+
+
+ Configure Options
+
+
+ -v
+ turns on verbose output during configuration, showing
+ which options are chosen and which are not.
+
+
+ -i
+ prevents overwriting existing files during
+ configuration without first querying the user.
+
+
+ -f
+ forces overwriting existing files during configuration
+ without querying the user. This is the default.
+
+
+ -h
+ prints the list of configuration options.
+
+
+ -?
+ prints the list of configuration options. This is the
+ same as -h.
+
+
+
+
+
+
+
+
+
+
+ Writing and Compiling &pooma; Programs
+
+ In this section, we describe how to write and compile &pooma;
+ programs. We illustrate this with a Hello, &pooma;
+ program that initializes and de-initializes the &pooma;
+ library.
+
+
+ A <quote>Hello, &pooma;</quote> Program
+
+ &initialize-finalize;
+
+
+ This &pooma; header file must be included directly or
+ indirectly in all &pooma; programs.
+
+
+ Every &pooma; program must initialize the &pooma; library
+ by invoking the initialize function.
+
+
+ The &poomatoolkit; is shut down by invoking the
+ finalize function, which must be called
+ after all other &pooma; functions.
+
+
+
+
+ The simplest &pooma; program is available at examples/Manual/Sequential/initialize-finalize.cpp.
+ It is annotated in . Before its
+ use, the &poomatoolkit; must be initialized by a call to
+ initialize. This usually occurs in the
+ main function. After its use, the
+ &poomatoolkit; should be shut down using a call to
+ finalize. This also usually occurs in the
+ main function. Both of these functions are
+ declared in Pooma/Pooma.h.
+ This header file or another &pooma; header file including it occurs
+ in every &pooma; program.
+
+ Compiling this program requires including &pooma; header
+ files and library. Let us assume that the environment variable
+ POOMAHOME describes the location of the &pooma;
+ source code. For example,
+ &initialspace;export POOMAHOME=/home/user/pooma
+ We illustrate how to compile the program using the
+ &gpp; compiler:
+ &initialspace;g++ -I${POOMAHOME}/src -I${POOMAHOME}/lib/LINUXgcc initialize-finalize.cpp -o initialize-finalize -L${POOMAHOME}/lib/${POOMASUITE} -lpooma-gcc
+ We explain the five command-line options:
+
+
+ -I${POOMAHOME}/src
+
+ is the root of a directory tree containing all &pooma;
+ template header files. For example, the full path name of
+ Pooma/Pooma.h is ${POOMAHOME}/src/Pooma/Pooma.h.
+
+
+
+ -I${POOMAHOME}/lib/${POOMASUITE}
+
+ indicates the directory that contains
+ configuration-specific header files.
+
+
+
+ initialize-finalize.cpp
+
+ is the source code to compile. It must have a
+ main function with calls to &pooma;'s
+ initialize and
+ finalize.
+
+
+
+ -o initialize-finalize
+
+ determines the name of the resulting executable program.
+
+
+
+ -L${POOMAHOME}/lib/${POOMASUITE}
+
+ is the directory containing the &pooma; library file to
+ use.
+
+
+
+ -lpooma-gcc
+
+ indicates libpooma-gcc.a is the name of
+ the &pooma; library in the directory specified by the
+ -L option.
+
+
+
+ Running the resulting executable prints Hello,
+ Pooma.:
+ &initialspace;$ ./initialize-finalize
+ &initialspace;Hello, Pooma.
+ &initialspace;$
+
+
+
+
+ &danger;: <function>initialize</function> and <function>finalize</function>
+
+ In this section, we present detailed explanations of
+ initialize and
+ finalize. Very few &pooma; users ever need
+ to use any form different from that presented in the Hello,
+ &pooma; program.
+
+ Prototypes
+
+
+ &initialspace;#include "Pooma/Pooma.h" // or "Pooma/Arrays.h" or "Pooma/Fields.h" or …
+
+
+
+
+ bool Pooma::initialize
+
+ int &argc,
+ char ** &argv,
+ bool initRTS = true,
+ bool getCLArgsArch = true,
+ bool initArch = true
+
+
+
+
+ bool Pooma::initialize
+
+ Pooma::Options &opts,
+ bool initRTS = true,
+ bool initArch = true
+
+
+
+
+ bool Pooma::finalize
+
+
+
+
+ bool Pooma::finalize
+
+ bool quitRTS,
+ bool quitArch
+
+
+
+
+ Explanation
+
+ Before its use, the &poomatoolkit; must be initialized by a
+ call to initialize. This usually occurs in
+ the main function. The first form removes
+ and processes any &pooma;-specific arguments from the command-line
+ arguments argv and argc.
+
+ The third, fourth, and fifth arguments all have a default value of
+ &true;. If initRTS is
+ &true;, the run-time system is initialized. E.g., the contexts
+ are prepared for use. If getCLArgsArch is &true,
+ architecture-specific command-line arguments are removed from
+ argv and argc.
+ Architecture-specific initialization occurs if getCLArgsArch is &true;. An architecture is specified
+ by a hardware interface, e.g., processor type, but frequently is
+ also associated with an operating system or compiler. For
+ example, Metrowerks for the Macintosh has an architecture-specific
+ initialization. The function always returns &true;.
+
+ initialize's alternative form assumes
+ the &pooma;-specific and architecture-specific command-line
+ arguments have already been removed from argv
+ and argc and stored in opts. Its other two parameters have
+ the same meaning, and the two functions' semantics are otherwise
+ the same.
+
+ After its use, the &poomatoolkit; should be shut down using
+ a call to finalize. This usually occurs in
+ the main function. The former, and more
+ frequently used, form first prints any statistics and turns off
+ all default &pooma; streams. Then it shuts down the run-time
+ system if it was previously initialized and then shuts down
+ architecture-specific objects if they were previously initialized.
+ The latter form gives provides explicit control whether the
+ run-time system (quitRTS)
+ and architecture-specific objects (quitArch) are shut down. Both
+ functions always returns &true;.
+
+ Including almost any &pooma; header file, rather than just
+ Pooma/Pooma.h suffices
+ since most other &pooma; header files include it.
+
+
+
+
+
+
+
+ Supporting Distributed Computation
+
+ To use multiple processors with &pooma; requires installing
+ the &cheetah; messaging library and an underlying messaging library
+ such as the Message Passing Interface (&mpi;) Communications
+ Library or the &mm; Shared Memory Library. In the following
+ section, we first describe how to install &mm;. Read it only if
+ using &mm;, not &mpi;. Then we describe how to install &cheetah;
+ and configure &pooma; to use it.
+
+
+ Obtaining and Installing the &mm; Shared Memory Library
+
+ &cheetah;, and thus &pooma;, can use Ralf Engelschall's &mm;
+ Shared Memory Library to pass messages between processors. For
+ example, the &author; uses this library on a two-processor
+ computer running &linux;. The library, available at http://www.engelschall.com/sw/mm/,
+ is available at no cost and has been successfully tested on a
+ variety of Unix-like platforms.
+
+ We describe how to download and install the &mm; library.
+
+
+ Download the library from the &pooma; Download page
+ (&poomadownloadpage;) available off the &pooma; home page
+ (&poomahomepage;).
+
+
+ Extract the source code using tar xzvf
+ mm-1.1.3.tar.gz. Change directories into the
+ resulting source code directory mm-1.1.3.
+
+
+ Prepare to compile the source code by configuring it
+ using the configure command. To change
+ the default installation directory /usr/local, specify
+ &dashdash;prefix=directory
+ option. The other configuration options can be listed by
+ specifying the &dashdash;help option. Since the
+ &author; prefers to keep all &pooma;-related code in his
+ poomasubdirectory, he
+ uses
+
+ ./configure &dashdash;prefix=${HOME}/pooma/mm-1.1.3
+
+
+
+ Create the library by issuing the
+ make command. This compiles the source
+ code using a &c; compiler. To use a different compiler than
+ the &mm; configuration chooses, set the CC
+ environment variable to the desired compiler before
+ configuring.
+
+
+ Optionally test the library by issuing the make
+ test command. If successful, the penultimate line
+ should be OK - ALL TESTS SUCCESSFULLY
+ PASSED.
+
+
+ Install the &mm; Library by issuing the make
+ install command. This copies the library files to the
+ installation directory. The mm-1.1.3 directory containing the
+ source code may now be removed.
+
+
+
+
+
+
+
+ Obtaining and Installing the &cheetah; Messaging Library
+
+ The &cheetah; Library decouples communication from
+ synchronization. Using asynchronous messaging rather than
+ synchronous messaging permits a message sender to operate without
+ the cooperation of the message recipient. Thus, implementing
+ message sending is simpler and processing is more efficiently
+ overlapped with it. Remote method invocation is also supported.
+ The library was developed at the Los Alamos National Laboratory's
+ Advanced Computing Laboratory.
+
+ &cheetah;'s messaging is implemented using an underlying
+ messaging library such as the Message Passing Interface (&mpi;)
+ Communications Library
+ )
+ ]]>
+ or the &mm; Shared Memory Library. &mpi; works on a wide variety
+ of platforms and has achieved widespread usage. &mm; works under
+ Unix-like operating systems on any computer with shared memory. Both libraries are
+ available at no cost. The instructions below work for whichever
+ library you choose.
+
+ We describe how to download and install &cheetah;.
+
+
+ Download the library from the &pooma; Download page
+ (&poomadownloadpage;) available off the &pooma; home page
+ (&poomahomepage;).
+
+
+ Extract the source code using tar xzvf
+ cheetah-1.0.tgz. Change directories into the
+ resulting source code directory cheetah-1.0.
+
+
+ Edit a configuration file corresponding to your operating
+ system and compiler. These .conf files are located in the
+ config directory. For
+ example, to use &gcc; (really &gpp;) with the &linux; operating
+ system, use config/LINUXGCC.conf.
+
+ The configuration file usually does not need
+ modification. However, if you are using &mm;, ensure
+ shmem_default_dir specifies its location.
+ For example, the &author; modified the value to
+ "/home/oldham/pooma/mm-1.1.3".
+
+
+ Prepare to compile the source code by configuring it
+ using the configure command. Specify the
+ configuration file using the &dashdash;arch option.
+ Its argument should be the configuration file's name, omitting
+ its .conf suffix. For
+ example, &dashdash;arch LINUXGCC. Some other
+ options include
+
+
+ &dashdash;help
+
+ lists all the available options
+
+
+
+ &dashdash;shmem &dashdash;nompi
+
+ indicates use of &mm;, not &mpi;
+
+
+
+ &dashdash;mpi &dashdash;noshmem
+
+ indicates use of &mpi;, not &mm;
+
+
+
+ &dashdash;opt
+
+ causes the compiler to produce optimized source code
+
+
+
+ &dashdash;noex
+
+ prevents use of &cc; exceptions
+
+
+
+ &dashdash;static
+
+ creates a static library, not a shared library
+
+
+
+ &dashdash;shared
+
+ creates a shared library, not a static library. This
+ is the default.
+
+
+
+ &dashdash;prefix directory
+
+ specifies the installation directory where the
+ library will be copied rather than the default.
+
+
+
+ For example, the &author; uses
+
+ ./configure &dashdash;arch LINUXGCC &dashdash;shmem &dashdash;nompi
+ &dashdash;noex &dashdash;static &dashdash;prefix ${HOME}/pooma/cheetah-1.0
+ &dashdash;opt
+ The
+ &dashdash;arch LINUXGCC indicates use of
+ &gcc; (or &gpp;) under a &linux; operating system. The &mm;
+ library is used, but &cc; exceptions are not. The latter
+ choice matches &pooma;'s default choice. A static library,
+ not a shared library, is created. This is also &pooma;'s
+ default choice. The library will be installed in the
+ ${HOME}/pooma/cheetah-1.0.
+ Finally, the library code will be optimized, hopefully running
+ faster than unoptimized code.
+
+
+ Follow the directions printed by
+ configure: Change directories to the
+ lib subdirectory named
+ by the &dashdash;arch argument and then type
+ make to compile the source code and create
+ the library.
+
+
+ Optionally ensure the library works correctly by issuing
+ the make tests command.
+
+
+ Install the library by issuing the make
+ install command. This copies the library files to
+ the installation directory. The cheetah-1.0 directory containing
+ the source code may now be removed.
+
+
+
+
+
+
+ Configuring &pooma; When Using &cheetah;
+
+ To use &pooma; with &cheetah;, one must tell &pooma; the
+ location of the &cheetah; library using the
+ &dashdash;messaging configuration option. To do this,
+
+
+ Set the &cheetah; directory environment variable
+ CHEETAHDIR to the directory containing the
+ installed &cheetah; library. For
+ example,
+
+ declare -x CHEETAHDIR=${HOME}/pooma/cheetah-1.0
+ specifies the
+ installation directory used in the previous section. If using
+ the csh shell, use setenv
+ CHEETAHDIR ${HOME}/pooma/cheetah-1.0.
+
+
+ When configuring &pooma;, specify the
+ &dashdash;messaging option. For example,
+ ./configure &dashdash;arch LINUXgcc &dashdash;opt
+ &dashdash;messaging configures for &linux;, &gcc;, and an
+ optimized library using &cheetah;.
+
+
+
+
+
+
Index: template.xml
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/template.xml,v
retrieving revision 1.6
diff -c -p -r1.6 template.xml
*** template.xml 2002/01/31 21:20:27 1.6
--- template.xml 2002/02/27 03:44:29
***************
*** 1,5 ****
!
! Programming with Templatestemplates
--- 1,5 ----
!
! &danger;: Programming with Templatestemplates
***************
*** 15,22 ****
we briefly introduce using templates in &cc; programs by relating
them to ordinary &cc; constructs such as values,
objects, and classes. The two main concepts underlying &cc;
! templates will occur repeatedly:
! Template programming constructs execute at compile time,
not run time. That is, template operations occur within the
--- 15,21 ----
we briefly introduce using templates in &cc; programs by relating
them to ordinary &cc; constructs such as values,
objects, and classes. The two main concepts underlying &cc;
! templates will occur repeatedly:Template programming constructs execute at compile time,
not run time. That is, template operations occur within the
*************** struct CreateLeaf
*** 1092,1095 ****
Leaf_t. Unlike for function objects, the function's
name within the class must be given a name.
!
--- 1091,1094 ----
Leaf_t. Unlike for function objects, the function's
name within the class must be given a name.
!
Index: tutorial.xml
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/tutorial.xml,v
retrieving revision 1.11
diff -c -p -r1.11 tutorial.xml
*** tutorial.xml 2002/01/31 21:20:27 1.11
--- tutorial.xml 2002/02/27 03:44:29
***************
*** 111,195 ****
]]>
-
- Installing &pooma;
-
- ADD: How does one install &pooma; using Windows or Mac?
-
- UPDATE: Make a more recent &pooma; source code file
- available on &poomadownloadpage;. For example,
- LINUXgcc.conf is not available.
- ]]>
-
- In this section, we describe how to obtain, build, and
- install the &poomatoolkit;. We focus on installing under a
- Unix-like operating system.
- .
- ]]>
-
-
- Obtain the &pooma; source code &poomasourcefile;
- from the &pooma; download page (&poomadownloadpage;) available off
- the &pooma; home page (&poomahomepage;). The tgz
- indicates this is a compressed tar archive file. To extract the
- source files, use tar xzvf &poomasourcefile;.
- Move into the source code directory &poomasource; directory; e.g.,
- cd &poomasource;.
-
- Configuring the source code determines file names needed for
- compilation. First, determine a configuration file in the config/arch/ directory corresponding to
- your operating system and compiler. For example, LINUXgcc.conf supports compiling
- under a &linux; operating system with &gcc;, while SGI64KCC.conf supports compiling
- under a 64-bit SGI Irix operating system
-
- with &kcc;. Next, configure the source code: ./configure
- &dashdash;arch LINUXgcc &dashdash;opt &dashdash;suite
- LINUXgcc-opt. The architecture argument to the
- &dashdash;arch option is the name of the
- corresponding configuration file, omitting its .conf suffix. The
- &dashdash;opt indicates the &poomatoolkit; will
- contain optimized source code, which makes the code run more quickly
- but may impede debugging. Alternatively, use the
- &dashdash;debug option which supports debugging.
- The suite name
- can be any arbitrary string. We chose
- LINUXgcc-opt to remind us of the architecture and
- optimization choice. configure creates subdirectories
- named LINUXgcc-opt for use when compiling the source
- files. Comments at the beginning of lib/suiteName/PoomaConfiguration.h
- record the configuration arguments.
-
- To compile the source code, set the POOMASUITE
- environment variable to the suite name and then type
- make. To set the environment variable for the
-
- bash shell use export
- POOMASUITE=suiteName,
- substituting the suite name's suiteName.
-
- For the csh shell, use setenv
- POOMASUITE LINUXgcc-opt. Issuing the
- make command compiles the &pooma; source code
- files to create the &pooma; library. The &pooma; makefiles assume
- the GNU &make; is available so substitute the
- proper command to run GNU &make; if
- necessary. The &pooma; library can be found in, e.g., lib/LINUXgcc-opt/libpooma-gcc.a.
-
-
Hand-Coded Implementation
--- 111,116 ----
***************
*** 285,291 ****
directory. Ensure the POOMASUITE environment
variable specifies the desired suite name
suiteName, as we did when compiling
! &pooma; in . Issuing
the make Doof2d-C-element command creates the
executable
suiteName/Doof2d-C-element.
--- 206,212 ----
directory. Ensure the POOMASUITE environment
variable specifies the desired suite name
suiteName, as we did when compiling
! &pooma; in . Issuing
the make Doof2d-C-element command creates the
executable
suiteName/Doof2d-C-element.
***************
*** 760,766 ****
url="http://www.engelschall.com/sw/mm/">), communicates
the available contexts to the executable. &pooma; must be
configured for the particular run-time system in use. See .
A layout combines patches with contexts
so the program can be executed. If &distributedtag; is specified,
--- 681,687 ----
url="http://www.engelschall.com/sw/mm/">), communicates
the available contexts to the executable. &pooma; must be
configured for the particular run-time system in use. See .A layout combines patches with contexts
so the program can be executed. If &distributedtag; is specified,
Index: figures/Makefile
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/figures/Makefile,v
retrieving revision 1.2
diff -c -p -r1.2 Makefile
*** figures/Makefile 2002/02/01 02:08:07 1.2
--- figures/Makefile 2002/02/27 03:44:29
*************** MPOST= mpost
*** 20,28 ****
EPSTOPNG= /home/oldham/bin/peps
# MetaPost macro definitions used in multiple files.
! MACRO_SOURCES= box-macros.mp grid-macros.mp
# These MetaPost files describe the figures.
! SOURCES= concepts.mp data-parallel.mp distributed.mp doof2d.mp introduction.mp
# MetaPost can produce multiple files per input file. These multiple
# files have names %.[0-9]+. Since make does not deal well with
# producing an indeterminate number of files from the same rule, we
--- 20,31 ----
EPSTOPNG= /home/oldham/bin/peps
# MetaPost macro definitions used in multiple files.
! MACRO_SOURCES= box-macros.mp grid-macros.mp uml.mp
! # These MetaPost files describe the UML class diagrams.
! UML_SOURCES= explanation-uml.mp
# These MetaPost files describe the figures.
! SOURCES= concepts.mp data-parallel.mp distributed.mp doof2d.mp introduction.mp \
! $(UML_SOURCES)
# MetaPost can produce multiple files per input file. These multiple
# files have names %.[0-9]+. Since make does not deal well with
# producing an indeterminate number of files from the same rule, we
*************** RESULTS= $(SOURCES:%.mp=mproof-%.ps)
*** 33,38 ****
--- 36,46 ----
# figures.
TREE_SOURCES= $(SOURCES) Makefile macros.ltx
+ # UML class diagrams that occur in the appendix containing these.
+ UML_DIAGRAMS= explanation-uml-1.png array-uml.1 array-uml.2 array-uml.3 \
+ domain-uml.1 engine-uml.1 engine-uml.2 engine-uml.3 \
+ engine-uml.4
+
# Create all the EPS and PNG files. The 'mproof-all' target creates
# the EPS files. This should happen before trying to create the PNG
# files, but this rule may not guarantee this ordering.
*************** all: mproof-all \
*** 40,46 ****
concepts-101.png concepts-111.png data-parallel-101.png \
data-parallel-212.png distributed-101.png \
doof2d-201.png doof2d-202.png doof2d-203.png \
! doof2d-210.png doof2d-211.png introduction-101.png
mproof-all: $(RESULTS)
--- 48,55 ----
concepts-101.png concepts-111.png data-parallel-101.png \
data-parallel-212.png distributed-101.png \
doof2d-201.png doof2d-202.png doof2d-203.png \
! doof2d-210.png doof2d-211.png introduction-101.png \
! $(UML_DIAGRAMS)
mproof-all: $(RESULTS)
*************** distributed-%.png: distributed.%
*** 60,65 ****
--- 69,82 ----
doof2d-%.png: doof2d.%
$(EPSTOPNG) -p -o $@ $^
introduction-%.png: introduction.%
+ $(EPSTOPNG) -p -o $@ $^
+ array-uml-%.png: array-uml.%
+ $(EPSTOPNG) -p -o $@ $^
+ domain-uml-%.png: domain-uml.%
+ $(EPSTOPNG) -p -o $@ $^
+ engine-uml-%.png: engine-uml.%
+ $(EPSTOPNG) -p -o $@ $^
+ explanation-uml-%.png: explanation-uml.%
$(EPSTOPNG) -p -o $@ $^
clean:
Index: figures/array-uml-1.png
===================================================================
RCS file: array-uml-1.png
diff -N array-uml-1.png
Binary files /dev/null and array-uml-1.png differ
Index: figures/array-uml-2.png
===================================================================
RCS file: array-uml-2.png
diff -N array-uml-2.png
Binary files /dev/null and array-uml-2.png differ
Index: figures/array-uml-3.png
===================================================================
RCS file: array-uml-3.png
diff -N array-uml-3.png
Binary files /dev/null and array-uml-3.png differ
Index: figures/array-uml.mp
===================================================================
RCS file: array-uml.mp
diff -N array-uml.mp
*** /dev/null Fri Mar 23 21:37:44 2001
--- array-uml.mp Tue Feb 26 20:44:31 2002
***************
*** 0 ****
--- 1,338 ----
+ %% Oldham, Jeffrey D.
+ %% 2002Feb19
+ %% POOMA
+
+ %% Engine UML Diagram
+
+
+ %% Assumes TEX=latex.
+
+ %% Ensure fonts are included in the output.
+ prologues := 2; % >= 2 for PostScript
+
+ input boxes;
+ input box-macros;
+ input uml;
+
+ verbatimtex
+ \documentclass[10pt]{article}
+ \usepackage{amsmath}
+ \input{macros.ltx}
+ \usepackage{times}
+ \usepackage{mathptm}
+ \newlength{\cnw} % Required to use \classnameWidth and \emptyBox
+ \begin{document}
+ etex
+
+
+ beginfig(1)
+ %% Create the boxes.
+ % Array
+ boxit.array[0](btex \classnameWidth{Array}{DynamicArray<1,T,Tag>} etex);
+ boxit.array[1](btex etex);
+ boxit.array[2](
+ btex
+ \begin{lists}
+ Array() \\
+ Array(Domain \ldots) \\
+ Array(Domain \ldots, ModelElement) \\
+ Array(Array) \\
+ Array(Array, Domain) \\
+ initialize(Domain \ldots) \\
+ initialize(Domain \ldots, ModelElement) \\
+ read(\ldots) \\
+ operator()(\ldots) \\
+ domain() \\
+ physicalDomain() \\
+ totalDomain() \\
+ first(int) \\
+ last(int) \\
+ length(int) \\
+ firsts() \\
+ lasts() \\
+ lengths() \\
+ size() \\
+ layout() \\
+ engine() \\
+ operator<<
+ \end{lists} etex);
+ boxit.array[3](
+ btex
+ \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.array[4](
+ btex \begin{files}
+ Array.h \\
+ PrintArray.h
+ \end{files} etex);
+
+ % DynamicArray
+ boxit.dynamicarray[0](btex \classnameWidth{DynamicArray<1,T,Tag>}{DynamicArray<1,T,Tag>} etex);
+ boxit.dynamicarray[1](btex etex);
+ boxit.dynamicarray[2](
+ btex
+ \begin{lists}
+ DynamicArray() \\
+ DynamicArray(Domain) \\
+ DynamicArray(Domain, ModelElement) \\
+ DynamicArray(DynamicArray) \\
+ DynamicArray(DynamicArray, Domain) \\
+ initialize(Domain \ldots) \\
+ initialize(Domain \ldots, ModelElement) \\
+ read(\ldots) \\
+ operator()(\ldots) \\
+ domain() \\
+ physicalDomain() \\
+ totalDomain() \\
+ first(int) \\
+ last(int) \\
+ length(int) \\
+ firsts() \\
+ lasts() \\
+ lengths() \\
+ size() \\
+ layout() \\
+ engine() \\
+ operator<< \\
+ array() \\
+ arrayAll() \\
+ create(CreateSize\t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.dynamicarray[3](
+ btex
+ \begin{lists}
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.dynamicarray[4](
+ btex \begin{files}
+ DynamicArray.h
+ \end{files} etex);
+
+
+ %% Position the boxes.
+ % Position the template parameters.
+ forsuffixes $=array,dynamicarray:
+ fixsize($[0]);
+ endfor
+ forsuffixes $=array,dynamicarray:
+ fixsize($[3]);
+ $[0].ne - $[3].sw =
+ (min(0.5 xpart($[3].ne - $[3].sw), $[0].dx),
+ min(0.5 ypart($[3].ne - $[3].sw), $[0].dy));
+ endfor
+
+ % Position the UML classes.
+ array[0].c = origin;
+ array[0].s - dynamicarray[0].n = (0, 2yUnit);
+
+ %% Draw the boxes.
+ % Draw the UML class boxes.
+ forsuffixes $=array,dynamicarray:
+ for t = 0 upto 0:
+ drawboxed($[t]);
+ endfor
+ endfor
+ % Draw the template parameters.
+ forsuffixes $=array,dynamicarray:
+ unfill bpath($[3]);
+ drawunboxed($[3]);
+ draw bpath($[3]) dashed evenly;
+ endfor
+
+ % Draw arrows between classes.
+ drawDiscriminator(array[0].s, 0);
+ z0 = array[0].s - (0,discriminatorScale);
+ draw z0 -- dynamicarray[0].n;
+ endfig;
+
+
+ %% Draw the Array box.
+ beginfig(2)
+ %% Create the boxes.
+ % Array
+ boxit.array[0](btex \classnameWidth{Array}{DynamicArray<1,T,Tag>} etex);
+ boxit.array[1](btex etex);
+ boxit.array[2](
+ btex
+ \begin{lists}
+ Array() \\
+ Array(Domain \ldots) \\
+ Array(Domain \ldots, ModelElement) \\
+ Array(Array) \\
+ Array(Array, Domain) \\
+ initialize(Domain \ldots) \\
+ initialize(Domain \ldots, ModelElement) \\
+ read(\ldots) \\
+ operator()(\ldots) \\
+ domain() \\
+ physicalDomain() \\
+ totalDomain() \\
+ first(int) \\
+ last(int) \\
+ length(int) \\
+ firsts() \\
+ lasts() \\
+ lengths() \\
+ size() \\
+ layout() \\
+ engine() \\
+ operator<<
+ \end{lists} etex);
+ boxit.array[3](
+ btex
+ \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.array[4](
+ btex \begin{files}
+ Array.h \\
+ PrintArray.h
+ \end{files} etex);
+
+ %% Position the boxes.
+ % Position the template parameters.
+ forsuffixes $=array:
+ samewidth($[0],$[1],$[2]);
+ for t = 0 upto 1:
+ $.[t].se = $[t+1].ne;
+ $.[t].sw = $[t+1].nw;
+ endfor
+ fixsize($[0],$[1],$[2]);
+ endfor
+ forsuffixes $=array:
+ fixsize($[3]);
+ $[0].ne - $[3].sw =
+ (min(0.5 xpart($[3].ne - $[3].sw), $[0].dx),
+ min(0.5 ypart($[3].ne - $[3].sw), $[0].dy));
+ endfor
+ % Position the implementation files boxes.
+ forsuffixes $=array:
+ fixsize($[4]);
+ $[2].s = $[4].nw;
+ endfor
+
+ % Position the UML classes.
+ array[0].c = origin;
+
+ %% Draw the boxes.
+ % Draw the UML class boxes.
+ forsuffixes $=array:
+ for t = 0 upto 2:
+ drawboxed($[t]);
+ endfor
+ endfor
+ % Draw the template parameters.
+ forsuffixes $=array:
+ unfill bpath($[3]);
+ drawunboxed($[3]);
+ draw bpath($[3]) dashed evenly;
+ endfor
+ % Draw the implementation files.
+ forsuffixes $=array:
+ drawunboxed($[4]);
+ endfor
+ endfig;
+
+
+ % Print the DynamicArray class box.
+ beginfig(3)
+ %% Create the boxes.
+ % DynamicArray
+ boxit.dynamicarray[0](btex \classnameWidth{DynamicArray<1,T,Tag>}{DynamicArray<1,T,Tag>} etex);
+ boxit.dynamicarray[1](btex etex);
+ boxit.dynamicarray[2](
+ btex
+ \begin{lists}
+ DynamicArray() \\
+ DynamicArray(Domain) \\
+ DynamicArray(Domain, ModelElement) \\
+ DynamicArray(DynamicArray) \\
+ DynamicArray(DynamicArray, Domain) \\
+ initialize(Domain \ldots) \\
+ initialize(Domain \ldots, ModelElement) \\
+ read(\ldots) \\
+ operator()(\ldots) \\
+ domain() \\
+ physicalDomain() \\
+ totalDomain() \\
+ first(int) \\
+ last(int) \\
+ length(int) \\
+ firsts() \\
+ lasts() \\
+ lengths() \\
+ size() \\
+ layout() \\
+ engine() \\
+ operator<< \\
+ array() \\
+ arrayAll() \\
+ create(CreateSize\t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.dynamicarray[3](
+ btex
+ \begin{lists}
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.dynamicarray[4](
+ btex \begin{files}
+ DynamicArray.h
+ \end{files} etex);
+
+
+ %% Position the boxes.
+ % Position the template parameters.
+ forsuffixes $=dynamicarray:
+ samewidth($[0],$[1],$[2]);
+ for t = 0 upto 1:
+ $.[t].se = $[t+1].ne;
+ $.[t].sw = $[t+1].nw;
+ endfor
+ fixsize($[0],$[1],$[2]);
+ endfor
+ forsuffixes $=dynamicarray:
+ fixsize($[3]);
+ $[0].ne - $[3].sw =
+ (min(0.5 xpart($[3].ne - $[3].sw), $[0].dx),
+ min(0.5 ypart($[3].ne - $[3].sw), $[0].dy));
+ endfor
+ % Position the implementation files boxes.
+ forsuffixes $=dynamicarray:
+ fixsize($[4]);
+ $[2].s = $[4].nw;
+ endfor
+
+ % Position the UML classes.
+ dynamicarray[0].c = origin;
+
+ %% Draw the boxes.
+ % Draw the UML class boxes.
+ forsuffixes $=dynamicarray:
+ for t = 0 upto 2:
+ drawboxed($[t]);
+ endfor
+ endfor
+ % Draw the template parameters.
+ forsuffixes $=dynamicarray:
+ unfill bpath($[3]);
+ drawunboxed($[3]);
+ draw bpath($[3]) dashed evenly;
+ endfor
+ % Draw the implementation files.
+ forsuffixes $=dynamicarray:
+ drawunboxed($[4]);
+ endfor
+ endfig;
+
+ bye
Index: figures/domain-uml-1.png
===================================================================
RCS file: domain-uml-1.png
diff -N domain-uml-1.png
Binary files /dev/null and domain-uml-1.png differ
Index: figures/domain-uml.mp
===================================================================
RCS file: domain-uml.mp
diff -N domain-uml.mp
*** /dev/null Fri Mar 23 21:37:44 2001
--- domain-uml.mp Tue Feb 26 20:44:33 2002
***************
*** 0 ****
--- 1,230 ----
+ %% Oldham, Jeffrey D.
+ %% 2002Feb18
+ %% POOMA
+
+ %% Domain UML Diagram
+
+
+ %% Assumes TEX=latex.
+
+ %% Ensure fonts are included in the output.
+ prologues := 2; % >= 2 for PostScript
+
+ input boxes;
+ input box-macros;
+ input uml;
+
+ verbatimtex
+ \documentclass[10pt]{article}
+ \usepackage{amsmath}
+ \input{macros.ltx}
+ \usepackage{times}
+ \usepackage{mathptm}
+ \newlength{\cnw} % Required to use \classnameWidth and \emptyBox
+ \begin{document}
+ etex
+
+
+ beginfig(1)
+ %% Create the boxes.
+ % Domain
+ boxit.domain[0](btex \classname{Domain} etex);
+ boxit.domain[1](btex etex);
+ boxit.domain[2](
+ btex \begin{lists}
+ long size() \\
+ bool empty() \\
+ Domain<1> \breakLine operator[](int dim)
+ \end{lists} etex);
+ boxit.domain[3](
+ btex
+ \begin{lists}
+ dim D
+ \end{lists} etex);
+ boxit.domain[4](
+ btex \begin{files}
+ Domain.h \\
+ DomainBase.h \\
+ DomainTraits.h
+ \end{files} etex);
+
+ % Domain<1>
+ boxit.domainOne[0](btex \classname{Domain<1>} etex);
+ boxit.domainOne[1](btex etex);
+ boxit.domainOne[2](
+ btex \begin{lists}
+ long length() \\
+ int first() \\
+ int last() \\
+ int min() \\
+ int max() \\
+ Domain<1>::iter-\breakLine ator begin() \\
+ Domain<1>::iter-\breakLine ator end() \\
+ \end{lists} etex);
+
+ % Domain<1>::iterator
+ boxit.domainOneIterator[0](btex \classname{Domain<1>::iterator} etex);
+ boxit.domainOneIterator[1](btex etex);
+ boxit.domainOneIterator[2](
+ btex \begin{lists}
+ operator*() \\
+ operator++() \\
+ operator->() \\
+ \end{lists} etex);
+ boxit.domainOneIterator[4](
+ btex \begin{files}
+ DomainIterator.h
+ \end{files} etex);
+
+ % Loc
+ boxit.loc[0](btex \classname{Loc} etex);
+ boxit.loc[1](btex \emptyBox{Interval<1>} etex);
+ boxit.loc[2](btex etex);
+ boxit.loc[3](
+ btex \begin{lists}
+ dim D
+ \end{lists} etex);
+ boxit.loc[4](
+ btex \begin{files}
+ Loc.h \\
+ DomainTraits.Loc.h
+ \end{files} etex);
+
+ % Loc<1>
+ boxit.locOne[0](btex \classname{Loc<1>} etex);
+ boxit.locOne[1](btex \emptyBox{Interval<1>} etex);
+ boxit.locOne[2](btex etex);
+
+ % Interval
+ boxit.interval[0](btex \classname{Interval} etex);
+ boxit.interval[1](btex \emptyBox{Interval<1>} etex);
+ boxit.interval[2](btex etex);
+ boxit.interval[3](
+ btex
+ \begin{lists}
+ dim D
+ \end{lists} etex);
+ boxit.interval[4](
+ btex \begin{files}
+ Interval.h \\
+ DomainTraits.Interval.h
+ \end{files} etex);
+
+ % Interval<1>
+ boxit.intervalOne[0](btex \classname{Interval<1>} etex);
+ boxit.intervalOne[1](btex \emptyBox{Interval<1>} etex);
+ boxit.intervalOne[2](btex etex);
+
+ % Range
+ boxit.rangeBox[0](btex \classname{Range} etex);
+ boxit.rangeBox[1](btex \emptyBox{Interval<1>} etex);
+ boxit.rangeBox[2](btex etex);
+ boxit.rangeBox[3](btex
+ \begin{lists}
+ dim D
+ \end{lists} etex);
+ boxit.rangeBox[4](
+ btex \begin{files}
+ Range.h \\
+ DomainTraits.Range.h
+ \end{files} etex);
+
+ % Range<1>
+ boxit.rangeOne[0](btex \classname{Range<1>} etex);
+ boxit.rangeOne[1](btex \emptyBox{Interval<1>} etex);
+ boxit.rangeOne[2](btex etex);
+
+ % Grid
+ boxit.grid[0](btex \classname{Grid} etex);
+ boxit.grid[1](btex \emptyBox{Interval<1>} etex);
+ boxit.grid[2](btex etex);
+ boxit.grid[3](btex
+ \begin{lists}
+ dim D
+ \end{lists} etex);
+ boxit.grid[4](
+ btex \begin{files}
+ Grid.h \\
+ DomainTraits.Grid.h
+ \end{files} etex);
+
+ % Grid<1>
+ boxit.gridOne[0](btex \classname{Grid<1>} etex);
+ boxit.gridOne[1](btex \emptyBox{Interval<1>} etex);
+ boxit.gridOne[2](btex etex);
+
+ %% Position the boxes.
+ % Position the boxes within the UML class diagrams.
+ forsuffixes $=domain, domainOne, domainOneIterator, loc, locOne, interval, intervalOne, rangeBox, rangeOne, grid, gridOne:
+ samewidth($[0],$[1],$[2]);
+ for t = 0 upto 1:
+ $.[t].se = $[t+1].ne;
+ $.[t].sw = $[t+1].nw;
+ endfor
+ fixsize($[0],$[1],$[2]);
+ endfor
+ % Position the template parameters.
+ forsuffixes $=domain, loc, interval, rangeBox, grid:
+ fixsize($[3]);
+ $[0].ne - $[3].sw =
+ (min(0.5 xpart($[3].ne - $[3].sw), $[0].dx),
+ min(0.5 ypart($[3].ne - $[3].sw), $[0].dy));
+ endfor
+ % Position the implementation files boxes.
+ forsuffixes $=domain, domainOneIterator, loc, interval, rangeBox, grid:
+ fixsize($[4]);
+ $[2].s = $[4].nw;
+ endfor
+
+ % Position the UML classes.
+ domain[0].c = origin;
+ domainOne[0].nw - domain[0].ne = (xUnit,0);
+ domainOneIterator[0].nw - domainOne[0].ne = (xUnit,0);
+ domain[2].sw - loc[0].nw = (0, yUnit + max(0, ypart(domain[2].s - domainOne[2].s)));
+ loc[2].s - locOne[0].n = (0, yUnit);
+ interval[0].nw - loc[0].ne = (xUnit, 0);
+ interval[2].s - intervalOne[0].n = (0, yUnit);
+ rangeBox[0].nw - interval[0].ne = (2xUnit, 0);
+ rangeBox[2].s - rangeOne[0].n = (0, yUnit);
+ grid[0].nw - rangeBox[0].ne = (xUnit, 0);
+ grid[2].s - gridOne[0].n = (0, yUnit);
+
+ %% Draw the boxes.
+ % Draw the UML class boxes.
+ forsuffixes $=domain, domainOne, domainOneIterator, loc, locOne, interval, intervalOne, rangeBox, rangeOne, grid, gridOne:
+ for t = 0 upto 2:
+ drawboxed($[t]);
+ endfor
+ endfor
+ % Draw the template parameters.
+ forsuffixes $=domain, loc, interval, rangeBox, grid:
+ unfill bpath($[3]);
+ drawunboxed($[3]);
+ draw bpath($[3]) dashed evenly;
+ endfor
+ % Draw the file names.
+ forsuffixes $=domain, domainOneIterator, loc, interval, rangeBox, grid:
+ drawunboxed($[4]);
+ endfor
+
+ % Draw arrows between classes.
+ drawarrow locOne[0].n -- loc[2].s dashed evenly;
+ drawarrow intervalOne[0].n -- interval[2].s dashed evenly;
+ drawarrow rangeOne[0].n -- rangeBox[2].s dashed evenly;
+ drawarrow gridOne[0].n -- grid[2].s dashed evenly;
+ drawarrow domainOne[1].w -- domain[1].e dashed evenly;
+
+ % Draw lines between classes.
+ draw domainOneIterator[1].w -- domainOne[1].e;
+ drawDiscriminator(domain[2].s, 0);
+ numeric foo; foo = 0.7yUnit;
+ forsuffixes $=loc, interval, rangeBox, grid:
+ draw $[0].n -- ($[0].n+(0,foo));
+ endfor
+ draw loc[0].n+(0,foo) -- grid[0].n+(0,foo);
+ z0 = domain[2].s - (0,discriminatorScale);
+ draw z0 -- (x0, ypart(loc[0].n+(0,foo)));
+
+ endfig;
+
+ bye
Index: figures/doof2d.mp
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/figures/doof2d.mp,v
retrieving revision 1.6
diff -c -p -r1.6 doof2d.mp
*** figures/doof2d.mp 2002/01/31 21:29:58 1.6
--- figures/doof2d.mp 2002/02/27 03:44:34
*************** verbatimtex
*** 18,24 ****
etex
-
input grid-macros;
%% Global Declarations
--- 18,23 ----
Index: figures/engine-uml-1.png
===================================================================
RCS file: engine-uml-1.png
diff -N engine-uml-1.png
Binary files /dev/null and engine-uml-1.png differ
Index: figures/engine-uml-2.png
===================================================================
RCS file: engine-uml-2.png
diff -N engine-uml-2.png
Binary files /dev/null and engine-uml-2.png differ
Index: figures/engine-uml-3.png
===================================================================
RCS file: engine-uml-3.png
diff -N engine-uml-3.png
Binary files /dev/null and engine-uml-3.png differ
Index: figures/engine-uml-4.png
===================================================================
RCS file: engine-uml-4.png
diff -N engine-uml-4.png
Binary files /dev/null and engine-uml-4.png differ
Index: figures/engine-uml.mp
===================================================================
RCS file: engine-uml.mp
diff -N engine-uml.mp
*** /dev/null Fri Mar 23 21:37:44 2001
--- engine-uml.mp Tue Feb 26 20:44:36 2002
***************
*** 0 ****
--- 1,996 ----
+ %% Oldham, Jeffrey D.
+ %% 2002Feb19
+ %% POOMA
+
+ %% Engine UML Diagram
+
+
+ %% Assumes TEX=latex.
+
+ %% Ensure fonts are included in the output.
+ prologues := 2; % >= 2 for PostScript
+
+ input boxes;
+ input box-macros;
+ input uml;
+
+ verbatimtex
+ \documentclass[10pt]{article}
+ \usepackage{amsmath}
+ \input{macros.ltx}
+ \usepackage{times}
+ \usepackage{mathptm}
+ \newlength{\cnw} % Required to use \classnameWidth and \emptyBox
+ \begin{document}
+ etex
+
+
+ %% The first figure will show the relationships among the UML classes.
+ %% Subsequent figures will describe the classes.
+
+ beginfig(1)
+ %% Create the boxes.
+ % Engine
+ boxit.engine[0](btex \classnameWidth{Engine}{Engine} etex);
+ boxit.engine[1](btex etex);
+ boxit.engine[2](btex etex);
+ boxit.engine[3](
+ btex
+ \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.engine[4](
+ btex \begin{files}
+ Engine.h
+ \end{files} etex);
+
+ % Brick
+ boxit.brick[0](btex \classname{Engine} etex);
+ boxit.brick[1](btex etex);
+
+ picture engineOperations;
+ engineOperations =
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ layout()
+ \end{lists} etex;
+
+ boxit.brick[2](engineOperations);
+
+ picture taggedEngineTemplates;
+ taggedEngineTemplates =
+ btex \begin{lists}
+ dim D \\
+ val type T
+ \end{lists} etex;
+
+ boxit.brick[3](taggedEngineTemplates);
+ boxit.brick[4](
+ btex \begin{files}
+ BrickEngine.h \\
+ BrickEngine.cpp \\
+ BrickEngine.[1-7].inst.cpp \\
+ BrickBase.h \\
+ BrickBase.cpp \\
+ BrickBase[1-7].cmpl.cpp
+ \end{files} etex);
+
+ % CompressibleBrick
+ boxit.compressiblebrick[0](btex \classname{Engine} etex);
+ boxit.compressiblebrick[1](btex etex);
+ boxit.compressiblebrick[2](engineOperations);
+ boxit.compressiblebrick[3](taggedEngineTemplates);
+ boxit.compressiblebrick[4](
+ btex \begin{files}
+ CompressibleBrick.h \\
+ CompressibleBlock.h \\
+ CompressedFraction.h
+ \end{files} etex);
+
+ % Dynamic
+ boxit.dynamic[0](btex \classname{Engine<1,T,Dynamic>} etex);
+ boxit.dynamic[1](btex etex);
+ boxit.dynamic[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ layout() \\
+ create(CreateSize\_t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.dynamic[3](
+ btex \begin{lists}
+ val type T
+ \end{lists} etex);
+ boxit.dynamic[4](
+ btex \begin{files}
+ DynamicEngine.h \\
+ DynamicEngine.cpp
+ \end{files} etex);
+
+ % MultiPatch
+ boxit.multipatch[0](btex \classname{Engine >} etex);
+ boxit.multipatch[1](btex etex);
+ boxit.multipatch[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ innerDomain() \\
+ layout()
+ \end{lists} etex);
+ boxit.multipatch[3](
+ btex \begin{lists}
+ dim D \\
+ val type T \\
+ layout LT \\
+ patch PT
+ \end{lists} etex);
+ boxit.multipatch[4](
+ btex \begin{files}
+ MultiPatchEngine.h
+ \end{files} etex);
+
+ % Remote
+ boxit.remote[0](btex \classname{Engine >} etex);
+ boxit.remote[1](btex etex);
+ boxit.remote[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain()
+ \end{lists} etex);
+ boxit.remote[3](
+ btex \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.remote[4](
+ btex \begin{files}
+ RemoteEngine.h
+ \end{files} etex);
+
+ % RemoteDynamic
+ boxit.remotedynamic[0](btex \classname{Engine<1,T,Remote >} etex);
+ boxit.remotedynamic[1](btex etex);
+ boxit.remotedynamic[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ create(CreateSize\_t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.remotedynamic[3](
+ btex \begin{lists}
+ value type T
+ \end{lists} etex);
+ boxit.remotedynamic[4](
+ btex \begin{files}
+ RemoteDynamicEngine.h
+ \end{files} etex);
+
+
+ %% Position the boxes.
+ % Position the template parameters.
+ forsuffixes $=engine:
+ samewidth($[0],$[1],$[2]);
+ for t = 0 upto 1:
+ $.[t].se = $[t+1].ne;
+ $.[t].sw = $[t+1].nw;
+ endfor
+ fixsize($[0],$[1],$[2]);
+ endfor
+ forsuffixes $=engine, brick, compressiblebrick, dynamic, multipatch, remote, remotedynamic:
+ fixsize($[0]);
+ endfor
+ forsuffixes $=engine, brick, compressiblebrick, dynamic, multipatch, remote, remotedynamic:
+ fixsize($[3]);
+ $[0].ne - $[3].sw =
+ (min(0.5 xpart($[3].ne - $[3].sw), $[0].dx),
+ min(0.5 ypart($[3].ne - $[3].sw), $[0].dy));
+ endfor
+ % Position the implementation files boxes.
+ forsuffixes $=engine:
+ fixsize($[4]);
+ $[2].s = $[4].nw;
+ endfor
+
+ % Position the UML classes.
+ engine[0].c = origin;
+ xpart(brick[0].w) = xpart(dynamic[0].w);
+ xpart(compressiblebrick[3].e) = xpart(multipatch[3].e);
+ ypart(brick[0].n - compressiblebrick[0].n) = 0;
+ ypart(dynamic[0].n - multipatch[0].n) = 0;
+ ypart(compressiblebrick[0].s - multipatch[3].n) =
+ ypart(remote[0].s - remotedynamic[3].n) =
+ ypart(dynamic[0].s - remote[3].n) = yUnit;
+ numeric leftColumn;
+ leftColumn = max(xpart(brick[3].e),xpart(dynamic[3].e));
+ numeric rightColumn;
+ rightColumn = min(xpart(compressiblebrick[0].w),xpart(multipatch[0].w));
+ rightColumn - leftColumn = xUnit;
+ xpart(remote[0].n) = xpart(remotedynamic[0].n) = 0.5[leftColumn,rightColumn];
+ xpart(engine[2].s) = 0.5[leftColumn,rightColumn];
+ ypart(engine[2].s) = yUnit + max(ypart(brick[3].n),ypart(compressiblebrick[3].n));
+
+ %% Draw the boxes.
+ % Draw the UML class boxes.
+ forsuffixes $=engine:
+ for t = 0 upto 2:
+ drawboxed($[t]);
+ endfor
+ endfor
+ forsuffixes $=engine, brick, compressiblebrick, dynamic, multipatch, remote, remotedynamic:
+ for t = 0 upto 0:
+ drawboxed($[t]);
+ endfor
+ endfor
+ % Draw the template parameters.
+ forsuffixes $=engine, brick, compressiblebrick, dynamic, multipatch, remote, remotedynamic:
+ unfill bpath($[3]);
+ drawunboxed($[3]);
+ draw bpath($[3]) dashed evenly;
+ endfor
+ % Draw the implementation files.
+ forsuffixes $=engine:
+ drawunboxed($[4]);
+ endfor
+
+ % Draw arrows between classes.
+ drawarrow (xpart(remote[0].s), ypart(remotedynamic[0].n)) -- remote[0].s dashed evenly;
+ numeric middleColumn; middleColumn = 0.5[leftColumn,rightColumn];
+ drawarrow multipatch[0].w -- (middleColumn,ypart(multipatch[0].w)) dashed evenly;
+ drawarrow dynamic[0].e -- (middleColumn, ypart(dynamic[0].e)) dashed evenly;
+ drawarrow compressiblebrick[0].w -- (middleColumn,ypart(compressiblebrick[0].w)) dashed evenly;
+ drawarrow brick[0].e -- (middleColumn, ypart(brick[0].e)) dashed evenly;
+ draw compressiblebrick[0].w -- brick[0].e dashed evenly;
+ drawarrow (middleColumn,ypart(multipatch[0].w)) -- engine[2].s
+ dashed evenly;
+ draw remote[0].n .. (middleColumn,ypart(multipatch[0].w)) dashed evenly;
+
+ endfig;
+
+
+ %% Draw the Brick and CompressibleBrick boxes.
+ beginfig(2)
+ %% Create the boxes.
+ % Engine
+ boxit.engine[0](btex \classname{Engine} etex);
+ boxit.engine[1](btex etex);
+ boxit.engine[2](btex etex);
+ boxit.engine[3](
+ btex
+ \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.engine[4](
+ btex \begin{files}
+ Engine.h
+ \end{files} etex);
+
+ % Brick
+ boxit.brick[0](btex \classname{Engine} etex);
+ boxit.brick[1](btex etex);
+
+ picture engineOperations;
+ engineOperations =
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ layout()
+ \end{lists} etex;
+
+ boxit.brick[2](engineOperations);
+
+ picture taggedEngineTemplates;
+ taggedEngineTemplates =
+ btex \begin{lists}
+ dim D \\
+ value type T
+ \end{lists} etex;
+
+ boxit.brick[3](taggedEngineTemplates);
+ boxit.brick[4](
+ btex \begin{files}
+ BrickEngine.h \\
+ BrickEngine.cpp \\
+ BrickEngine.[1-7].inst.cpp \\
+ BrickBase.h \\
+ BrickBase.cpp \\
+ BrickBase[1-7].cmpl.cpp
+ \end{files} etex);
+
+ % CompressibleBrick
+ boxit.compressiblebrick[0](btex \classname{Engine} etex);
+ boxit.compressiblebrick[1](btex etex);
+ boxit.compressiblebrick[2](engineOperations);
+ boxit.compressiblebrick[3](taggedEngineTemplates);
+ boxit.compressiblebrick[4](
+ btex \begin{files}
+ CompressibleBrick.h \\
+ CompressibleBlock.h \\
+ CompressedFraction.h
+ \end{files} etex);
+
+ % Dynamic
+ boxit.dynamic[0](btex \classname{Engine<1,T,Dynamic>} etex);
+ boxit.dynamic[1](btex etex);
+ boxit.dynamic[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ layout() \\
+ create(CreateSize\_t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.dynamic[3](
+ btex \begin{lists}
+ value type T
+ \end{lists} etex);
+ boxit.dynamic[4](
+ btex \begin{files}
+ DynamicEngine.h \\
+ DynamicEngine.cpp
+ \end{files} etex);
+
+ % MultiPatch
+ boxit.multipatch[0](btex \classname{Engine >} etex);
+ boxit.multipatch[1](btex etex);
+ boxit.multipatch[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ innerDomain() \\
+ layout()
+ \end{lists} etex);
+ boxit.multipatch[3](
+ btex \begin{lists}
+ dim D \\
+ value type T \\
+ layout tag LT \\
+ patch tag PT
+ \end{lists} etex);
+ boxit.multipatch[4](
+ btex \begin{files}
+ MultiPatchEngine.h
+ \end{files} etex);
+
+ % Remote
+ boxit.remote[0](btex \classname{Engine >} etex);
+ boxit.remote[1](btex etex);
+ boxit.remote[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain()
+ \end{lists} etex);
+ boxit.remote[3](
+ btex \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.remote[4](
+ btex \begin{files}
+ RemoteEngine.h
+ \end{files} etex);
+
+ % RemoteDynamic
+ boxit.remotedynamic[0](btex \classname{Engine<1,T,Remote >} etex);
+ boxit.remotedynamic[1](btex etex);
+ boxit.remotedynamic[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ create(CreateSize\_t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.remotedynamic[3](
+ btex \begin{lists}
+ value type T
+ \end{lists} etex);
+ boxit.remotedynamic[4](
+ btex \begin{files}
+ RemoteDynamicEngine.h
+ \end{files} etex);
+
+
+ %% Position the boxes.
+ % Position the boxes within the UML class diagrams.
+ forsuffixes $=brick, compressiblebrick:
+ samewidth($[0],$[1],$[2]);
+ for t = 0 upto 1:
+ $.[t].se = $[t+1].ne;
+ $.[t].sw = $[t+1].nw;
+ endfor
+ fixsize($[0],$[1],$[2]);
+ endfor
+ % Position the template parameters.
+ forsuffixes $=brick, compressiblebrick:
+ fixsize($[3]);
+ $[0].ne - $[3].sw =
+ (min(0.5 xpart($[3].ne - $[3].sw), $[0].dx),
+ min(0.5 ypart($[3].ne - $[3].sw), $[0].dy));
+ endfor
+ % Position the implementation files boxes.
+ forsuffixes $=brick, compressiblebrick:
+ fixsize($[4]);
+ $[2].s = $[4].nw;
+ endfor
+
+ % Position the UML classes.
+ brick[0].c = origin;
+ xpart(brick[0].w - compressiblebrick[0].w) = 0;
+ ypart(compressiblebrick[3].n - brick[4].s) = -yUnit;
+
+ %% Draw the boxes.
+ % Draw the UML class boxes.
+ forsuffixes $=brick, compressiblebrick:
+ for t = 0 upto 2:
+ drawboxed($[t]);
+ endfor
+ endfor
+ % Draw the template parameters.
+ forsuffixes $=brick, compressiblebrick:
+ unfill bpath($[3]);
+ drawunboxed($[3]);
+ draw bpath($[3]) dashed evenly;
+ endfor
+ % Draw the file names.
+ forsuffixes $=brick, compressiblebrick:
+ drawunboxed($[4]);
+ endfor
+
+ endfig;
+
+
+ %% Draw the Dynamic and MultiPatch boxes.
+ beginfig(3)
+ %% Create the boxes.
+ % Engine
+ boxit.engine[0](btex \classname{Engine} etex);
+ boxit.engine[1](btex etex);
+ boxit.engine[2](btex etex);
+ boxit.engine[3](
+ btex
+ \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.engine[4](
+ btex \begin{files}
+ Engine.h
+ \end{files} etex);
+
+ % Brick
+ boxit.brick[0](btex \classname{Engine} etex);
+ boxit.brick[1](btex etex);
+
+ picture engineOperations;
+ engineOperations =
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ layout()
+ \end{lists} etex;
+
+ boxit.brick[2](engineOperations);
+
+ picture taggedEngineTemplates;
+ taggedEngineTemplates =
+ btex \begin{lists}
+ dim D \\
+ value type T
+ \end{lists} etex;
+
+ boxit.brick[3](taggedEngineTemplates);
+ boxit.brick[4](
+ btex \begin{files}
+ BrickEngine.h \\
+ BrickEngine.cpp \\
+ BrickEngine.[1-7].inst.cpp \\
+ BrickBase.h \\
+ BrickBase.cpp \\
+ BrickBase[1-7].cmpl.cpp
+ \end{files} etex);
+
+ % CompressibleBrick
+ boxit.compressiblebrick[0](btex \classname{Engine} etex);
+ boxit.compressiblebrick[1](btex etex);
+ boxit.compressiblebrick[2](engineOperations);
+ boxit.compressiblebrick[3](taggedEngineTemplates);
+ boxit.compressiblebrick[4](
+ btex \begin{files}
+ CompressibleBrick.h \\
+ CompressibleBlock.h \\
+ CompressedFraction.h
+ \end{files} etex);
+
+ % Dynamic
+ boxit.dynamic[0](btex \classname{Engine<1,T,Dynamic>} etex);
+ boxit.dynamic[1](btex etex);
+ boxit.dynamic[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ layout() \\
+ create(CreateSize\_t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.dynamic[3](
+ btex \begin{lists}
+ value type T
+ \end{lists} etex);
+ boxit.dynamic[4](
+ btex \begin{files}
+ DynamicEngine.h \\
+ DynamicEngine.cpp
+ \end{files} etex);
+
+ % MultiPatch
+ boxit.multipatch[0](btex \classname{Engine >} etex);
+ boxit.multipatch[1](btex etex);
+ boxit.multipatch[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ innerDomain() \\
+ layout()
+ \end{lists} etex);
+ boxit.multipatch[3](
+ btex \begin{lists}
+ dim D \\
+ value type T \\
+ layout tag LT \\
+ patch tag PT
+ \end{lists} etex);
+ boxit.multipatch[4](
+ btex \begin{files}
+ MultiPatchEngine.h
+ \end{files} etex);
+
+ % Remote
+ boxit.remote[0](btex \classname{Engine >} etex);
+ boxit.remote[1](btex etex);
+ boxit.remote[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain()
+ \end{lists} etex);
+ boxit.remote[3](
+ btex \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.remote[4](
+ btex \begin{files}
+ RemoteEngine.h
+ \end{files} etex);
+
+ % RemoteDynamic
+ boxit.remotedynamic[0](btex \classname{Engine<1,T,Remote >} etex);
+ boxit.remotedynamic[1](btex etex);
+ boxit.remotedynamic[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ create(CreateSize\_t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.remotedynamic[3](
+ btex \begin{lists}
+ value type T
+ \end{lists} etex);
+ boxit.remotedynamic[4](
+ btex \begin{files}
+ RemoteDynamicEngine.h
+ \end{files} etex);
+
+
+ %% Position the boxes.
+ % Position the boxes within the UML class diagrams.
+ forsuffixes $=dynamic, multipatch:
+ samewidth($[0],$[1],$[2]);
+ for t = 0 upto 1:
+ $.[t].se = $[t+1].ne;
+ $.[t].sw = $[t+1].nw;
+ endfor
+ fixsize($[0],$[1],$[2]);
+ endfor
+ % Position the template parameters.
+ forsuffixes $=dynamic, multipatch:
+ fixsize($[3]);
+ $[0].ne - $[3].sw =
+ (min(0.5 xpart($[3].ne - $[3].sw), $[0].dx),
+ min(0.5 ypart($[3].ne - $[3].sw), $[0].dy));
+ endfor
+ % Position the implementation files boxes.
+ forsuffixes $=dynamic, multipatch:
+ fixsize($[4]);
+ $[2].s = $[4].nw;
+ endfor
+
+ % Position the UML classes.
+ dynamic[0].c = origin;
+ xpart(dynamic[0].w - multipatch[0].w) = 0;
+ ypart(multipatch[3].n - dynamic[4].s) = -yUnit;
+
+ %% Draw the boxes.
+ % Draw the UML class boxes.
+ forsuffixes $=dynamic, multipatch:
+ for t = 0 upto 2:
+ drawboxed($[t]);
+ endfor
+ endfor
+ % Draw the template parameters.
+ forsuffixes $=dynamic, multipatch:
+ unfill bpath($[3]);
+ drawunboxed($[3]);
+ draw bpath($[3]) dashed evenly;
+ endfor
+ % Draw the file names.
+ forsuffixes $=dynamic, multipatch:
+ drawunboxed($[4]);
+ endfor
+
+ endfig;
+
+
+ %% Draw the Remote and Remote boxes.
+ beginfig(4)
+ %% Create the boxes.
+ % Engine
+ boxit.engine[0](btex \classname{Engine} etex);
+ boxit.engine[1](btex etex);
+ boxit.engine[2](btex etex);
+ boxit.engine[3](
+ btex
+ \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.engine[4](
+ btex \begin{files}
+ Engine.h
+ \end{files} etex);
+
+ % Brick
+ boxit.brick[0](btex \classname{Engine} etex);
+ boxit.brick[1](btex etex);
+
+ picture engineOperations;
+ engineOperations =
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ layout()
+ \end{lists} etex;
+
+ boxit.brick[2](engineOperations);
+
+ picture taggedEngineTemplates;
+ taggedEngineTemplates =
+ btex \begin{lists}
+ dim D \\
+ value type T
+ \end{lists} etex;
+
+ boxit.brick[3](taggedEngineTemplates);
+ boxit.brick[4](
+ btex \begin{files}
+ BrickEngine.h \\
+ BrickEngine.cpp \\
+ BrickEngine.[1-7].inst.cpp \\
+ BrickBase.h \\
+ BrickBase.cpp \\
+ BrickBase[1-7].cmpl.cpp
+ \end{files} etex);
+
+ % CompressibleBrick
+ boxit.compressiblebrick[0](btex \classname{Engine} etex);
+ boxit.compressiblebrick[1](btex etex);
+ boxit.compressiblebrick[2](engineOperations);
+ boxit.compressiblebrick[3](taggedEngineTemplates);
+ boxit.compressiblebrick[4](
+ btex \begin{files}
+ CompressibleBrick.h \\
+ CompressibleBlock.h \\
+ CompressedFraction.h
+ \end{files} etex);
+
+ % Dynamic
+ boxit.dynamic[0](btex \classname{Engine<1,T,Dynamic>} etex);
+ boxit.dynamic[1](btex etex);
+ boxit.dynamic[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ layout() \\
+ create(CreateSize\_t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.dynamic[3](
+ btex \begin{lists}
+ value type T
+ \end{lists} etex);
+ boxit.dynamic[4](
+ btex \begin{files}
+ DynamicEngine.h \\
+ DynamicEngine.cpp
+ \end{files} etex);
+
+ % MultiPatch
+ boxit.multipatch[0](btex \classname{Engine >} etex);
+ boxit.multipatch[1](btex etex);
+ boxit.multipatch[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ innerDomain() \\
+ layout()
+ \end{lists} etex);
+ boxit.multipatch[3](
+ btex \begin{lists}
+ dim D \\
+ value type T \\
+ layout tag LT \\
+ patch tag PT
+ \end{lists} etex);
+ boxit.multipatch[4](
+ btex \begin{files}
+ MultiPatchEngine.h
+ \end{files} etex);
+
+ % Remote
+ boxit.remote[0](btex \classname{Engine >} etex);
+ boxit.remote[1](btex etex);
+ boxit.remote[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain()
+ \end{lists} etex);
+ boxit.remote[3](
+ btex \begin{lists}
+ dim D \\
+ value type T \\
+ engine tag Tag
+ \end{lists} etex);
+ boxit.remote[4](
+ btex \begin{files}
+ RemoteEngine.h
+ \end{files} etex);
+
+ % RemoteDynamic
+ boxit.remotedynamic[0](btex \classname{Engine<1,T,Remote >} etex);
+ boxit.remotedynamic[1](btex etex);
+ boxit.remotedynamic[2](
+ btex \begin{lists}
+ Engine() \\
+ Engine(Domain) \\
+ Engine(Domain,T) \\
+ Engine(Layout) \\
+ Engine(Engine) \\
+ read(Loc) \\
+ read(int ...) \\
+ operator()(Loc) \\
+ operator()(int ...) \\
+ domain() \\
+ create(CreateSize\_t) \\
+ destroy(Domain) \\
+ destroy(Iter, Iter)
+ \end{lists} etex);
+ boxit.remotedynamic[3](
+ btex \begin{lists}
+ value type T
+ \end{lists} etex);
+ boxit.remotedynamic[4](
+ btex \begin{files}
+ RemoteDynamicEngine.h
+ \end{files} etex);
+
+
+ %% Position the boxes.
+ % Position the boxes within the UML class diagrams.
+ forsuffixes $=remote, remotedynamic:
+ samewidth($[0],$[1],$[2]);
+ for t = 0 upto 1:
+ $.[t].se = $[t+1].ne;
+ $.[t].sw = $[t+1].nw;
+ endfor
+ fixsize($[0],$[1],$[2]);
+ endfor
+ % Position the template parameters.
+ forsuffixes $=remote, remotedynamic:
+ fixsize($[3]);
+ $[0].ne - $[3].sw =
+ (min(0.5 xpart($[3].ne - $[3].sw), $[0].dx),
+ min(0.5 ypart($[3].ne - $[3].sw), $[0].dy));
+ endfor
+ % Position the implementation files boxes.
+ forsuffixes $=remote, remotedynamic:
+ fixsize($[4]);
+ $[2].s = $[4].nw;
+ endfor
+
+ % Position the UML classes.
+ remote[0].c = origin;
+ xpart(remote[0].w - remotedynamic[0].w) = 0;
+ ypart(remotedynamic[3].n - remote[4].s) = -yUnit;
+
+ %% Draw the boxes.
+ % Draw the UML class boxes.
+ forsuffixes $=remote, remotedynamic:
+ for t = 0 upto 2:
+ drawboxed($[t]);
+ endfor
+ endfor
+ % Draw the template parameters.
+ forsuffixes $=remote, remotedynamic:
+ unfill bpath($[3]);
+ drawunboxed($[3]);
+ draw bpath($[3]) dashed evenly;
+ endfor
+ % Draw the file names.
+ forsuffixes $=remote, remotedynamic:
+ drawunboxed($[4]);
+ endfor
+
+ endfig;
+ bye
Index: figures/explanation-uml-1.png
===================================================================
RCS file: explanation-uml-1.png
diff -N explanation-uml-1.png
Binary files /dev/null and explanation-uml-1.png differ
Index: figures/explanation-uml.mp
===================================================================
RCS file: explanation-uml.mp
diff -N explanation-uml.mp
*** /dev/null Fri Mar 23 21:37:44 2001
--- explanation-uml.mp Tue Feb 26 20:44:37 2002
***************
*** 0 ****
--- 1,246 ----
+ %% Oldham, Jeffrey D.
+ %% 2002Feb26
+ %% POOMA
+
+ %% Explanatory UML Diagram
+
+ %% This diagram indicates how to read a class UML diagram.
+
+ %% Assumes TEX=latex.
+
+ %% Ensure fonts are included in the output.
+ prologues := 2; % >= 2 for PostScript
+
+ input boxes;
+ input box-macros;
+ input uml;
+
+ verbatimtex
+ \documentclass[10pt]{article}
+ \usepackage{amsmath}
+ \input{macros.ltx}
+ \usepackage{times}
+ \usepackage{mathptm}
+ \newlength{\cnw} % Required to use \classnameWidth and \emptyBox
+ \begin{document}
+ etex
+
+
+ beginfig(1)
+ %% Create the boxes.
+ % Domain
+ boxit.domain[0](btex \classname{Classname1} etex);
+ boxit.domain[1](btex etex);
+ boxit.domain[2](
+ btex \begin{lists}
+ member function~1 \\
+ member function~2 \\
+ member function~3
+ \end{lists} etex);
+ boxit.domain[3](
+ btex
+ \begin{lists}
+ template parameter T
+ \end{lists} etex);
+ boxit.domain[4](
+ btex \begin{files}
+ implementation file~1 \\
+ implementation file~2
+ \end{files} etex);
+
+ % Domain<1>
+ boxit.domainOne[0](btex \classname{Domain<1>} etex);
+ boxit.domainOne[1](btex etex);
+ boxit.domainOne[2](
+ btex \begin{lists}
+ long length() \\
+ int first() \\
+ int last() \\
+ int min() \\
+ int max() \\
+ Domain<1>::iter-\breakLine ator begin() \\
+ Domain<1>::iter-\breakLine ator end() \\
+ \end{lists} etex);
+
+ % Domain<1>::iterator
+ boxit.domainOneIterator[0](btex \classname{Domain<1>::iterator} etex);
+ boxit.domainOneIterator[1](btex etex);
+ boxit.domainOneIterator[2](
+ btex \begin{lists}
+ operator*() \\
+ operator++() \\
+ operator->() \\
+ \end{lists} etex);
+ boxit.domainOneIterator[4](
+ btex \begin{files}
+ DomainIterator.h
+ \end{files} etex);
+
+ % Loc
+ boxit.loc[0](btex \classname{Classname2} etex);
+ boxit.loc[1](btex \emptyBox{Interval<1>} etex);
+ boxit.loc[2](btex etex);
+ boxit.loc[3](
+ btex \begin{lists}
+ template parameter T
+ \end{lists} etex);
+ boxit.loc[4](
+ btex \begin{files}
+ implementation file~a
+ \end{files} etex);
+
+ % Loc<1>
+ boxit.locOne[0](btex \classname{Classname2<1>} etex);
+ boxit.locOne[1](btex \emptyBox{Interval<1>} etex);
+ boxit.locOne[2](btex etex);
+
+ % Interval
+ boxit.interval[0](btex \classname{Interval} etex);
+ boxit.interval[1](btex \emptyBox{Interval<1>} etex);
+ boxit.interval[2](btex etex);
+ boxit.interval[3](
+ btex
+ \begin{lists}
+ dim D
+ \end{lists} etex);
+ boxit.interval[4](
+ btex \begin{files}
+ Interval.h \\
+ DomainTraits.Interval.h
+ \end{files} etex);
+
+ % Interval<1>
+ boxit.intervalOne[0](btex \classname{Interval<1>} etex);
+ boxit.intervalOne[1](btex \emptyBox{Interval<1>} etex);
+ boxit.intervalOne[2](btex etex);
+
+ % Range
+ boxit.rangeBox[0](btex \classname{Range} etex);
+ boxit.rangeBox[1](btex \emptyBox{Interval<1>} etex);
+ boxit.rangeBox[2](btex etex);
+ boxit.rangeBox[3](btex
+ \begin{lists}
+ dim D
+ \end{lists} etex);
+ boxit.rangeBox[4](
+ btex \begin{files}
+ Range.h \\
+ DomainTraits.Range.h
+ \end{files} etex);
+
+ % Range<1>
+ boxit.rangeOne[0](btex \classname{Range<1>} etex);
+ boxit.rangeOne[1](btex \emptyBox{Interval<1>} etex);
+ boxit.rangeOne[2](btex etex);
+
+ % Grid
+ boxit.grid[0](btex \classname{Grid} etex);
+ boxit.grid[1](btex \emptyBox{Interval<1>} etex);
+ boxit.grid[2](btex etex);
+ boxit.grid[3](btex
+ \begin{lists}
+ dim D
+ \end{lists} etex);
+ boxit.grid[4](
+ btex \begin{files}
+ Grid.h \\
+ DomainTraits.Grid.h
+ \end{files} etex);
+
+ % Grid<1>
+ boxit.gridOne[0](btex \classname{Grid<1>} etex);
+ boxit.gridOne[1](btex \emptyBox{Interval<1>} etex);
+ boxit.gridOne[2](btex etex);
+
+ %% Position the boxes.
+ % Position the boxes within the UML class diagrams.
+ forsuffixes $=domain, domainOne, domainOneIterator, loc, locOne, interval, intervalOne, rangeBox, rangeOne, grid, gridOne:
+ samewidth($[0],$[1],$[2]);
+ for t = 0 upto 1:
+ $.[t].se = $[t+1].ne;
+ $.[t].sw = $[t+1].nw;
+ endfor
+ fixsize($[0],$[1],$[2]);
+ endfor
+ % Position the template parameters.
+ forsuffixes $=domain, loc, interval, rangeBox, grid:
+ fixsize($[3]);
+ $[0].ne - $[3].sw =
+ (min(0.5 xpart($[3].ne - $[3].sw), $[0].dx),
+ min(0.5 ypart($[3].ne - $[3].sw), $[0].dy));
+ endfor
+ % Position the implementation files boxes.
+ forsuffixes $=domain, domainOneIterator, loc, interval, rangeBox, grid:
+ fixsize($[4]);
+ $[2].s = $[4].nw;
+ endfor
+
+ % Position the UML classes.
+ domain[0].c = origin;
+ domainOne[0].nw - domain[0].ne = (xUnit,0);
+ domainOneIterator[0].nw - domainOne[0].ne = (xUnit,0);
+ domain[2].s - loc[0].n = (0, max(0, ypart(domain[2].s - domainOne[2].s)));
+ loc[2].s - locOne[0].n = (0, 2yUnit);
+ interval[0].nw - loc[0].ne = (xUnit, 0);
+ interval[2].s - intervalOne[0].n = (0, yUnit);
+ rangeBox[0].nw - interval[0].ne = (2xUnit, 0);
+ rangeBox[2].s - rangeOne[0].n = (0, yUnit);
+ grid[0].nw - rangeBox[0].ne = (xUnit, 0);
+ grid[2].s - gridOne[0].n = (0, yUnit);
+
+ %% Draw the boxes.
+ % Draw the UML class boxes.
+ forsuffixes $=domain, loc:
+ for t = 0 upto 2:
+ drawboxed($[t]);
+ endfor
+ endfor
+ forsuffixes $=locOne:
+ for t = 0 upto 0:
+ drawboxed($[t]);
+ endfor
+ endfor
+ % Draw the template parameters.
+ forsuffixes $=domain, loc:
+ unfill bpath($[3]);
+ drawunboxed($[3]);
+ draw bpath($[3]) dashed evenly;
+ endfor
+ % Draw the file names.
+ forsuffixes $=domain, loc:
+ drawunboxed($[4]);
+ endfor
+
+ % Draw arrows between classes.
+ drawarrow locOne[0].n -- loc[2].s dashed evenly;
+
+ % Draw lines between classes.
+ drawDiscriminator(domain[2].s, 0);
+ numeric foo; foo = 0.7yUnit;
+ forsuffixes $=loc:
+ draw $[0].n -- ($[0].n+(0,foo));
+ endfor
+ z0 = domain[2].s - (0,discriminatorScale);
+ draw z0 -- (x0, ypart(loc[0].n+(0,foo)));
+
+ % Add explanatory labels.
+ label.rt(btex Public data members, if any, would be listed here. etex,
+ domain[1].e);
+ label.rt(btex Public member functions, if any, are listed here. etex,
+ domain[2].e);
+ label.rt(btex This class adds no new public member functions. etex,
+ loc[2].e);
+ label.lrt(btex Template parameters are listed in dashed boxes. etex,
+ 0.4[loc[3].sw,loc[3].s]);
+ label.rt(btex Files implementing the class etex, loc[4].e);
+ label.rt(btex A dashed arrow indicates an instantiated class. etex,
+ 0.7[loc[2].s,locOne[0].n]);
+ label.lft(btex \begin{tabular}{l}Class specialization is indicated by\\ an arrow with a large triangle.\end{tabular} etex,
+ 0.5[domain[2].s,loc[0].n]);
+ label.rt(btex This class's details are presented elsewhere. etex,
+ locOne[0].e);
+
+ endfig;
+
+
+ bye
Index: figures/macros.ltx
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/figures/macros.ltx,v
retrieving revision 1.4
diff -c -p -r1.4 macros.ltx
*** figures/macros.ltx 2002/01/31 21:29:58 1.4
--- figures/macros.ltx 2002/02/27 03:44:37
***************
*** 42,44 ****
--- 42,83 ----
% Avoid a problem with dvitomp and ligatures.
\newcommand{\avoidFi}{F\mbox{}i}%
% Avoid a problem with dvitomp and ligatures.
+
+ %% UML Macros.
+
+ % Produce a class's name, presumbly at the top of a UML class box.
+ % input <- class's name
+ \newcommand{\classname}[1]{\strut\texttt{#1}}
+
+ % Produce a class's name, presumbly at the top of a UML class box,
+ % with a width equal to the specified class's name.
+ \newcommand{\classnameWidth}[2]{\strut\settowidth{\cnw}{\classname{#2}}\makebox[\cnw]{\classname{#1}}}%
+ % Requires: 1. class's name
+ % 2. class name to set the width
+
+ % Produce an empty box with width equal to specified class name.
+ \newcommand{\emptyBox}[1]{\settowidth{\cnw}{\classname{#1}}\makebox[\cnw]{\strut}}%
+ % Requires: 1. class name to set width
+
+ % Produce a list of operations, attributes, or template parameters.
+ % The contents should be acceptable for a tabular{l} environment.
+ % These are displayed in small typewriter text.
+ \newenvironment{lists}%
+ {\ttfamily \small \begin{tabular}{l}}%
+ {\end{tabular}}
+
+ % Break one line and indent following line.
+ \newcommand{\breakLine}{\\ \hspace{1ex}}
+
+ % Produce a list of files.
+ % The contents should be acceptable for a tabular{l} environment.
+ % These are displayed in scriptsize typewriter text.
+ \newenvironment{files}%
+ {\ttfamily \scriptsize \begin{tabular}{l}}%
+ {\end{tabular}}
+
+
+ % Print bound parameters.
+ \newcommand{\binder}[1]{\guillemotleft #1\guillemotright}%
+ % Requires: 1. bound parameters
+ % inclusion of 'aeguill' package
Index: figures/uml.mp
===================================================================
RCS file: uml.mp
diff -N uml.mp
*** /dev/null Fri Mar 23 21:37:44 2001
--- uml.mp Tue Feb 26 20:44:37 2002
***************
*** 0 ****
--- 1,28 ----
+ %% Oldham, Jeffrey D.
+ %% 2002Feb19
+ %% Pooma
+
+ %% MetaPost Macros for UML Diagrams
+
+ %% Discriminator
+
+ %% Connects specialized classes to general class. The triangle points
+ %% up and may be scaled appropriately.
+ path discriminator;
+ discriminator = origin -- ((1,0) rotated -120) -- ((1,0) rotated -60) -- cycle;
+
+ numeric discriminatorScale; discriminatorScale = 0.5cm;
+
+ % The location is the top of the triangle
+ vardef drawDiscriminator(expr location, rotation) =
+ draw discriminator scaled discriminatorScale rotated rotation shifted location;
+ enddef;
+
+
+ %% Spacing definitions
+ numeric unit; unit = 1cm;
+ numeric xUnit; xUnit = unit;
+ numeric yUnit; yUnit = unit;
+
+ % Arrowhead modifier.
+ ahlength := 2ahlength;
Index: programs/Sequential/initialize-finalize-annotated.patch
===================================================================
RCS file: /home/pooma/Repository/r2/docs/manual/programs/Sequential/initialize-finalize-annotated.patch,v
retrieving revision 1.1
diff -c -p -r1.1 initialize-finalize-annotated.patch
*** programs/Sequential/initialize-finalize-annotated.patch 2002/01/31 22:20:43 1.1
--- programs/Sequential/initialize-finalize-annotated.patch 2002/02/27 03:44:37
***************
*** 1,20 ****
! *** initialize-finalize.cpp Thu Jan 24 11:14:13 2002
! --- initialize-finalize-annotated.cpp Thu Jan 24 11:14:17 2002
***************
! *** 1,4 ****
! #include "Pooma/Pooma.h"
! #include
int main(int argc, char *argv[])
! --- 1,5 ----
! +
! #include "Pooma/Pooma.h"
! #include <iostream>
int main(int argc, char *argv[])
! ***************
! *** 11,12 ****
! --- 12,14 ----
return 0;
}
+
--- 1,35 ----
! *** /home/oldham/pooma/pooma1/examples/Manual/Sequential/initialize-finalize.cpp Mon Feb 25 13:11:58 2002
! --- initialize-finalize-annotated.cpp Mon Feb 25 13:40:48 2002
***************
! *** 1,14 ****
! ! #include "Pooma/Pooma.h"
! #include
int main(int argc, char *argv[])
! {
! // Prepare the Pooma library for execution.
! ! Pooma::initialize(argc,argv);
!
! std::cout << "Hello, Pooma." << std::endl;
!
! // Tell the Pooma library execution has finished.
! ! Pooma::finalize();
! return 0;
! }
! --- 1,16 ----
! !
! ! #include "Pooma/Pooma.h"
! #include <iostream>
int main(int argc, char *argv[])
! {
! // Prepare the Pooma library for execution.
! ! Pooma::initialize(argc,argv);
!
! std::cout << "Hello, Pooma." << std::endl;
!
! // Tell the Pooma library execution has finished.
! ! Pooma::finalize();
return 0;
}
+