From oldham at codesourcery.com Mon Jul 1 22:26:57 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Mon, 1 Jul 2002 15:26:57 -0700 Subject: [pooma-dev] [PATCH] C++ correctness fixes In-Reply-To: ; from rguenth@tat.physik.uni-tuebingen.de on Thu, Jun 27, 2002 at 01:41:54PM +0200 References: Message-ID: <20020701152657.B17990@codesourcery.com> On Thu, Jun 27, 2002 at 01:41:54PM +0200, Richard Guenther wrote: > Hi! > > The attached patch provides some fixes for C++ correctness to either > avoid warnings or, in case of ContextMapper.h, fix the destructor being > not virtual. > > All of these were catched by gcc3.1, pooma r2 now compiles without > warnings [apart from using <*.h> rather than <*> includes]. > > Richard. > > Btw. is it considered good practice to post patches to this mailinglist? > I have (after some cleanup) more stuff pending, like introducing HDF5 > I/O classes and activation of CoordinateSystem support (much like the one > from pooma-2.3.0). For my own development I set up a bitkeeper repository > to mirror the CVS one, but its not pullable from outside our institute. Thanks for the submission. I read it, approved it, and committed it. Yes, it is appropriate to send patches to the mailing list. The patch process is: 1) Create a patch. 2) Check the patch by compiling the POOMA library and, if appropriate, POOMA test cases. For example, if changing a Field feature, run all the src/Field/tests/ tests. 3) Create a ChangeLog entry associated with the patch. (See the attached file.) Be sure to list how the patch was tested. 4) Send to either the pooma-dev email list or to an individual for comments and possible approval. 5) Commit the patch. Be sure to note who approved the patch. 6) Send the committed patch to the pooma-dev email list. FWIW, I'm used to reading the output of 'cvs diff' using this ~/.cvsrc: update -d -P diff -c -p -N cvs -z6 I'm glad you are using POOMA. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- 2002Jul01 Richard Guenther (Jeffrey D. Oldham (oldham at codesourcery.com) typed this ChangeLog.) * Field/NearestNeighbors.h (NearestNeighborClass::operator()): Add 'typename'. (NearestNeighborClass::nearestNeighbors): Likewise. * Field/DiffOps/FieldShiftEngine.h (FieldShiftSimple::make): Likewise. * Field/FieldEngine/FieldEngine.h (FieldEngine::FieldEngine): Reorder constructor initializers to reflect member declaration order. * Partition/ContextMapper.h (ContextMapper::~ContextMapper): New virtual destructor for class with virtual functions. Tested using g++ 3.0.3 on sequential Linux by compiling Pooma library. Approved by Jeffrey D. Oldham. -------------- next part -------------- Index: src/Field/NearestNeighbors.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Field/NearestNeighbors.h,v retrieving revision 1.2 diff -c -p -r1.2 NearestNeighbors.h *** src/Field/NearestNeighbors.h 2001/10/06 00:39:19 1.2 --- src/Field/NearestNeighbors.h 2002/07/01 22:11:47 *************** public: *** 129,135 **** // Determine nearest neighbors for each output value. ! for (Answer_t::size_type outputIndex = 0; outputIndex < outputCentering.size(); ++outputIndex) answer[outputIndex] = nearestNeighbors(inputPositions, --- 129,135 ---- // Determine nearest neighbors for each output value. ! for (typename Answer_t::size_type outputIndex = 0; outputIndex < outputCentering.size(); ++outputIndex) answer[outputIndex] = nearestNeighbors(inputPositions, *************** public: *** 173,179 **** // Determine nearest neighbors for each field offset. ! for (FieldOffsetList_t::size_type folIndex = 0; folIndex < outputCentering.size(); ++folIndex) { PInsist(fieldOffsetList[folIndex].subFieldNumber() < outputCentering.size(), --- 173,179 ---- // Determine nearest neighbors for each field offset. ! for (typename FieldOffsetList_t::size_type folIndex = 0; folIndex < outputCentering.size(); ++folIndex) { PInsist(fieldOffsetList[folIndex].subFieldNumber() < outputCentering.size(), *************** private: *** 238,244 **** FieldOffset_vt answerHolder; if (IntraCellOnly) { ! for (MinimumSet::size_type minIndex = 0; minIndex < minimumSet.size(); ++minIndex) answerHolder.push_back(FieldOffset_t(Loc(0), --- 238,244 ---- FieldOffset_vt answerHolder; if (IntraCellOnly) { ! for (typename MinimumSet::size_type minIndex = 0; minIndex < minimumSet.size(); ++minIndex) answerHolder.push_back(FieldOffset_t(Loc(0), *************** private: *** 246,252 **** } else { FieldOffset_vt partialAnswer; ! for (MinimumSet::size_type minIndex = 0; minIndex < minimumSet.size(); ++minIndex) { --- 246,252 ---- } else { FieldOffset_vt partialAnswer; ! for (typename MinimumSet::size_type minIndex = 0; minIndex < minimumSet.size(); ++minIndex) { Index: src/Field/DiffOps/FieldShiftEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Field/DiffOps/FieldShiftEngine.h,v retrieving revision 1.1 diff -c -p -r1.1 FieldShiftEngine.h *** src/Field/DiffOps/FieldShiftEngine.h 2001/08/30 01:15:09 1.1 --- src/Field/DiffOps/FieldShiftEngine.h 2002/07/01 22:11:48 *************** struct FieldShiftSimple *** 435,441 **** const std::vector > &vs1, const Centering ¢ering) { ! typedef std::vector >::size_type size_type; // Create a model field with the new centering. --- 435,441 ---- const std::vector > &vs1, const Centering ¢ering) { ! typedef typename std::vector >::size_type size_type; // Create a model field with the new centering. Index: src/Field/FieldEngine/FieldEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Field/FieldEngine/FieldEngine.h,v retrieving revision 1.2 diff -c -p -r1.2 FieldEngine.h *** src/Field/FieldEngine/FieldEngine.h 2001/10/04 22:06:54 1.2 --- src/Field/FieldEngine/FieldEngine.h 2002/07/01 22:11:48 *************** public: *** 182,189 **** FieldEngine(const This_t &model) : num_materials_m(model.num_materials_m), - stride_m(model.stride_m), centering_m(model.centering_m), data_m(model.data_m), physicalCellDomain_m(model.physicalCellDomain_m), guards_m(model.guards_m), --- 182,189 ---- FieldEngine(const This_t &model) : num_materials_m(model.num_materials_m), centering_m(model.centering_m), + stride_m(model.stride_m), data_m(model.data_m), physicalCellDomain_m(model.physicalCellDomain_m), guards_m(model.guards_m), *************** public: *** 244,251 **** FieldEngine(const FieldEngine &model, const Domain_t &d) : num_materials_m(model.numMaterials()), - stride_m(model.centeringSize()), centering_m(model.centering()), guards_m(0), mesh_m(model.mesh(), inputDomainToVertexDomain(d)) --- 244,251 ---- FieldEngine(const FieldEngine &model, const Domain_t &d) : num_materials_m(model.numMaterials()), centering_m(model.centering()), + stride_m(model.centeringSize()), guards_m(0), mesh_m(model.mesh(), inputDomainToVertexDomain(d)) *************** public: *** 282,289 **** FieldEngine(const FieldEngine &model, const Domain &d) : num_materials_m(model.numMaterials()), - stride_m(model.centeringSize()), centering_m(model.centering()), guards_m(0) { addSubFields(); --- 282,289 ---- FieldEngine(const FieldEngine &model, const Domain &d) : num_materials_m(model.numMaterials()), centering_m(model.centering()), + stride_m(model.centeringSize()), guards_m(0) { addSubFields(); *************** public: *** 304,311 **** FieldEngine(const FieldEngine &model, const INode &i) : num_materials_m(model.numMaterials()), - stride_m(model.centeringSize()), centering_m(model.centering()), guards_m(0), mesh_m(model.mesh(), inputDomainToVertexDomain(i.domain())) // FIXME: should hand INode to mesh? --- 304,311 ---- FieldEngine(const FieldEngine &model, const INode &i) : num_materials_m(model.numMaterials()), centering_m(model.centering()), + stride_m(model.centeringSize()), guards_m(0), mesh_m(model.mesh(), inputDomainToVertexDomain(i.domain())) // FIXME: should hand INode to mesh? *************** public: *** 342,349 **** FieldEngine(const FieldEngine &model, const EngineView &ev) : num_materials_m(model.numMaterials()), - stride_m(model.centeringSize()), centering_m(model.centering()), physicalCellDomain_m(model.physicalCellDomain()), guards_m(model.guardLayers()), mesh_m(model.mesh()) --- 342,349 ---- FieldEngine(const FieldEngine &model, const EngineView &ev) : num_materials_m(model.numMaterials()), centering_m(model.centering()), + stride_m(model.centeringSize()), physicalCellDomain_m(model.physicalCellDomain()), guards_m(model.guardLayers()), mesh_m(model.mesh()) *************** public: *** 366,373 **** FieldEngine(const FieldEngine &model, const FieldEnginePatch &p) : num_materials_m(model.numMaterials()), - stride_m(model.centeringSize()), centering_m(model.centering()), guards_m(model.guardLayers()), mesh_m(model.mesh()) // FIXME: should take a view of the mesh??? { --- 366,373 ---- FieldEngine(const FieldEngine &model, const FieldEnginePatch &p) : num_materials_m(model.numMaterials()), centering_m(model.centering()), + stride_m(model.centeringSize()), guards_m(model.guardLayers()), mesh_m(model.mesh()) // FIXME: should take a view of the mesh??? { *************** public: *** 384,391 **** FieldEngine(const FieldEngine &model, const ComponentWrapper &cw) : num_materials_m(model.numMaterials()), - stride_m(model.centeringSize()), centering_m(model.centering()), physicalCellDomain_m(model.physicalCellDomain()), guards_m(model.guardLayers()), mesh_m(model.mesh()) --- 384,391 ---- FieldEngine(const FieldEngine &model, const ComponentWrapper &cw) : num_materials_m(model.numMaterials()), centering_m(model.centering()), + stride_m(model.centeringSize()), physicalCellDomain_m(model.physicalCellDomain()), guards_m(model.guardLayers()), mesh_m(model.mesh()) *************** public: *** 405,412 **** FieldEngine(const This_t &model, const Pooma::DontCopyRelations &d) : num_materials_m(model.numMaterials()), - stride_m(model.centeringSize()), centering_m(model.centering()), physicalCellDomain_m(model.physicalCellDomain_m), guards_m(model.guardLayers()), mesh_m(model.mesh()) --- 405,412 ---- FieldEngine(const This_t &model, const Pooma::DontCopyRelations &d) : num_materials_m(model.numMaterials()), centering_m(model.centering()), + stride_m(model.centeringSize()), physicalCellDomain_m(model.physicalCellDomain_m), guards_m(model.guardLayers()), mesh_m(model.mesh()) Index: src/Partition/ContextMapper.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Partition/ContextMapper.h,v retrieving revision 1.20 diff -c -p -r1.20 ContextMapper.h *** src/Partition/ContextMapper.h 2000/12/29 02:47:37 1.20 --- src/Partition/ContextMapper.h 2002/07/01 22:11:48 *************** public: *** 80,85 **** --- 80,87 ---- ContextMapper(){}; + virtual ~ContextMapper(){}; + virtual void map(const List_t & templist) const = 0; From rguenth at tat.physik.uni-tuebingen.de Thu Jul 4 12:39:00 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 4 Jul 2002 14:39:00 +0200 (CEST) Subject: Functors and Array ctors Message-ID: Hi! In resurrecting RectilinearMesh, I came across the problem of creating a Functor for IndexFunction engine containing an Array<> member. This lead to lots of problems with appearantly incorrectly(?) autogenerated copy constructors and assignment operators for this functor. Those seem at some point always to invoke a Array.assign() operation which does assert for uninitialized Arrays. I worked around this by defining constructor, assignment and copy constructors that do essentially whichever(const Array&a) { array_m.engine() = Engine<1, T, Brick>(a.engine()); array_m = a; } I.e. manually re-set the engines before assignment. Is there a better way to achieve this? How would one handle Functors with Array members? Is Array flawed in not allowing it to be compile-generated copy-constructable? Any hints/help appreciated, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From rguenth at tat.physik.uni-tuebingen.de Fri Jul 5 11:54:55 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Fri, 5 Jul 2002 13:54:55 +0200 (CEST) Subject: RectilinearMeshData from FieldEnginePatch Message-ID: Hi! What is (for a non-uniform rectilinear mesh) RectilinearMeshData(const RectilinearMeshData &model, const FieldEnginePatch &p) supposed to do compared to RectilinearMeshData(const RectilinearMeshData &model, const Interval &d) ? Thanx for clarification, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From toon.knapen at si-lab.com Fri Jul 5 14:15:19 2002 From: toon.knapen at si-lab.com (Toon Knapen) Date: Fri, 5 Jul 2002 16:15:19 +0200 Subject: pooma manual Message-ID: I've been reading a bit of the manual and found some typo's and got some remarks fyi. two time 'history of pooma' _ point 3 in preface _ section 2.3 p33, Efficient code : par 2, "Pooma uses of ..." should be "Pooma's use of ... " Although taken as an example in the manual, there is no LINUXgcc in the config/arch of the pooma-2.3.0 distribution (it's in the CVS, I know). And although the LINUXgcc file indicates paws_able = 1, cheetah_able and fftw_able, it seems to compile fine without all those pacakages. BTW, I've been unable to succefully build cheetah. Could it be that some of the installation procedure has changed since the release of the manual ? Thanks toon From rguenth at tat.physik.uni-tuebingen.de Fri Jul 5 14:19:10 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Fri, 5 Jul 2002 16:19:10 +0200 (CEST) Subject: src/Field/ToDo Message-ID: Hi! Can someone go through src/Field/ToDo and delete stuff that is already done in current CVS? I think at least (2) is done, dont know of the rest. Thanx, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From oldham at codesourcery.com Thu Jul 11 19:14:01 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 11 Jul 2002 12:14:01 -0700 Subject: Pooma Release 2.4.0 Message-ID: <200207111914.g6BJE1w03116@oz.codesourcery.com> I've released POOMA version 2.4.0 via http://www.codesourcery.com/pooma/pooma_download. Here is the excerpt from the README file: //////////////////////////////////////////////////////////////////// RELEASE NOTES v2.4.0 //////////////////////////////////////////////////////////////////// Version 2.4.0 introduces significant changes to Fields. An individual field cell can contain multiple values, and the nearest neighboring values to a given value can be computed. Also, each Field supports multiple materials, and the Field mesh implementation was improved. Field relations support lazy evaluation of Field values. That is, a dependent Field's values can be a function of other Fields' values. When the dependent Field is used, its values are computed if any of the other Fields' values have changed since it was last computed. Using this technique avoids difficulties caused by using values computed at different times during a computation. This version incorporates other minor source code changes to support compilation using g++ version 3.1 and some improvements to POOMA Fields. Compilation using g++ version 2.96 is no longer supported. g++ version 3.1 is freely available at http://gcc.gnu.org/. POOMA has also been tested using KAI C++ 4.0e. This recent POOMA development has been performed by CodeSourcery LLC (www.codesourcery.com) and Proximation LLC (www.proximation.com) under funding from the Department of Energy through Los Alamos National Laboratory. Despite the license's claims, the latest POOMA code base and documentation can be found at the latter's WWW site: www.codesourcery.com/pooma/pooma www.pooma.com is a synonym. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Thu Jul 11 20:16:07 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 11 Jul 2002 22:16:07 +0200 (CEST) Subject: [pooma-dev] Pooma Release 2.4.0 In-Reply-To: <200207111914.g6BJE1w03116@oz.codesourcery.com> Message-ID: On Thu, 11 Jul 2002, Jeffrey Oldham wrote: > I've released POOMA version 2.4.0 via > http://www.codesourcery.com/pooma/pooma_download. The tarball contains empty (probably dead) directories and all CVS directories. We may want to improve this. > Here is the excerpt from the README file: Which is not yet in CVS. Richard. From oldham at codesourcery.com Thu Jul 11 22:08:53 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 11 Jul 2002 15:08:53 -0700 Subject: [pooma-dev] Pooma Release 2.4.0 In-Reply-To: ; from rguenth@tat.physik.uni-tuebingen.de on Thu, Jul 11, 2002 at 10:16:07PM +0200 References: <200207111914.g6BJE1w03116@oz.codesourcery.com> Message-ID: <20020711150853.A3308@codesourcery.com> On Thu, Jul 11, 2002 at 10:16:07PM +0200, Richard Guenther wrote: > On Thu, 11 Jul 2002, Jeffrey Oldham wrote: > > > I've released POOMA version 2.4.0 via > > http://www.codesourcery.com/pooma/pooma_download. > > The tarball contains empty (probably dead) directories and all CVS > directories. We may want to improve this. Thanks for the note. I removed all the empty directories except 'lib' and all the CVS directories from the tgz file http://www.codesourcery.com/pooma/pooma_download/pooma-2.4.0.tgz. > > Here is the excerpt from the README file: > > Which is not yet in CVS. Done! Thanks, Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Mon Jul 15 12:38:35 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Mon, 15 Jul 2002 14:38:35 +0200 (CEST) Subject: RectilinearMesh and coordinate system support Message-ID: Hi! I put a patch and some new files regarding RectilinearMesh support and integration of coordinate systems (Cartesian, cylindrical and spherical) on my local pooma-work site at http://www.tat.physik.uni-tuebingen.de/~rguenth/pooma/ The RectilinearMesh support has two problems (that probably will be a non-issue to most uses, but still is ugly): The view constructor is implemented as RectilinearMeshData(const RectilinearMeshData &model, const Interval &d) : NoMeshData(d) { for (int i = 0; i < Dim; i++) { // FIXME: Wheeee ;) (we cant store a BrickView... // and still dont want to copy) spacings_m(i).engine() = Engine<1, T, Brick>(&model.spacings_m(i)(d[i])(0), d[i]); positions_m(i).engine() = Engine<1, T, Brick>(&model.positions_m(i)(d[i])(0), d[i]); origin_m(i) = positions_m(i)(d[i].min()); } } which as the comment reads is broken. The FieldEnginePatch view constructor is implemented like the copy constructor as I dont know what it is supposed to do (and got no answer from a previous mail). The coordinate system support is quite invasive as it requires changes to existing source - mainly meshes are now templated on a MeshTraits class rather than Dim, T to avoid overly complex type-typing. All UniformRectilinearMesh need to be changed to MeshTraits::Mesh_t (the patch should cover nearly all necessary changes in the core code apart from tests outside of Field/tests - I have a more complete patch for people caring). I'd like to recieve feedback on the way I re-integrated coordinate system support and be happy to contribute it to the pooma project. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From garnet at bastille.cchem.berkeley.edu Wed Jul 17 07:00:16 2002 From: garnet at bastille.cchem.berkeley.edu (Garnet Kin-Lic Chan) Date: Wed, 17 Jul 2002 00:00:16 -0700 (PDT) Subject: notes on compiling for gcc-2.96-RH (and small bug?) Message-ID: I've found that I need to make a few changes to compile for this version of gcc, one of which is due to a small bug I believe. choose arch LINUXgcc in /lib/$ARCH/PoomaConfiguration.h, #define POOMA_MISSING_IO_MANIPS POOMA_YES #define POOMA_NO_STD_IOSBASE POOMA_YES in src/$ARCH/IO/DiskLayout.cmp.cpp, change #include to #include in src/$ARCH/IO/DiskLayout.h there is no #include (I believe this is an error). Add this to the header. in src/Tiny/Vector.h, change #include to #include . Garnet From garnet at bastille.cchem.berkeley.edu Wed Jul 17 08:20:48 2002 From: garnet at bastille.cchem.berkeley.edu (Garnet Kin-Lic Chan) Date: Wed, 17 Jul 2002 01:20:48 -0700 (PDT) Subject: simple pooma question Message-ID: Sorry if these are simple questions, but I am having quite a lot of difficulty trying to understand what POOMA does during its parallel execution. I have done some parallel programming before, but here everything is hidden! If a piece of code has both a serial component and a parallel component, and one is executing it in a distributed environment, does every copy of the code run the serial component, or does POOMA only make one node execute the serial component. Similarly, are arrays which are not declared as distributed, then exist as identical copies on each node? Also, where can I look to better understand the parallel behaviour of POOMA? Thanks in advance, Garnet From rguenth at tat.physik.uni-tuebingen.de Wed Jul 17 09:40:23 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 17 Jul 2002 11:40:23 +0200 (CEST) Subject: [pooma-dev] simple pooma question In-Reply-To: Message-ID: On Wed, 17 Jul 2002, Garnet Kin-Lic Chan wrote: > > Sorry if these are simple questions, but I am having quite a lot of > difficulty trying to understand what POOMA does during its parallel > execution. I have done some parallel programming before, > but here everything is hidden! > > If a piece of code has both a serial component and a parallel > component, and one is executing it in a distributed environment, does > every copy of the code run the serial component, or does POOMA only make > one node execute the serial component. All nodes execute the serial component except you mark the serial section with something like if (Pooma::context() == 0) { ... serial part to be executed exclusively on node 0 ... } but you need to be careful to not have non-local engines working in such sections (or you'll deadlock and get errors). > Similarly, are arrays which are not > declared as distributed, then exist as identical copies on each node? Yes, they exist on each node as identical copies (similar to choosing ReplicatedTag). > Also, where can I look to better understand the parallel behaviour of > POOMA? Browse through the available documentation - and the source, if necessary. Parallel behavior ist straight forward except for some surprising effects... Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From rguenth at tat.physik.uni-tuebingen.de Wed Jul 17 11:13:53 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 17 Jul 2002 13:13:53 +0200 (CEST) Subject: [PATCH] make Evaluator/ReductionTest4 compile Message-ID: The attached patch/changelog makes Evaluator/ReductionTest4.cpp compile by adding the required DistributedTag() to the layout constructor calls. Test compiles and passes now. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ -------------- next part -------------- 2002Jul17 Richard Guenther * Evaluator/tests/ReductionTest4.cpp (main): Add DistributedTag() to layout constructor invocation Tested using g++ 3.1.1 on sequential Linux by compiling and running Pooma Evaluator testsuite. -------------- next part -------------- diff -u -r1.2 ReductionTest4.cpp --- src/Evaluator/tests/ReductionTest4.cpp 2000/05/03 18:58:59 1.2 +++ src/Evaluator/tests/ReductionTest4.cpp 2002/07/17 11:06:23 @@ -45,8 +45,8 @@ Loc<1> blocks2(2), blocks5(5); UniformGridPartition<1> partition2(blocks2), partition5(blocks5); - UniformGridLayout<1> layout2(Interval<1>(10), partition2), - layout5(Interval<1>(10), partition5); + UniformGridLayout<1> layout2(Interval<1>(10), partition2, DistributedTag()), + layout5(Interval<1>(10), partition5, DistributedTag()); Array<1, int, MultiPatch > > a(layout2), b(layout5); Array<1, int> c(10); From jcrotinger at proximation.com Wed Jul 17 15:36:16 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Wed, 17 Jul 2002 09:36:16 -0600 Subject: [pooma-dev] notes on compiling for gcc-2.96-RH (and small bug ?) Message-ID: We have, at times, tried to institute a policy of not including in any of the public headers. Perhaps this was abandoned at some point. There are a number of places where and should suffice, though. (I haven't looked at these specific examples.) Since gcc 3.1 is out, it would be best to keep the LINUXgcc configuration appropriate for it, and perhaps add a LINUXgcc296 or something for changes necessary to keep it compiling with the older compiler. Jim > -----Original Message----- > From: Garnet Kin-Lic Chan [mailto:garnet at bastille.cchem.berkeley.edu] > Sent: Wednesday, July 17, 2002 1:00 AM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] notes on compiling for gcc-2.96-RH (and > small bug?) > > > > > I've found that I need to make a few changes to compile > for this version of gcc, one of > which is due to a small bug I believe. > > choose arch LINUXgcc > in /lib/$ARCH/PoomaConfiguration.h, > #define POOMA_MISSING_IO_MANIPS POOMA_YES > #define POOMA_NO_STD_IOSBASE POOMA_YES > > in src/$ARCH/IO/DiskLayout.cmp.cpp, change #include to > #include > > in src/$ARCH/IO/DiskLayout.h there is no #include (I > believe this is an error). Add this to the header. > > in src/Tiny/Vector.h, change #include to #include . > > Garnet > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcrotinger at proximation.com Wed Jul 17 15:41:58 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Wed, 17 Jul 2002 09:41:58 -0600 Subject: [pooma-dev] simple pooma question Message-ID: > Sorry if these are simple questions, but I am having quite a > lot of difficulty trying to understand what POOMA does during > its parallel execution. I have done some parallel programming > before, but here everything is hidden! That was the point. (Hiding parallelism, not causing you difficulty 8-) > If a piece of code has both a serial component and a parallel > component, and one is executing it in a distributed > environment, does every copy of the code run the serial > component, or does POOMA only make one node execute the > serial component. Similarly, are arrays which are not > declared as distributed, then exist as identical copies on each node? Under normal operation, POOMA is basically SPMD, so yes, the serial code runs in every process. If a threaded evaluator is used, then the serial code runs in the main thread of every process, but not in the worker threads. > > Also, where can I look to better understand the parallel > behaviour of POOMA? I'm not sure what the state of the tutorials are. The nitty-gritty is not documented anywhere that I'm aware of. We tried to do a good job of commenting the source, so there is always that. A high level design document would have been good, especially for an open-source development model. When this was being developed at the lab, there were 8-10 people working closely together, having weekly meetings, etc., and some of the stuff that was well known to all just never got written down. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From garnet at bastille.cchem.berkeley.edu Thu Jul 18 07:19:25 2002 From: garnet at bastille.cchem.berkeley.edu (Garnet Kin-Lic Chan) Date: Thu, 18 Jul 2002 00:19:25 -0700 (PDT) Subject: manual README note Message-ID: When compiling the manual, in README.txt, under the section, if you have problems, can also add `may need to change XML to location of xml.dcl in Makefile' Garnet From garnet at bastille.cchem.berkeley.edu Thu Jul 18 08:08:16 2002 From: garnet at bastille.cchem.berkeley.edu (Garnet Kin-Lic Chan) Date: Thu, 18 Jul 2002 01:08:16 -0700 (PDT) Subject: another simple question Message-ID: When installing Cheetah with MM, how does one then run code to utilise more than one processor on a shared memory machine? (I've already configured POOMA; I was wondering about the equivalent of mpirun for shared memory...) thanks, Garnet From rguenth at tat.physik.uni-tuebingen.de Thu Jul 18 10:18:36 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 18 Jul 2002 12:18:36 +0200 (CEST) Subject: [PATCH] fix href in docs/index.html Message-ID: The attached patch/changelog fixes the pointer to the layouts section. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ -------------- next part -------------- 2002Jul18 Richard Guenther * docs/index.html: fixed reference from layout.html to Layout.html -------------- next part -------------- Index: docs/index.html =================================================================== RCS file: /home/pooma/Repository/r2/docs/index.html,v retrieving revision 1.1 diff -u -r1.1 index.html --- docs/index.html 2001/03/19 16:11:13 1.1 +++ docs/index.html 2002/07/18 10:16:21 @@ -20,7 +20,7 @@

