文件列表:

benchmarks (0, 2000-05-10)
benchmarks\ABCTest (0, 2000-05-10)
benchmarks\ABCTest\ABC.cpp (2812, 1999-11-03)
benchmarks\ABCTest\ABC.h (10234, 1999-11-03)
benchmarks\ABCTest\ABCInC.c (2476, 1999-11-03)
benchmarks\Acoustic2d (0, 2000-05-10)
benchmarks\Acoustic2d\Acoustic2d.cpp (2927, 1999-11-03)
benchmarks\Acoustic2d\Acoustic2dInC.c (2900, 1999-11-03)
benchmarks\Acoustic2d\Acoustic2dInC.h (7913, 1999-11-03)
benchmarks\Acoustic2d\Acoustic2dInCppTran.h (6694, 1999-11-03)
benchmarks\Acoustic2d\Acoustic2dInP2.h (6341, 1999-11-03)
benchmarks\BlitzLoops (0, 2000-05-10)
benchmarks\BlitzLoops\Loop18.cpp (3056, 1999-11-03)
benchmarks\BlitzLoops\Loop18InC.c (2363, 1999-11-03)
benchmarks\BlitzLoops\Loop18InC.h (4847, 1999-11-03)
benchmarks\BlitzLoops\Loop18InCppTran.h (4453, 1999-11-03)
benchmarks\BlitzLoops\Loop18InP2.h (4347, 1999-11-03)
benchmarks\Doof2d (0, 2000-05-10)
benchmarks\Doof2dField (0, 2000-05-10)
benchmarks\Doof2dField\cpptran1.cpp (2176, 1999-11-03)
benchmarks\Doof2dField\cpptran2.cpp (2194, 1999-11-03)
benchmarks\Doof2dField\Doof2dField.cpp (2637, 1999-11-03)
benchmarks\Doof2dField\Doof2dField.h (13734, 1999-11-03)
benchmarks\Doof2dField\pooma1.cpp (2165, 1999-11-03)
benchmarks\Doof2dField\pooma1c.cpp (2179, 1999-11-03)
benchmarks\Doof2dField\pooma2.cpp (2346, 1999-11-03)
benchmarks\Doof2dField\pooma3.cpp (2203, 1999-11-03)
benchmarks\Doof2dGMP (0, 2000-05-10)
benchmarks\Doof2dGMP\cpptran1.cpp (2178, 1999-11-03)
benchmarks\Doof2dGMP\cpptran2.cpp (2196, 1999-11-03)
benchmarks\Doof2dGMP\Doof2dGMP.cpp (2639, 1999-11-03)
benchmarks\Doof2dGMP\Doof2dGMP.h (13720, 1999-11-03)
benchmarks\Doof2dGMP\pooma1.cpp (2167, 1999-11-03)
benchmarks\Doof2dGMP\pooma1c.cpp (2181, 1999-11-03)
benchmarks\Doof2dGMP\pooma2.cpp (2346, 1999-11-03)
benchmarks\Doof2dGMP\pooma3.cpp (2205, 1999-11-03)
benchmarks\Doof2dUMP (0, 2000-05-10)
benchmarks\Doof2dUMP\cpptran1.cpp (2174, 1999-11-03)
benchmarks\Doof2dUMP\cpptran2.cpp (2192, 1999-11-03)
benchmarks\Doof2dUMP\Doof2dUMP.cpp (2637, 1999-11-03)
... ...

