From rguenth at tat.physik.uni-tuebingen.de Thu May 2 15:04:58 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 2 May 2002 17:04:58 +0200 (CEST) Subject: Pooma/Cheetah and MPI Message-ID: Hi! I tried to use MPI to parallelize a pooma application and stumbeled over the following problem: A simple mpirun -np 4 myprog -mpi does not work, the first process gets spawned, but just runs as in uniprocessor mode. The problem is, the spawned processes dont get the -mpi parameter and such dont call MPI_Init. The problem is in Cheetah ControllerFactory::create which _removes_ the controller argument (-mpi) from the argument list and as such the master MPI_Init and any further MPI_Init's dont see it. I worked around this by manually re-inserting -mpi to the arguments list in my program, but of course this is not a solution to the problem. A fix would be to move the argument removal in Cheetah to _after_ the MPI_Init call. Anyone with a different solution to the problem? I'll happily contribute the above suggestion, if nobody has a fix already. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From jcrotinger at proximation.com Thu May 2 16:29:21 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Thu, 2 May 2002 10:29:21 -0600 Subject: [pooma-dev] Pooma/Cheetah and MPI Message-ID: I believe Cheetah is still being actively developed at LANL. Check the readme files in the Cheetah distribution - there should be some contact information there somewhere. You might also check the www.acl.lanl.gov page. Jim >-----Original Message----- >From: Richard Guenther [mailto:rguenth at tat.physik.uni-tuebingen.de] >Sent: Thursday, May 02, 2002 9:05 AM >To: pooma-dev at pooma.codesourcery.com >Subject: [pooma-dev] Pooma/Cheetah and MPI > >Hi! > >I tried to use MPI to parallelize a pooma application and stumbeled >over the following problem: > >A simple mpirun -np 4 myprog -mpi does not work, the first process >gets spawned, but just runs as in uniprocessor mode. The problem is, >the spawned processes dont get the -mpi parameter and such dont >call MPI_Init. > >The problem is in Cheetah ControllerFactory::create which _removes_ >the controller argument (-mpi) from the argument list and as such >the master MPI_Init and any further MPI_Init's dont see it. > >I worked around this by manually re-inserting -mpi to the arguments >list in my program, but of course this is not a solution to the problem. >A fix would be to move the argument removal in Cheetah to _after_ the >MPI_Init call. > >Anyone with a different solution to the problem? I'll happily contribute >the above suggestion, if nobody has a fix already. > >Richard. > >-- >Richard Guenther >WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ >The GLAME Project: http://www.glame.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rguenth at tat.physik.uni-tuebingen.de Fri May 3 12:18:47 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Fri, 3 May 2002 14:18:47 +0200 (CEST) Subject: Accessing remote parts of a Field Message-ID: Hi! I'd like to know how to access (efficiently) remote parts of a Field. I.e. suppose I have a layout, I want to iterate through all sub-domains and aquirie a local (read-only) copy of each domain. Also the reverse operation, i.e. constructing locally the sub-domains and transferring them to the appropriate remote location. I need this for (serial) I/O. Any suggestions? Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From nilsb at cns.mpg.de Tue May 7 16:59:00 2002 From: nilsb at cns.mpg.de (Nils H. Busch) Date: Tue, 07 May 2002 18:59:00 +0200 Subject: Memory overhead Message-ID: <3CD807D3.3AD9FC4E@cns.mpg.de> Hello, can someone give me a rough estimation of what will be the memory overhead for using Pooma::Arrays and Pooma::Fields. For using small arrays/fields, my experiments showed that there seems to be a constant base amount of about 6MB (using Pooma v 2.3 on an Origin 2000 with SGI CC v 7.3). For larger arrays/fields the ratio of memory needed theoretically for a data set to the memory actually occupied showed roughly a 60% overhead for the latter. Is this reasonable ? Which parts of pooma require the additional memory ? First, I thought, the 60% increase would only happen when using Fields and the underlying position arrays needed the extra memory, but using arrays showed the same increase. Also, the old tutorial states that all mesh classes have guard layers the size of N/2, N being the number of vertices along an axis. For large high-dimensional meshes, I think, this could be quite a large memory overhead, if actually memory is allocated for the guard layers. Is really memory allocated and if so, can this fixed guard layer size be adjusted to what is really required prior to memory allocation ? Thanks for any comments. -- Nils H. Busch Max-Planck-Institute of Cognitive Neuroscience phone: ++49 (341) 9940-335 fax: ++49 (341) 9940-204 e-mail: nilsb at cns.mpg.de From rguenth at tat.physik.uni-tuebingen.de Fri May 10 14:51:50 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Fri, 10 May 2002 16:51:50 +0200 (CEST) Subject: Reference documentation Message-ID: Hi! I see there is a lot of in-source reference documentation (good!), but its hard to find. Is the way the documentation is formatted usable by any documentation-generating utility? I tried to throw doxygen at it, but that doesnt recognize the comments. Did you use any such tools during development? If not, I'll probably change comments to be able to be recognized by doxygen. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From oldham at codesourcery.com Mon May 13 16:55:41 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Mon, 13 May 2002 09:55:41 -0700 Subject: [pooma-dev] Reference documentation In-Reply-To: ; from rguenth@tat.physik.uni-tuebingen.de on Fri, May 10, 2002 at 04:51:50PM +0200 References: Message-ID: <20020513095541.D8609@codesourcery.com> On Fri, May 10, 2002 at 04:51:50PM +0200, Richard Guenther wrote: > Hi! > > I see there is a lot of in-source reference documentation (good!), but > its hard to find. Is the way the documentation is formatted usable by > any documentation-generating utility? I tried to throw doxygen at it, but > that doesnt recognize the comments. Did you use any such tools during > development? No. > If not, I'll probably change comments to be able to be recognized by > doxygen. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Wed May 15 10:15:43 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 15 May 2002 12:15:43 +0200 (CEST) Subject: Preliminary reference documentation available Message-ID: Hi! I put my work-in-progress doxygenifizing the documentation inside the pooma source online at http://www.tat.physik.uni-tuebingen.de/~rguenth/pooma-reference-documentation/ At the moment, mainly the summaries / class descriptions are available, method documentation will follow as I need them. 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 Thu May 16 07:51:53 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 16 May 2002 09:51:53 +0200 (CEST) Subject: [pooma-dev] Preliminary reference documentation available In-Reply-To: Message-ID: On Wed, 15 May 2002, James Crotinger wrote: > Cool. The last time we tried a tool like this, it choked on too much of our > crazy template syntax. Looks like the tools may be catching up with the > language. Yes, its quite usable - maybe I need teach doxygen to better group partially specialized templates, though. > One annoyance, however, is that this ends up including a lot of classes that > are totally implementation details of other classes and would never be seen > by a normal user. Due to all the compile-time tricks, this may well be the > case for most of the classes. Yes - I'll be able to hide classes from the documentation (though I thought the reference documentation be useful for the developer of the code, too - i.e. I'm actually going to implement HDF5 I/O, AMR and in conjunction with that a generic (time) integrator scheme). If anyone has hints which classes to hide or wants to contribute extra documentation be my guest. I will see if I can make my local bitkeeper tree available for cloning (need to talk to the sysadmins here). 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 Thu May 16 14:57:34 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 16 May 2002 16:57:34 +0200 (CEST) Subject: Using CoordinateSystems Message-ID: Hi! How am I supposed to use CoordinateSystems like f.i. Cylindrical? I see that the CoordinateSystems classes provide methods like volume and distance taking Regions/Vectors in coordinates in the respective coordinate system. But on the other hand a Mesh gets initialized with a Cartesian domain only(?). And the PositionTraits::Type_t of the Mesh always yields Cartesian components as there is no place to specify an alternate coordinate system? I'm confused... Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From oldham at codesourcery.com Mon May 20 22:45:44 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Mon, 20 May 2002 15:45:44 -0700 Subject: [pooma-dev] Using CoordinateSystems In-Reply-To: ; from rguenth@tat.physik.uni-tuebingen.de on Thu, May 16, 2002 at 04:57:34PM +0200 References: Message-ID: <20020520154544.B339@codesourcery.com> On Thu, May 16, 2002 at 04:57:34PM +0200, Richard Guenther wrote: > > How am I supposed to use CoordinateSystems like f.i. Cylindrical? > I see that the CoordinateSystems classes provide methods like > volume and distance taking Regions/Vectors in coordinates in the > respective coordinate system. But on the other hand a Mesh gets > initialized with a Cartesian domain only(?). And the > PositionTraits::Type_t of the Mesh always yields Cartesian components > as there is no place to specify an alternate coordinate system? I do not think that full POOMA support for using different coordinate systems was ever implemented. (Will someone please correct me if I am wrong?) docs/tut-07.html describes using meshes, centerings, geometries, and fields, but the new Field implementation might have made some of this out-of-date. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Mon May 20 22:52:56 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Mon, 20 May 2002 15:52:56 -0700 Subject: [pooma-dev] Memory overhead In-Reply-To: <3CD807D3.3AD9FC4E@cns.mpg.de>; from nilsb@cns.mpg.de on Tue, May 07, 2002 at 06:59:00PM +0200 References: <3CD807D3.3AD9FC4E@cns.mpg.de> Message-ID: <20020520155256.D339@codesourcery.com> On Tue, May 07, 2002 at 06:59:00PM +0200, Nils H. Busch wrote: > Hello, > > can someone give me a rough estimation of what will be the memory > overhead for using Pooma::Arrays and Pooma::Fields. > > For using small arrays/fields, my experiments showed that there seems to > be a constant base amount of about 6MB (using Pooma v 2.3 on an Origin > 2000 with SGI CC v 7.3). > For larger arrays/fields the ratio of memory needed theoretically for a > data set to the memory actually occupied showed roughly a 60% overhead > for the latter. > > Is this reasonable ? Which parts of pooma require the additional memory > ? First, I thought, the 60% increase would only happen when using Fields > and the underlying position arrays needed the extra memory, > but using arrays showed the same increase. > > Also, the old tutorial states that all mesh classes have guard layers > the size of N/2, N being the number of vertices along an axis. For large > high-dimensional meshes, I think, this could be quite a large memory > overhead, if actually memory is allocated for the guard layers. Is > really memory allocated and if so, can this fixed guard layer size be > adjusted to what is really required prior to memory allocation ? The new Field interface, available from the POOMA CVS tree, permits specifying the mesh so explicit control of the guard layers is permitted. > Thanks for any comments. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Tue May 21 08:52:15 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 21 May 2002 10:52:15 +0200 (CEST) Subject: [pooma-dev] Using CoordinateSystems In-Reply-To: <20020520154544.B339@codesourcery.com> Message-ID: On Mon, 20 May 2002, Jeffrey Oldham wrote: > On Thu, May 16, 2002 at 04:57:34PM +0200, Richard Guenther wrote: > > > > How am I supposed to use CoordinateSystems like f.i. Cylindrical? > > I see that the CoordinateSystems classes provide methods like > > volume and distance taking Regions/Vectors in coordinates in the > > respective coordinate system. But on the other hand a Mesh gets > > initialized with a Cartesian domain only(?). And the > > PositionTraits::Type_t of the Mesh always yields Cartesian components > > as there is no place to specify an alternate coordinate system? > > I do not think that full POOMA support for using different coordinate > systems was ever implemented. (Will someone please correct me if I am > wrong?) > > docs/tut-07.html describes using meshes, centerings, geometries, and > fields, but the new Field implementation might have made some of this > out-of-date. Ok, did you have specific ideas on how to integrate support for different coordinate systems? If yes, I'm happy to go the suggested way, else I need to come up with ideas myself. Also, were there ideas on how to actually support something like AMR? From the current code I see that reduction operators for doing the neccesary interpolation do not exist. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From oldham at codesourcery.com Wed May 29 21:59:14 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 29 May 2002 14:59:14 -0700 Subject: [pooma-dev] Using CoordinateSystems In-Reply-To: ; from rguenth@tat.physik.uni-tuebingen.de on Tue, May 21, 2002 at 10:52:15AM +0200 References: <20020520154544.B339@codesourcery.com> Message-ID: <20020529145914.A17989@codesourcery.com> On Tue, May 21, 2002 at 10:52:15AM +0200, Richard Guenther wrote: > On Mon, 20 May 2002, Jeffrey Oldham wrote: > > > On Thu, May 16, 2002 at 04:57:34PM +0200, Richard Guenther wrote: > > > > > > How am I supposed to use CoordinateSystems like f.i. Cylindrical? > > > I see that the CoordinateSystems classes provide methods like > > > volume and distance taking Regions/Vectors in coordinates in the > > > respective coordinate system. But on the other hand a Mesh gets > > > initialized with a Cartesian domain only(?). And the > > > PositionTraits::Type_t of the Mesh always yields Cartesian components > > > as there is no place to specify an alternate coordinate system? > > > > I do not think that full POOMA support for using different coordinate > > systems was ever implemented. (Will someone please correct me if I am > > wrong?) > > > > docs/tut-07.html describes using meshes, centerings, geometries, and > > fields, but the new Field implementation might have made some of this > > out-of-date. > > Ok, did you have specific ideas on how to integrate support for different > coordinate systems? If yes, I'm happy to go the suggested way, else I need > to come up with ideas myself. > > Also, were there ideas on how to actually support something like AMR? From > the current code I see that reduction operators for doing the neccesary > interpolation do not exist. I believe Julien Cummings or Scott Haney was the person most involved in coordinate systems. I do not know if there is a suggested way. Jeffrey D. Oldham oldham at codesourcery.com