Parallelism Models: Messaging and Threads

-

Layouts

+

Layouts

New description of Particles

Text I/O

Object I/O

From rguenth at tat.physik.uni-tuebingen.de Mon Jul 22 12:55:25 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Mon, 22 Jul 2002 14:55:25 +0200 (CEST) Subject: [PATCH] fix Tiny/Zero.h Message-ID: The attached patch makes the Zero class work - protection is fixed, as well as missing const and ambigous return type traits. One class to come. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ -------------- next part -------------- 2002Jul22 Richard Guenther * Tiny/Zero.h: fixed class protection const'ified operator T() deleted ambigous return type specializations -------------- next part -------------- Index: src/Tiny/Zero.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Tiny/Zero.h,v retrieving revision 1.6 diff -u -r1.6 Zero.h --- src/Tiny/Zero.h 2000/03/07 13:18:17 1.6 +++ src/Tiny/Zero.h 2002/07/22 12:51:50 @@ -67,13 +67,13 @@ //----------------------------------------------------------------------------- template -class Zero +struct Zero { // If you need to convert to an object of type T, // just build one from zero. This will be used in // the cases where the operators below don't match. - operator T() { return T(0); } + operator T() const { return T(0); } // Give it empty ctors and assignment operators @@ -238,24 +238,6 @@ // Trait class definitios for the cases where the Zero gets // converted to a T. // - -template -struct UnaryReturn< Zero , Op > -{ - typedef typename UnaryReturn::Type_t Type_t; -}; - -template -struct BinaryReturn< Zero , T2, Op > -{ - typedef typename BinaryReturn::Type_t Type_t; -}; - -template -struct BinaryReturn< T1 , Zero, Op > -{ - typedef typename BinaryReturn::Type_t Type_t; -}; template struct BinaryReturn< Zero , Zero, Op > From oldham at codesourcery.com Mon Jul 22 23:08:14 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Mon, 22 Jul 2002 16:08:14 -0700 Subject: [pooma-dev] another simple question In-Reply-To: ; from garnet@bastille.cchem.berkeley.edu on Thu, Jul 18, 2002 at 01:08:16AM -0700 References: Message-ID: <20020722160814.B31226@codesourcery.com> On Thu, Jul 18, 2002 at 01:08:16AM -0700, Garnet Kin-Lic Chan wrote: > > When installing Cheetah with MM, how does one then run code to utilise > more than one processor on a shared memory machine? (I've already > configured POOMA; I was wondering about the equivalent of mpirun for > shared memory...) Use a command line like Doof2d-Array-distributed -shmem -np 4 2 10 1000 '-shmem' indicates the MM shared memory library should be used. '-np 4' indicates four processors. The last paragraph of http://www.codesourcery.com/pooma/pooma_manual/tutorial-array_distributed.html has this command line. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Wed Jul 24 09:05:40 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 24 Jul 2002 11:05:40 +0200 (CEST) Subject: [PATCH] add support for Intel/icc compiler Message-ID: The attached patch introduces config/arch/LINUXICC.conf and fixes Utilities/Inform.h. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ -------------- next part -------------- 2002Jul24 Richard Guenther * config/arch/LINUXICC.conf: new * src/Utilities/Inform.h: icc has std::ios_base::fmtflags -------------- next part -------------- # This is a BitKeeper generated patch for the following project: # Project Name: pooma/cheetah repository tracking CVS/tarball # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.43 -> 1.44 # r2/src/Utilities/Inform.h 1.2 -> 1.3 # (new) -> 1.1 r2/config/arch/LINUXICC.conf # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/07/24 rguenth at bellatrix.tat.physik.uni-tuebingen.de 1.44 # Intel icpc support # -------------------------------------------- # diff --minimal -Nru a/r2/config/arch/LINUXICC.conf b/r2/config/arch/LINUXICC.conf --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/r2/config/arch/LINUXICC.conf Wed Jul 24 10:53:59 2002 @@ -0,0 +1,318 @@ +# Perl input file +# ACL:license +# ---------------------------------------------------------------------- +# This software and ancillary information (herein called "SOFTWARE") +# called POOMA (Parallel Object-Oriented Methods and Applications) is +# made available under the terms described here. The SOFTWARE has been +# approved for release with associated LA-CC Number LA-CC-98-65. +# +# Unless otherwise indicated, this SOFTWARE has been authored by an +# employee or employees of the University of California, operator of the +# Los Alamos National Laboratory under Contract No. W-7405-ENG-36 with +# the U.S. Department of Energy. The U.S. Government has rights to use, +# reproduce, and distribute this SOFTWARE. The public may copy, distribute, +# prepare derivative works and publicly display this SOFTWARE without +# charge, provided that this Notice and any statement of authorship are +# reproduced on all copies. Neither the Government nor the University +# makes any warranty, express or implied, or assumes any liability or +# responsibility for the use of this SOFTWARE. +# +# If SOFTWARE is modified to produce derivative works, such modified +# SOFTWARE should be clearly marked, so as not to confuse it with the +# version available from LANL. +# +# For more information about POOMA, send e-mail to pooma at acl.lanl.gov, +# or visit the POOMA web page at http://www.acl.lanl.gov/pooma/. +# ---------------------------------------------------------------------- +# ACL:license + +########################################################################### +# POOMA configuration settings +# +# Platform: LINUX (Intel Pentium running Linux) +# Compiler: icc +# +########################################################################### +# +# This file contains specialized settings indicating how to build POOMA +# with this platform and compiler. This is a perl script executed by +# the 'configure' script at the top level of the POOMA directory structure. +# This file has two sections: +# 1) The locations of include files and libraries for external packages. +# 3) The specialized settings on how to use this platform and compiler. +# You should edit the lines in section 1) to the proper location of the +# external packages. Do not edit the lines in section 2) unless you +# know what you're doing. +# +########################################################################### + +########################################################################### +# Section 0: architecture type +########################################################################### + +$archtype = "linux"; + +########################################################################### +# Section 1: external package locations. +# Include search directories should have a '-I' prepended. +# Library search directories should have a '-L' prepended. +# Library filenames should just list the name or use -l prefix as needed. +# Required defines should have -a '-D' prepended. +########################################################################### + +### location of SMARTS files for threads + +$threads_able = 1; +$threads_default_dir = "/home/smarts/build/smarts-current"; +$threads_lib_subdir = "$archtype/lib"; +$threads_basic_makefile = "Makefile.smarts-g++"; +$threads_profile_makefile = "Makefile.smarts-tau-g++"; + + +### location of TAU files for profiling + +$profile_able = 1; +$profile_default_dir = "/home/tau/build/tau-current"; +$ductape_default_dir = "/usr/local/pooma/packages/ductape"; +$profile_archtype = "i386_linux"; +$profile_lib_subdir = "$profile_archtype/lib"; +$profile_basic_makefile = "Makefile.tau-egcs"; +$profile_smarts_makefile = "Makefile.tau-smarts-egcs"; +$profile_pthreads_makefile = "Makefile.tau-pthread-egcs"; + + +### location of PAWS files for program coupling + +$paws_able = 1; +$paws_default_dir = "/home/paws/build/paws-current"; +$paws_lib_subdir = "$archtype/lib"; +$paws_makefile = "Makefile.paws-egcs"; + + +### location of HDF5 files for I/O + +$hdf5_able = 1; +$hdf5_default_dir = "/home/rguenth/ix86"; + + +### location of FFTW files for ffts + +$fftw_able = 1; +$fftw_default_dir = "/home/pooma/packages/fftw/$archtype"; + + +### location of cheetah + +$cheetah_able = 1; +$cheetah_default_dir = "/home/rguenth/ix86/pooma/"; +$cheetah_arch = "$archtype"; +$cheetah_lib_subdir = "lib/icc"; +$cheetah_include_makefile = "Makefile.cheetah"; + + +### location of LUX files for runtime visualization + +$lux_able = 0; + + +### location and names of Purify analysis package + +$purify_able = 0; + + +### location and names of Insure++ analysis package + +$insure_able = 1; +$cppinsure = "icpc"; +$cinsure = "icc"; +$cpp_insure_run = "insure"; +$cpp_insure_arg = "-Zvm -Zoi \"compiler $cppinsure\""; +$c_insure_run = "insure"; +$c_insure_arg = "-Zvm -Zoi \"compiler $cinsure\""; +$ar_insure_run = "ar"; +$ar_insure_arg = ""; +$ld_insure_run = "insure"; +$ld_insure_arg = "-Zvm -Zoi \"compiler $cppinsure\""; + + +########################################################################### +# Section 2: compilation settings +########################################################################### + +################### +### characteristics +################### + +$comptype = "icc"; +$compext = "-icc"; + +### are shared libraries supported? + +$canmakesharedlib = 0; +$shared = 0; +$sharedext = "so"; + +### other special characteristics: for all special cases for this +### architecture that differ from the standard, include a line +### here to indicate what the differences are, setting a variable +### equal to one. If the architecture does the "right thing", though, +### there is no reason to mention anything here, although you can set +### the special characteristics variables to 0 if you want. + +# ICC does not have the C++ standard stringstream class +$no_stringstream = 1; + +# ICC does have all the proper iomanips +$no_complete_iomanips = 0; + +# ICC does have restrict (use __restrict__) +$no_restrict = 0; + +# ICC does have complex in the std:: namespace +$no_std_complex = 0; + +# ICC does have a ios_base class in std:: namespace +$no_std_iosbase = 0; + +# Must include to get POSIX file modes +$inc_sys_stat_h_file_modes = 1; + +# Use gettimeofday in Utilities/Clock.h +$clock_uses_gettimeofday = 1; + +################ +### C++ settings +################ + +### general settings for using the C++ compiler, for both libs and apps + +$cpp = "icpc"; +$cppargs = "-restrict"; +$cppex = "-Kc++eh"; # flag to use exceptions +$cppnoex = ""; # flag to use to turn off exceptions +$cppverbose = "-v"; # flag for verbose compiler output +$cpponeper = ""; # flag to turn on one-instantance-per-obj +$cppstrict = ""; # flag for ANSI conformance checking + + +### debug or optimized build settings for C++ applications + +$cppdbg_app = "-g"; +$cppopt_app = "-DNOPAssert -DNOCTAssert -O2"; + + +### debug or optimized build settings for C++ libraries + +$cppdbg_lib = $cppdbg_app; +$cppopt_lib = $cppopt_app; + + +############## +### C settings +############## + +### general settings for using the C compiler, for both libs and apps + +$c = "icc"; +$cargs = "-restrict"; +$cverbose = ""; + + +### debug or optimized build settings for C applications + +$cdbg_app = "-g"; +$copt_app = "-O2"; + + +### debug or optimized build settings for C libraries + +$cdbg_lib = $cdbg_app; +$copt_lib = $copt_app; + + +################ +### F77 settings +################ + +### general settings for using the F77 compiler, for both libs and apps + +$f77 = "ifc"; +$f77args = ""; +$f77libs = ""; +$f77verbose = ""; + + +### debug or optimized build settings for F77 applications + +$f77dbg_app = "-g"; +$f77opt_app = "-O2"; + + +### debug or optimized build settings for F77 libraries + +$f77dbg_lib = $f77dbg_app; +$f77opt_lib = $f77opt_app; + + +################### +### linker settings +################### + +$link = $cpp; +$linkargs = ""; +$linkverbose = ""; +$linkshare = ""; + +##################### +### archiver settings +##################### + +$ar = "ar"; # program to make static lib +$arshare = $cpp; # program to make shared lib + +# arguments for making static lib +$arargs = "rc"; +# arguments for making shared lib +$arshareargs = "-shared -o"; + +# flag to turn on verbose ar output +$arverbose = ""; +$arshareverbose = $cppverbose; + +# flag for exceptions +$arex = ""; +$arshareex = $cppex; + +# flag for no exceptions +$arnoex = ""; +$arsharenoex = $cppnoex; + +# flag for one instantiation per object +$aroneper = ""; +$arshareoneper = $cpponeper; + +# flag for ANSI conformance checking +$arstrict = ""; +$arsharestrict = $cppstrict; + +### debug or optimized build settings for archiving libraries + +$ardbg = ""; +$aropt = ""; +$arsharedbg = $cppdbg_app; +$arshareopt = $cppopt_app; + + +# ACL:rcsinfo +# ---------------------------------------------------------------------- +# $RCSfile: LINUXEGCS.conf,v $ $Author: oldham $ +# $Revision: 1.26 $ $Date: 2001/10/15 17:34:28 $ +# ---------------------------------------------------------------------- +# ACL:rcsinfo + +########################################################################### +# the last line of this file must be a '1' so that Perl sees a non-zero +# results from this file +########################################################################### +1; + diff --minimal -Nru a/r2/src/Utilities/Inform.h b/r2/src/Utilities/Inform.h --- a/r2/src/Utilities/Inform.h Wed Jul 24 10:53:59 2002 +++ b/r2/src/Utilities/Inform.h Wed Jul 24 10:53:59 2002 @@ -278,7 +278,8 @@ void output() { flush(); } #if (defined(__MWERKS__) && __MWERKS__ >= 0x2301) \ - || (defined(__GLIBCPP__) && __GLIBCPP__ >= 20001129) + || (defined(__GLIBCPP__) && __GLIBCPP__ >= 20001129) \ + || (defined(__ICC)) typedef std::ios_base::fmtflags FmtFlags_t; #else typedef long FmtFlags_t; From rguenth at tat.physik.uni-tuebingen.de Wed Jul 24 09:07:44 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 24 Jul 2002 11:07:44 +0200 (CEST) Subject: [PATCH] Fix Tiny/Zero.h, add Tiny/One.h, new testcase Message-ID: The attached patch introduces Tiny/One.h and a new testcase to check ConstantFunction engine and Tiny/Zero.h, Tiny/One.h. Tiny/Zero.h is also fixed (as in the previously sent patch + additional fixes). Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ -------------- next part -------------- 2002Jul24 Richard Guenther * Tiny/Zero.h: fixed class protection const'ified operator T() deleted ambigous return type specializations * Tiny/One.h: new * Pooma/Tiny.h: include Zero.h and One.h * Engine/tests/makefile: new constant_test testcase * Engine/tests/constant_test.cpp: new -------------- next part -------------- # This is a BitKeeper generated patch for the following project: # Project Name: pooma/cheetah repository tracking CVS/tarball # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.40 -> 1.41 # r2/src/Pooma/Tiny.h 1.2 -> 1.3 # r2/src/Engine/tests/makefile 1.1 -> 1.2 # r2/src/Tiny/Zero.h 1.1 -> 1.2 # (new) -> 1.1 r2/src/Tiny/One.h # (new) -> 1.1 r2/src/Engine/tests/constant_test.cpp # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/07/24 rguenth at bellatrix.tat.physik.uni-tuebingen.de 1.41 # Fixed Zero<>, added One<> and MinusOne<> tiny classes, added testcase # -------------------------------------------- # diff --minimal -Nru a/r2/src/Engine/tests/constant_test.cpp b/r2/src/Engine/tests/constant_test.cpp --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/r2/src/Engine/tests/constant_test.cpp Wed Jul 24 10:55:50 2002 @@ -0,0 +1,112 @@ +// -*- C++ -*- +// ACL:license +// ---------------------------------------------------------------------- +// This software and ancillary information (herein called "SOFTWARE") +// called POOMA (Parallel Object-Oriented Methods and Applications) is +// made available under the terms described here. The SOFTWARE has been +// approved for release with associated LA-CC Number LA-CC-98-65. +// +// Unless otherwise indicated, this SOFTWARE has been authored by an +// employee or employees of the University of California, operator of the +// Los Alamos National Laboratory under Contract No. W-7405-ENG-36 with +// the U.S. Department of Energy. The U.S. Government has rights to use, +// reproduce, and distribute this SOFTWARE. The public may copy, distribute, +// prepare derivative works and publicly display this SOFTWARE without +// charge, provided that this Notice and any statement of authorship are +// reproduced on all copies. Neither the Government nor the University +// makes any warranty, express or implied, or assumes any liability or +// responsibility for the use of this SOFTWARE. +// +// If SOFTWARE is modified to produce derivative works, such modified +// SOFTWARE should be clearly marked, so as not to confuse it with the +// version available from LANL. +// +// For more information about POOMA, send e-mail to pooma at acl.lanl.gov, +// or visit the POOMA web page at http://www.acl.lanl.gov/pooma/. +// ---------------------------------------------------------------------- +// ACL:license + +// Tests that check the ConstantFunction engine and the One and +// Zero tiny classes for successful optimization. + +#include "Pooma/Pooma.h" +#include "Pooma/Arrays.h" +#include "Pooma/Tiny.h" + + +// "number" classes we can use to detect successful optimization. +// Optimization failures will cause compilation errors. +class Number { +public: + Number() : neg_m(false) {} + explicit Number(bool n) : neg_m(n) {} + bool operator==(const Number& n) const { return neg_m == n.neg_m; } + Number operator-() const { return Number(false); } +private: + bool neg_m; +}; + + +// Check successful optimization of ConstantFunction Ones and Zeros +void check_array_optimize(Pooma::Tester& tester) +{ + Interval<1> I(0, 15); + Array<1, Zero, ConstantFunction> zero(I); + Array<1, One, ConstantFunction> one(I); + Array<1, Number, Brick> n(I); + + // simple checks involving n + tester.check("n + Zero == n", all(n+zero == n)); + tester.check("Zero + n == n", all(zero+n == n)); + tester.check("n - Zero == n", all(n-zero == n)); + tester.check("n * One == n", all(n*one == n)); + tester.check("One * n == n", all(one*n == n)); + tester.check("n / One == n", all(n/one == n)); + tester.check("Zero / n == Zero", all(zero/n == zero)); + + // some more complex checks [-n needed] + tester.check("n * (Zero - One) / -One == n", all(n*(zero-one)/(-one) == n)); +} + + +// Check One and Zero is working correctly wrt arithmentics +void check_arithmetic(Pooma::Tester& tester) +{ + Interval<1> I(0, 15); + + Array<1, Zero, ConstantFunction> zero(I); + Array<1, One, ConstantFunction> one(I); + + tester.check("one*zero == 0", all(one*zero == 0)); + tester.check("zero*one == 0", all(zero*one == 0)); + tester.check("one*one == 1", all(one*one == 1)); + + tester.check("one/one == 1", all(one/one == 1)); + tester.check("zero/one == 0", all(zero/one == 0)); + + tester.check("one+zero == 1", all(one+zero == 1)); + tester.check("zero+one == 1", all(zero+one == 1)); + + tester.check("one-zero == 1", all(one-zero == 1)); + tester.check("zero-one == -1", all(zero-one == -1)); + tester.check("zero-one == -one", all(zero-one == -one)); + + tester.check("one+one == 2", all(one+one == 2)); + tester.check("2+one == 3", all(2+one == 3)); +} + + +int main(int argc, char *argv[]) +{ + Pooma::initialize(argc, argv); + Pooma::Tester tester(argc, argv); + + check_array_optimize(tester); + check_arithmetic(tester); + + int ret = tester.results("constant_test"); + Pooma::finalize(); + return ret; +} + + diff --minimal -Nru a/r2/src/Engine/tests/makefile b/r2/src/Engine/tests/makefile --- a/r2/src/Engine/tests/makefile Wed Jul 24 10:55:50 2002 +++ b/r2/src/Engine/tests/makefile Wed Jul 24 10:55:50 2002 @@ -36,7 +36,8 @@ default:: tests tests:: dynamic_tests brick_tests brickview_tests compbrick_tests \ - ump_tests gmp_tests indirect_tests brickbase_tests remote_tests + ump_tests gmp_tests indirect_tests brickbase_tests remote_tests \ + constant_test brick_tests:: brick_test1 brick_test2 brick_test3 brick_test4 @@ -63,7 +64,8 @@ run_tests: tests \ run_brickbase run_dynamic run_compbrick run_indirect \ - run_brick run_brickview run_ump run_gmp run_remote + run_brick run_brickview run_ump run_gmp run_remote \ + run_constant run_compbrick: $(MPIRUN) $(ODIR)/compbrick_test1 $(TSTOPTS) 1>compbrick_test1.out 2>&1 @@ -125,6 +127,10 @@ $(MPIRUN) $(ODIR)/makeOwnCopy $(TSTOPTS) \ 1>makeOwnCopy.out 2>&1 +run_constant: + $(MPIRUN) $(ODIR)/constant_test $(TSTOPTS) \ + 1>constant_test.out 2>&1 + .PHONY: dynamic_test1 .PHONY: dynamic_test2 @@ -211,6 +217,9 @@ remoteDynamicTest1: $(ODIR)/remoteDynamicTest1 makeOwnCopy: $(ODIR)/makeOwnCopy +.PHONY: constant_test + +constant_test: $(ODIR)/constant_test $(ODIR)/dynamic_test1: $(ODIR)/dynamic_test1.o @@ -310,6 +319,9 @@ $(LinkToSuite) $(ODIR)/makeOwnCopy: $(ODIR)/makeOwnCopy.o + $(LinkToSuite) + +$(ODIR)/constant_test: $(ODIR)/constant_test.o $(LinkToSuite) include $(SHARED_ROOT)/tail.mk diff --minimal -Nru a/r2/src/Pooma/Tiny.h b/r2/src/Pooma/Tiny.h --- a/r2/src/Pooma/Tiny.h Wed Jul 24 10:55:50 2002 +++ b/r2/src/Pooma/Tiny.h Wed Jul 24 10:55:50 2002 @@ -46,6 +46,9 @@ #include "Tiny/Reductions.h" +#include "Tiny/Zero.h" +#include "Tiny/One.h" + #endif // POOMA_POOMA_TINY_H // ACL:rcsinfo diff --minimal -Nru a/r2/src/Tiny/One.h b/r2/src/Tiny/One.h --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/r2/src/Tiny/One.h Wed Jul 24 10:55:50 2002 @@ -0,0 +1,425 @@ +// -*- C++ -*- +// ACL:license +// ---------------------------------------------------------------------- +// This software and ancillary information (herein called "SOFTWARE") +// called POOMA (Parallel Object-Oriented Methods and Applications) is +// made available under the terms described here. The SOFTWARE has been +// approved for release with associated LA-CC Number LA-CC-98-65. +// +// Unless otherwise indicated, this SOFTWARE has been authored by an +// employee or employees of the University of California, operator of the +// Los Alamos National Laboratory under Contract No. W-7405-ENG-36 with +// the U.S. Department of Energy. The U.S. Government has rights to use, +// reproduce, and distribute this SOFTWARE. The public may copy, distribute, +// prepare derivative works and publicly display this SOFTWARE without +// charge, provided that this Notice and any statement of authorship are +// reproduced on all copies. Neither the Government nor the University +// makes any warranty, express or implied, or assumes any liability or +// responsibility for the use of this SOFTWARE. +// +// If SOFTWARE is modified to produce derivative works, such modified +// SOFTWARE should be clearly marked, so as not to confuse it with the +// version available from LANL. +// +// For more information about POOMA, send e-mail to pooma at acl.lanl.gov, +// or visit the POOMA web page at http://www.acl.lanl.gov/pooma/. +// ---------------------------------------------------------------------- +// ACL:license + +#ifndef POOMA_TINY_ONE_H +#define POOMA_TINY_ONE_H + +//----------------------------------------------------------------------------- +// Class: One +//----------------------------------------------------------------------------- + +/** @file + * @ingroup Tiny + * @brief + * A numeric class for a number that is always one. + */ + +//----------------------------------------------------------------------------- +// Typedefs: +//----------------------------------------------------------------------------- + +//----------------------------------------------------------------------------- +// Includes: +//----------------------------------------------------------------------------- + +//----------------------------------------------------------------------------- +// Forward Declarations: +//----------------------------------------------------------------------------- + +template struct Zero; +template struct UnaryReturn; +template struct BinaryReturn; + + +/// The point of this class is to be a number of type T which is known at +/// compile time to be one. +/// +/// This is reflected in the operations like +/// multiplication and division that use it. If you return a One object, +/// the compiler should be able to make better optimizations than if you +/// just return one. +/// One is templated on type T, to represent a one object of type T. +/// Type T is required to be constructable from an integer one. + +template +struct One +{ + /// If you need to convert to an object of type T, + /// just build one from one. This will be used in + /// the cases where the operators below don't match. + + operator T() const { return T(1); } + + bool operator==(const One&) const { return true; } + + /// Give it empty ctors and assignment operators + /// to try and keep purify happy. + + One() {} + One(const One&) {} + One& operator=(const One&) { return *this; } +}; + +/// The point of this class is to be a number of type T which is known at +/// compile time to be minus one. +/// +/// This is reflected in the operations like +/// multiplication and division that use it. If you return a MinusOne object, +/// the compiler should be able to make better optimizations than if you +/// just return minus one. +/// MinusOne is templated on type T, to represent a one object of type T. +/// Type T is required to be constructable from an integer minus one. + +template +struct MinusOne +{ + /// If you need to convert to an object of type T, + /// just build one from minus one. This will be used in + /// the cases where the operators below don't match. + + operator T() const { return T(-1); } + + bool operator==(const MinusOne&) const { return true; } + + /// Give it empty ctors and assignment operators + /// to try and keep purify happy. + + MinusOne() {} + MinusOne(const One&) {} + MinusOne& operator=(const MinusOne&) { return *this; } +}; + + +//----------------------------------------------------------------------------- +// +// Operators using One and/or MinusOne. +// +//----------------------------------------------------------------------------- + +// +// Unary minus operators. +// + +template + inline MinusOne operator-(One) { return MinusOne(); } + +template + inline One operator-(MinusOne) { return One(); } + + +// +// Binary multiply/divide operations involving One/MinusOne. +// + +template + inline T operator*(One, const T& val) { return val; } + +template + inline T operator*(const T& val, One) { return val; } + +template + inline One operator*(One, One) { return One(); } + +template + inline One operator/(One, One) { return One(); } + +template + inline T operator/(const T& val, One) { return val; } + +template + inline T operator*(MinusOne, const T& val) { return -val; } + +template + inline T operator*(const T& val, MinusOne) { return -val; } + +template + inline One operator*(MinusOne, MinusOne) { return One(); } + +template + inline One operator/(MinusOne, MinusOne) { return One(); } + +template + inline T operator/(const T& val, MinusOne) { return -val; } + +template + inline MinusOne operator*(MinusOne, One) { return MinusOne(); } + +template + inline MinusOne operator*(One, MinusOne) { return MinusOne(); } + +template + inline MinusOne operator/(MinusOne, One) { return MinusOne(); } + +template + inline MinusOne operator/(One, MinusOne) { return MinusOne(); } + +// +// Subtraction/addition of a One/MinusOne from a One/MinusOne +// which yields Zero. +// + +template + inline Zero operator-(One, One) { return Zero(); } + +template + inline Zero operator-(MinusOne, MinusOne) { return Zero(); } + +template + inline Zero operator+(One, MinusOne) { return Zero(); } + +template + inline Zero operator+(MinusOne, One) { return Zero(); } + + +template + inline MinusOne operator-(Zero, One) { return MinusOne(); } + +template + inline One operator-(Zero, MinusOne) { return One(); } + + + +// +// Trait classes so that expression templates will deal correctly +// with Ones/MinusOnes in specific operations. +// + +// Unary minus + +template +struct UnaryReturn< One , OpUnaryMinus > +{ + typedef MinusOne Type_t; +}; + +template +struct UnaryReturn< MinusOne , OpUnaryMinus > +{ + typedef One Type_t; +}; + +// Multiply + +template +struct BinaryReturn< One , T , OpMultiply > +{ + typedef T Type_t; +}; + +template +struct BinaryReturn< T, One , OpMultiply > +{ + typedef T Type_t; +}; + +template +struct BinaryReturn< One, One , OpMultiply > +{ + typedef One Type_t; +}; + +template +struct BinaryReturn< MinusOne , T , OpMultiply > +{ + typedef T Type_t; +}; + +template +struct BinaryReturn< T, MinusOne , OpMultiply > +{ + typedef T Type_t; +}; + +template +struct BinaryReturn< MinusOne, MinusOne , OpMultiply > +{ + typedef One Type_t; +}; + +template +struct BinaryReturn< MinusOne, One , OpMultiply > +{ + typedef MinusOne Type_t; +}; + +template +struct BinaryReturn< One, MinusOne , OpMultiply > +{ + typedef MinusOne Type_t; +}; + +// Divide + +template +struct BinaryReturn< T, One , OpDivide > +{ + typedef T Type_t; +}; + +template +struct BinaryReturn< T, MinusOne , OpDivide > +{ + typedef T Type_t; +}; + +template +struct BinaryReturn< MinusOne, One , OpDivide > +{ + typedef MinusOne Type_t; +}; + +template +struct BinaryReturn< One, MinusOne , OpDivide > +{ + typedef MinusOne Type_t; +}; + +// Subtract + +template +struct BinaryReturn< One, One , OpSubtract > +{ + typedef Zero Type_t; +}; + +template +struct BinaryReturn< MinusOne, MinusOne , OpSubtract > +{ + typedef Zero Type_t; +}; + +template +struct BinaryReturn< Zero, One, OpSubtract > +{ + typedef MinusOne Type_t; +}; + +template +struct BinaryReturn< Zero, MinusOne, OpSubtract > +{ + typedef One Type_t; +}; + +// Add + +template +struct BinaryReturn< One, MinusOne , OpAdd > +{ + typedef Zero Type_t; +}; + +template +struct BinaryReturn< MinusOne, One , OpAdd > +{ + typedef Zero Type_t; +}; + +// Equality + +template +struct BinaryReturn< MinusOne, MinusOne, OpEQ> +{ + typedef bool Type_t; +}; + +template +struct BinaryReturn< One, One, OpEQ> +{ + typedef bool Type_t; +}; + + +// +// Trait class definitios for the cases where the One/MinusOne gets +// converted to a T. Traits with just one specialized operand are +// ambigous to specialized operator versions. +// + +template +struct BinaryReturn< One , One, Op > +{ + typedef typename BinaryReturn::Type_t Type_t; +}; + +template +struct BinaryReturn< MinusOne , MinusOne, Op > +{ + typedef typename BinaryReturn::Type_t Type_t; +}; + + +// +// Let Zero, One and MinusOne play together for other operators. +// + +template +struct BinaryReturn< One, Zero, Op > +{ + typedef typename BinaryReturn::Type_t Type_t; +}; + +template +struct BinaryReturn< Zero, One, Op > +{ + typedef typename BinaryReturn::Type_t Type_t; +}; + +template +struct BinaryReturn< MinusOne, Zero, Op > +{ + typedef typename BinaryReturn::Type_t Type_t; +}; + +template +struct BinaryReturn< Zero, MinusOne, Op > +{ + typedef typename BinaryReturn::Type_t Type_t; +}; + +template +struct BinaryReturn< One, MinusOne, Op > +{ + typedef typename BinaryReturn::Type_t Type_t; +}; + +template +struct BinaryReturn< MinusOne, One, Op > +{ + typedef typename BinaryReturn::Type_t Type_t; +}; + + + +#endif + +// ACL:rcsinfo +// ---------------------------------------------------------------------- +// $RCSfile: One.h,v $ $Author: swhaney $ +// $Revision: 1.6 $ $Date: 2000/03/07 13:18:17 $ +// ---------------------------------------------------------------------- +// ACL:rcsinfo diff --minimal -Nru a/r2/src/Tiny/Zero.h b/r2/src/Tiny/Zero.h --- a/r2/src/Tiny/Zero.h Wed Jul 24 10:55:50 2002 +++ b/r2/src/Tiny/Zero.h Wed Jul 24 10:55:50 2002 @@ -30,14 +30,14 @@ #define POOMA_TINY_ZERO_H //----------------------------------------------------------------------------- - // Class: Zero //----------------------------------------------------------------------------- -//----------------------------------------------------------------------------- -// Overview: -// A numeric class for a number that is always zero. -//----------------------------------------------------------------------------- +/** @file + * @ingroup Tiny + * @brief + * A numeric class for a number that is always zero. + */ //----------------------------------------------------------------------------- // Typedefs: @@ -53,7 +53,7 @@ //----------------------------------------------------------------------------- // -// Full Description: +/** // // The point of this class is to be a number of type T which is known at // compile time to be zero. This is reflected in the operations like @@ -63,21 +63,22 @@ // // Zero is templated on type T, to represent a zero object of type T. // Type T is required to be constructable from an integer zero. -// +*/ //----------------------------------------------------------------------------- template -class Zero +struct Zero { - // If you need to convert to an object of type T, - // just build one from zero. This will be used in - // the cases where the operators below don't match. + /// If you need to convert to an object of type T, + /// just build one from zero. This will be used in + /// the cases where the operators below don't match. - operator T() { return T(0); } + operator T() const { return T(0); } + bool operator==(const Zero&) const { return true; } - // Give it empty ctors and assignment operators - // to try and keep purify happy. + /// Give it empty ctors and assignment operators + /// to try and keep purify happy. Zero() {} Zero(const Zero&) {} @@ -236,31 +237,20 @@ // // Trait class definitios for the cases where the Zero gets -// converted to a T. +// converted to a T. Traits with just one Zero specialization +// are ambigous if operator is not specified. // -template -struct UnaryReturn< Zero , Op > -{ - typedef typename UnaryReturn::Type_t Type_t; -}; - -template -struct BinaryReturn< Zero , T2, Op > -{ - typedef typename BinaryReturn::Type_t Type_t; -}; - template -struct BinaryReturn< T1 , Zero, Op > +struct BinaryReturn< Zero , Zero, Op > { typedef typename BinaryReturn::Type_t Type_t; }; -template -struct BinaryReturn< Zero , Zero, Op > +template +struct BinaryReturn< Zero, Zero, OpEQ > { - typedef typename BinaryReturn::Type_t Type_t; + typedef bool Type_t; }; From rguenth at tat.physik.uni-tuebingen.de Mon Jul 29 18:48:23 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Mon, 29 Jul 2002 20:48:23 +0200 (CEST) Subject: [pooma-dev] [PATCH] Fix Tiny/Zero.h, add Tiny/One.h, new testcase In-Reply-To: <20020729101634.A18365@codesourcery.com> Message-ID: On Mon, 29 Jul 2002, Jeffrey Oldham wrote: > On Wed, Jul 24, 2002 at 11:07:44AM +0200, Richard Guenther wrote: > > > > The attached patch introduces Tiny/One.h and a new testcase to > > check ConstantFunction engine and Tiny/Zero.h, Tiny/One.h. Tiny/Zero.h > > is also fixed (as in the previously sent patch + additional fixes). > > This and the other patches are great! I appreciate your work, and I > read the emails, but CodeSourcery cannot incorporate the changes > without a copyright assignment analogous to how the Free Software > Foundation (FSF) handles contributions to the GCC compiler suite. > CodeSourcery is working on writing such an agreement. Are you willing > to sign such an agreement? While I dont have objections in assigning copyright to the FSF for gcc which is GPL, I would like to have a more elaborate statement on why CodeSourcery needs copyright assignment for pooma (which is sort of BSD license with advertising clause). Regarding to the advertising clause - is it necessary to put it on new files? I'd rather place an LGPL license in my contributed files, but like to hear wether this imposes restrictions on the use for pooma users. Also I do the work on pooma as part of a Deutsche Forschungsgesellschaft funded work, so I may not be allowed to give away copyright (in fact, I may not own copyright anyway!?). So in any case I have to ask the local legal department on this. How do other users think of the license/copyright issues? Thanks, Richard. Btw. - patches/work done by me on pooma so far can be viewed beyond http://www.tat.physik.uni-tuebingen.de/~rguenth/pooma/ -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From rguenth at tat.physik.uni-tuebingen.de Mon Jul 29 18:55:28 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Mon, 29 Jul 2002 20:55:28 +0200 (CEST) Subject: [pooma-dev] [PATCH] Fix Tiny/Zero.h, add Tiny/One.h, new testcase In-Reply-To: Message-ID: I just re-read the LICENSE file and am confused about [...] The U.S. Government has rights to use, reproduce, and distribute this SOFTWARE. The public may copy, distribute, prepare derivative works and publicly display this SOFTWARE without charge, provided that this Notice and any statement of authorship are reproduced on all copies. [...] while the U.S. Government is given the rights to use pooma, the public is not, but may only copy, distribute & prepare derivative works, etc.!? But in the next sentence liability for the use is denied (but this may just apply to the U.S. Government). Oh well, license stuff. If only we could switch to BSD w/o advertising clause... Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From oldham at codesourcery.com Tue Jul 30 17:11:33 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 30 Jul 2002 10:11:33 -0700 Subject: Patch: Fix Manual Mistakes Message-ID: <20020730101133.A23646@codesourcery.com> 2002-Jul-30 Jeffrey D. Oldham * index.html: Fix incorrect hyperlink. * manual/README.txt: Update tips on how to compile the manual. * manual/introduction.xml: Remove the duplicate history section. * manual/preface.xml: Replace existing history section with one that is indexed. Tested by viewing the HTML and remaking the manual on Linux RedHat 7.2. Approved by Jim Crotinger Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: index.html =================================================================== RCS file: /home/pooma/Repository/r2/docs/index.html,v retrieving revision 1.1 diff -c -p -r1.1 index.html *** index.html 2001/03/19 16:11:13 1.1 --- index.html 2002/07/30 17:04:19 *************** the new material, as well as the origina *** 20,26 ****