/******************************************************************* * * * POOMA Release Notes * * Version 2.2.0 * * * ******************************************************************* * For installation help, see the relevant INSTALL.* file * * * * For licensing info, see LICENSE (or LICENSE.TXT on Windows) * * * * For the people who created POOMA, see CREDITS (CREDITS.TXT) * * * * For a tutorial on using POOMA, open html/index.html in your * * web browser. * * * * For more information, including updates and new releases, * * see http://www.acl.lanl.gov/pooma * * * * For other neat software packages from the ACL, * * see http://www.acl.lanl.gov/software * * * * For help, reporting bugs, and making suggestions, please * * send e-mail to pooma@acl.lanl.gov * *******************************************************************/ //////////////////////////////////////////////////////////////////// RELEASE NOTES v2.2.0 //////////////////////////////////////////////////////////////////// OBJECT I/O ---------- Binary I/O is now experimentally supported. The first level of the design is comprised of a set of classes called the storage classes that are transparent to users. They organize any given storage resource into byte records. The system does not necessarily know the internal structure of a byte record, only its length in bytes. Records are elements of byte arrays. Each array is independently accessible within a storage resource and each record or element of a byte array is also independently addressable. A range of elements within a byte array can be read or written in one operation. These byte arrays are automatically extended whenever an operation writes past the current number of elements. Arrays are members of a collection called a storage set which serves as the logical interface to storage in terms of arrays. The physical storage in this implementation is a disk file, but a storage set is an abstraction barrier that need not be associated with a file in general. For example, future implementations may support storage sets based on databases or remote application resources. The second level is made up of the object storage classes. These classes view storage as a set of typed objects called an object set. Any instance of a type supported by the I/O system can be stored along with a descriptive label in one operation. Object sets can be queried to reveal the number of objects contained, the types of objects contained, the number of objects of each type, and the labels of each object. A single operation is sufficient to retrieve an object given either its name, or its instance ID which is equivalent to its position in the list of object instances for a given type. The storage of specific types is enabled by specializations of two generic classes: object serializers and object adapters. Storage adapters are currently hand-crafted, so there are only a few basic types supported at this time. This release supports standard native binary I/O. Future releases may support storage using the HDF5 format. NEW DEBUG FUNCTIONS ------------------- The POOMA PrintArray class has templated print() methods that print readable formatted output of large containers of values. It provides methods for controlling formatting parameters like the number of values per line, numeric format, and precision. The global dbprint() template functions are a procedural interface around PrintArray, used with a set of global functions for setting common formatting parameters shared by all subsequent dbprint() invocations. These are useful shorthand for ASCII output from source code, but more importantly, they provide a means to set up nontemplate output functions callable interactively from within a debugger. This is helpful for debugging POOMA programs by examining values from Arrays and other containers. NEW BUILD OPTIONS ----------------- The POOMA 2.2.0 configure script now supports the new options: --shared: create a shared version of the POOMA library, libPooma.so --static: create a static version of the POOMA library, libPooma.a (default) BUGS FIXED ---------- (1) Added missing initialize() functions to ConstField and Field. Now, there is a corresponding initialize() for every construct. The initialize() functions are written so that the code Field<...> f(args); and Field<...> f; f.initialize(args); leaves the object f in an identical state. (2) Fixed an assertion failure that resulted from retargeting component boundary conditions (e.g. created with ComponentBC<1, ZeroFaceBC>). (3) Fixed memory affinity of patches in a multi-patch array when running multithreaded. //////////////////////////////////////////////////////////////////// RELEASE NOTES v2.1.1 //////////////////////////////////////////////////////////////////// IMPROVED FIELD PERFORMANCE -------------------------- We have inlined functions related to indexing and ensured that domain calculations do not make their way into inner loops. The result is a factor of 6 speed-up in some kernels, particularly with compilers without the sophisticated optimization machinery of KCC. INITIALIZE FUNCTION BEHAVIOR ---------------------------- The Array, DiscreteGeometry, Mesh, and Field classes have been equipped with a sets of initialize() member functions that take the same arguments as constructors. The most basic usage is to initialize an object that has been build with a default constructor: Array<2> a; a.initialize(10, 10); // Create 10 x 10 array In prior POOMA versions, the initialize function could not be called with an already initialized object either from a constructor or a previous initialize() call. However, now, inialize() can be called multiple times: Array<2> a; a.initialize(10, 10); // Create 10 x 10 array a.initialize(20, 20); // Change the size of a to 20 x 20 Finally, note that since initialize() encompasses the behavior of Array's changeSize() member function, this function has been deleted. BOUNDARY CONDITIONS ------------------- POOMA 2.1.1 fixes problems associated with initializing a Field with a set of boundary conditions taken from another Field of the same type. The problem is due to the fact that, for efficiency and expressibility, boundary condition objects store a view of the Field they are to modify. Therefore, copying a BCondList from one Field to another previously resulted in the original Field continuing to be updated. This behavior was also seen with Field::makeOwnCopy(). Now, boundary conditions can be retargeted to a new Field. To support this, all concrete boundary condition classes must now supply a retarget() member function as illustrated by the code: template<> class BCond : public FieldBCondBase { public: BCond(const FieldType_t &f, const PositionFaceBC &bc); void applyBoundaryCondition(); BCond *retarget(const FieldType_t &f) const { return new BCond(f, bc_m); } private: PositionFaceBC bc_m; }; COMPRESSIBLE BRICK ENGINES -------------------------- The algorithm for attempting to compress a block has been modified. It now performs the check in two stages. First, if it has failed to compress before, it will compare the previously unequal elements to see if they are still unequal. If they are, it is done. If not, before doing the exhaustive search (comparing all elements to the first) it will check a few random values. Also, added --pooma-nocompress runtime flag. This disables compression of CompressibleBrick Engines, causing them to behave like Bricks. Useful for comparing performance (and correctness) of code that uses CompressibleBricks. GENERALIZED COMPONENT ACCESS ---------------------------- It is now possible to use the comp() member function of arrays to create views of arrays that reference members of user defined structures. For example, you can now write: struct State { double pressure; ... }; POOMA_COMPONENT_ACCESS(State,Pr,double,pressure) Array<2,State> a; a.comp(Pr()) = ...; See the code in examples/Components/Shock for an illustration. ENHANCED TENSOR FUNCTIONALITY ----------------------------- In addition to the Full class, we now provide three classes to use for the Tensor class' EngineTag parameter, representing non-full storage according to special symmetries: Symmetric, Antisymmetric, Diagonal The Antisymmetric class defines the diagonal elements to be zero, with negatively reflected values across the diagonal. Symmetric defines positively-reflected values across the diagonal, which can have nonzero elements. Diagonal defines zero everywhere except on the diagonal. Tensors declared using these EngineTag classes will only store the minimum required number of values, and use the symmetry properties to compute the reflected or zero values. Several new functions on Tensors return scalar or Tensor values. These also act on Arrays/Fields of Tensors: T trace(Tensor) - Sum of diagonal elements T det(Tensor) - Determinant of the tensor Tensor transpose(Tensor) - transpose(i,j) = input(j,i) template Tensor symmetrize(Tensor) - Applies appropriate symmetrizing operator. NEW BENCHMARKS AND EXAMPLES --------------------------- benchmarks/Doof2dField - same as Doof2dUMP except with Fields (to measure Field abstraction penalty). examples/Laplace2 - same as Laplace example except the boundary conditions are associated with the operator rather than the Field. examples/Components/Shock - example of how to use the new component access capabilities. //////////////////////////////////////////////////////////////////// RELEASE NOTES v2.1.0 //////////////////////////////////////////////////////////////////// SGI COMPILER VERSION 7.3 ------------------------ For users compiling with the native SGI C++ compiler on IRIX platforms, please note that version 7.3 of the SGI C++ compiler is required to compile POOMA II. Earlier versions do not provide the necessary language features. One problem you may encounter is that a common patch applied to the 7.3 compiler (patch 3659) actually is harmful to its health and should be removed in order to compile POOMA. NOTES ON RUNNING IN PARALLEL ---------------------------- Parallel operation using the SMARTS library is only supported on SGI computers running IRIX when compiled with the KCC compiler and SMARTS version 1.0. An upcoming release of SMARTS will include modifications to support more platforms and compilers and to improve performance. The new differential operators below are an experimental feature in POOMA 2.1.0 which currently does not work correctly with the parallel or the serial asynchronous schedulers (configure options --parallel --sched async or --parallel --sched serialAsync). Serial code should work for all engine types. These limitations will be addressed in a future version of POOMA. NEW GEOMETRY, MESH, AND COORDINATE SYSTEM CLASSES ------------------------------------------------- The POOMA 2.1.0 Field class (described below) is templated on a Geometry type. The Geometry concept provides metric and position data, and performs various geometry-specific services for Field. Currently, Pooma includes two models for a Geometry concept: o DiscreteGeometry - combines mesh and centering information o NoGeometry - only includes positions at which the field is defined DiscreteGoemetry depends on a Centering concept. Pooma II meshes (see below) do not know about centering - it enters at the geometry level. Centering is simply a mechanism to determine where the points of the Field are defined, relative to the mesh points. Pooma 2.1.0 includes the following centerings: o Cell - Field defined at cell centers o Vert - Field defined at mesh vertices o RectilinearCentering - Combination Vert/Cell centerings such as face and edge centering - Componentwise centerings, where different components of a multicomponent Field element type have different centerings o NoCentering - No centering information available. The Mesh concept provides a discrete set of points in a particular coordinate system, and can provide certain information about the mesh, such as mesh positions, spacings, cell volumes, etc. POOMA 2.1.0 includes two models for the Mesh concept: o UniformRectilinearMesh - constant spacing logically-rectangular mesh o RectilinearMesh - non-constant spacing logically-rectangular mesh The CoordinateSystem concept is used by meshes and geometries to perform various coordinate-specific services and calculations. POOMA 2.1.0 includes two models for the CoordinateSystem concept: o Cartesian - Dim dimensional cartesian system o Cylindrical (Dim == 3) o Polar (Dim == 2) o RhoZ (Dim == 2) o Rho (Dim == 1) - variations on cylindrical coordinates in different dimensions. See the tutorials for more information on using the new geometry, mesh, and coordinate system classes and concepts. NEW FIELD AND CONSTFIELD CLASSES -------------------------------- POOMA 2.1.0 introduces the Field class, which represents a set of points in a coordinate space, and a set of values defined at those points. The Field class takes a Geometry template parameter to represent the set of coordinate-space points: template class Field; The T and EngineTag parameters correspond exactly to the same template parameters in the Array class. Currently, we are only providing discrete classes to use for the Geometry parameter (see below). In these discrete cases, the elements of the Field are indexed like N-dimensional Array elements. Field has essentially all of the syntax and semantics of Array, including scalar-indexing and data-parallel expressions. The ConstField class, from which Field inherits, is a read-only version of Field. The Field::x() function returns an Array of position vectors; this is the set of coordinate-space points on which the Field is defined. (If you think of the Field like a mathematical function, Field::x() is the domain of the function; the Field element values themselves are the range.) Field supports automatic boundary conditions, via global guard-element layers; boundary-condition objects associated with the Field object fill in the guard elements to enforce various Dirichlet, Neumann, and periodic boundary conditions. To support this, the Field class for discrete geometries has two array domains, Field::totalDomain() and Field::physicalDomain(). The first of these two includes the global guard layers, if there are any. POOMA 2.1.0 provides a set of boundary-condition classes for Fields using Geometry classes based on (logically) rectilinear meshes, and provides a BCondList container for storing sets of boundary conditions to associate together with a Field or set of Fields sharing the same Geometry. These classes support boundary conditions expressed componentwise on Fields of multicomponent elemental types like Vectors or Tensors. Expressions involving Fields will automatically invoke the automatic boundary conditions associated with the Field whenever the expression tries to read from the global guard elements, and they haven't already been filled using up-to-date information. See the tutorials for more information on using the new Field class. NEW DIFFERENTIAL OPERATORS FOR FIELDS (EXPERIMENTAL) ---------------------------------------------------- POOMA 2.1.0 now includes all the POOMA R1 differential and averaging operators, with a new interface and new implementation using FieldStencil functors (also new in POOMA 2.1.0). The user interface to these is the following global templated functions: o div<>() o grad<>() o average<>() These have specializations for taking as arguments Fields on DiscreteGeometry with certain centerings relative to UniformRectilinearMesh or RectilinearMesh meshes. Each function requires the caller to explicitly specify the output-centering type, plus provide a Field as the input argument. For example: // Take the divergence of a Field F2 with some centering (Cell or // Vert, for example), and generate a Cell-centered Field F1. F1 = div(F2); The div<>() function takes as input argument a Field of Vector or Tensor elements and returns a Field of scalar or Vector elements. Input centering can be Cell or Vert, as can output centering, in any combination. The grad<>() function takes as input argument a Field of scalar or Vector elements and returns a Field of Vector or Tensor elements. Input/output centerings are any combination of Cell and Vert. The average<>() function is similar, except that it has prototypes including a 2nd argument to be used as a weighting Field for the averaging calculation. NEW PARTICLE CLASSES -------------------- A new Particles class has been added to POOMA II that can store a heterogenous set of particle "attributes" (DynamicArray objects that each store a list of data for some quantity) that are kept synchronized by a user-selected particle layout. Particles objects also can store a list of boundary conditions for the particle attributes. POOMA 2.1.0 includes the following particle layout classes: o SpatialLayout: Keeps particles distributed among a set of patches based on some "position" attribute, in conjunction with a provided Geometry and patch layout. o UniformLayout: Keeps particles distributed among a set of patches so that each patch stores an equal number of particles (or as close as is possible). See the tutorials for more information on using the new Particles class. NEW PARTICLE BOUNDARY CONDITION CLASSES --------------------------------------- POOMA 2.1.0 provides generalized boundary conditions or filters that can be applied to Particle ... ...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：