Parallelism Models: Messaging and Threads

!

Layouts

New description of Particles

Text I/O

Object I/O

--- 20,26 ----

Parallelism Models: Messaging and Threads

!

Layouts

New description of Particles

Text I/O

Object I/O

Index: manual/README.txt =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/README.txt,v retrieving revision 1.1 diff -c -p -r1.1 README.txt *** manual/README.txt 2002/02/01 17:43:13 1.1 --- manual/README.txt 2002/07/30 17:04:19 *************** If you have having trouble with: *** 37,42 **** --- 37,43 ---- DocBook stylesheets. Modify pooma.xml's DOCTYPE line to specify the location of the DocBook docbookx.dtd. + Modify $(XML) in Makefile to the correct location for xml.dcl. jadetex: Ensure it has large enough TeX capacities. See http://jadetex.sourceforge.net. Index: manual/introduction.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/introduction.xml,v retrieving revision 1.7 diff -c -p -r1.7 introduction.xml *** manual/introduction.xml 2002/01/30 23:51:45 1.7 --- manual/introduction.xml 2002/07/30 17:04:19 *************** while (iterA != A.end()) { *** 426,613 **** &poomatoolkit; is low-risk software. - -
- History of &pooma; - - - &pooma; - history - - - Los Alamos National Laboratory - - - The &poomatoolkit; was developed at Los Alamos National - Laboratory to assist nuclear fusion - - fusion - - and fission - - fission - - research. - In 1994, the &toolkit; grew out of the Object-Oriented Particle Simulation - - Object-Oriented Particle Simulation Library - - 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 - - Tokamak - - 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. -
- - Parallel Platform Paradox - - The framework's goal of being able to quickly write efficient - scientific code that could be run on a wide variety of platforms - remains unchanged today. Development, mainly at the - Advanced Computing Laboratory - - Los Alamos National Laboratory - Advanced Computing Laboratory - - at Los Alamos, proceeded rapidly. A matrix solver application was - written using the framework. - - Support for hydrodynamics, - - hydrodynamics - - Monte Carlo simulations, - - Monte Carlo simulation - - and molecular dynamics - - molecular dynamics modeling - - modeling soon followed. - - - By 1998, &pooma; was part of the U.S. Department of - Energy's - - Department of Energy - - Accelerated Strategic Computing Initiative - (ASCI). - - Department of Energy - Accelerated Strategic Computing Initiative - - - Accelerated Strategic Computing Initiative - Department of Energy, Accelerated Strategic Computing Initiative. - - The Comprehensive Test Ban Treaty - - 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. A linear accelerator code linac and a 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 - - &array; - - was introduced with its use of &engine;s, - - &engine; - - separating - container use from container storage. A new asynchronous scheduler - permitted out-of-order execution - - out-of-order evaluation - - to improve cache coherency. - Incorporating the Portable - Expression Template Engine (PETE) - - &pete; - - permitted faster loop execution. Soon, container views - - container - view - - and - ConstantFunction - - &engine; - ConstantFunction - - and IndexFunction - - &engine; - IndexFunction - - &engine;s were added. Release 2.1.0 included &field;s - - &field; - - with - their spatial extent and &dynamicarray;s - - &dynamicarray; - - 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 - - &cheetah; - - separated &pooma; from the actual messaging - library used, and support for applications running on clusters of - computers was added. CodeSourcery, LLC, - - CodeSourcery, LLC - - and - Proximation, LLC, - - Proximation, LLC - - took - over &pooma; development from Los Alamos National Laboratory. - During the past two years, the &field; - abstraction - - &field; - - and implementation was improved to increase its - flexibility, add support for multiple values and materials in the - same cell, and permit lazy evaluation. - - lazy evaluation - - Simultaneously, the - execution speed of the inner loops was greatly increased. -
- --- 426,429 ---- Index: manual/preface.xml =================================================================== RCS file: /home/pooma/Repository/r2/docs/manual/preface.xml,v retrieving revision 1.2 diff -c -p -r1.2 preface.xml *** manual/preface.xml 2002/03/04 23:48:09 1.2 --- manual/preface.xml 2002/07/30 17:04:19 *************** *** 281,350 **** !
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 --- 281,468 ----
!
History of &pooma; + + &pooma; + history + + + Los Alamos National Laboratory + + The &poomatoolkit; was developed at Los Alamos National ! Laboratory to assist nuclear fusion ! ! fusion ! ! and fission ! ! fission ! ! research. ! In 1994, the &toolkit; grew out of the Object-Oriented Particle Simulation ! ! Object-Oriented Particle Simulation Library ! ! 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 ! ! Tokamak ! ! 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. !
! ! Parallel Platform Paradox ! ! The framework's goal of being able to quickly write efficient ! scientific code that could be run on a wide variety of platforms ! remains unchanged today. Development, mainly at the ! Advanced Computing Laboratory ! ! Los Alamos National Laboratory ! Advanced Computing Laboratory ! ! at Los Alamos, proceeded rapidly. A matrix solver application was ! written using the framework. ! ! Support for hydrodynamics, ! ! hydrodynamics ! ! Monte Carlo simulations, ! ! Monte Carlo simulation ! ! and molecular dynamics ! ! molecular dynamics modeling ! ! modeling soon followed. ! ! By 1998, &pooma; was part of the U.S. Department of ! Energy's ! ! Department of Energy ! ! Accelerated Strategic Computing Initiative ! (ASCI). ! ! Department of Energy ! Accelerated Strategic Computing Initiative ! ! ! Accelerated Strategic Computing Initiative ! Department of Energy, Accelerated Strategic Computing Initiative. ! ! The Comprehensive Test Ban Treaty ! ! 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. A linear accelerator code linac and a 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 ! ! &array; ! ! was introduced with its use of &engine;s, ! ! &engine; ! ! separating ! container use from container storage. A new asynchronous scheduler ! permitted out-of-order execution ! ! out-of-order evaluation ! ! to improve cache coherency. ! Incorporating the Portable ! Expression Template Engine (PETE) ! ! &pete; ! ! permitted faster loop execution. Soon, container views ! ! container ! view ! ! and ! ConstantFunction ! ! &engine; ! ConstantFunction ! ! and IndexFunction ! ! &engine; ! IndexFunction ! ! &engine;s were added. Release 2.1.0 included &field;s ! ! &field; ! ! with ! their spatial extent and &dynamicarray;s ! ! &dynamicarray; ! ! 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 ! ! &cheetah; ! ! separated &pooma; from the actual messaging library used, and support for applications running on clusters of computers was added. CodeSourcery, LLC, ! ! CodeSourcery, LLC ! ! and Proximation, LLC, ! ! Proximation, LLC ! ! took ! over &pooma; development from Los Alamos National Laboratory. ! During the past two years, the &field; ! abstraction ! ! &field; ! ! and implementation was improved to increase its ! flexibility, add support for multiple values and materials in the ! same cell, and permit lazy evaluation. ! ! lazy evaluation ! ! Simultaneously, the ! execution speed of the inner loops was greatly increased.
Acknowledgements