From jhall at swcp.com Tue Jul 6 19:52:24 2004 From: jhall at swcp.com (John H. Hall) Date: Tue, 6 Jul 2004 15:52:24 -0400 Subject: Open-Source licensing Message-ID: <004271B3-CF86-11D8-8432-000A958E5012@swcp.com> Gang: I have now been asked officially by Jeff Brown (LANL CCS-DO) to get these licensing issues straightened out which makes it official work instead of a part-time hobby. So I need to know which packages y'all want transferred out. I prefer the BSD license myself of the existing licenses out there but I am open to debate on this issue. So here is what I seem to remember. We want: Cheetah Pete Pooma R1 and R2 (R1 for compatibility issues) from the ACL. (Someone needs to remind me what is wrong with the license R2 was taken out under so I don't go down the same path.) And I would like to take out: TecFramework Poomalote Physics Support Layer from the now defunct Blanca project. Are there any other items I need to put in the hopper. Is this list sufficient for the VSIPL people? Thanks, John Hall New Open-Source minion P.S. Who owns the smarts package? From james.crotinger at numerix.com Tue Jul 6 19:56:18 2004 From: james.crotinger at numerix.com (James Crotinger) Date: Tue, 6 Jul 2004 13:56:18 -0600 Subject: [pooma-dev] Open-Source licensing Message-ID: SMARTS was ACL. Jim ------------------------------------------------------------------------ James A. Crotinger email: jimc at numerix.com NumeriX, LLC phone: (505) 424-4477 x104 2960 Rodeo Park Dr. W. Santa Fe, NM 87505 > -----Original Message----- > From: John H. Hall [mailto:jhall at swcp.com] > Sent: Tuesday, July 06, 2004 1:52 PM > To: 'pooma-dev at pooma.codesourcery.com' > Cc: Scott Haney; John Hall; Stephen Smith > Subject: [pooma-dev] Open-Source licensing > > Gang: > I have now been asked officially by Jeff Brown (LANL CCS-DO) to get > these licensing issues straightened out which makes it official work > instead of a part-time hobby. So I need to know which packages y'all > want transferred out. I prefer the BSD license myself of the existing > licenses out there but I am open to debate on this issue. So here is > what I seem to remember. > > We want: > > Cheetah > Pete > Pooma R1 and R2 (R1 for compatibility issues) > > from the ACL. > > (Someone needs to remind me what is wrong with the license R2 was taken > out under so I don't go down the same path.) > > And I would like to take out: > > TecFramework > Poomalote > Physics Support Layer > > from the now defunct Blanca project. > > Are there any other items I need to put in the hopper. Is this list > sufficient for the VSIPL people? > > Thanks, > John Hall > New Open-Source minion > > P.S. Who owns the smarts package? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhall at swcp.com Tue Jul 6 20:04:51 2004 From: jhall at swcp.com (John H. Hall) Date: Tue, 6 Jul 2004 16:04:51 -0400 Subject: [pooma-dev] Open-Source licensing In-Reply-To: References: Message-ID: So do we need to take it out as open source also? John Hall On Jul 6, 2004, at 3:56 PM, James Crotinger wrote: > SMARTS was ACL. > > ??????? Jim > > ----------------------------------------------------------------------- > - > James A. Crotinger?????????????????????????? email:???? > jimc at numerix.com > NumeriX, LLC???????????????????????????????? phone:? (505) 424-4477 > x104 > 2960 Rodeo Park Dr. W. > Santa Fe, NM 87505 > > > -----Original Message----- > > From: John H. Hall [mailto:jhall at swcp.com] > > Sent: Tuesday, July 06, 2004 1:52 PM > > To: 'pooma-dev at pooma.codesourcery.com' > > Cc: Scott Haney; John Hall; Stephen Smith > > Subject: [pooma-dev] Open-Source licensing > > > > Gang: > > I have now been asked officially by Jeff Brown (LANL CCS-DO) to get > > these licensing issues straightened out which makes it official work > > instead of a part-time hobby. So I need to know which packages y'all > > want transferred out. I prefer the BSD license myself of the existing > > licenses out there but I am open to debate on this issue. So here is > > what I seem to remember. > > > > We want: > > > > Cheetah > > Pete > > Pooma R1 and R2 (R1 for compatibility issues) > > > > from the ACL. > > > > (Someone needs to remind me what is wrong with the license R2 was > taken > > out under so I don't go down the same path.) > > > > And I would like to take out: > > > > TecFramework > > Poomalote > > Physics Support Layer > > > > from the now defunct Blanca project. > > > > Are there any other items I need to put in the hopper. Is this list > > sufficient for the VSIPL people? > > > > Thanks, > > John Hall > > New Open-Source minion > > > > P.S. Who owns the smarts package? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2678 bytes Desc: not available URL: From james.crotinger at numerix.com Tue Jul 6 20:06:39 2004 From: james.crotinger at numerix.com (James Crotinger) Date: Tue, 6 Jul 2004 14:06:39 -0600 Subject: [pooma-dev] Open-Source licensing Message-ID: I'd talk to Ron Minnich or someone back at the lab. If the lab isn't planning further work on these, then I don't see why not. Hmm - even if they are, I don't see why not. So why not? Cheers, Jim ------------------------------------------------------------------------ James A. Crotinger email: jimc at numerix.com NumeriX, LLC phone: (505) 424-4477 x104 2960 Rodeo Park Dr. W. Santa Fe, NM 87505 _____ From: John H. Hall [mailto:jhall at swcp.com] Sent: Tuesday, July 06, 2004 2:05 PM To: 'pooma-dev at pooma.codesourcery.com'; James Crotinger Cc: Scott Haney; Stephen Smith Subject: Re: [pooma-dev] Open-Source licensing So do we need to take it out as open source also? John Hall On Jul 6, 2004, at 3:56 PM, James Crotinger wrote: SMARTS was ACL. Jim ------------------------------------------------------------------------ James A. Crotinger email: jimc at numerix.com NumeriX, LLC phone: (505) 424-4477 x104 2960 Rodeo Park Dr. W. Santa Fe, NM 87505 > -----Original Message----- > From: John H. Hall [mailto:jhall at swcp.com] > Sent: Tuesday, July 06, 2004 1:52 PM > To: 'pooma-dev at pooma.codesourcery.com' > Cc: Scott Haney; John Hall; Stephen Smith > Subject: [pooma-dev] Open-Source licensing > > Gang: > I have now been asked officially by Jeff Brown (LANL CCS-DO) to get > these licensing issues straightened out which makes it official work > instead of a part-time hobby. So I need to know which packages y'all > want transferred out. I prefer the BSD license myself of the existing > licenses out there but I am open to debate on this issue. So here is > what I seem to remember. > > We want: > > Cheetah > Pete > Pooma R1 and R2 (R1 for compatibility issues) > > from the ACL. > > (Someone needs to remind me what is wrong with the license R2 was taken > out under so I don't go down the same path.) > > And I would like to take out: > > TecFramework > Poomalote > Physics Support Layer > > from the now defunct Blanca project. > > Are there any other items I need to put in the hopper. Is this list > sufficient for the VSIPL people? > > Thanks, > John Hall > New Open-Source minion > > P.S. Who owns the smarts package? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rguenth at tat.physik.uni-tuebingen.de Tue Jul 6 20:10:16 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 06 Jul 2004 22:10:16 +0200 Subject: [pooma-dev] Open-Source licensing In-Reply-To: <004271B3-CF86-11D8-8432-000A958E5012@swcp.com> References: <004271B3-CF86-11D8-8432-000A958E5012@swcp.com> Message-ID: <40EB0728.6030306@tat.physik.uni-tuebingen.de> John H.Hall wrote: > Gang: > I have now been asked officially by Jeff Brown (LANL CCS-DO) to get > these licensing issues straightened out which makes it official work > instead of a part-time hobby. So I need to know which packages y'all > want transferred out. I prefer the BSD license myself of the existing > licenses out there but I am open to debate on this issue. So here is > what I seem to remember. > > We want: > > Cheetah > Pete > Pooma R1 and R2 (R1 for compatibility issues) > > from the ACL. > > (Someone needs to remind me what is wrong with the license R2 was taken > out under so I don't go down the same path.) I think there was nothing "wrong" per se, but find the following wording confusing: "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." It tells about rights for "using" for the U.S. Government, but not for the public (that gets rights to "display" - whatever this is). I would go for a 2-clause BSD license, because we're so familiar with it. Richard. From rguenth at tat.physik.uni-tuebingen.de Tue Jul 6 20:13:56 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 06 Jul 2004 22:13:56 +0200 Subject: [pooma-dev] Open-Source licensing In-Reply-To: References: Message-ID: <40EB0804.8050400@tat.physik.uni-tuebingen.de> John H.Hall wrote: > So do we need to take it out as open source also? Yes - better than loose it. Though it looks like it is in the same state as POOMA r2 currently is. There may be also tau (profiling) and mm (distributed memory, used by cheetah), which also were from ACL if I remember correctly. Richard. > John Hall > On Jul 6, 2004, at 3:56 PM, James Crotinger wrote: > > SMARTS was ACL. > > Jim From oldham at codesourcery.com Tue Jul 6 20:20:11 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 06 Jul 2004 13:20:11 -0700 Subject: [pooma-dev] Open-Source licensing In-Reply-To: <004271B3-CF86-11D8-8432-000A958E5012@swcp.com> References: <004271B3-CF86-11D8-8432-000A958E5012@swcp.com> Message-ID: <40EB097B.3090505@codesourcery.com> John H. Hall wrote: > Gang: > I have now been asked officially by Jeff Brown (LANL CCS-DO) to get > these licensing issues straightened out which makes it official work > instead of a part-time hobby. So I need to know which packages y'all > want transferred out. I prefer the BSD license myself of the existing > licenses out there but I am open to debate on this issue. So here is > what I seem to remember. > > We want: > > Cheetah > Pete > Pooma R1 and R2 (R1 for compatibility issues) > > from the ACL. > > (Someone needs to remind me what is wrong with the license R2 was > taken out under so I don't go down the same path.) > > And I would like to take out: > > TecFramework > Poomalote > Physics Support Layer > > from the now defunct Blanca project. > > Are there any other items I need to put in the hopper. Is this list > sufficient for the VSIPL people? Thank you for pushing this forward for so long. For VSIPL++, POOMA and PETE probably suffice. Personally, I believe making as much software available to as wide an audience as possible is a good use of taxpayers' moneys. We'll let the marketplace decide which will survive. -- Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Wed Jul 7 17:22:59 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 07 Jul 2004 19:22:59 +0200 Subject: [RFC] Specialize (internal) guard cell handling, more data-flow analysis Message-ID: <40EC3173.30408@tat.physik.uni-tuebingen.de> I'm at the point thinking on how to improve MPI scalarization even more. And again the obvious point is we're doing way too much (unnecessary) communication. The problem is we "lower" the representation of guard cells and necessary updates of them too early (in the intersectors) and create usual iterates out of them. A better approach would be to compute necessary guards at intersection time only (as I introduced in the previous performance improvement patches), _not_ update them, but store this information in the iterates. We can then, before finally issuing the iterates, do data-flow analysis of the necessary guard cells and insert optimal update iterates at optimal places (in principle). As iterates are per-patch, in the process of getting the above done, I'd suggest moving the dirty flag and its handling from the MultiPatchEngine down to the BrickEngine, together with more accurate information about the up-to-date-ness of the guards (use f.i. a GuardLayer<> to count the up-to-date cells). Were there any previous plans on improving this situation within POOMA? Did you never experience performance problems with the communication? How did SMARTS improve situation with the guard updates (did it?)? Thanks for any input (before I start hacking this up)! Richard. From james.crotinger at numerix.com Wed Jul 7 17:34:37 2004 From: james.crotinger at numerix.com (James Crotinger) Date: Wed, 7 Jul 2004 11:34:37 -0600 Subject: [pooma-dev] [RFC] Specialize (internal) guard cell handling, more data-flow analysis Message-ID: It's closing in on four years since the POOMA team left the lab, so memory is rusting in this regard, but... Smarts did apply data-flow to filling the guards. However, it wasn't perfectly efficient as there was only one Smarts DataObject associated with each patch. More parallelism could have been achieved by having a data object for each guard region, and this idea was thrown around, but never seriously studied. (This would allow multiple parts of the brick to be written into in parallel - obviously care would have to be taken in implementing this.) We also discussed aggregating all of the guard updates for a single brick into a single iterate - the current behavior creates lots of small iterates and the overhead can kill you. This may be more along the lines of what you're considering. I personally don't like the idea of putting anything to do with guards, dirty-ness, etc in BrickEngine. It is a clean abstraction. If you need an enhanced abstraction for MultiPatchEngine to work with, then I'd build it on top of BrickEngine. That's my 2 pfennigs anyway. :) Jim ------------------------------------------------------------------------ James A. Crotinger email: jimc at numerix.com NumeriX, LLC phone: (505) 424-4477 x104 2960 Rodeo Park Dr. W. Santa Fe, NM 87505 > -----Original Message----- > From: Richard Guenther [mailto:rguenth at tat.physik.uni-tuebingen.de] > Sent: Wednesday, July 07, 2004 11:23 AM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] [RFC] Specialize (internal) guard cell handling, more > data-flow analysis > > I'm at the point thinking on how to improve MPI scalarization even more. > And again the obvious point is we're doing way too much (unnecessary) > communication. > > The problem is we "lower" the representation of guard cells and > necessary updates of them too early (in the intersectors) and create > usual iterates out of them. A better approach would be to compute > necessary guards at intersection time only (as I introduced in the > previous performance improvement patches), _not_ update them, but store > this information in the iterates. We can then, before finally issuing > the iterates, do data-flow analysis of the necessary guard cells and > insert optimal update iterates at optimal places (in principle). > > As iterates are per-patch, in the process of getting the above done, I'd > suggest moving the dirty flag and its handling from the MultiPatchEngine > down to the BrickEngine, together with more accurate information about > the up-to-date-ness of the guards (use f.i. a GuardLayer<> to count the > up-to-date cells). > > Were there any previous plans on improving this situation within POOMA? > Did you never experience performance problems with the communication? > How did SMARTS improve situation with the guard updates (did it?)? > > Thanks for any input (before I start hacking this up)! > > Richard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rguenth at tat.physik.uni-tuebingen.de Wed Jul 7 17:54:43 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 07 Jul 2004 19:54:43 +0200 Subject: [pooma-dev] [RFC] Specialize (internal) guard cell handling, more data-flow analysis In-Reply-To: References: Message-ID: <40EC38E3.1040402@tat.physik.uni-tuebingen.de> James Crotinger wrote: > It's closing in on four years since the POOMA team left the lab, so > memory is rusting in this regard, but... > > Smarts did apply data-flow to filling the guards. However, it wasn't > perfectly efficient as there was only one Smarts DataObject associated > with each patch. More parallelism could have been achieved by having a > data object for each guard region, and this idea was thrown around, but > never seriously studied. (This would allow multiple parts of the brick > to be written into in parallel - obviously care would have to be taken > in implementing this.) Yeah, I thought of this as well, but it's too complicated. I merely guess treating the guard updates as regular iterates (and exposing this fact too early - before data-flow analysis) is the main problem ... > We also discussed aggregating all of the guard updates for a single > brick into a single iterate - the current behavior creates lots of small > iterates and the overhead can kill you. This may be more along the lines > of what you're considering. ... which the above would support. And these single iterates indeed prevent you from implementing efficient guard communication schemes. > I personally don't like the idea of putting anything to do with guards, > dirty-ness, etc in BrickEngine. It is a clean abstraction. If you need > an enhanced abstraction for MultiPatchEngine to work with, then I'd > build it on top of BrickEngine. That's my 2 pfennigs anyway. :) Ok, first I thought on tackling external guards at the same time - and obviously BrickEngine may have external guards, so it fitted naturally. Also dirtying a patch-view of a MultiPatchEngine would work the right way then (I suppose it doesn't right now - but need to check). But yes, it should be even possible to leave it in MultiPatchEngine. Richard. > Jim From rkrylov at mail.ru Thu Jul 8 15:01:42 2004 From: rkrylov at mail.ru (Roman Krylov) Date: Thu, 08 Jul 2004 19:01:42 +0400 Subject: examples/Particles/PIC2d/PIC2d.cpp works Message-ID: <40ED61D6.1060407@mail.ru> It's about examples/Particles/PIC2d. I made it compilable and runnable, though I have no experience in CVS, and even in RCS so I can't express it that way. I had modified examples/Particles/PIC2d/PIC2d.cpp, src/Particles/Interpolation.cpp, src/Particles/InterpolatorNGP.h, created 2D spec. of grad(vert2cell only) in src/Field/DiffOps/Grad.h and Grad.UR.h In PIC2d.cpp I had to change '.x().comp(0)' to 'iota(1,nx).comp(0)' for example to make it work and some other subtleties. Does anybody working on it this time? Perhaps I'm wasting my time if it's all done already? Roman. From rguenth at tat.physik.uni-tuebingen.de Thu Jul 8 15:25:15 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 8 Jul 2004 17:25:15 +0200 (CEST) Subject: [pooma-dev] examples/Particles/PIC2d/PIC2d.cpp works In-Reply-To: <40ED61D6.1060407@mail.ru> References: <40ED61D6.1060407@mail.ru> Message-ID: On Thu, 8 Jul 2004, Roman Krylov wrote: > It's about examples/Particles/PIC2d. > I made it compilable and runnable, though I have no experience in CVS, > and even in RCS so I can't express it that way. You can get differences compared to the CVS version by issuing > cvs diff -u Interpolation.cpp f.i., or just > cvs diff -u for all directories beyond the current one. > I had modified > examples/Particles/PIC2d/PIC2d.cpp, > src/Particles/Interpolation.cpp, > src/Particles/InterpolatorNGP.h, > created 2D spec. of grad(vert2cell only) in src/Field/DiffOps/Grad.h and > Grad.UR.h > In PIC2d.cpp I had to change '.x().comp(0)' to > 'iota(1,nx).comp(0)' for example to make it work and some other subtleties. > Does anybody working on it this time? Perhaps I'm wasting my time if > it's all done already? I don't know of anyone working with Particles stuff, and I personally are not very interested in Particles. But surely it is useful to get Particle - Field interaction back to working. Richard. > Roman. > -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ From rguenth at tat.physik.uni-tuebingen.de Thu Jul 8 21:18:49 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 08 Jul 2004 23:18:49 +0200 Subject: [pooma-dev] examples/Particles/PIC2d/PIC2d.cpp works In-Reply-To: <40ED61D6.1060407@mail.ru> References: <40ED61D6.1060407@mail.ru> Message-ID: <40EDBA39.9030100@tat.physik.uni-tuebingen.de> Roman Krylov wrote: > It's about examples/Particles/PIC2d. > I made it compilable and runnable, though I have no experience in CVS, > and even in RCS so I can't express it that way. > I had modified > examples/Particles/PIC2d/PIC2d.cpp, > src/Particles/Interpolation.cpp, > src/Particles/InterpolatorNGP.h, > created 2D spec. of grad(vert2cell only) in src/Field/DiffOps/Grad.h and > Grad.UR.h > In PIC2d.cpp I had to change '.x().comp(0)' to > 'iota(1,nx).comp(0)' for example to make it work and some other subtleties. > Does anybody working on it this time? Perhaps I'm wasting my time if > it's all done already? > Roman. Btw., if you are wanting to contribute your improvements back to the official POOMA CVS you need to talk to the CodeSourcery people. There is some Copyright fuss to be done. But if there is enough momentum in the community, I guess (public) forking would be another option. Richard. From rguenth at tat.physik.uni-tuebingen.de Thu Jul 8 21:23:20 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 08 Jul 2004 23:23:20 +0200 Subject: [pooma-dev] examples/Particles/PIC2d/PIC2d.cpp works In-Reply-To: <40EDBA39.9030100@tat.physik.uni-tuebingen.de> References: <40ED61D6.1060407@mail.ru> <40EDBA39.9030100@tat.physik.uni-tuebingen.de> Message-ID: <40EDBB48.20201@tat.physik.uni-tuebingen.de> Richard Guenther wrote: > Btw., if you are wanting to contribute your improvements back to the I should have added "which would be appreciated". > official POOMA CVS you need to talk to the CodeSourcery people. There > is some Copyright fuss to be done. But if there is enough momentum in > the community, I guess (public) forking would be another option. > > Richard. > From rkrylov at mail.ru Fri Jul 9 14:04:38 2004 From: rkrylov at mail.ru (Roman Krylov) Date: Fri, 09 Jul 2004 18:04:38 +0400 Subject: [pooma-dev] examples/Particles/PIC2d/PIC2d.cpp works In-Reply-To: References: <40ED61D6.1060407@mail.ru> Message-ID: <40EEA5F6.1070301@mail.ru> Perhaps some changes were unnecessary, I was experiencing. Here they are: ---------- Index: examples/Particles/PIC2d/PIC2d.cpp =================================================================== RCS file: /home/pooma/Repository/r2/examples/Particles/PIC2d/PIC2d.cpp,v retrieving revision 1.19 diff -u -r1.19 PIC2d.cpp --- examples/Particles/PIC2d/PIC2d.cpp 21 Sep 2001 20:27:21 -0000 1.19 +++ examples/Particles/PIC2d/PIC2d.cpp 9 Jul 2004 13:55:04 -0000 @@ -33,16 +33,23 @@ // static electric field using nearest-grid-point interpolation. //----------------------------------------------------------------------------- +#include "Field/FieldCentering.h" +#include "Field/DiffOps/Grad.h" +#include "Field/DiffOps/Grad.UR.h" +#include "Particles/InterpolatorNGP.h" +#include "Particles/Interpolation.h" #include "Pooma/Particles.h" #include "Pooma/DynamicArrays.h" #include "Pooma/Fields.h" #include "Utilities/Inform.h" +#include "Pooma/Indices.h" + #include #include #include // Traits class for Particles object -template struct PTraits { @@ -50,7 +57,7 @@ typedef EngineTag AttributeEngineTag_t; // The type of particle layout to use - typedef SpatialLayout,FL> + typedef SpatialLayout ParticleLayout_t; // The type of interpolator to use @@ -87,6 +94,7 @@ DynamicArray R; DynamicArray V; DynamicArray E; + DynamicArray phi; // for testing purposes of course DynamicArray qm; }; @@ -102,24 +110,25 @@ #endif // Mesh type -typedef UniformRectilinearMesh,double> Mesh_t; +typedef UniformRectilinearMesh,*/double> Mesh_t; // Centering of Field elements on mesh -typedef Cell Centering_t; +//typedef CanonicalCentering::CellType Centering_t; +//static const int Centering_t = CanonicalCentering::CellType; // Geometry type for Fields -typedef DiscreteGeometry Geometry_t; +//typedef DiscreteGeometry Geometry_t; // Field types #if POOMA_CHEETAH -typedef Field< Geometry_t, double, +typedef Field< Mesh_t, double, MultiPatch< UniformTag, Remote > > DField_t; -typedef Field< Geometry_t, Vector, +typedef Field< Mesh_t, Vector, MultiPatch< UniformTag, Remote > > VecField_t; #else -typedef Field< Geometry_t, double, +typedef Field< Mesh_t, double, MultiPatch > DField_t; -typedef Field< Geometry_t, Vector, +typedef Field< Mesh_t, Vector, MultiPatch > VecField_t; #endif @@ -131,7 +140,7 @@ typedef NGP InterpolatorTag_t; // Particle traits class -typedef PTraits PTraits_t; // Type of particle layout @@ -153,7 +162,7 @@ const double pi = acos(-1.0); // Maximum value for particle q/m ratio -const double qmmax = 1.0; +const double qmmax = 10;//1.0; // Timestep const double dt = 1.0; @@ -169,35 +178,61 @@ out << "-------------------------" << std::endl; // Create mesh and geometry objects for cell-centered fields. + Loc blocks(4,4); + UniformGridPartition<2> partition( + Loc<2>(1, 1), + GuardLayers<2>(1), // internal + GuardLayers<2>(0) + ); // external Interval meshDomain(nx+1,ny+1); - Mesh_t mesh(meshDomain); - Geometry_t geometry(mesh); + FLayout_t flayout(meshDomain,partition,DistributedTag()); + Mesh_t mesh(flayout, Vector<2>(0.0), Vector<2>(1.0, 1.0));//(meshDomain); + Centering<2> cell = + canonicalCentering<2>(CellType, Continuous, AllDim); + /*Geometry_t geometry(mesh);*/ // Create a second geometry object that includes a guard layer. - GuardLayers gl(1); - Geometry_t geometryGL(mesh,gl); +// GuardLayers gl(1); +// FLayout_t flayoutGL(meshDomain,partition,DistributedTag()); + /*Geometry_t geometryGL(mesh,gl);*/ // Create field layout objects for our electrostatic potential // and our electric field. Decomposition is 4 x 4. - Loc blocks(4,4); - FLayout_t flayout(geometry.physicalDomain(),blocks,DistributedTag()); - FLayout_t flayoutGL(geometryGL.physicalDomain(),blocks,gl,DistributedTag()); +// Loc blocks(4,4); +// FLayout_t flayout(mesh.physicalDomain(),blocks,DistributedTag()); +// FLayout_t flayoutGL(geometryGL.physicalDomain(),blocks,gl,DistributedTag()); // Create and initialize electrostatic potential and electric field. - DField_t phi(geometryGL,flayoutGL); - VecField_t EFD(geometry,flayout); + DField_t phi(cell,flayout,mesh); + VecField_t EFD(cell,flayout,mesh); // potential phi = phi0 * sin(2*pi*x/Lx) * cos(4*pi*y/Ly) // Note that phi is a periodic Field // Electric field EFD = -grad(phi); - Pooma::addAllPeriodicFaceBC(phi, 0.0); +// Pooma::addAllPeriodicFaceBC(phi, 0.0); + phi.addRelation(new Relation0 >(phi,PeriodicFaceBC(0))); + phi.addRelation(new Relation0 >(phi,PeriodicFaceBC(1))); + phi.addRelation(new Relation0 >(phi,PeriodicFaceBC(2))); + phi.addRelation(new Relation0 >(phi,PeriodicFaceBC(3))); double phi0 = 0.01 * static_cast(nx); - phi = phi0 * sin(2.0*pi*phi.x().comp(0)/nx) - * cos(4.0*pi*phi.x().comp(1)/ny); - EFD = -grad(phi); + phi = phi0 * sin(2.0*pi*iota(1,nx).comp(0)/nx) + * cos(4.0*pi*iota(1,ny).comp(1)/ny); +// phi = 100; + EFD = -gradVertToCell(phi); + + PrintArray pa; + out << "potential: " << std::endl; + pa.setDataWidth(10); + pa.setScientific(true); + pa.print(out.stream(),phi); + out << "electric field(to test does grad(phi) work): " << std::endl; + pa.setDataWidth(10); + pa.setScientific(true); + pa.print(out.stream(),EFD); + // Create a particle layout object for our use - PLayout_t layout(geometry,flayout); + PLayout_t layout(mesh,flayout); // Create a Particles object and set periodic boundary conditions Particles_t P(layout); @@ -233,7 +268,6 @@ out << "---------------------" << std::endl; // Display the initial particle positions, velocities and qm values. - PrintArray pa; pa.setCarReturn(5); out << "Initial particle data:" << std::endl; out << "Particle positions: " << std::endl; @@ -244,6 +278,11 @@ pa.setDataWidth(10); pa.setScientific(true); pa.print(out.stream(),P.V); + out << "Field: " << std::endl; + pa.setDataWidth(10); + pa.setScientific(true); + pa.print(out.stream(),P.V); + out << "Particle charge-to-mass ratios: " << std::endl; pa.print(out.stream(),P.qm); @@ -266,6 +305,7 @@ out << "Advance particle velocities ..." << std::endl; P.V = P.V + dt * P.qm * P.E; } +// gather( P.phi, phi, P.R, Particles_t::InterpolatorTag_t() );//joke :0 // Display the final particle positions, velocities and qm values. out << "PIC2d timestep loop complete!" << std::endl; @@ -281,6 +321,11 @@ pa.print(out.stream(),P.V); out << "Particle charge-to-mass ratios: " << std::endl; pa.print(out.stream(),P.qm); + + out << "Field: " << std::endl; + pa.setDataWidth(10); + pa.setScientific(true); + pa.print(out.stream(),phi); // Shut down POOMA and exit out << "End PIC2d example code." << std::endl; Index: src/Particles/Interpolation.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Particles/Interpolation.h,v retrieving revision 1.7 diff -u -r1.7 Interpolation.h --- src/Particles/Interpolation.h 26 Oct 2003 12:27:36 -0000 1.7 +++ src/Particles/Interpolation.h 9 Jul 2004 13:55:10 -0000 @@ -50,7 +50,7 @@ //----------------------------------------------------------------------------- // Includes: //----------------------------------------------------------------------------- - +#include "Evaluator/PatchFunction.h" //----------------------------------------------------------------------------- // Forward Declarations: //----------------------------------------------------------------------------- Index: src/Particles/InterpolatorNGP.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Particles/InterpolatorNGP.h,v retrieving revision 1.13 diff -u -r1.13 InterpolatorNGP.h --- src/Particles/InterpolatorNGP.h 26 Oct 2003 12:27:36 -0000 1.13 +++ src/Particles/InterpolatorNGP.h 9 Jul 2004 13:55:12 -0000 @@ -160,7 +160,7 @@ // Create a PatchFunction using this functor PatchFunction< NGPGather, - PatchParticle2 > patchfun(intfun); + PatchParticle2 > patchfun(intfun); // Apply the PatchFunction to the attribute using the // particle position attribute @@ -444,14 +444,16 @@ Size_t i; Loc indx; - typedef typename Field_t::Geometry_t Geometry_t; - const Geometry_t& geom = field_m.geometry(); + typedef typename Field_t::Mesh_t Mesh_t; +// typedef typename Field_t::Mesh_t Geometry_t; +// const Geometry_t& geom = field_m.geometry(); + const Mesh_t& mesh = field_m.mesh(); for (i=0; iOn Thu, 8 Jul 2004, Roman Krylov wrote: > > > >>It's about examples/Particles/PIC2d. >>I made it compilable and runnable, though I have no experience in CVS, >>and even in RCS so I can't express it that way. >> >> > >You can get differences compared to the CVS version by issuing > > > >>cvs diff -u Interpolation.cpp >> >> > >f.i., or just > > > >>cvs diff -u >> >> > >for all directories beyond the current one. > > > >>I had modified >> examples/Particles/PIC2d/PIC2d.cpp, >> src/Particles/Interpolation.cpp, >> src/Particles/InterpolatorNGP.h, >>created 2D spec. of grad(vert2cell only) in src/Field/DiffOps/Grad.h and >>Grad.UR.h >>In PIC2d.cpp I had to change '.x().comp(0)' to >>'iota(1,nx).comp(0)' for example to make it work and some other subtleties. >>Does anybody working on it this time? Perhaps I'm wasting my time if >>it's all done already? >> >> > >I don't know of anyone working with Particles stuff, and I personally are >not very interested in Particles. > >But surely it is useful to get Particle - Field interaction back to >working. > >Richard. > > > >>Roman. >> >> >> > >-- >Richard Guenther >WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ > > > > From rkrylov at mail.ru Fri Jul 9 14:27:23 2004 From: rkrylov at mail.ru (Roman Krylov) Date: Fri, 09 Jul 2004 18:27:23 +0400 Subject: [pooma-dev] Re:Re: [pooma-dev] examples/Particles/PIC2d/PIC2d.cpp works In-Reply-To: <40EEA5F6.1070301@mail.ru> References: <40ED61D6.1060407@mail.ru> <40EEA5F6.1070301@mail.ru> Message-ID: <40EEAB4B.9050706@mail.ru> > + DynamicArray phi; // for testing purposes of course Oh, I meant DynamicArray phi; of course. I haven't used it really, that's why the mistake was harmless :) The reason was that I had noticed that E was 0 at every particle and I thought gather() doesn't work and I intended to test gather() with scalar attr. :) , but the reason was not in gather... I had changed '.x().comp(0)'(which was R1-style expr.) to '.comp(0)' first, then, as I had mentioned, to 'iota(1,nx).comp(0)' and problem seemed to disappear. Roman. From rguenth at tat.physik.uni-tuebingen.de Sun Jul 11 14:49:37 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Sun, 11 Jul 2004 16:49:37 +0200 Subject: [PATCH] Fix some of Particle - Field interaction Message-ID: <40F15381.9060609@tat.physik.uni-tuebingen.de> Inspired by the simplicity of some of the fixes by Roman Krylov I ran over the interpolate.cpp particle test and tried to make it compile. The following patch makes that and also makes it pass (by pure luck). The only transformation I'm not sure about is Geometry::indexPoint() -> Mesh::vertexPosition() Maybe one of the former developers can comment. I also needed to introduce setExternalGuards() which implementation may not be optimal. But well, better than before. Tested particles with no regressions, interpolation now passing. Ok? Richard. 2004Jul11 Richard Guenther Particles/Interpolation.h: add setExternalGuards. Particles/Interpolation.cpp: likewise. Particles/InterpolatorCIC.h: convert to new Field/Mesh representation. Particles/InterpolatorNGP.h: likewise. Particles/InterpolatorSUDS.h: likewise. Pooma/Particles.h: include interpolators. Particles/tests/interpolate.cpp: convert to new Field/Mesh representation, comment unavailable functionality. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rguenth at tat.physik.uni-tuebingen.de Sun Jul 11 15:49:59 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Sun, 11 Jul 2004 17:49:59 +0200 Subject: Strange initialization code for Particle layouts Message-ID: <40F161A7.5050309@tat.physik.uni-tuebingen.de> Hi! There is some strange code in the particle layout initializations: template class SpatialLayout : public PatchSwapLayout< SpatialLayout > { public: [...] // Default constructor. Initialize with assignment operator. SpatialLayout() : Base_t(*this) {} what is this idiom Base(*this) supposed to do!? PatchSwapLayout doesn't define an assignment operator, so the comment doesn't make any sense. It looks like this initialization provokes undefined behavior and such can be dropped in favor of default-construction (which the PatchSwapLayout doesn't define)? I'm confused, so maybe someone could shed a light on me here. I guess the layout_m member of PatchSwapLayout could be implemented as static_cast(*this) rather than playing this "trick"? Thanks, Richard. From rguenth at tat.physik.uni-tuebingen.de Sun Jul 11 16:15:48 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Sun, 11 Jul 2004 18:15:48 +0200 Subject: [PATCH] Fix Particle layouts Message-ID: <40F167B4.40204@tat.physik.uni-tuebingen.de> ... so I guess like the following. Adds missing initializers to SpatialLayout, too. Ok? Richard. 2004Jul11 Richard Guenther * src/Particles/PatchSwapLayout.h: remove layout_m member. src/Particles/PatchSwapLayout.cpp: use static_cast(*this) instead of now removed layout_m member. src/Particles/UniformLayout.h: no need to initialize base. src/Particles/SpatialLayout.h: likewise, add initializers. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rguenth at tat.physik.uni-tuebingen.de Sun Jul 11 16:19:37 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Sun, 11 Jul 2004 18:19:37 +0200 Subject: [PATCH] Fix particle_test[1234].cpp Message-ID: <40F16899.6040907@tat.physik.uni-tuebingen.de> This moves the particle tests to new Field. RectilinearMesh still missing for 2 and 4, though. Hm, I remembered submitting that long time ago. Ok? Richard. 2004Jul11 Richard Guenther * src/Particles/tests/particle_test1.cpp: move to new Field representation. src/Particles/tests/particle_test2.cpp: likewise. src/Particles/tests/particle_test3.cpp: likewise. src/Particles/tests/particle_test4.cpp: likewise. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rguenth at tat.physik.uni-tuebingen.de Sun Jul 11 17:39:40 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Sun, 11 Jul 2004 19:39:40 +0200 Subject: [PATCH] Fix some examples Message-ID: <40F17B5C.5090501@tat.physik.uni-tuebingen.de> Fixes LinearAdvection1d and Lattice. Ok? Richard. 2004Jul11 Richard Guenther * examples/Field/ScalarAdvection1D/ScalarAdvection1D.cpp: move to new Field representation. examples/Lattice/Coordinate.cpp: likewise. makefile: re-enable them. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rguenth at tat.physik.uni-tuebingen.de Mon Jul 12 08:08:46 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Mon, 12 Jul 2004 10:08:46 +0200 (CEST) Subject: [PATCH] Add RectilinearMesh Message-ID: Richard Guenther wrote: > This moves the particle tests to new Field. RectilinearMesh still > missing for 2 and 4, though. Hm, I remembered submitting that long time > ago. Indeed I have. This is mainly RectilinearMesh from v2.1 fixed for v2.4. particle_test[24] will then work, too (after some minor fix). Ok? Richard. 2004Jul11 Richard Guenther * src/Field/Mesh/RectilinearMesh.h: new. src/Pooma/Fields.h: include RectilinearMesh.h. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rkrylov at mail.ru Mon Jul 12 12:37:20 2004 From: rkrylov at mail.ru (Roman Krylov) Date: Mon, 12 Jul 2004 16:37:20 +0400 Subject: grads Message-ID: <40F28600.8040002@mail.ru> Hi! Concerning GRADs - I've made only 2d vert2cell(attached) only to make PIC2D example available. First, I did for f in `ls Div*.h`;do cat $f|sed s/Div/Grad/g|sed s/div/grad/g>${f};done :-) well... then I had converted that FieldStencil's functor GradVertToCell to be SCALAR->VECTOR from VECTOR->SCALAR operator. and finally, implying OutputElement_t should b Vector<...>, curly braces member: > template > inline OutputElement_t > operator()(const F &f, int i1, int i2) const > { > return OutputElement_t( > 0.5*(fact_m(0)*( > f(i1 + 1, i2 ) - f(i1 , i2 ) + > f(i1 + 1, i2 + 1) - f(i1 , i2 + 1))), > 0.5*(fact_m(1)*( > f(i1 , i2 + 1) - f(i1 , i2 ) + > f(i1 + 1, i2 + 1) - f(i1 + 1, i2 ))) > ); So, it exposed not to be unresolvable. wbw, Roman. -------------- next part -------------- A non-text attachment was scrubbed... Name: Grad.UR.h Type: text/x-c-header Size: 11151 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Grad.h Type: text/x-c-header Size: 5899 bytes Desc: not available URL: From oldham at codesourcery.com Mon Jul 12 18:39:56 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Mon, 12 Jul 2004 11:39:56 -0700 Subject: [PATCH] Fix some examples In-Reply-To: <40F17B5C.5090501@tat.physik.uni-tuebingen.de> References: <40F17B5C.5090501@tat.physik.uni-tuebingen.de> Message-ID: <40F2DAFC.6050904@codesourcery.com> Richard Guenther wrote: > Fixes LinearAdvection1d and Lattice. > > Ok? Yes. It's always good to have more working examples. > Richard. > > > 2004Jul11 Richard Guenther > > * examples/Field/ScalarAdvection1D/ScalarAdvection1D.cpp: > move to new Field representation. > examples/Lattice/Coordinate.cpp: likewise. > makefile: re-enable them. > >------------------------------------------------------------------------ > >===== makefile 1.4 vs edited ===== >--- 1.4/r2/makefile 2003-12-10 10:59:32 +01:00 >+++ edited/makefile 2004-07-11 19:32:40 +02:00 >@@ -67,6 +67,7 @@ > EXAMPLEDIRS = examples/Components/Shock \ > examples/Doof2d \ > examples/Field/ScalarAdvection \ >+ examples/Field/ScalarAdvection1D \ > examples/GKPoisson \ > examples/Indirection/FFT \ > examples/Manual/Doof2d examples/Manual/Sequential \ >@@ -84,12 +85,12 @@ > examples/Solvers/UMPJacobi \ > examples/Stencil/Laplace examples/Stencil/Life \ > examples/Tiny \ >- examples/UserFunction/CosTimes >+ examples/UserFunction/CosTimes \ >+ examples/Lattice > # Those dont compile... > # examples/Field/Caramana examples/Field/Laplace \ >-# examples/Field/Laplace2 examples/Field/ScalarAdvection1D \ >+# examples/Field/Laplace2 \ > # examples/Field/StatigraphicFlow \ >-# examples/Lattice \ > # examples/Particles/PIC2d \ > > .PHONY: examples examplesclean $(EXAMPLEDIRS) >===== examples/Field/ScalarAdvection1D/ScalarAdvection1D.cpp 1.1 vs edited ===== >--- 1.1/r2/examples/Field/ScalarAdvection1D/ScalarAdvection1D.cpp 2002-05-13 17:47:22 +02:00 >+++ edited/examples/Field/ScalarAdvection1D/ScalarAdvection1D.cpp 2004-07-11 19:31:18 +02:00 >@@ -27,7 +27,7 @@ > // ACL:license > > // ----------------------------------------------------------------------------- >-// 1D Wave propagation example, illustrating use of Mesh, DiscreteGeometry, and >+// 1D Wave propagation example, illustrating use of Mesh, and > // Fields. > // ---------------------------------------------------------------------------- > >@@ -50,20 +50,20 @@ > typedef UniformRectilinearMesh<1> Mesh_t; > Mesh_t mesh(vertexDomain, origin, spacings); > >- // Create two geometry objects - one allowing 1 guard layer to >+ // Create two layout objects - one allowing 1 guard layer to > // account for stencil width and another with no guard layers to support > // temporaries: >- typedef DiscreteGeometry > Geometry_t ; >- Geometry_t geom1c(mesh, GuardLayers<1>(1)); >- Geometry_t geom1ng(mesh); >+ DomainLayout<1> layout1(vertexDomain, GuardLayers<1>(1)); >+ DomainLayout<1> layoutng(vertexDomain); >+ Centering<1> cell = canonicalCentering<1>(CellType, Continuous); > > // Create the Fields: > > // The flow Field u(x,t): >- Field u(geom1c); >+ Field u(cell, layout1, mesh); > // The same, stored at the previous timestep for staggered leapfrog > // plus a useful temporary: >- Field uPrev(geom1ng), uTemp(geom1ng); >+ Field uPrev(cell, layoutng, mesh), uTemp(cell, layoutng, mesh); > > // Initialize flow Field to zero everywhere, even global guard layers: > u.all() = 0.0; >@@ -79,8 +79,8 @@ > // decaying to zero away from nCells/4 both directions, with a height of 1.0, > // with a half-width of nCells/8: > const double pulseWidth = spacings(0)*nCells/8; >- const double u0 = u.x(nCells/4)(0); >- u = 1.0*exp(-pow2(u.xComp(0)(pd)-u0)/(2.0*pulseWidth)); >+ const double u0 = positions(u).read(nCells/4)(0); >+ u = 1.0*exp(-pow2(positions(u).comp(0).read(pd)-u0)/(2.0*pulseWidth)); > > // Output the initial field on its physical domain: > std::cout << "Time = 0:\n"; >===== examples/Lattice/Coordinate.cpp 1.1 vs edited ===== >--- 1.1/r2/examples/Lattice/Coordinate.cpp 2002-05-13 17:47:23 +02:00 >+++ edited/examples/Lattice/Coordinate.cpp 2004-07-11 19:18:06 +02:00 >@@ -87,10 +87,8 @@ > typedef UniformRectilinearMesh<2> Mesh_t; > Mesh_t mesh(domain, origin, spacings); > >- typedef DiscreteGeometry > Geometry_t; >- Geometry_t geom(mesh, GuardLayers<2>(1)); >- >- Field u(geom); >+ Centering<2> cell = canonicalCentering<2>(CellType, Continuous); >+ Field > u(cell, layout, mesh); > > Interval<2> d2 = u.physicalDomain(); > > > -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Mon Jul 12 18:42:46 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Mon, 12 Jul 2004 11:42:46 -0700 Subject: [PATCH] Add RectilinearMesh In-Reply-To: References: Message-ID: <40F2DBA6.3020907@codesourcery.com> Richard Guenther wrote: > Richard Guenther wrote: > >> This moves the particle tests to new Field. RectilinearMesh still >> missing for 2 and 4, though. Hm, I remembered submitting that long time >> ago. > > > Indeed I have. This is mainly RectilinearMesh from v2.1 fixed for v2.4. > particle_test[24] will then work, too (after some minor fix). > > Ok? Yes. I wonder why I am listed as the last author to touch the file since I do not remember modifying it. It's been a long time. > Richard. > > > 2004Jul11 Richard Guenther > > * src/Field/Mesh/RectilinearMesh.h: new. > src/Pooma/Fields.h: include RectilinearMesh.h. > >------------------------------------------------------------------------ > >Index: Pooma/Fields.h >=================================================================== >RCS file: /home/pooma/Repository/r2/src/Pooma/Fields.h,v >retrieving revision 1.16 >diff -u -u -r1.16 Fields.h >--- Pooma/Fields.h 21 Nov 2003 17:36:10 -0000 1.16 >+++ Pooma/Fields.h 11 Jul 2004 17:05:25 -0000 >@@ -55,6 +55,7 @@ > > #include "Field/Mesh/NoMesh.h" > #include "Field/Mesh/UniformRectilinearMesh.h" >+#include "Field/Mesh/RectilinearMesh.h" > #include "Field/Mesh/MeshFunctions.h" > #include "Field/Mesh/PositionFunctions.h" > >Index: Field/Mesh/RectilinearMesh.h >=================================================================== >RCS file: Field/Mesh/RectilinearMesh.h >diff -N Field/Mesh/RectilinearMesh.h >--- /dev/null 1 Jan 1970 00:00:00 -0000 >+++ Field/Mesh/RectilinearMesh.h 11 Jul 2004 17:05:27 -0000 >@@ -0,0 +1,904 @@ >+// -*- 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 >+ >+/** @file >+ * @ingroup Mesh >+ * @brief >+ * A rectilinear mesh without uniform spacing between vertices. >+ */ >+ >+#ifndef POOMA_FIELD_MESH_RECTILINEARMESH_H >+#define POOMA_FIELD_MESH_RECTILINEARMESH_H >+ >+//----------------------------------------------------------------------------- >+// Includes: >+//----------------------------------------------------------------------------- >+ >+#include >+ >+#include "Engine/ConstantFunctionEngine.h" // Used in functors >+#include "Engine/IndexFunctionEngine.h" // Used in functors >+#include "Layout/INode.h" // Used in ctors >+#include "Field/FieldEngine/FieldEnginePatch.h" // Used in ctors >+#include "Field/Mesh/NoMesh.h" // Base class >+#include "Field/FieldCentering.h" // Centering inline >+#include "Tiny/Vector.h" // Class member >+#include "Field/Mesh/MeshTraits.h" // Template parameter >+ >+ >+//----------------------------------------------------------------------------- >+/// Holds the data for a rectilinear mesh. That class has a ref-counted >+/// instance of this class. >+//----------------------------------------------------------------------------- >+ >+template >+class RectilinearMeshData : public NoMeshData >+{ >+public: >+ >+ // shortcuts to MeshTraits types >+ typedef typename MeshTraits::Domain_t Domain_t; >+ typedef typename MeshTraits::MeshData_t MeshData_t; >+ typedef typename MeshTraits::Scalar_t Scalar_t; >+ typedef typename MeshTraits::PointType_t PointType_t; >+ typedef typename MeshTraits::VectorType_t VectorType_t; >+ typedef typename MeshTraits::SpacingsType_t SpacingsType_t; >+ typedef typename MeshTraits::PositionsType_t PositionsType_t; >+ >+ enum { dimensions = MeshTraits::dimensions }; >+ >+ >+ //--------------------------------------------------------------------------- >+ // Constructors. >+ >+ /// We provide a default constructor that creates the object with empty >+ /// domains. To be useful, this object must be replaced by another >+ /// version via assignment. >+ >+ RectilinearMeshData() >+ { >+ // This space intentionally left blank. >+ } >+ >+ /// This constructor fully constructs the object. It uses the layout to >+ /// compute domains and also initializes the origin and the spacings in each >+ /// coordinate direction. The indices in the layout refer to VERTEX >+ /// positions. >+ >+ template >+ RectilinearMeshData( >+ const Layout &layout, >+ const PointType_t &origin, >+ const Vector > &spacings) >+ : NoMeshData(layout), >+ origin_m(origin) >+ //spacings_m(spacings) >+ { >+ for (int i=0; i+ spacings_m(i).engine() = spacings(i).engine(); // init >+ spacings_m(i).engine().makeOwnCopy(); // FIXME? Do we want this? >+ Interval<1> I(layout.domain()[i]); >+ positions_m(i).engine() = Engine<1, Scalar_t, Brick>(I); >+ positions_m(i)(0) = origin_m(i); >+ // initialize from origin downward the ghost cells >+ for (int j=-1; j>=I.min(); j--) >+ positions_m(i)(j) = positions_m(i).read(j+1) - spacings_m(i).read(j); >+ // initialize from origin upward >+ for (int j=1; j<=I.max(); j++) >+ positions_m(i)(j) = positions_m(i).read(j-1) + spacings_m(i).read(j-1); >+ } >+ } >+ >+ /// Constructor for constructing evenly spaced rectilinear meshes just >+ /// like UniformRectilinearMesh does. >+ >+ template >+ RectilinearMeshData( >+ const Layout &layout, >+ const PointType_t &origin, >+ const VectorType_t &spacings) >+ : NoMeshData(layout), >+ origin_m(origin) >+ { >+ // for each dimension we allocate engines for spacings & positions >+ // and initialize them according to origin/spacings >+ for (int i=0; i+ Interval<1> I(layout.domain()[i]); >+ // allocate and assign spacings >+ spacings_m(i).engine() = Engine<1, Scalar_t, Brick>(I); >+ spacings_m(i)(I) = spacings(i); // no Array.all() >+ Pooma::blockAndEvaluate(); >+ // allocate positions, assign origin >+ positions_m(i).engine() = Engine<1, Scalar_t, Brick>(I); >+ positions_m(i)(0) = origin_m(i); >+ // initialize from origin downward the ghost cells >+ for (int j=-1; j>=I.min(); j--) >+ positions_m(i)(j) = positions_m(i).read(j+1) - spacings_m(i).read(j); >+ // initialize from origin upward >+ for (int j=1; j<=I.max(); j++) >+ positions_m(i)(j) = positions_m(i).read(j-1) + spacings_m(i).read(j-1); >+ } >+ } >+ >+ /// Copy constructor. >+ >+ RectilinearMeshData(const MeshData_t &model) >+ : NoMeshData(model), >+ origin_m(model.origin_m) >+ //spacings_m(model.spacings_m), >+ //positions_m(model.positions_m) >+ { >+ for (int i=0; i+ spacings_m(i).engine() = model.spacings_m(i).engine(); >+ positions_m(i).engine() = model.positions_m(i).engine(); >+ } >+ // This space intentionally left blank. >+ } >+ >+ /// @name View constructors. >+ //@{ >+ >+ /// Interval view. This means that we simply need to adjust the >+ /// origin by the amount the view is offset from the model's physical >+ /// cell domain. We rely on the base class to do the heavy lifting >+ /// with respect to figuring out the domains correctly. >+ /// >+ /// The Interval supplied must refer to VERTEX positions. >+ >+ RectilinearMeshData(const MeshData_t &model, >+ const Interval &d) >+ : NoMeshData(d) >+ { >+ for (int i = 0; i < dimensions; i++) { >+ // FIXME: Wheeee ;) (we cant store a BrickView... >+ // and still dont want to copy) >+ spacings_m(i).engine() = Engine<1, Scalar_t, Brick>(&model.spacings_m(i)(d[i])(0), d[i]); >+ positions_m(i).engine() = Engine<1, Scalar_t, Brick>(&model.positions_m(i)(d[i])(0), d[i]); >+ origin_m(i) = positions_m(i)(d[i].min()); >+ } >+ } >+#if 0 >+ /// FieldEnginePatch view. We don't fiddle with the origin because we are not >+ /// making the domain zero-based. >+ /// >+ /// The domain supplied by the FieldEnginePatch must refer to VERTEX >+ /// positions. >+ >+ RectilinearMeshData(const MeshData_t &model, >+ const FieldEnginePatch &p) >+ : NoMeshData(model, p), >+ origin_m(model.origin_m), >+ spacings_m(model.spacings_m), >+ positions_m(model.spacings_m) >+ { >+ std::cerr << "RectilinearMeshData(FieldEnginePatch) constructor called" << std::endl; >+ abort(); >+ // FIXME: what does FieldEnginePatch do??? >+ for (int i=0; i+ spacings_m(i).engine() = model.spacings_m(i).engine(); >+ positions_m(i).engine() = model.positions_m(i).engine(); >+ } >+ } >+#endif >+ //@} >+ >+ //--------------------------------------------------------------------------- >+ /// Copy assignment operator. >+ >+ MeshData_t & >+ operator=(const MeshData_t &rhs) >+ { >+ if (this != &rhs) >+ { >+ NoMeshData::operator=(rhs); >+ origin_m = rhs.origin_m; >+ for (int i=0; i+ spacings_m(i).engine() = rhs.spacings_m(i).engine(); >+ positions_m(i).engine() = rhs.positions_m(i).engine(); >+ } >+ } >+ >+ return *this; >+ } >+ >+ //--------------------------------------------------------------------------- >+ /// Empty destructor is fine. Note, however, that NoMeshData does not have >+ /// a virtual destructor. We must be careful to delete these puppies as >+ /// RectilinearMeshData. >+ >+ ~RectilinearMeshData() { } >+ >+ //--------------------------------------------------------------------------- >+ /// @name General accessors. >+ //@{ >+ >+ /// The mesh spacing. >+ >+ inline const SpacingsType_t &spacings() const >+ { >+ return spacings_m; >+ } >+ >+ /// The mesh vertex positions. >+ >+ inline const PositionsType_t &positions() const >+ { >+ return positions_m; >+ } >+ >+ /// The mesh origin. >+ >+ inline const PointType_t &origin() const >+ { >+ return origin_m; >+ } >+ >+ //@} >+ >+private: >+ >+ /// Origin of mesh (coordinate vector of first vertex). >+ >+ PointType_t origin_m; >+ >+ /// Spacings between vertices. >+ >+ SpacingsType_t spacings_m; >+ >+ /// Vertex positions. >+ >+ PositionsType_t positions_m; >+ >+}; >+ >+ >+ >+ >+/// >+/// RectilinearMesh is a rectilinear mesh sometimes called a >+/// "cartesian product" or "tensor product" mesh. Each dimension has a >+/// spacing value between every pair of vertices along that dimension; >+/// these spacings can all be different. >+/// >+template >+class RectilinearMesh : public MeshTraits::CoordinateSystem_t >+{ >+public: >+ >+ //--------------------------------------------------------------------------- >+ // Exported typedefs and enumerations. >+ >+ typedef MeshTraits MeshTraits_t; >+ >+ /// The type of the mesh class. >+ >+ typedef typename MeshTraits::Mesh_t Mesh_t; >+ >+ /// The type of the mesh data class. >+ >+ typedef typename MeshTraits::MeshData_t MeshData_t; >+ >+ /// The type of the coordinate system. >+ >+ typedef typename MeshTraits::CoordinateSystem_t CoordinateSystem_t; >+ >+ /// The type of domains. >+ >+ typedef typename MeshTraits::Domain_t Domain_t; >+ >+ /// The type of locations. >+ >+ typedef typename MeshTraits::Loc_t Loc_t; >+ >+ /// The type T, used to represent, for example, volumes & areas, etc. >+ >+ typedef typename MeshTraits::T_t T_t; >+ >+ /// The type of scalars. >+ >+ typedef typename MeshTraits::Scalar_t Scalar_t; >+ >+ /// The type of mesh points. >+ >+ typedef typename MeshTraits::PointType_t PointType_t; >+ >+ /// The type of vectors used to represent, for example, normals. >+ >+ typedef typename MeshTraits::VectorType_t VectorType_t; >+ >+ /// The type used to store spacings. >+ >+ typedef typename MeshTraits::SpacingsType_t SpacingsType_t; >+ >+ /// The type used to store positions. >+ >+ typedef typename MeshTraits::PositionsType_t PositionsType_t; >+ >+ /// The number of indices required to select a point in this mesh. >+ >+ enum { dimensions = MeshTraits::dimensions }; >+ >+ /// The number of components of a position vector inside the mesh. >+ >+ enum { coordinateDimensions = MeshTraits::coordinateDimensions }; >+ >+ >+ //--------------------------------------------------------------------------- >+ // Constructors. >+ >+ /// We supply a default constructor, but it doesn't generate a useful mesh. >+ /// This is accomplished through assignment. >+ >+ RectilinearMesh() >+ : data_m(new MeshData_t) >+ { >+ // This space intentionally left blank. >+ } >+ >+ /// This constructor fully constructs the object. It uses the layout to >+ /// compute domains and also initializes the origin and the spacings in each >+ /// coordinate direction. >+ /// >+ /// The Layout supplied must refer to VERTEX positions. >+ >+ template >+ inline RectilinearMesh(const Layout &layout, >+ const PointType_t &origin, >+ const Vector > &spacings) >+ : data_m(new MeshData_t(layout, origin, spacings)) >+ { >+ } >+ >+ /// Constructor compatible to UniformRectilinearMesh. >+ >+ template >+ inline RectilinearMesh(const Layout &layout, >+ const PointType_t &origin, >+ const PointType_t &spacings) >+ : data_m(new MeshData_t(layout, origin, spacings)) >+ { >+ } >+ >+ template >+ inline explicit RectilinearMesh(const Layout &layout) >+ : data_m(new MeshData_t(layout, >+ PointType_t(0), >+ PointType_t(1))) >+ { >+ } >+ >+ /// Copy constructor. >+ >+ inline RectilinearMesh(const Mesh_t &model) >+ : data_m(model.data_m) >+ { >+ } >+ >+ /// @name View constructors >+ /// These are the only possible views of this >+ /// mesh. Other views will make a NoMesh. >+ //@{ >+ >+ /// Interval view. >+ /// >+ /// The Interval supplied must refer to VERTEX positions. >+ >+ inline RectilinearMesh(const Mesh_t &model, >+ const Domain_t &d) >+ : data_m(new MeshData_t(*model.data_m, d)) >+ { >+ } >+ >+ /// INode view. >+ /// >+ /// The INode supplied must refer to VERTEX positions. >+ >+ inline RectilinearMesh(const Mesh_t &model, >+ const INode &i) >+ : data_m(new MeshData_t(*model.data_m, i.domain())) >+ { >+ } >+#if 0 >+ /// FieldEnginePatch view. >+ /// >+ /// The FieldEnginePatch supplied must refer to VERTEX positions. >+ >+ inline RectilinearMesh(const Mesh_t &model, >+ const FieldEnginePatch &p) >+ : data_m(new MeshData_t(*model.data_m, p)) >+ { >+ } >+#endif >+ //@} >+ >+ //--------------------------------------------------------------------------- >+ /// Copy assignment operator. >+ >+ inline Mesh_t & >+ operator=(const Mesh_t &rhs) >+ { >+ if (&rhs != this) >+ { >+ data_m = rhs.data_m; >+ } >+ >+ return *this; >+ } >+ >+ //--------------------------------------------------------------------------- >+ /// Empty destructor is fine. The pointer to the data is ref-counted so its >+ /// lifetime is correctly managed. >+ >+ ~RectilinearMesh() >+ { >+ } >+ >+ /// Data member access. >+ const MeshData_t& data() const >+ { >+ return *data_m; >+ } >+ >+ //--------------------------------------------------------------------------- >+ /// @name Domain functions. >+ //@{ >+ >+ /// The vertex domain, as the mesh was constructed with. >+ >+ inline const Domain_t &physicalVertexDomain() const >+ { >+ return data_m->physicalVertexDomain(); >+ } >+ >+ /// Function that returns a domain adjusted to give the indices of the cells. >+ >+ inline const Domain_t &physicalCellDomain() const >+ { >+ return data_m->physicalCellDomain(); >+ } >+ >+ /// The total vertex domain, including mesh guard vertices. >+ >+ inline const Domain_t &totalVertexDomain() const >+ { >+ return data_m->totalVertexDomain(); >+ } >+ >+ /// The total cell domain, including mesh guard cells. >+ >+ inline const Domain_t &totalCellDomain() const >+ { >+ return data_m->totalCellDomain(); >+ } >+ >+ //@} >+ >+ //--------------------------------------------------------------------------- >+ /// @name General accessors. >+ //@{ >+ >+ /// The mesh origin. >+ >+ inline const PointType_t &origin() const >+ { >+ return data_m->origin(); >+ } >+ >+ /// The mesh spacing. Return type is dependend on mesh type. >+ >+ inline const SpacingsType_t &spacings() const >+ { >+ return data_m->spacings(); >+ } >+ >+ /// The mesh positions. Return type is dependend on mesh type. >+ >+ inline const PositionsType_t &positions() const >+ { >+ return data_m->positions(); >+ } >+ >+ /// The cell containing a particular point. >+ >+ inline Loc_t cellContaining(const PointType_t &point) const >+ { >+ /// FIXME >+ Loc_t loc((0, Pooma::NoInit())); // Avoid a g++ parse error. >+ for (int i = 0; i < dimensions; i++) >+ { >+ const T_t *start = &positions()(i)(0); >+ const T_t *finish = start + positions()(i).physicalDomain()[i].length(); >+ const T_t *p = std::lower_bound(start, finish, point(i)); >+#if POOMA_BOUNDS_CHECK >+ PInsist(p != finish, >+ "Rectilinear::cellContaining(): point is outside mesh."); >+#endif >+ // The lower_bound function returns the first element that is not >+ // less than the point we're searching for. >+ int j = static_cast(std::distance(start, p)); >+ if (*p == point(i)) >+ loc[i] = j; >+ else >+ loc[i] = j-1; >+ } >+ >+ return loc; >+ } >+ >+ /// The lower-left vertex associated with a given cell location. >+ >+ inline PointType_t vertexPosition(const Loc_t &loc) const >+ { >+ PointType_t point; >+ for (int i = 0; i < dimensions; i++) >+ point(i) = positions()(i)(loc[i]); >+ return point; >+ } >+ >+ inline Scalar_t vertexPosition(int dim, int i) const >+ { >+ return positions()(dim)(i); >+ } >+ >+ /// The position of a given cell location for canonical cell centering. >+ >+ inline PointType_t cellPosition(const Loc_t &loc) const >+ { >+ PointType_t point; >+ >+ for (int i=0; i+ point(i) = positions()(i)(loc[i]) + 0.5*spacings()(i)(loc[i]); >+ >+ return point; >+ } >+ >+ inline Scalar_t cellPosition(int dim, int i) const >+ { >+ return positions()(dim)(i) + 0.5*spacings()(dim)(i); >+ } >+ >+ /// The vertex spacing for a given cell location. >+ >+ inline VectorType_t vertexSpacing(const Loc_t &loc) const >+ { >+ VectorType_t delta; >+ >+ for (int i=0; i+ delta(i) = spacings()(i)(loc[i]); >+ >+ return delta; >+ } >+ >+ inline Scalar_t vertexSpacing(int dim, int i) const >+ { >+ return spacings()(dim)(i); >+ } >+ >+ /// The cell spacing for a given cell location. >+ >+ inline VectorType_t cellSpacing(const Loc_t &loc) const >+ { >+ VectorType_t delta; >+ >+ for (int i=0; i+ delta(i) = 0.5 * (spacings()(i)(loc[i]) + spacings()(i)(loc[i]+1)); >+ >+ return delta; >+ } >+ >+ inline Scalar_t cellSpacing(int dim, int i) const >+ { >+ return 0.5*(spacings()(dim)(i) + spacings()(dim)(i+1)); >+ } >+ >+ //@} >+ >+ >+private: >+ >+ /// Our data, stored as a ref-counted pointer to simplify memory management. >+ >+ RefCountedPtr data_m; >+}; >+ >+ >+ >+/// >+/// GenericRM contains mesh functions related functors that are applicapble >+/// regardless of the coordinate system type. >+/// >+template >+struct GenericRM { >+ >+ /// The coordinate type. >+ >+ typedef typename MeshTraits::T_t T_t; >+ >+ /// The mesh data class. >+ >+ typedef typename MeshTraits::Mesh_t Mesh_t; >+ >+ /// The type to represent points. >+ >+ typedef typename MeshTraits::PointType_t PointType_t; >+ >+ /// The type to represent vectors. >+ >+ typedef typename MeshTraits::VectorType_t VectorType_t; >+ >+ /// The type to represent the spacings. >+ >+ typedef typename MeshTraits::SpacingsType_t SpacingsType_t; >+ >+ /// The type used to store positions. >+ >+ typedef typename MeshTraits::PositionsType_t PositionsType_t; >+ >+ /// The type of locations. >+ >+ typedef typename MeshTraits::Loc_t Loc_t; >+ >+ /// Dimensionality of the mesh. >+ >+ enum { dimensions = MeshTraits::dimensions }; >+ enum { coordinateDimensions = MeshTraits::coordinateDimensions }; >+ >+ >+ //--------------------------------------------------------------------------- >+ /// Support for the positions() function. We need to provide a functor for >+ /// use with IndexFunction-engine. We also need to export the >+ /// PositionsEngineTag_t typedef and the positionsFunctor() member function, >+ /// which computes the positions using the centering point positions. >+ /// The indices passed in refer to cells. >+ >+ class PositionsFunctor { >+ public: >+ >+ /// Need to be able to default construct since we fill in the details >+ /// after the fact. >+ >+ // WARNING! For Arrays to be initialized (copy constructed, assigned, >+ // etc.) correctly, even in the case of uninitialized targets >+ // we need to copy the engines explicitly rather than rely >+ // on the compiler generating correct copy constructors and >+ // assignment operators. >+ // FIXME! Technically we either can dump the copy constructor or the >+ // assignment operator. >+ >+ PositionsFunctor() { } >+ >+ PositionsFunctor(const Mesh_t &m, >+ const Centering &c) >+ : centering_m(c.position(0)) >+ { >+ for (int i=0; i+ positions_m(i).engine() = m.positions()(i).engine(); >+ spacings_m(i).engine() = m.spacings()(i).engine(); >+ } >+ } >+ >+ PositionsFunctor(const PositionsFunctor &m) >+ : centering_m(m.centering_m) >+ { >+ for (int i=0; i+ positions_m(i).engine() = m.positions_m(i).engine(); >+ spacings_m(i).engine() = m.spacings_m(i).engine(); >+ } >+ } >+ >+ PositionsFunctor& operator=(const PositionsFunctor &m) >+ { >+ centering_m = m.centering_m; >+ for (int i=0; i+ positions_m(i).engine() = m.positions_m(i).engine(); >+ spacings_m(i).engine() = m.spacings_m(i).engine(); >+ } >+ >+ return *this; >+ } >+ >+ inline PointType_t operator()(int i0) const >+ { >+ return PointType_t(positions_m(0).read(i0) + spacings_m(0).read(i0)*centering_m(0)); >+ } >+ >+ inline PointType_t operator()(int i0, int i1) const >+ { >+ return PointType_t(positions_m(0).read(i0) + spacings_m(0).read(i0)*centering_m(0), >+ positions_m(1).read(i1) + spacings_m(1).read(i1)*centering_m(1)); >+ } >+ >+ inline PointType_t operator()(int i0, int i1, int i2) const >+ { >+ return PointType_t(positions_m(0).read(i0) + spacings_m(0).read(i0)*centering_m(0), >+ positions_m(1).read(i1) + spacings_m(1).read(i1)*centering_m(1), >+ positions_m(2).read(i2) + spacings_m(2).read(i2)*centering_m(2)); >+ } >+ >+ private: >+ >+ PositionsType_t positions_m; >+ SpacingsType_t spacings_m; >+ typename Centering::Position centering_m; >+ >+ }; >+ >+ typedef IndexFunction PositionsEngineTag_t; >+ >+ template >+ void initializePositions( >+ Engine &e, >+ const Centering &c) const >+ { >+ e.setFunctor(typename PositionsEngineTag::Functor_t(static_cast(*this), c)); >+ } >+ >+ >+ //--------------------------------------------------------------------------- >+ /// Support for the spacings() function. We need to provide a functor for >+ /// use with IndexFunction-engine. We also need to export the >+ /// SpacingsEngineTag_t typedef and the spacingsFunctor() member function, >+ /// which computes the spacings using the centering point positions. >+ /// The indices passed in refer to cells. >+ >+ class SpacingsFunctor { >+ public: >+ >+ /// Need to be able to default construct since we fill in the details >+ /// after the fact. >+ >+ // WARNING! For Arrays to be initialized (copy constructed, assigned, >+ // etc.) correctly, even in the case of uninitialized targets >+ // we need to copy the engines explicitly rather than rely >+ // on the compiler generating correct copy constructors and >+ // assignment operators. >+ // FIXME! Technically we either can dump the copy constructor or the >+ // assignment operator. >+ >+ SpacingsFunctor() { } >+ >+ SpacingsFunctor(const Mesh_t &m, >+ const Centering &c) >+ : centering_m(c.position(0)) >+ { >+ for (int i=0; i+ spacings_m(i).engine() = m.spacings()(i).engine(); >+ } >+ >+ SpacingsFunctor(const SpacingsFunctor &m) >+ : centering_m(m.centering_m) >+ { >+ for (int i=0; i+ spacings_m(i).engine() = m.spacings_m(i).engine(); >+ } >+ >+ SpacingsFunctor& operator=(const SpacingsFunctor &m) >+ { >+ centering_m = m.centering_m; >+ for (int i=0; i+ spacings_m(i).engine() = m.spacings_m(i).engine(); >+ >+ return *this; >+ } >+ >+ /* FIXME: the following may cause an out of bound condition, if >+ * the spacings is queried for the last cell - spacings >+ * for non-existing cells are used then. >+ */ >+ >+ inline VectorType_t operator()(int i0) const >+ { >+ return VectorType_t(spacings_m(0).read(i0) >+ + (spacings_m(0).read(i0+1)-spacings_m(0).read(i0))*centering_m(0)); >+ } >+ >+ inline VectorType_t operator()(int i0, int i1) const >+ { >+ return VectorType_t(spacings_m(0).read(i0) >+ + (spacings_m(0).read(i0+1)-spacings_m(0).read(i0))*centering_m(0), >+ spacings_m(1).read(i1) >+ + (spacings_m(1).read(i1+1)-spacings_m(1).read(i1))*centering_m(1)); >+ } >+ >+ inline VectorType_t operator()(int i0, int i1, int i2) const >+ { >+ return VectorType_t(spacings_m(0).read(i0) >+ + (spacings_m(0).read(i0+1)-spacings_m(0).read(i0))*centering_m(0), >+ spacings_m(1).read(i1) >+ + (spacings_m(1).read(i1+1)-spacings_m(1).read(i1))*centering_m(1), >+ spacings_m(2).read(i2) >+ + (spacings_m(2).read(i2+1)-spacings_m(2).read(i2))*centering_m(2)); >+ } >+ >+ private: >+ >+ SpacingsType_t spacings_m; >+ typename Centering::Position centering_m; >+ >+ }; >+ >+ typedef IndexFunction SpacingsEngineTag_t; >+ >+ void initializeSpacings( >+ Engine &e, >+ const Centering &c) const >+ { >+ e.setFunctor(SpacingsFunctor(static_cast(*this), c)); >+ } >+ >+ >+ //--------------------------------------------------------------------------- >+ /// Support for the outwardNormals() and coordinateNormals() functions. >+ /// We also need to export the NormalsEngineTag_t typedef and the >+ /// initializeNormals() member function, which sets the appropriate constant >+ /// value (since the normals exactly align with the coordinate axes). >+ /// The boolean value passed is true if we are asking for outward normals, >+ /// as opposed to coordinate normals. The indices passed in refer to cells. >+ >+ typedef ConstantFunction NormalsEngineTag_t; >+ >+ void initializeNormals( >+ Engine &e, >+ const Centering &c, >+ bool outward = true) const >+ { >+ // Check some pre-conditions. We need there to be a single centering >+ // point and it must be face-centered. >+ >+ PAssert(c.size() == 1); >+ PAssert(c.centeringType() == FaceType); >+ >+ // Generate the normals. The coordinate normals are computed from >+ // 1 - orientation. Then, if we are on the near face, indicated by >+ // position == 0.0, we need to multiply by -1.0 if we are doing >+ // outward normals. >+ >+ VectorType_t normal; >+ for (int i = 0; i < dimensions; i++) >+ { >+ normal(i) = static_cast(1 - c.orientation(0)[i].first()); >+ if (outward && c.position(0)(i) == 0.0) >+ normal(i) *= static_cast(-1); >+ } >+ >+ e.setConstant(normal); >+ } >+ >+}; >+ >+ >+ >+#endif // POOMA_FIELD_MESH_RECTILINEARMESH_H >+ >+// ACL:rcsinfo >+// ---------------------------------------------------------------------- >+// $RCSfile: RectilinearMesh.h,v $ $Author: oldham $ >+// $Revision: 1.4 $ $Date: 2001/12/11 20:43:30 $ >+// ---------------------------------------------------------------------- >+// ACL:rcsinfo >+ > > -- Jeffrey D. Oldham oldham at codesourcery.com From cummings at linkline.com Mon Jul 12 19:14:56 2004 From: cummings at linkline.com (Julian C. Cummings) Date: Mon, 12 Jul 2004 12:14:56 -0700 Subject: [pooma-dev] Strange initialization code for Particle layouts In-Reply-To: <40F161A7.5050309@tat.physik.uni-tuebingen.de> Message-ID: <002401c46844$84d67ad0$6401a8c0@JULES> Hi Richard, I don't really keep up with Pooma maintenance issues anymore, but I guess I should comment as one of the Pooma Particles developers of long ago. You are correct that the layout_m member is there only for convenience, so that you don't have to cast the this pointer repeatedly. It is fewer keystrokes to use the layout_m reference instead, but your changes should do no harm. The code comment below is inaccurate. It should say that you need to call the initialize() method if you use the default constructor. A valid SpatialLayout for Particles requires FieldLayout and Geometry objects. I believe your conversion of Geometry::indexPoint() to Mesh::vertexPosition() is right. I never fully implemented the Particle-Field interpolation routines for the new Field class definition provided in Pooma 2.4 because I was not certain how to handle the issues of run-time selection of Field centering and "mixed" Field centerings that are not simple cell or vertex centerings. With the wider selection of possible Field centerings, a very general Particle-Field interpolation scheme (and even management of the SpatialLayout itself) becomes quite complicated. Regards, Julian C. > -----Original Message----- > From: Richard Guenther [mailto:rguenth at tat.physik.uni-tuebingen.de] > Sent: Sunday, July 11, 2004 8:50 AM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] Strange initialization code for Particle layouts > > > Hi! > > There is some strange code in the particle layout initializations: > > template > class SpatialLayout > : public PatchSwapLayout< SpatialLayout > > { > public: > [...] > // Default constructor. Initialize with assignment operator. > > SpatialLayout() > : Base_t(*this) > {} > > > what is this idiom Base(*this) supposed to do!? > PatchSwapLayout doesn't > define an assignment operator, so the comment doesn't make any sense. > It looks like this initialization provokes undefined behavior > and such > can be dropped in favor of default-construction (which the > PatchSwapLayout doesn't define)? I'm confused, so maybe > someone could > shed a light on me here. I guess the layout_m member of > PatchSwapLayout > could be implemented as static_cast(*this) rather > than playing > this "trick"? > > Thanks, > Richard. > From oldham at codesourcery.com Tue Jul 13 22:43:43 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 13 Jul 2004 15:43:43 -0700 Subject: [pooma-dev] ? In-Reply-To: <40E18A84.9090602@mail.ru> References: <40E17E3E.5000408@mail.ru> <40E18499.9040608@codesourcery.com> <40E18A84.9090602@mail.ru> Message-ID: <40F4659F.9060503@codesourcery.com> Roman Krylov wrote: > I'm sorry, I merely copied/pasted it from > http://www.zib.de/benger/pooma/tut-01.html#laplace > So,... is it proposal to change that tutorial? > But the question persists: > how a metal sheet could have non-constant(spatially) electric > potential distribution whereas it should be constant V=const ? > Cheers > Roman. > >> >> Would this text be more acceptable: >> "... where V is, for example, the electric potential of a charge-free >> flat metal sheet"? >> Yes, we can change the tutorial text if that clarifies the text for you. In case it does not, let me try to explain some reasons for presenting the charge-free equation in a different way. I do understand that a charge-free region should have a constant voltage. The tutorial does begin with this case but then moves to the case with a non-zero charge distribution \Beta. For this, the voltage should not be constant. There are several reasons for taking this approach: 1) When introducing a topic, it is usually a good idea to introduce the simplest possible case even if it is not particularly interesting in the real world. This permits the person learning the topic to learn a simpler case with fewer things to learn at once. After a simple case is learned, it can be made more complicated by gradually adding complications. This gradual approach permits the learner to see how each particular addition changes the previous solution. This approach is taken for this particular POOMA tutorial. A non-physicist, non-computer-scientist has a lot to learn at the beginning of the tutorial. A physicist might be bored by the physics but still needs to learn the POOMA toolkit. A computer scientist has to learn some physics to understand the tutorial. Those who understand both physics and computer science are a fortunate few. 2) We cannot rely on POOMA learners to know how to solve the Laplace equation for a charge-free region. 3) It is not immediately clear that the proposed solution for the charge-free region using POOMA will exactly match the analytical solution although, admittedly, it does not require much thought to see this. If there are small numerical inaccuracies, solving the charge-free equation using the toolkit will indicate what types of inaccuracies occur. Using this knowledge, one can better understand the inaccuracies found when solving the charged-region equation. (For this particular example, I do not explect any inaccuracies, but I might be wrong.) I hope this explains some reasons why the tutorial is presented the way it is. If you wish to have some text changed, please send a recommended change that will make sense to people who do not know how to solve the charge-free equation and to people who do not know physics. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Tue Jul 13 23:11:15 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 13 Jul 2004 16:11:15 -0700 Subject: [pooma-dev] examples/Particles/PIC2d/PIC2d.cpp works In-Reply-To: <40EDBA39.9030100@tat.physik.uni-tuebingen.de> References: <40ED61D6.1060407@mail.ru> <40EDBA39.9030100@tat.physik.uni-tuebingen.de> Message-ID: <40F46C13.2030308@codesourcery.com> Richard Guenther wrote: > Roman Krylov wrote: > >> It's about examples/Particles/PIC2d. >> I made it compilable and runnable, though I have no experience in >> CVS, and even in RCS so I can't express it that way. >> I had modified >> examples/Particles/PIC2d/PIC2d.cpp, >> src/Particles/Interpolation.cpp, >> src/Particles/InterpolatorNGP.h, >> created 2D spec. of grad(vert2cell only) in src/Field/DiffOps/Grad.h >> and Grad.UR.h >> In PIC2d.cpp I had to change '.x().comp(0)' to >> 'iota(1,nx).comp(0)' for example to make it work and some other >> subtleties. >> Does anybody working on it this time? Perhaps I'm wasting my time if >> it's all done already? >> Roman. > > > Btw., if you are wanting to contribute your improvements back to the > official POOMA CVS you need to talk to the CodeSourcery people. There > is some Copyright fuss to be done. But if there is enough momentum in > the community, I guess (public) forking would be another option. > Yes, there is some CodeSourcery fuss to satisfy the lawyers, but it's not too difficult. Send email to Mark Mitchell for the details. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Tue Jul 13 23:21:55 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 13 Jul 2004 16:21:55 -0700 Subject: [PATCH] Fix some of Particle - Field interaction In-Reply-To: <40F15381.9060609@tat.physik.uni-tuebingen.de> References: <40F15381.9060609@tat.physik.uni-tuebingen.de> Message-ID: <40F46E93.3060700@codesourcery.com> Richard Guenther wrote: > Inspired by the simplicity of some of the fixes by Roman Krylov I ran > over the interpolate.cpp particle test and tried to make it compile. > The following patch makes that and also makes it pass (by pure luck). > The only transformation I'm not sure about is > Geometry::indexPoint() -> Mesh::vertexPosition() > Maybe one of the former developers can comment. > > I also needed to introduce setExternalGuards() which implementation > may not be optimal. But well, better than before. > > Tested particles with no regressions, interpolation now passing. > > Ok? Yes, it's good progress. I appreciate Krylov's and your work on this. Please see the questions below. There's no need to send replies before committing. Somewhere in the patch, an 'Interpolater' template parameter was added, but I did not see its use within the structure. >@@ -328,8 +317,8 @@ > << sum(chargeDensity) > << std::endl; > tester.check("chargeDensity(NGP,attrib) == numparticles", >- abs(sum(chargeDensity) - >- static_cast(createnum))<1.0e-5); >+ fabs(sum(chargeDensity) - >+ static_cast(createnum))<1.0e-5); > > > In C++, std::abs is overloaded to mean std::fabs. In other words, the language designers finally get it right. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Tue Jul 13 23:26:25 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 13 Jul 2004 16:26:25 -0700 Subject: [PATCH] Fix Particle layouts In-Reply-To: <40F167B4.40204@tat.physik.uni-tuebingen.de> References: <40F167B4.40204@tat.physik.uni-tuebingen.de> Message-ID: <40F46FA1.3050304@codesourcery.com> Richard Guenther wrote: > ... so I guess like the following. Adds missing initializers to > SpatialLayout, too. > > Ok? > > Richard. > > > 2004Jul11 Richard Guenther > > * src/Particles/PatchSwapLayout.h: remove layout_m member. > src/Particles/PatchSwapLayout.cpp: use > static_cast(*this) instead of now removed layout_m member. > src/Particles/UniformLayout.h: no need to initialize base. > src/Particles/SpatialLayout.h: likewise, add initializers. Yes, it is fine, especially per Julian Cummings's comments. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Tue Jul 13 23:29:56 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 13 Jul 2004 16:29:56 -0700 Subject: [PATCH] Fix particle_test[1234].cpp In-Reply-To: <40F16899.6040907@tat.physik.uni-tuebingen.de> References: <40F16899.6040907@tat.physik.uni-tuebingen.de> Message-ID: <40F47074.8010403@codesourcery.com> Richard Guenther wrote: > This moves the particle tests to new Field. RectilinearMesh still > missing for 2 and 4, though. Hm, I remembered submitting that long > time ago. > > Ok? > > Richard. > > > 2004Jul11 Richard Guenther > > * src/Particles/tests/particle_test1.cpp: move to new Field > representation. > src/Particles/tests/particle_test2.cpp: likewise. > src/Particles/tests/particle_test3.cpp: likewise. > src/Particles/tests/particle_test4.cpp: likewise. It looks good. Please commit it. Do you still have the RectilinearMesh patch to resubmit? -- Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Wed Jul 14 07:15:55 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 14 Jul 2004 09:15:55 +0200 (CEST) Subject: [pooma-dev] Re: [PATCH] Fix some of Particle - Field interaction In-Reply-To: <40F46E93.3060700@codesourcery.com> References: <40F15381.9060609@tat.physik.uni-tuebingen.de> <40F46E93.3060700@codesourcery.com> Message-ID: On Tue, 13 Jul 2004, Jeffrey D. Oldham wrote: > Richard Guenther wrote: > > > Inspired by the simplicity of some of the fixes by Roman Krylov I ran > > over the interpolate.cpp particle test and tried to make it compile. > > The following patch makes that and also makes it pass (by pure luck). > > The only transformation I'm not sure about is > > Geometry::indexPoint() -> Mesh::vertexPosition() > > Maybe one of the former developers can comment. > > > > I also needed to introduce setExternalGuards() which implementation > > may not be optimal. But well, better than before. > > > > Tested particles with no regressions, interpolation now passing. > > > > Ok? > > Yes, it's good progress. I appreciate Krylov's and your work on this. > Please see the questions below. > There's no need to send replies before committing. > > Somewhere in the patch, an 'Interpolater' template parameter was added, > but I did not see its use within the structure. Hm. This may be a misreading of the patch by you. Can you point at the context? > >@@ -328,8 +317,8 @@ > > << sum(chargeDensity) > > << std::endl; > > tester.check("chargeDensity(NGP,attrib) == numparticles", > >- abs(sum(chargeDensity) - > >- static_cast(createnum))<1.0e-5); > >+ fabs(sum(chargeDensity) - > >+ static_cast(createnum))<1.0e-5); > > > > > > > In C++, std::abs is overloaded to mean std::fabs. In other words, the > language designers finally get it right. Of course, but it used ::abs which causes compile-time warnings of implicitly casting from double -> int, so I changed it to fabs - but I'll happily change it to std::abs if anyone cares. Thanks, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ From oldham at codesourcery.com Wed Jul 14 15:16:25 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Wed, 14 Jul 2004 08:16:25 -0700 Subject: [pooma-dev] Re: [PATCH] Fix some of Particle - Field interaction In-Reply-To: References: <40F15381.9060609@tat.physik.uni-tuebingen.de> <40F46E93.3060700@codesourcery.com> Message-ID: <40F54E49.60400@codesourcery.com> Richard Guenther wrote: >On Tue, 13 Jul 2004, Jeffrey D. Oldham wrote: > > > >>Richard Guenther wrote: >> >> >> >>>Inspired by the simplicity of some of the fixes by Roman Krylov I ran >>>over the interpolate.cpp particle test and tried to make it compile. >>>The following patch makes that and also makes it pass (by pure luck). >>>The only transformation I'm not sure about is >>> Geometry::indexPoint() -> Mesh::vertexPosition() >>>Maybe one of the former developers can comment. >>> >>>I also needed to introduce setExternalGuards() which implementation >>>may not be optimal. But well, better than before. >>> >>>Tested particles with no regressions, interpolation now passing. >>> >>>Ok? >>> >>> >>Yes, it's good progress. I appreciate Krylov's and your work on this. >>Please see the questions below. >>There's no need to send replies before committing. >> >>Somewhere in the patch, an 'Interpolater' template parameter was added, >>but I did not see its use within the structure. >> >> > >Hm. This may be a misreading of the patch by you. Can you point at the >context? > > It's hard to tell from this patch fragment if Interpolator is actually used in PTraits, but I do not see any used in the next few subsequent patch fragments. (What is the correct terminology for one piece of a patch?) ===== Particles/tests/interpolate.cpp 1.2 vs edited ===== --- 1.2/r2/src/Particles/tests/interpolate.cpp 2004-01-07 09:54:08 +01:00 +++ edited/Particles/tests/interpolate.cpp 2004-07-11 16:34:38 +02:00 @@ -47,7 +47,7 @@ // A traits class for a Particles object //----------------------------------------------------------------------------- -template struct PTraits { >>>@@ -328,8 +317,8 @@ >>> << sum(chargeDensity) >>> << std::endl; >>> tester.check("chargeDensity(NGP,attrib) == numparticles", >>>- abs(sum(chargeDensity) - >>>- static_cast(createnum))<1.0e-5); >>>+ fabs(sum(chargeDensity) - >>>+ static_cast(createnum))<1.0e-5); >>> >>> >>> >>> >>> >>In C++, std::abs is overloaded to mean std::fabs. In other words, the >>language designers finally get it right. >> >> > >Of course, but it used ::abs which causes compile-time warnings of >implicitly casting from double -> int, so I changed it to fabs - but I'll >happily change it to std::abs if anyone cares. > > Either abs or fabs is fine. -- Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Wed Jul 14 19:57:36 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 14 Jul 2004 21:57:36 +0200 Subject: [PATCH] Fix particle_bench?.cpp Message-ID: <40F59030.60301@tat.physik.uni-tuebingen.de> This transforms the last bit of particle tests to v2.4. Ok? Richard. 2004Jul14 Richard Guenther * src/Particles/tests/particle_bench1.cpp: convert to v2.4 Mesh/Field representation. src/Particles/tests/particle_bench2.cpp: likewise. src/Particles/tests/particle_bench3.cpp: likewise. src/Particles/tests/particle_bench4.cpp: likewise. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rguenth at tat.physik.uni-tuebingen.de Wed Jul 14 20:21:45 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 14 Jul 2004 22:21:45 +0200 Subject: [PATCH] Initialize PatchSwapLayout correctly Message-ID: <40F595D9.6020308@tat.physik.uni-tuebingen.de> Cures SEGFAULTing particle tests. Ok? Richard. 2004Jul14 Richard Guenther * src/Particles/PatchSwapLayout.h: initialize contextSizes_m properly in default constructor. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From oldham at codesourcery.com Wed Jul 14 21:38:40 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Wed, 14 Jul 2004 14:38:40 -0700 Subject: [PATCH] Fix particle_bench?.cpp In-Reply-To: <40F59030.60301@tat.physik.uni-tuebingen.de> References: <40F59030.60301@tat.physik.uni-tuebingen.de> Message-ID: <40F5A7E0.4030906@codesourcery.com> Richard Guenther wrote: > This transforms the last bit of particle tests to v2.4. > > Ok? > > Richard. > > > 2004Jul14 Richard Guenther > > * src/Particles/tests/particle_bench1.cpp: convert to v2.4 > Mesh/Field representation. > src/Particles/tests/particle_bench2.cpp: likewise. > src/Particles/tests/particle_bench3.cpp: likewise. > src/Particles/tests/particle_bench4.cpp: likewise. Yes, this patch is approved. You're making good progress making particles usable. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Wed Jul 14 21:43:00 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Wed, 14 Jul 2004 14:43:00 -0700 Subject: [PATCH] Initialize PatchSwapLayout correctly In-Reply-To: <40F595D9.6020308@tat.physik.uni-tuebingen.de> References: <40F595D9.6020308@tat.physik.uni-tuebingen.de> Message-ID: <40F5A8E4.7080309@codesourcery.com> Richard Guenther wrote: > Cures SEGFAULTing particle tests. > > Ok? > > Richard. > > > 2004Jul14 Richard Guenther > > * src/Particles/PatchSwapLayout.h: initialize contextSizes_m > properly in default constructor. Yes, this cures a distinct lack of symmetry in the PatchSwapLayout constructors. >------------------------------------------------------------------------ > >Index: PatchSwapLayout.h >=================================================================== >RCS file: /home/pooma/Repository/r2/src/Particles/PatchSwapLayout.h,v >retrieving revision 1.21 >diff -u -u -r1.21 PatchSwapLayout.h >--- PatchSwapLayout.h 14 Jul 2004 15:44:59 -0000 1.21 >+++ PatchSwapLayout.h 14 Jul 2004 20:19:21 -0000 >@@ -587,7 +587,10 @@ > //============================================================ > > PatchSwapLayout() >- : patchInfo_m(0) {} >+ : patchInfo_m(0) >+ { >+ contextSizes_m.initialize(Pooma::contexts()); >+ } > > // The main constructor takes a reference to the Layout_t type > // that we will use in the swap() routine. > > -- Jeffrey D. Oldham oldham at codesourcery.com From rkrylov at mail.ru Thu Jul 15 16:37:52 2004 From: rkrylov at mail.ru (Roman Krylov) Date: Thu, 15 Jul 2004 20:37:52 +0400 Subject: src/Particles/tests compilable Message-ID: <40F6B2E0.5090908@mail.ru> Hi. Now all src/Particles/tests compilable. What I have to note especially is that I had commented //#include "Particles/InterpolatorNGP.h" //#include "Particles/InterpolatorCIC.h" //#include "Particles/InterpolatorSUDS.h" in src/Pooma/Particles.h - I think it'll be better if one who need it will include it manually OK? And I've commented all 'setExternalGuards(field,zero);'. As I thought external guards are only an optimization not real g.l. ? As I had noticed previously 'pointIndex'->'cellContaining' and also 'indexPoint'->'vertexPosition'. Well here they are(attached). Roman. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cvs_diff URL: From rguenth at tat.physik.uni-tuebingen.de Thu Jul 15 20:27:45 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 15 Jul 2004 22:27:45 +0200 Subject: [pooma-dev] src/Particles/tests compilable In-Reply-To: <40F6B2E0.5090908@mail.ru> References: <40F6B2E0.5090908@mail.ru> Message-ID: <40F6E8C1.3010600@tat.physik.uni-tuebingen.de> Roman Krylov wrote: > Hi. > Now all src/Particles/tests compilable. > > What I have to note especially is that I had commented > //#include "Particles/InterpolatorNGP.h" > //#include "Particles/InterpolatorCIC.h" > //#include "Particles/InterpolatorSUDS.h" > in src/Pooma/Particles.h - I think it'll be better if one who need it > will include it manually OK? > And I've commented all 'setExternalGuards(field,zero);'. As I thought > external guards are only an optimization not real g.l. ? They are real guard layers, but this use looked suspicious to me, too, as usually external guards filling is up to the user, as is the physical domain. Maybe Julian can comment on this: Interpolator::scatter(const PA& attrib, const FC& field, const PPos& pos) { ... // Zero out the guard layers before scattering typename FC::Element_t zero(0); field.engine().setGuards(zero); setExternalGuards(field,zero); ... } The question is, if we assume the destination field to be zeroed by the user at entry of this function, then we need to do this only if we bypass the guard updating. And this will be an optimization, if and only if we assum initial zero field value (else clearing the internal guards is even wrong). The external guards can be handled by the user by just field.all() = 0.0; before scattering, instead of field = 0.0; How was this all supposed to being used? Richard. > As I had noticed previously 'pointIndex'->'cellContaining' > and also 'indexPoint'->'vertexPosition'. > Well here they are(attached). > Roman. From rguenth at tat.physik.uni-tuebingen.de Thu Jul 15 21:31:20 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 15 Jul 2004 23:31:20 +0200 Subject: [PATCH] Add gradient operator Message-ID: <40F6F7A8.6090109@tat.physik.uni-tuebingen.de> Like Div, this adds DiffOps/Grad. Needed for PIC2d to work. Ok? Richard. 2004Jul15 Richard Guenther * src/Field/DiffOps/Grad.h: new. src/Field/DiffOps/Grad.UR.h: likewise. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rguenth at tat.physik.uni-tuebingen.de Thu Jul 15 21:35:35 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 15 Jul 2004 23:35:35 +0200 Subject: [PATCH] Make PIC2d compile Message-ID: <40F6F8A7.3070505@tat.physik.uni-tuebingen.de> The following makes PIC2d compile. It doesn't segfault, but the output is black magic to me. Ok? Richard. 2004Jul15 Richard Guenther * examples/Particles/PIC2d/PIC2d.cpp: move to new Field/Mesh representation. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rguenth at tat.physik.uni-tuebingen.de Thu Jul 15 21:53:51 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Thu, 15 Jul 2004 23:53:51 +0200 Subject: [PATCH] Finish/clean Div.UR.h Message-ID: <40F6FCEF.2010304@tat.physik.uni-tuebingen.de> Finishes (DivCellToVert) and cleans the Divergence operator implementation. Tested with only Div test. As I was in the neighbourhood. Ok? Richard. 2004Jul15 Richard Guenther * src/Field/DiffOps/Div.h: adjust documentation. src/Field/DiffOps/Div.UR.h: implement DivCellToVert, clean implementation. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From oldham at codesourcery.com Thu Jul 15 22:57:15 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Thu, 15 Jul 2004 15:57:15 -0700 Subject: [PATCH] Finish/clean Div.UR.h In-Reply-To: <40F6FCEF.2010304@tat.physik.uni-tuebingen.de> References: <40F6FCEF.2010304@tat.physik.uni-tuebingen.de> Message-ID: <40F70BCB.8000309@codesourcery.com> Richard Guenther wrote: > Finishes (DivCellToVert) and cleans the Divergence operator > implementation. Tested with only Div test. As I was in the > neighbourhood. > > Ok? > > Richard. > > > 2004Jul15 Richard Guenther > > * src/Field/DiffOps/Div.h: adjust documentation. > src/Field/DiffOps/Div.UR.h: implement DivCellToVert, > clean implementation. > > > template > inline OutputElement_t > operator()(const F &f, int i1, int i2) const > { >- return 0.5 * >- (fact_m(0) * >- (f(i1 + 1, i2 )(0) - f(i1 , i2 )(0) + >- f(i1 + 1, i2 + 1)(0) - f(i1 , i2 + 1)(0) >- ) + >- fact_m(1) * >- (f(i1 , i2 + 1)(1) - f(i1 , i2 )(1) + >- f(i1 + 1, i2 + 1)(1) - f(i1 + 1, i2 )(1) >- ) >- ); >+ return OutputElement_t >+ (fact_m(0) * (f.read(i1+1, i2)(0) - f.read(i1, i2)(0)) >+ + fact_m(1) * (f.read(i1, i2+1)(1) - f.read(i1, i2)(1))); > } > > Yes, this is a good patch. For the operator()s, I suggest placing the + at the end of lines rather than at the beginning of the next line. Doing so will vertically align the addends, easing reading. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Thu Jul 15 22:59:45 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Thu, 15 Jul 2004 15:59:45 -0700 Subject: [PATCH] Make PIC2d compile In-Reply-To: <40F6F8A7.3070505@tat.physik.uni-tuebingen.de> References: <40F6F8A7.3070505@tat.physik.uni-tuebingen.de> Message-ID: <40F70C61.6050307@codesourcery.com> Richard Guenther wrote: > The following makes PIC2d compile. It doesn't segfault, but the > output is black magic to me. > > Ok? > > Richard. > > > 2004Jul15 Richard Guenther > > * examples/Particles/PIC2d/PIC2d.cpp: move to new Field/Mesh > representation. Yes, I like this patch. I also like the vertical alignment of operator()s' long operands. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Thu Jul 15 23:04:04 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Thu, 15 Jul 2004 16:04:04 -0700 Subject: [PATCH] Make PIC2d compile In-Reply-To: <40F6F8A7.3070505@tat.physik.uni-tuebingen.de> References: <40F6F8A7.3070505@tat.physik.uni-tuebingen.de> Message-ID: <40F70D64.3000108@codesourcery.com> Richard Guenther wrote: > The following makes PIC2d compile. It doesn't segfault, but the > output is black magic to me. > > Ok? > > Richard. > > > 2004Jul15 Richard Guenther > > * examples/Particles/PIC2d/PIC2d.cpp: move to new Field/Mesh > representation. Yes, it's good to compile. Neither you nor I know what this code does. Perhaps Julian Cummings does. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Thu Jul 15 23:05:06 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Thu, 15 Jul 2004 16:05:06 -0700 Subject: [pooma-dev] Re: [PATCH] Make PIC2d compile In-Reply-To: <40F70C61.6050307@codesourcery.com> References: <40F6F8A7.3070505@tat.physik.uni-tuebingen.de> <40F70C61.6050307@codesourcery.com> Message-ID: <40F70DA2.4030605@codesourcery.com> Jeffrey D. Oldham wrote: > Richard Guenther wrote: > >> The following makes PIC2d compile. It doesn't segfault, but the >> output is black magic to me. >> >> Ok? >> >> Richard. >> >> >> 2004Jul15 Richard Guenther >> >> * examples/Particles/PIC2d/PIC2d.cpp: move to new Field/Mesh >> representation. > > > Yes, I like this patch. I also like the vertical alignment of > operator()s' long operands. > I goofed. This comment was supposed to refer to the gradient patch. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Thu Jul 15 23:05:41 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Thu, 15 Jul 2004 16:05:41 -0700 Subject: [PATCH] Add gradient operator In-Reply-To: <40F6F7A8.6090109@tat.physik.uni-tuebingen.de> References: <40F6F7A8.6090109@tat.physik.uni-tuebingen.de> Message-ID: <40F70DC5.1010105@codesourcery.com> Richard Guenther wrote: > Like Div, this adds DiffOps/Grad. Needed for PIC2d to work. > > Ok? > > Richard. > > > 2004Jul15 Richard Guenther > > * src/Field/DiffOps/Grad.h: new. > src/Field/DiffOps/Grad.UR.h: likewise. > > > Yes, I like this patch. I also like the vertical alignment of operator()s' long operands. -- Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Fri Jul 16 08:11:13 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Fri, 16 Jul 2004 10:11:13 +0200 (CEST) Subject: [pooma-dev] Re: [PATCH] Finish/clean Div.UR.h In-Reply-To: <40F70BCB.8000309@codesourcery.com> References: <40F6FCEF.2010304@tat.physik.uni-tuebingen.de> <40F70BCB.8000309@codesourcery.com> Message-ID: On Thu, 15 Jul 2004, Jeffrey D. Oldham wrote: > Richard Guenther wrote: > > > 2004Jul15 Richard Guenther > > > > * src/Field/DiffOps/Div.h: adjust documentation. > > src/Field/DiffOps/Div.UR.h: implement DivCellToVert, > > clean implementation. > > > > > > template > > inline OutputElement_t > > operator()(const F &f, int i1, int i2) const > > { > >- return 0.5 * > >- (fact_m(0) * > >- (f(i1 + 1, i2 )(0) - f(i1 , i2 )(0) + > >- f(i1 + 1, i2 + 1)(0) - f(i1 , i2 + 1)(0) > >- ) + > >- fact_m(1) * > >- (f(i1 , i2 + 1)(1) - f(i1 , i2 )(1) + > >- f(i1 + 1, i2 + 1)(1) - f(i1 + 1, i2 )(1) > >- ) > >- ); > >+ return OutputElement_t > >+ (fact_m(0) * (f.read(i1+1, i2)(0) - f.read(i1, i2)(0)) > >+ + fact_m(1) * (f.read(i1, i2+1)(1) - f.read(i1, i2)(1))); > > } > > > > > Yes, this is a good patch. For the operator()s, I suggest placing the + > at the end of lines rather than at the beginning of the next line. > Doing so will vertically align the addends, easing reading. Uh, but the patch is wrong I noticed. I was implementing FaceToCell/CellToFace stuff, not VertexToCell/CellToVertex. I'll fixup and resubmit. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ From rkrylov at mail.ru Fri Jul 16 10:40:01 2004 From: rkrylov at mail.ru (Roman Krylov) Date: Fri, 16 Jul 2004 14:40:01 +0400 Subject: [pooma-dev] [PATCH] Make PIC2d compile In-Reply-To: <40F6F8A7.3070505@tat.physik.uni-tuebingen.de> References: <40F6F8A7.3070505@tat.physik.uni-tuebingen.de> Message-ID: <40F7B081.9000309@mail.ru> Richard Guenther wrote: > The following makes PIC2d compile. It doesn't segfault, but the > output is black magic to me. Black magic? You mean velocities computed are higher than 3E+8 mps ? :-) From cummings at linkline.com Sat Jul 17 18:22:45 2004 From: cummings at linkline.com (Julian C. Cummings) Date: Sat, 17 Jul 2004 11:22:45 -0700 Subject: [pooma-dev] src/Particles/tests compilable In-Reply-To: <40F6E8C1.3010600@tat.physik.uni-tuebingen.de> Message-ID: <001801c46c2b$0ea93420$6401a8c0@JULES> Richard, The guard layers act differently than usual in a particle scatter operation because it is possible for particles to scatter a portion of their data value into guard cells. At the end of the scatter operation, we must add the value in a physical cell to the values in all of the corresponding guard cells and assign that to the physical cell. And then we can update the guard cells from the physical cells once again for consistency. So the zeroing of the guard cells is needed at the beginning so that there is no miscounting. It is the equivalent of setting a summation variable to zero before beginning to compute the sum. The external guard cells are a bit different because they presumably do not have any corresponding physical cells. There is probably no chance of miscounting the scatter in this case. However, there could be a boundary condition that has set the external guard cells to a non-zero value, so we zero them out as well. These actions are primarily safety measures to guard against user stupidity. Perhaps there is an easier way now to achieve the same effect by doing field.all() = 0.0. This may have been a syntax that was added after the particle-field interpolation code was written. It makes more sense to just make sure the *entire* field is zero before starting the scatter computation. Alternatively, you could leave this responsibility to the user and write some assertion code that just checks that all physical and guard cells are set to zero. The assertion code would be removed in an optimized compile. Regards, Julian C. Dr. Julian C. Cummings Staff Scientist, CACR/Caltech (626) 395-2543 cummings at cacr.caltech.edu > -----Original Message----- > From: Richard Guenther [mailto:rguenth at tat.physik.uni-tuebingen.de] > Sent: Thursday, July 15, 2004 1:28 PM > To: Roman Krylov > Cc: pooma-dev at pooma.codesourcery.com > Subject: Re: [pooma-dev] src/Particles/tests compilable > > > Roman Krylov wrote: > > Hi. > > Now all src/Particles/tests compilable. > > > > What I have to note especially is that I had commented //#include > > "Particles/InterpolatorNGP.h" //#include > "Particles/InterpolatorCIC.h" > > //#include "Particles/InterpolatorSUDS.h" > > in src/Pooma/Particles.h - I think it'll be better if one > who need it > > will include it manually OK? > > And I've commented all 'setExternalGuards(field,zero);'. As > I thought > > external guards are only an optimization not real g.l. ? > > They are real guard layers, but this use looked suspicious to > me, too, > as usually external guards filling is up to the user, as is > the physical > domain. Maybe Julian can comment on this: > > Interpolator::scatter(const PA& attrib, const FC& field, > const PPos& pos) > { > ... > // Zero out the guard layers before scattering > typename FC::Element_t zero(0); > field.engine().setGuards(zero); > setExternalGuards(field,zero); > ... > } > > The question is, if we assume the destination field to be > zeroed by the > user at entry of this function, then we need to do this only if we > bypass the guard updating. And this will be an optimization, if and > only if we assum initial zero field value (else clearing the internal > guards is even wrong). The external guards can be handled by > the user by just field.all() = 0.0; before scattering, > instead of field = 0.0; > > How was this all supposed to being used? > > Richard. > > > As I had noticed previously 'pointIndex'->'cellContaining' and also > > 'indexPoint'->'vertexPosition'. Well here they are(attached). > > Roman. > From cummings at linkline.com Sat Jul 17 19:05:14 2004 From: cummings at linkline.com (Julian C. Cummings) Date: Sat, 17 Jul 2004 12:05:14 -0700 Subject: [pooma-dev] Re: [PATCH] Make PIC2d compile In-Reply-To: <40F70D64.3000108@codesourcery.com> Message-ID: <001a01c46c30$fdbd2d00$6401a8c0@JULES> As I mentioned, it's an electrostatics code. Just some charged particles bouncing around in their own self-generated electric potential. You scatter the particle charge density onto a field, solve Poisson's equation to compute the electric potential, and then advance the particle positions and velocities in time using the resulting electric field. It's a bit hard to verify a code like this other than by comparing the particle positions and velocities at some time t with those obtained from a baseline code that you *know* is correct. I don't know if I ever created such a baseline code for this example. However, you can also verify the particle scatter and gather by writing more simple examples and just checking the results by hand. That is what I did when I originally worked on this. Regards, Julian C. > -----Original Message----- > From: Jeffrey D. Oldham [mailto:oldham at codesourcery.com] > Sent: Thursday, July 15, 2004 4:04 PM > To: Richard Guenther > Cc: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] Re: [PATCH] Make PIC2d compile > > > Richard Guenther wrote: > > > The following makes PIC2d compile. It doesn't segfault, but the > > output is black magic to me. > > > > Ok? > > > > Richard. > > > > > > 2004Jul15 Richard Guenther > > > > * examples/Particles/PIC2d/PIC2d.cpp: move to new Field/Mesh > > representation. > > Yes, it's good to compile. Neither you nor I know what this > code does. > Perhaps Julian Cummings does. > > -- > Jeffrey D. Oldham > oldham at codesourcery.com > > From rguenth at tat.physik.uni-tuebingen.de Sun Jul 18 16:59:21 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Sun, 18 Jul 2004 18:59:21 +0200 Subject: [PATCH, committed] Grad/Div Message-ID: <40FAAC69.903@tat.physik.uni-tuebingen.de> This is what I finally committed. Richard. 2004Jul15 Richard Guenther * src/Field/DiffOps/Grad.h: new. src/Field/DiffOps/Grad.UR.h: likewise. 2004Jul15 Richard Guenther * src/Field/DiffOps/Div.h: adjust documentation. src/Field/DiffOps/Div.UR.h: implement DivCellToVert, clean implementation. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rguenth at tat.physik.uni-tuebingen.de Mon Jul 19 15:46:17 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Mon, 19 Jul 2004 17:46:17 +0200 Subject: [PATCH] Enable more FieldStencil testing Message-ID: <40FBECC9.9040002@tat.physik.uni-tuebingen.de> Although FieldStencil is quite unusable ATM (doesn't work with expressions as arguments), with this patch we enable some additional testing. test4 cannot be enabled due to the mentioned problem (we cannot default-construct expression engines, but FieldEngine requires this all over the place). Ok? Richard. 2004Jul19 Richard Guenther * src/Field/tests/ExpressionTest.cpp: convert Stencil to FieldStencil, enable test3. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From rguenth at tat.physik.uni-tuebingen.de Mon Jul 19 15:59:12 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Mon, 19 Jul 2004 17:59:12 +0200 Subject: [PATCH] Use StencilEngine in FieldStencil Message-ID: <40FBEFD0.8060802@tat.physik.uni-tuebingen.de> This patch drops nearly all special-casing for FieldStencil in that it uses the StencilEngine implemented in Engine/Stencil.h. The StencilEngine needs to be able to default construct itself and assign to itself for Fields, though. Thus this capability is added until maybe the FieldEngine is fixed. Tested with the two only FieldStencil tests and the two other Array Stencil tests. A follow up patch could move the Array specific parts of Engine/Stencil.h to Array/ArrayStencil.h if desired. Ok? Richard. 2004Jul19 Richard Guenther * src/Field/DiffOps/FieldStencil.h: rip out all ApplyFieldStencil engine stuff. src/Engine/Stencil.h: prepare StencilEngine being used by FieldStencilSimple. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: p URL: From oldham at codesourcery.com Mon Jul 19 18:04:51 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Mon, 19 Jul 2004 11:04:51 -0700 Subject: [PATCH] Enable more FieldStencil testing In-Reply-To: <40FBECC9.9040002@tat.physik.uni-tuebingen.de> References: <40FBECC9.9040002@tat.physik.uni-tuebingen.de> Message-ID: <40FC0D43.9070700@codesourcery.com> Richard Guenther wrote: > Although FieldStencil is quite unusable ATM (doesn't work with > expressions as arguments), with this patch we enable some additional > testing. test4 cannot be enabled due to the mentioned problem (we > cannot default-construct expression engines, but FieldEngine requires > this all over the place). > > Ok? > > Richard. > > > 2004Jul19 Richard Guenther > > * src/Field/tests/ExpressionTest.cpp: convert Stencil to > FieldStencil, enable test3. Do you want any more tests turned on in the nightly regression testing? See also comments below. >------------------------------------------------------------------------ > >Index: ExpressionTest.cpp >=================================================================== >RCS file: /home/pooma/Repository/r2/src/Field/tests/ExpressionTest.cpp,v >retrieving revision 1.2 >diff -u -u -r1.2 ExpressionTest.cpp >--- ExpressionTest.cpp 25 Dec 2003 11:26:04 -0000 1.2 >+++ ExpressionTest.cpp 19 Jul 2004 15:42:57 -0000 >@@ -222,11 +222,26 @@ > tester.check(checkTest(tester, test, a2, a4)); > } > >-class TwoPt >+template >+struct TwoPt > { >-public: >+ typedef double OutputElement_t; > TwoPt() { } >- TwoPt(const TwoPt &) { } >+ TwoPt(const TwoPt &m) : inputCentering_m(m.inputCentering_m) { } >+ template >+ TwoPt(const FE& fe) >+ { >+ inputCentering_m = fe.centering(); >+ } >+ >+ Centering outputCentering() const >+ { >+ return inputCentering_m; >+ } >+ Centering inputCentering() const >+ { >+ return inputCentering_m; >+ } > > template > inline >@@ -239,9 +254,17 @@ > inline int lowerExtent(int) const { return 1; } > inline int upperExtent(int) const { return 0; } > >-private: >+ Centering inputCentering_m; > > Do we really want this member to be public, not private or protected? > }; > >+template >+typename FieldStencilSimple, typename View1, Dom>::Type_t >::Type_t >+twoPt(const Field& expr, const Dom &domain) >+{ >+ typedef FieldStencilSimple, typename View1, Dom>::Type_t > Ret_t; >+ return Ret_t::make(TwoPt(expr), expr(domain)); >+} >+ > template > void test3(Pooma::Tester& tester, int test, > const A1 &a1, const A2 &a2, const A3 &a3, const A4 &a4, >@@ -255,8 +278,6 @@ > int to = I.last(); > int i; > >- Stencil twoPt; > > How can you remove 'twoPt', which is used? >- > a1 = initial; > a2 = initial; > a3 = initial; >@@ -289,8 +310,6 @@ > int to = I.last(); > int i; > >- Stencil twoPt; >- > a1 = initial; > a2 = initial; > a3 = initial; >@@ -421,8 +440,8 @@ > // test2(tester, 2, a1, a2, a3, a4, initial, cellInterior); > > // Need to replace the stencil code above with Field Stencil code. >- // test3(tester, 3, a1, a2, a3, a4, initial, cellInterior); >- // test4(tester, 4, a1, a2, a3, a4, initial, cellInterior); >+ test3(tester, 3, a1, a2, a3, a4, initial, cellInterior); >+ //test4(tester, 4, a1, a2, a3, a4, initial, cellInterior); > > typedef > Field, double, MultiPatch@@ -444,8 +463,8 @@ > > test1(tester, 1, ca1, ca2, ca3, ca4, cinit, cellInterior); > // test2(tester, 2, ca1, ca2, ca3, ca4, cinit, cellInterior); >- // test3(tester, 3, ca1, ca2, ca3, ca4, cinit, cellInterior); >- // test4(tester, 4, ca1, ca2, ca3, ca4, cinit, cellInterior); >+ test3(tester, 3, ca1, ca2, ca3, ca4, cinit, cellInterior); >+ //test4(tester, 4, ca1, ca2, ca3, ca4, cinit, cellInterior); > > > int ret = tester.results("ExpressionTest"); > > -- Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Mon Jul 19 18:09:09 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Mon, 19 Jul 2004 20:09:09 +0200 Subject: [PATCH] Enable more FieldStencil testing In-Reply-To: <40FC0D43.9070700@codesourcery.com> References: <40FBECC9.9040002@tat.physik.uni-tuebingen.de> <40FC0D43.9070700@codesourcery.com> Message-ID: <40FC0E45.3000202@tat.physik.uni-tuebingen.de> Jeffrey D. Oldham wrote: > Richard Guenther wrote: > >> Although FieldStencil is quite unusable ATM (doesn't work with >> expressions as arguments), with this patch we enable some additional >> testing. test4 cannot be enabled due to the mentioned problem (we >> cannot default-construct expression engines, but FieldEngine requires >> this all over the place). >> >> Ok? >> >> Richard. >> >> >> 2004Jul19 Richard Guenther >> >> * src/Field/tests/ExpressionTest.cpp: convert Stencil to >> FieldStencil, enable test3. > > > Do you want any more tests turned on in the nightly regression testing? No, the test is already running, the offending lines are just commented. > See also comments below. > >> ------------------------------------------------------------------------ >> >> Index: ExpressionTest.cpp >> =================================================================== >> RCS file: /home/pooma/Repository/r2/src/Field/tests/ExpressionTest.cpp,v >> retrieving revision 1.2 >> diff -u -u -r1.2 ExpressionTest.cpp >> --- ExpressionTest.cpp 25 Dec 2003 11:26:04 -0000 1.2 >> +++ ExpressionTest.cpp 19 Jul 2004 15:42:57 -0000 >> @@ -222,11 +222,26 @@ >> tester.check(checkTest(tester, test, a2, a4)); >> } >> >> -class TwoPt >> +template >> +struct TwoPt >> { >> -public: >> + typedef double OutputElement_t; >> TwoPt() { } >> - TwoPt(const TwoPt &) { } >> + TwoPt(const TwoPt &m) : inputCentering_m(m.inputCentering_m) { } >> + template >> + TwoPt(const FE& fe) >> + { >> + inputCentering_m = fe.centering(); >> + } >> + >> + Centering outputCentering() const >> + { >> + return inputCentering_m; >> + } >> + Centering inputCentering() const >> + { >> + return inputCentering_m; >> + } >> >> template >> inline >> @@ -239,9 +254,17 @@ >> inline int lowerExtent(int) const { return 1; } >> inline int upperExtent(int) const { return 0; } >> >> -private: >> + Centering inputCentering_m; >> >> > Do we really want this member to be public, not private or protected? Just for convenience, otherwise we'd need an accessor in the copy constructor. I don't see any point in enforcing access checking in stencil objects anyway. >> }; >> >> +template >> +typename FieldStencilSimple, typename >> View1, Dom>::Type_t >::Type_t >> +twoPt(const Field& expr, const Dom &domain) >> +{ >> + typedef FieldStencilSimple, typename >> View1, Dom>::Type_t > Ret_t; >> + return Ret_t::make(TwoPt(expr), expr(domain)); >> +} >> + >> template >> void test3(Pooma::Tester& tester, int test, >> const A1 &a1, const A2 &a2, const A3 &a3, const A4 &a4, >> @@ -255,8 +278,6 @@ >> int to = I.last(); >> int i; >> >> - Stencil twoPt; >> >> > How can you remove 'twoPt', which is used? See above - I added a global function twoPt which does all the magic. Like divVertToCell and friends are. It seems to be the way to use FieldStencilSimple. >> - >> a1 = initial; >> a2 = initial; >> a3 = initial; >> @@ -289,8 +310,6 @@ >> int to = I.last(); >> int i; >> >> - Stencil twoPt; >> - >> a1 = initial; >> a2 = initial; >> a3 = initial; >> @@ -421,8 +440,8 @@ >> // test2(tester, 2, a1, a2, a3, a4, initial, cellInterior); >> >> // Need to replace the stencil code above with Field Stencil code. >> - // test3(tester, 3, a1, a2, a3, a4, initial, cellInterior); >> - // test4(tester, 4, a1, a2, a3, a4, initial, cellInterior); >> + test3(tester, 3, a1, a2, a3, a4, initial, cellInterior); >> + //test4(tester, 4, a1, a2, a3, a4, initial, cellInterior); >> >> typedef Field, double, >> MultiPatch> @@ -444,8 +463,8 @@ >> >> test1(tester, 1, ca1, ca2, ca3, ca4, cinit, cellInterior); >> // test2(tester, 2, ca1, ca2, ca3, ca4, cinit, cellInterior); >> - // test3(tester, 3, ca1, ca2, ca3, ca4, cinit, cellInterior); >> - // test4(tester, 4, ca1, ca2, ca3, ca4, cinit, cellInterior); >> + test3(tester, 3, ca1, ca2, ca3, ca4, cinit, cellInterior); >> + //test4(tester, 4, ca1, ca2, ca3, ca4, cinit, cellInterior); >> >> >> int ret = tester.results("ExpressionTest"); >> >> > > From oldham at codesourcery.com Mon Jul 19 18:12:15 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Mon, 19 Jul 2004 11:12:15 -0700 Subject: [PATCH] Enable more FieldStencil testing In-Reply-To: <40FC0E45.3000202@tat.physik.uni-tuebingen.de> References: <40FBECC9.9040002@tat.physik.uni-tuebingen.de> <40FC0D43.9070700@codesourcery.com> <40FC0E45.3000202@tat.physik.uni-tuebingen.de> Message-ID: <40FC0EFF.8040400@codesourcery.com> Richard Guenther wrote: > Jeffrey D. Oldham wrote: > >> Richard Guenther wrote: >> >>> Although FieldStencil is quite unusable ATM (doesn't work with >>> expressions as arguments), with this patch we enable some additional >>> testing. test4 cannot be enabled due to the mentioned problem (we >>> cannot default-construct expression engines, but FieldEngine >>> requires this all over the place). >>> >>> Ok? >>> >>> Richard. >>> >>> >>> 2004Jul19 Richard Guenther >>> >>> * src/Field/tests/ExpressionTest.cpp: convert Stencil to >>> FieldStencil, enable test3. >> >> >> >> Do you want any more tests turned on in the nightly regression testing? > > > No, the test is already running, the offending lines are just commented. > >> See also comments below. >> >>> ------------------------------------------------------------------------ >>> >>> >>> Index: ExpressionTest.cpp >>> =================================================================== >>> RCS file: >>> /home/pooma/Repository/r2/src/Field/tests/ExpressionTest.cpp,v >>> retrieving revision 1.2 >>> diff -u -u -r1.2 ExpressionTest.cpp >>> --- ExpressionTest.cpp 25 Dec 2003 11:26:04 -0000 1.2 >>> +++ ExpressionTest.cpp 19 Jul 2004 15:42:57 -0000 >>> @@ -222,11 +222,26 @@ >>> tester.check(checkTest(tester, test, a2, a4)); >>> } >>> >>> -class TwoPt >>> +template >>> +struct TwoPt >>> { >>> -public: >>> + typedef double OutputElement_t; >>> TwoPt() { } >>> - TwoPt(const TwoPt &) { } >>> + TwoPt(const TwoPt &m) : inputCentering_m(m.inputCentering_m) { } >>> + template >>> + TwoPt(const FE& fe) >>> + { >>> + inputCentering_m = fe.centering(); >>> + } >>> + >>> + Centering outputCentering() const >>> + { >>> + return inputCentering_m; >>> + } >>> + Centering inputCentering() const >>> + { >>> + return inputCentering_m; >>> + } >>> >>> template >>> inline >>> @@ -239,9 +254,17 @@ >>> inline int lowerExtent(int) const { return 1; } >>> inline int upperExtent(int) const { return 0; } >>> >>> -private: >>> + Centering inputCentering_m; >>> >>> >> Do we really want this member to be public, not private or protected? > > > Just for convenience, otherwise we'd need an accessor in the copy > constructor. I don't see any point in enforcing access checking in > stencil objects anyway. > >>> }; >>> >>> +template >>> +typename FieldStencilSimple, typename >>> View1, Dom>::Type_t >::Type_t >>> +twoPt(const Field& expr, const Dom &domain) >>> +{ >>> + typedef FieldStencilSimple, typename >>> View1, Dom>::Type_t > Ret_t; >>> + return Ret_t::make(TwoPt(expr), expr(domain)); >>> +} >>> + >>> template >>> void test3(Pooma::Tester& tester, int test, >>> const A1 &a1, const A2 &a2, const A3 &a3, const A4 &a4, >>> @@ -255,8 +278,6 @@ >>> int to = I.last(); >>> int i; >>> >>> - Stencil twoPt; >>> >>> >> How can you remove 'twoPt', which is used? > > > See above - I added a global function twoPt which does all the magic. > Like divVertToCell and friends are. It seems to be the way to use > FieldStencilSimple. > >>> - >>> a1 = initial; >>> a2 = initial; >>> a3 = initial; >>> @@ -289,8 +310,6 @@ >>> int to = I.last(); >>> int i; >>> >>> - Stencil twoPt; >>> - >>> a1 = initial; >>> a2 = initial; >>> a3 = initial; >>> @@ -421,8 +440,8 @@ >>> // test2(tester, 2, a1, a2, a3, a4, initial, cellInterior); >>> >>> // Need to replace the stencil code above with Field Stencil code. >>> - // test3(tester, 3, a1, a2, a3, a4, initial, cellInterior); >>> - // test4(tester, 4, a1, a2, a3, a4, initial, cellInterior); >>> + test3(tester, 3, a1, a2, a3, a4, initial, cellInterior); >>> + //test4(tester, 4, a1, a2, a3, a4, initial, cellInterior); >>> >>> typedef Field, double, >>> MultiPatch>> @@ -444,8 +463,8 @@ >>> >>> test1(tester, 1, ca1, ca2, ca3, ca4, cinit, cellInterior); >>> // test2(tester, 2, ca1, ca2, ca3, ca4, cinit, cellInterior); >>> - // test3(tester, 3, ca1, ca2, ca3, ca4, cinit, cellInterior); >>> - // test4(tester, 4, ca1, ca2, ca3, ca4, cinit, cellInterior); >>> + test3(tester, 3, ca1, ca2, ca3, ca4, cinit, cellInterior); >>> + //test4(tester, 4, ca1, ca2, ca3, ca4, cinit, cellInterior); >>> >>> >>> int ret = tester.results("ExpressionTest"); >> Ah. I now understand. Yes, for a stencil object, access control is not terribly important. I also see the twoPt function listed. The patch looks good. Tomorrow, we'll check that it still passes. -- Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Tue Jul 20 09:20:12 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 20 Jul 2004 11:20:12 +0200 (CEST) Subject: [PATCH] Sync some toplevel documentation Message-ID: Hi! I just looked around for uncommitted deltas in my closest-to-CVS repository and came along the following documentation update. Ok? Richard. 2004Jul20 Richard Guenther * docs/reference/array.doxygen: add summary. docs/reference/field.doxygen: extend summaries, remove mentioning of MeshTraits, document Relations. docs/reference/particles.doxygen: add summary. -------------- next part -------------- Index: array.doxygen =================================================================== RCS file: /home/pooma/Repository/r2/docs/reference/array.doxygen,v retrieving revision 1.1 diff -u -u -r1.1 array.doxygen --- array.doxygen 10 Oct 2003 17:33:40 -0000 1.1 +++ array.doxygen 20 Jul 2004 09:15:29 -0000 @@ -2,4 +2,7 @@ * @defgroup Array Arrays * @ingroup Objects * + * Arrays are simple multi-dimensional indexable data containers. Data is + * managed using the various engines (\ref Engine) and the related layouts + * (\ref Layout). */ Index: field.doxygen =================================================================== RCS file: /home/pooma/Repository/r2/docs/reference/field.doxygen,v retrieving revision 1.1 diff -u -u -r1.1 field.doxygen --- field.doxygen 10 Oct 2003 17:33:40 -0000 1.1 +++ field.doxygen 20 Jul 2004 09:15:30 -0000 @@ -2,9 +2,16 @@ * @defgroup Field Fields * @ingroup Objects * - * Field related classes/files. Important classes include Field, FieldEngine - * Centering and CanonicalCentering. - * + * Fields as opposed to Arrays are compound objects out of possibly multiple + * sub-fields spreading data over multiple centering points per cell and/or to + * multiple materials. Fields come with the notion of a Mesh which adds + * coordinate information to the indices and can be linked together using + * \ref Relations to automate updates of field dependencies. \ref Relations + * are also used to implement automatic boundary conditions. + * + * The Fields engine, FieldEngine, is composed of a \ref Mesh, Centering information + * and a list of \ref Relations. Further it contains references to possibly + * multiple engines representing Fields data or expression. */ /** @@ -26,24 +33,44 @@ * - RectilinearMesh which defines a arbitrarily spaced rectilinear mesh, * - NoMesh which defines a mesh without a mesh. * - * Meshes are completed by one of Cartesian, Cylindrical or Spherical - * coordinate system classes. Complete types for mesh can be constructed - * using the MeshTraits traits class and the appropriate tag classes for - * the mesh type and the coordinate system type. - * */ /** * @defgroup DiffOps * @ingroup Field * + * A simple stencil implementation for (single-centered) Fields, + * FieldStencilSimple, and example divergence and gradient operators. */ /** * @defgroup Relations Field Relations * @ingroup Field * - * Relations are FIXME. + * Relations are a way to couple fields via expressions. That is, you define + * a relation of a Field A (LHS) to one or more Fields B, C, ... (RHS). Think + * of it as a definition like A := F(B, C, ...) where A gets updated using the + * relation F if one of the arguments to F has changed since the last read of + * A. + * + * Relations are defined via Pooma::newRelation() which takes a relation functor + * as its first argument followed by the LHS and one or multiple RHS fields. Look + * at the Pooma::functionPtr and Pooma::memberPtr for how to supply global functions + * or class members as the relation function. + * + * A relation functor needs to include a default constructor, a copy constructor + * with an extra LHS typed argument and an operator() for evaluation. An example + * would look like +
+struct MyFunctor {
+  MyFunctor() {}
+  MyFunctor(const MyFunctor&, const LHS&) {}
+  void operator()(const LHS& lhs, const RHS1& rhs1, const RHS2& rhs2) {
+    lhs.all() = (rhs1 + rhs2).all();
+  }
+};
+
+ * and be initialized with Pooma::newRelation(MyFunctor(), lhs, rhs1, rhs2). * * Usable predefined relations include boundary conditions of which * the following are available: Index: particles.doxygen =================================================================== RCS file: /home/pooma/Repository/r2/docs/reference/particles.doxygen,v retrieving revision 1.1 diff -u -u -r1.1 particles.doxygen --- particles.doxygen 10 Oct 2003 17:33:40 -0000 1.1 +++ particles.doxygen 20 Jul 2004 09:15:30 -0000 @@ -2,6 +2,12 @@ * @defgroup Particles Particles (partly pre-r2) * @ingroup Objects * - * Particles files/classes. + * Particle support concentrates on PIC (Particle In Cell) like operation + * which means particle interaction is done via Fields. Unlike particle + * methods like SPH (Smoothed Particle Hydrodynamics) there are no ghost particles, + * but parallelization works through Field guard cells. + * + * Main mechanisms for Particle - Field interaction are the gather and scatter + * operations together with various predefined interpolation methods. * */ From rguenth at tat.physik.uni-tuebingen.de Tue Jul 20 09:32:55 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 20 Jul 2004 11:32:55 +0200 (CEST) Subject: [PATCH] Fix ABCTest Message-ID: Another one. Ok? Richard. 2004Jul20 Richard Guenther * benchmarks/ABCTest/ABC.h: qualify members because of two-stage name-lookup. -------------- next part -------------- --- pooma-bk/r2/benchmarks/ABCTest/ABC.h Thu Jan 30 22:30:17 2003 +++ pooma-bib/r2/benchmarks/ABCTest/ABC.h Thu Jul 15 16:47:49 2004 @@ -410,7 +410,7 @@ { typedef typename Store::Engine_t Engine_t; - std::string qual = ::qualification(a_m); + std::string qual = ::qualification(this->a_m); if (guarded_m) { @@ -436,8 +436,8 @@ for (int iter = 0; iter < 10; ++iter) { const double k = 1.0 / sqrt(static_cast(iter+1)); - a_m = b_m + k * c_m; - c_m = 0.5 * (a_m - b_m); + this->a_m = this->b_m + k * this->c_m; + this->c_m = 0.5 * (this->a_m - this->b_m); } Pooma::blockAndEvaluate(); @@ -451,8 +451,8 @@ { // Run setup. - b_m = 0.0; - c_m = 1000.0; + this->b_m = 0.0; + this->c_m = 1000.0; Pooma::blockAndEvaluate(); } From rguenth at tat.physik.uni-tuebingen.de Tue Jul 20 09:40:55 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 20 Jul 2004 11:40:55 +0200 (CEST) Subject: [PATCH] Another Stencil test Message-ID: This adds a Stencil test for expression arguments and removes a FIXME. Ok? Richard. 2004Jul20 Richard Guenther * src/Engine/Stencil.h: remove FIXME. src/Array/tests/array_test33.cpp: new. src/Array/tests/makefile: add array_test33. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ -------------- next part -------------- --- pooma-bk/r2/src/Engine/Stencil.h Fri Jan 16 23:03:53 2004 +++ pooma-bib/r2/src/Engine/Stencil.h Thu Jul 15 11:31:50 2004 @@ -815,8 +815,6 @@ GuardLayers &usedGuards) { intersect(engine); - // FIXME: accumulate used guards from intersect above and - // stencil extent? I.e. allow Stencil<>(a(i-1)+a(i+1))? usedGuards = stencilExtent_m; return true; } --- /dev/null Tue May 18 17:20:27 2004 +++ pooma-bib/r2/src/Array/tests/array_test33.cpp Thu Jul 15 11:31:41 2004 @@ -0,0 +1,86 @@ +// -*- 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 + +//----------------------------------------------------------------------------- +// array_test33.cpp verify correctnes of stencil objects with expressions +//----------------------------------------------------------------------------- + +// Include files + +#include "Pooma/Arrays.h" +#include "Utilities/Tester.h" +#include + +class EvaluateExpr +{ +public: + template + typename A::Element_t operator()(const A& x, int i) const + { + return x.read(i); + } + + int lowerExtent(int) const { return 0; } + int upperExtent(int) const { return 0; } +}; + +int main(int argc, char *argv[]) +{ + // Initialize POOMA and output stream, using Tester class + Pooma::initialize(argc, argv); + Pooma::Tester tester(argc, argv); + + Interval<1> domain(8); + UniformGridLayout<1> layout(domain, Loc<1>(2), GuardLayers<1>(1), DistributedTag()); + Array<1,int,MultiPatch > > a(layout), b(layout), c(layout); + + a = 0; + b = 1; + c = 2; + a(domain) = Stencil()(b(domain-1)+c(domain+1), domain); + tester.check("a = b(I-1) + c(I+1)", all(a(domain) == 3)); + tester.out() << a(domain) << std::endl; + + a = 0; + b = 2; + c = 3; + a(domain) = b(domain) + Stencil()(b(domain)+c(domain+1), domain); + tester.check("a = b + b(I-1) + c", all(a(domain) == 7)); + tester.out() << a(domain) << std::endl; + + int retval = tester.results("array_test33"); + Pooma::finalize(); + return retval; +} + +// ACL:rcsinfo +// ---------------------------------------------------------------------- +// $RCSfile: array_test23.cpp,v $ $Author: sa_smith $ +// $Revision: 1.5 $ $Date: 2000/07/04 05:06:54 $ +// ---------------------------------------------------------------------- +// ACL:rcsinfo From rguenth at tat.physik.uni-tuebingen.de Tue Jul 20 09:51:21 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 20 Jul 2004 11:51:21 +0200 (CEST) Subject: [RFC] Merge some ScalarCode improvements Message-ID: Hi! I have some improvements to ScalarCode which enhance its usability and performance. Unfortunately these patches depend on changes to ScalarCodeInfo which in turn change user-visible API. Patch to ScalarCodeInfo appended below for reference. The main change is templating ScalarCodeInfo on dimension and number of MultiArg arguments. Are you interested in having such changes merged? Part of the changes would be bugfixes to allow arbitrary expressions as ScalarCode arguments (it doesnt handle updating guards correctly for shifted arguments at the moment). Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ -------------- next part -------------- *** pooma-bk/r2/src/Evaluator/ScalarCodeInfo.h Thu Oct 23 14:39:32 2003 --- pooma-bib/r2/src/Evaluator/ScalarCodeInfo.h Thu Jul 15 11:31:53 2004 *************** *** 56,61 **** --- 56,62 ---- //----------------------------------------------------------------------------- #include "Layout/INode.h" + #include "Layout/GuardLayers.h" //----------------------------------------------------------------------------- // Forward Declarations: *************** *** 67,143 **** // //----------------------------------------------------------------------------- class ScalarCodeInfo { public: ! typedef std::vector Extents_t; typedef std::vector BoolVector_t; ScalarCodeInfo() { - arguments_m = 0; - dimensions_m = 0; - } - - /// The number of arguments of the ScalarCode functor. This needs to be - /// called before any of write() and useGuards(). - void arguments(int n) - { - PAssert(n > 0); - - arguments_m = n; - writers_m.resize(n); - readers_m.resize(n); - useGuards_m.resize(n); - - int i; - for (i = 0; i < n; ++i) - { - writers_m[i] = false; - readers_m[i] = true; - useGuards_m[i] = true; - } writers_m[0] = true; readers_m[0] = false; } ! /// The number of dimensions the arguments to the ScalarCode functor ! /// span. This needs to be specified before any of the lowerExtent() ! /// and upperExtent(). ! void dimensions(int n) ! { ! PAssert(n > 0); ! ! dimensions_m = n; ! lower_m.resize(n); ! upper_m.resize(n); ! int i; ! for (i = 0; i < n; ++i) ! { ! lower_m[i] = 0; ! upper_m[i] = 0; ! } } ! /// Lower extent for dimension i. This specifies the (maximum) stencil size. ! /// Note that you need to make sure a view extending the physical domain by ! /// this amount can be taken of every argument to the functor. ! ! int &lowerExtent(int i) { ! return lower_m[i]; } ! /// Upper extent for dimension i. This specifies the (maximum) stencil size. ! /// Note that you need to make sure a view extending the physical domain by ! /// this amount can be taken of every argument to the functor. ! ! int &upperExtent(int i) { ! return upper_m[i]; } ! /// Specify whether argument i is written to, writing allows reading. This /// triggers notifying the engine after writing and possibly dirtying /// relations attached to a written field. --- 68,111 ---- // //----------------------------------------------------------------------------- + template class ScalarCodeInfo { public: ! enum { dimensions = Dim }; ! enum { arguments = size }; ! typedef std::vector BoolVector_t; ScalarCodeInfo() + : extent_m(GuardLayers(0)), + useGuards_m(arguments, true), + writers_m(arguments, false), + readers_m(arguments, true) { writers_m[0] = true; readers_m[0] = false; } ! /// Specify the shape of the guard layers used. This is used for taking ! /// views of the arguments. ! void extent(const GuardLayers &g) ! { ! extent_m = g; } ! GuardLayers& extent() { ! return extent_m; } ! const GuardLayers& extent() const { ! return extent_m; } ! ! /// Specify whether argument i is written to, writing allows reading. This /// triggers notifying the engine after writing and possibly dirtying /// relations attached to a written field. *************** *** 170,220 **** /// The domain we take the view of before passing it to the functors /// operator() method. ! template ! inline Interval extendDomain(const Interval &domain) { ! Interval ret; ! int d; ! for (d = 0; d < D; ++d) ! { ! ret[d] = ! Interval<1>( ! domain[d].first() - lower_m[d], ! domain[d].last() + upper_m[d] ! ); ! } ! return ret; } /// The domain evaluation takes place on the viewed (zero-based!) engine. ! template ! inline Interval evaluationDomain(const Interval &domain) { ! Interval ret; ! int d; ! for (d = 0; d < D; ++d) { ! ret[d] = ! Interval<1>( ! lower_m[d], ! domain[d].last() - domain[d].first() + lower_m[d] ! ); } return ret; } ! template ! inline INode extendDomain(const INode &inode) { ! return INode(inode, extendDomain(inode.domain())); } private: ! int arguments_m; ! int dimensions_m; ! Extents_t upper_m; ! Extents_t lower_m; BoolVector_t useGuards_m; BoolVector_t writers_m; BoolVector_t readers_m; --- 138,169 ---- /// The domain we take the view of before passing it to the functors /// operator() method. ! inline Interval extendDomain(const Interval &domain) const { ! return grow(domain, extent_m); } /// The domain evaluation takes place on the viewed (zero-based!) engine. ! inline Interval evaluationDomain(const Interval &domain) const { ! Interval ret; ! for (int d = 0; d < Dim; ++d) { ! ret[d] = Interval<1>(extent_m.lower(d), ! domain[d].last() - domain[d].first() ! + extent_m.lower(d)); } return ret; } ! inline INode extendDomain(const INode &inode) const { ! return INode(inode, extendDomain(inode.domain())); } private: ! GuardLayers extent_m; BoolVector_t useGuards_m; BoolVector_t writers_m; BoolVector_t readers_m; From oldham at codesourcery.com Tue Jul 20 15:10:21 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 20 Jul 2004 08:10:21 -0700 Subject: [PATCH] Sync some toplevel documentation In-Reply-To: References: Message-ID: <40FD35DD.8040508@codesourcery.com> Richard Guenther wrote: >Hi! > >I just looked around for uncommitted deltas in my closest-to-CVS >repository and came along the following documentation update. > >Ok? > >Richard. > > >2004Jul20 Richard Guenther > > * docs/reference/array.doxygen: add summary. > docs/reference/field.doxygen: extend summaries, remove mentioning > of MeshTraits, document Relations. > docs/reference/particles.doxygen: add summary. > Yes, this is good documentation. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Tue Jul 20 15:10:59 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 20 Jul 2004 08:10:59 -0700 Subject: [PATCH] Fix ABCTest In-Reply-To: References: Message-ID: <40FD3603.3010702@codesourcery.com> Richard Guenther wrote: >Another one. > >Ok? > >Richard. > > >2004Jul20 Richard Guenther > > * benchmarks/ABCTest/ABC.h: qualify members because of two-stage > name-lookup. > Yes, please commit this. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Tue Jul 20 18:29:52 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 20 Jul 2004 11:29:52 -0700 Subject: [PATCH] Another Stencil test In-Reply-To: References: Message-ID: <40FD64A0.6070800@codesourcery.com> Richard Guenther wrote: >This adds a Stencil test for expression arguments and removes a FIXME. > >Ok? > > Yes, please commit this. More testing is always a good thing. I'll add another test to the nightly Pooma regression tests. >Richard. > > >2004Jul20 Richard Guenther > > * src/Engine/Stencil.h: remove FIXME. > src/Array/tests/array_test33.cpp: new. > src/Array/tests/makefile: add array_test33. > >-- >Richard Guenther >WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ > >------------------------------------------------------------------------ > >--- pooma-bk/r2/src/Engine/Stencil.h Fri Jan 16 23:03:53 2004 >+++ pooma-bib/r2/src/Engine/Stencil.h Thu Jul 15 11:31:50 2004 >@@ -815,8 +815,6 @@ > GuardLayers &usedGuards) > { > intersect(engine); >- // FIXME: accumulate used guards from intersect above and >- // stencil extent? I.e. allow Stencil<>(a(i-1)+a(i+1))? > usedGuards = stencilExtent_m; > return true; > } >--- /dev/null Tue May 18 17:20:27 2004 >+++ pooma-bib/r2/src/Array/tests/array_test33.cpp Thu Jul 15 11:31:41 2004 >@@ -0,0 +1,86 @@ >+// -*- 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 >+ >+//----------------------------------------------------------------------------- >+// array_test33.cpp verify correctnes of stencil objects with expressions >+//----------------------------------------------------------------------------- >+ >+// Include files >+ >+#include "Pooma/Arrays.h" >+#include "Utilities/Tester.h" >+#include >+ >+class EvaluateExpr >+{ >+public: >+ template >+ typename A::Element_t operator()(const A& x, int i) const >+ { >+ return x.read(i); >+ } >+ >+ int lowerExtent(int) const { return 0; } >+ int upperExtent(int) const { return 0; } >+}; >+ >+int main(int argc, char *argv[]) >+{ >+ // Initialize POOMA and output stream, using Tester class >+ Pooma::initialize(argc, argv); >+ Pooma::Tester tester(argc, argv); >+ >+ Interval<1> domain(8); >+ UniformGridLayout<1> layout(domain, Loc<1>(2), GuardLayers<1>(1), DistributedTag()); >+ Array<1,int,MultiPatch > > a(layout), b(layout), c(layout); >+ >+ a = 0; >+ b = 1; >+ c = 2; >+ a(domain) = Stencil()(b(domain-1)+c(domain+1), domain); >+ tester.check("a = b(I-1) + c(I+1)", all(a(domain) == 3)); >+ tester.out() << a(domain) << std::endl; >+ >+ a = 0; >+ b = 2; >+ c = 3; >+ a(domain) = b(domain) + Stencil()(b(domain)+c(domain+1), domain); >+ tester.check("a = b + b(I-1) + c", all(a(domain) == 7)); >+ tester.out() << a(domain) << std::endl; >+ >+ int retval = tester.results("array_test33"); >+ Pooma::finalize(); >+ return retval; >+} >+ >+// ACL:rcsinfo >+// ---------------------------------------------------------------------- >+// $RCSfile: array_test23.cpp,v $ $Author: sa_smith $ >+// $Revision: 1.5 $ $Date: 2000/07/04 05:06:54 $ >+// ---------------------------------------------------------------------- >+// ACL:rcsinfo > > -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Tue Jul 20 18:32:47 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Tue, 20 Jul 2004 11:32:47 -0700 Subject: [pooma-dev] Re: [PATCH] Another Stencil test In-Reply-To: <40FD64A0.6070800@codesourcery.com> References: <40FD64A0.6070800@codesourcery.com> Message-ID: <40FD654F.5040409@codesourcery.com> Jeffrey D. Oldham wrote: > Richard Guenther wrote: > >> This adds a Stencil test for expression arguments and removes a FIXME. >> >> Ok? >> >> > Yes, please commit this. More testing is always a good thing. I'll > add another test to the nightly Pooma regression tests. > >> Richard. >> >> >> 2004Jul20 Richard Guenther >> >> * src/Engine/Stencil.h: remove FIXME. >> src/Array/tests/array_test33.cpp: new. >> src/Array/tests/makefile: add array_test33. > The test should be named array_test29.cpp, not array_test33.cpp, since the largest "numbered" test is currently 28. -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Wed Jul 21 17:50:52 2004 From: oldham at codesourcery.com (Jeffrey D. Oldham) Date: Wed, 21 Jul 2004 10:50:52 -0700 Subject: [PATCH] Use StencilEngine in FieldStencil In-Reply-To: <40FBEFD0.8060802@tat.physik.uni-tuebingen.de> References: <40FBEFD0.8060802@tat.physik.uni-tuebingen.de> Message-ID: <40FEACFC.3060103@codesourcery.com> Richard Guenther wrote: > This patch drops nearly all special-casing for FieldStencil in that it > uses the StencilEngine implemented in Engine/Stencil.h. The > StencilEngine needs to be able to default construct itself and assign > to itself for Fields, though. Thus this capability is added until > maybe the FieldEngine is fixed. > > Tested with the two only FieldStencil tests and the two other Array > Stencil tests. > > A follow up patch could move the Array specific parts of > Engine/Stencil.h to Array/ArrayStencil.h if desired. > > Ok? > > Richard. > > > 2004Jul19 Richard Guenther > > * src/Field/DiffOps/FieldStencil.h: rip out all > ApplyFieldStencil engine stuff. > src/Engine/Stencil.h: prepare StencilEngine being used > by FieldStencilSimple. Yes, this patch is a good simplification. -- Jeffrey D. Oldham oldham at codesourcery.com From rguenth at tat.physik.uni-tuebingen.de Fri Jul 23 12:10:40 2004 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Fri, 23 Jul 2004 14:10:40 +0200 (CEST) Subject: [RFA] better igc up-to-date-ness tracking, optimized igc communication Message-ID: As a proof of concept the attached patch implements more accurate tracking of which igc cells are up-to-date to reduce communication. It also implements a new GuardSend/Receive iterate for the POOMA_MPI case which is able to merge consecutive igc updates by using a global std::map for bookkeeping (yay!). A new test Array/tests/array_test30.cpp tries to completely cover all possible cases of igc updates and passes in serial mode and in MPI mode for 1 process and #processes == #patches. For mixed remote/local updates there seems to be a problem, thus this is RFA and not a patch submission. Please look at it, tell me how to avoid the global std::map (or if it is ok), test it with your favorite application, etc. I'll be away for holidays for a few weeks now. Richard. 2004Jul23 Richard Guenther * src/Engine/MultiPatchEngine.h: abstract the dirty flag and record partial up-to-date-ness via a GuardLayer object. (setDirty): for POOMA_MPI mode clear the global hash. src/Engine/MultiPatchEngine.cpp: handle the abstract dirty flag. (simpleAssign): add optimized mode using the new GuardSend and GuardReceive iterates for POOMA_MPI. (fillGuardsHandler): honour partial up-to-date information, produce partial update domains. src/Layout/GuardLayers.h: abstract from the data-type, add operator>=. src/Threads/IterateSchedulers/SerialAsync.h (waitForSomeRequests): fix bug for non-blocking operation. (runSomething): always complete complete message iterates. src/Tulip/SendReceive.h: add GuardSend and GuardReceive iterates that are able to merge with consecutive iterates using a global std::map. src/Array/tests/array_test30.cpp: new. -------------- next part -------------- ===== src/Engine/MultiPatchEngine.h 1.12 vs edited ===== --- 1.12/r2/src/Engine/MultiPatchEngine.h 2004-01-29 12:01:35 +01:00 +++ edited/src/Engine/MultiPatchEngine.h 2004-07-23 13:34:34 +02:00 @@ -659,27 +659,36 @@ inline void setDirty() const { - *pDirty_m = (1<<(Dim*2))-1; + pDirty_m->setDirty(); + +#if POOMA_MPI + // We need to clear the GuardSend and GuardReceive iterate map for + // all DataObjects in this engine. + // Possibly instead of the O(n^2) looking loop we could loop over + // the guard fill list and identify all possible communication + // iterates that way. For later optimization. + typedef std::pair GIMKey_t; + typedef std::map GIMap_t; + extern GIMap_t guardSendIterateMap_g; + extern GIMap_t guardReceiveIterateMap_g; + for (int i=0; i= 0 && face <= Dim*2-1); - *pDirty_m &= ~(1<clearDirty(); } - inline bool isDirty(int face = -1) const + inline bool isDirty() const { - if (face == -1) - return *pDirty_m != 0; - else { - PAssert(face >= 0 && face <= Dim*2-1); - return *pDirty_m & (1<isDirty(); } //============================================================ @@ -879,6 +888,36 @@ }; + /// Opaque type for the dirty flag + + struct DirtyFlag + { + void setDirty() + { + dirty_m = true; + clean_m = GuardLayers(0); + } + void clearDirty() + { + dirty_m = false; + clean_m = GuardLayers(255); + } + bool isDirty() + { + return dirty_m; + } + int upToDate(int face) const + { + return face&1 ? clean_m.upper(face/2) : clean_m.lower(face/2); + } + typename GuardLayers::Element_t& upToDate(int face) + { + return face&1 ? clean_m.upper(face/2) : clean_m.lower(face/2); + } + GuardLayers clean_m; + bool dirty_m; + }; + //=========================================================================== // Data //=========================================================================== @@ -896,7 +935,7 @@ /// must share the same flag. We use the reference count in /// data_m to decide whether to clean this up. - int *pDirty_m; + DirtyFlag *pDirty_m; }; @@ -1245,14 +1284,14 @@ baseEngine_m.setDirty(); } - inline void clearDirty(int face=-1) const + inline void clearDirty() const { - baseEngine_m.clearDirty(face); + baseEngine_m.clearDirty(); } - inline bool isDirty(int face=-1) const + inline bool isDirty() const { - return baseEngine_m.isDirty(face); + return baseEngine_m.isDirty(); } //--------------------------------------------------------------------------- ===== src/Engine/MultiPatchEngine.cpp 1.12 vs edited ===== --- 1.12/r2/src/Engine/MultiPatchEngine.cpp 2004-01-29 12:06:22 +01:00 +++ edited/src/Engine/MultiPatchEngine.cpp 2004-07-23 13:17:28 +02:00 @@ -79,12 +79,10 @@ Engine(const Layout_t &layout) : layout_m(layout), data_m(layout.sizeGlobal()), - pDirty_m(new int) + pDirty_m(new DirtyFlag) { typedef typename Layout_t::Value_t Node_t; - setDirty(); - // check for correct match of PatchTag and the mapper used to make the // layout. // THIS IS A HACK! we test on the context of the first patch, and if it @@ -135,6 +133,8 @@ // Attach ourself to the layout so we can receive messages. layout_m.attach(*this); + + setDirty(); } @@ -250,7 +250,7 @@ { if (data_m.isValid() && data_m.isShared()) { data_m.makeOwnCopy(); - pDirty_m = new int(*pDirty_m); + pDirty_m = new DirtyFlag(*pDirty_m); } return *this; @@ -264,88 +264,134 @@ // //----------------------------------------------------------------------------- +#if POOMA_MPI + /// Guard layer assign between non-remote engines, just use the -/// ET mechanisms +/// ET mechanisms on the optimized domain template static inline void simpleAssign(const Array& lhs, const Array& rhs, - const Interval& domain) + const Interval&, + const Interval& domain2, + bool optimize) { - lhs(domain) = rhs(domain); + lhs(domain2) = rhs(domain2); } /// Guard layer assign between remote engines, use Send/Receive directly /// to avoid one extra copy of the data. +/// Uses domain2 for local->local copies and domain for copies involving +/// remote engines as Send/Receive requests get merged downway. template static inline void simpleAssign(const Array >& lhs, const Array >& rhs, - const Interval& domain) + const Interval& domain, + const Interval& domain2, + bool optimize) { - if (lhs.engine().owningContext() == rhs.engine().owningContext()) - lhs(domain) = rhs(domain); - else { - typedef typename NewEngine, Interval >::Type_t ViewEngine_t; - if (lhs.engine().engineIsLocal()) - Receive::receive(ViewEngine_t(lhs.engine().localEngine(), domain), - rhs.engine().owningContext()); - else if (rhs.engine().engineIsLocal()) - SendReceive::send(ViewEngine_t(rhs.engine().localEngine(), domain), + if (lhs.engine().owningContext() == rhs.engine().owningContext()) { + PAssert(lhs.engine().engineIsLocal() && rhs.engine().engineIsLocal()); + Array llhs, lrhs; + llhs.engine() = lhs.engine().localEngine(); + lrhs.engine() = rhs.engine().localEngine(); + llhs(domain2) = lrhs(domain2); + } else { + if (!optimize) { + typedef typename NewEngine, Interval >::Type_t ViewEngine_t; + if (lhs.engine().engineIsLocal()) + Receive::receive(ViewEngine_t(lhs.engine().localEngine(), domain), + rhs.engine().owningContext()); + else if (rhs.engine().engineIsLocal()) + SendReceive::send(ViewEngine_t(rhs.engine().localEngine(), domain), + lhs.engine().owningContext()); + } else { + if (lhs.engine().engineIsLocal()) + GuardReceive::receive(lhs.engine().localEngine(), domain, + rhs.engine().owningContext()); + else if (rhs.engine().engineIsLocal()) + GuardSend::send(rhs.engine().localEngine(), domain, lhs.engine().owningContext()); + } } } +#endif + template void Engine >:: fillGuardsHandler(const GuardLayers& g, const WrappedInt &) const { - if (!isDirty()) return; + if (!isDirty()) + return; - int updated = 0; typename Layout_t::FillIterator_t p = layout_m.beginFillList(); + GuardLayers clean = pDirty_m->clean_m; while (p != layout_m.endFillList()) { - int src = p->ownedID_m; - int dest = p->guardID_m; - - // Skip face, if not dirty. + // Check how much of the guards (needed) we need where (dim, upper) - if (isDirty(p->face_m)) { + int dim = p->face_m/2; + bool upper = p->face_m&1; + int needed = upper ? g.upper(dim) : g.lower(dim); - // Check, if the p->domain_m is a guard which matches the - // needed guard g. + // Check against up-to-date status - int d = p->face_m/2; - int guardSizeNeeded = p->face_m & 1 ? g.upper(d) : g.lower(d); - if (!(p->face_m != -1 - && guardSizeNeeded == 0)) { + if (pDirty_m->upToDate(p->face_m) < needed) { - // Create patch arrays that see the entire patch: + // Create patch arrays that see the entire patch: - Array lhs(data()[dest]), rhs(data()[src]); - - // Now do assignment from the subdomains. + int src = p->ownedID_m; + int dest = p->guardID_m; + Array lhs(data()[dest]), rhs(data()[src]); + + // Compute subdomain we need to assign by + // - shrinking the domain according to the needed guards + // - shrinking the domain according to the already up-to-date guards + + // needed + Interval domain = p->domain_m; + if (upper) + domain[dim] = shrinkRight(p->domain_m[dim], p->domain_m[dim].size() - g.upper(dim)); + else + domain[dim] = shrinkLeft(p->domain_m[dim], p->domain_m[dim].size() - g.lower(dim)); + + // needed minus already up-to-date + Interval domain2 = domain; + if (upper) + domain2[dim] = shrinkLeft(domain[dim], pDirty_m->upToDate(p->face_m)); + else + domain2[dim] = shrinkRight(domain[dim], pDirty_m->upToDate(p->face_m)); + + // Now do the assignment #if POOMA_MPI - simpleAssign(lhs, rhs, p->domain_m); + simpleAssign(lhs, rhs, domain, domain2, true); #else - lhs(p->domain_m) = rhs(p->domain_m); + lhs(domain2) = rhs(domain2); #endif - // Mark up-to-date. - updated |= 1<face_m; - - } + // Record guard up-to-date-ness change, but defer real update + // because it would confuse further processing of the fill list. + if (upper) + clean.upper(dim) = needed; + else + clean.lower(dim) = needed; } ++p; } - *pDirty_m &= ~updated; + // Do the deferred update of the clean status. + pDirty_m->clean_m = clean; + + // Check, if all internal guards are clean and update dirty flag accordingly. + if (pDirty_m->clean_m >= layout().internalGuards()) + pDirty_m->dirty_m = false; } @@ -377,7 +423,7 @@ ++p; } - setDirty(); + clearDirty(); } ===== src/Layout/GuardLayers.h 1.5 vs edited ===== --- 1.5/r2/src/Layout/GuardLayers.h 2003-12-03 12:30:43 +01:00 +++ edited/src/Layout/GuardLayers.h 2004-07-22 17:27:26 +02:00 @@ -57,6 +57,7 @@ class GuardLayers { public: + typedef int Element_t; //============================================================ // Constructors @@ -136,12 +137,12 @@ // Mutators //============================================================ - int &lower(int i) + Element_t &lower(int i) { PInsist(i=0," GuardLayers index out of range "); return lower_m[i]; } - int &upper(int i) + Element_t &upper(int i) { PInsist(i=0," GuardLayers index out of range "); return upper_m[i]; @@ -162,6 +163,17 @@ return result; } + bool operator>=(const GuardLayers &gcs) const + { + for (int d = 0; d < Dim; ++d) + { + if (!(lower_m[d] >= gcs.lower_m[d] + && upper_m[d] >= gcs.upper_m[d])) + return false; + } + return true; + } + bool operator==(int gcw) const { bool result = true; @@ -250,8 +262,8 @@ private: - int lower_m[Dim]; - int upper_m[Dim]; + Element_t lower_m[Dim]; + Element_t upper_m[Dim]; }; template ===== src/Threads/IterateSchedulers/SerialAsync.h 1.13 vs edited ===== --- 1.13/r2/src/Threads/IterateSchedulers/SerialAsync.h 2004-07-15 16:55:47 +02:00 +++ edited/src/Threads/IterateSchedulers/SerialAsync.h 2004-07-21 15:09:35 +02:00 @@ -263,7 +263,7 @@ res = MPI_Testsome(last_used_request+1, requests_m, &nr_finished, finished, statuses); PAssert(res == MPI_SUCCESS || res == MPI_ERR_IN_STATUS); - if (nr_finished == MPI_UNDEFINED) + if (nr_finished == MPI_UNDEFINED || nr_finished == 0) return false; // release finised requests @@ -311,9 +311,13 @@ static bool runSomething(bool mayBlock = true) { // do work in this order to minimize communication latency: + // - process finished messages // - issue all messages // - do some regular work // - wait for messages to complete + + if (waitForSomeRequests(false)) + return true; RunnablePtr_t p = NULL; if (!workQueueMessages_m.empty()) { ===== src/Tulip/Messaging.cmpl.cpp 1.5 vs edited ===== --- 1.5/r2/src/Tulip/Messaging.cmpl.cpp 2004-01-07 12:18:08 +01:00 +++ edited/src/Tulip/Messaging.cmpl.cpp 2004-07-21 10:05:49 +02:00 @@ -48,6 +48,12 @@ int RemoteProxyBase::tag_m = 0; #endif +#if POOMA_MPI +typedef std::pair GIMKey_t; +typedef std::map GIMap_t; +GIMap_t guardSendIterateMap_g; +GIMap_t guardReceiveIterateMap_g; +#endif //----------------------------------------------------------------------------- // Tag generator creates a set of tags for global use in r2. There is a ===== src/Tulip/SendReceive.h 1.12 vs edited ===== --- 1.12/r2/src/Tulip/SendReceive.h 2004-01-07 12:18:11 +01:00 +++ edited/src/Tulip/SendReceive.h 2004-07-23 13:50:24 +02:00 @@ -491,6 +491,262 @@ }; +/// A map of -> Iterate* relations. +typedef std::pair GIMKey_t; +typedef std::map GIMap_t; +extern GIMap_t guardSendIterateMap_g; +extern GIMap_t guardReceiveIterateMap_g; + +/** + * A SendIterate requests a read lock on a piece of data. When that read lock + * is granted, we call a cheetah matching handler to send the data to the + * appropriate context. We construct the SendIterate with a tag that is used + * to match the appropriate ReceiveIterate on the remote context. + */ + +template +class GuardSendIterate + : public Pooma::Iterate_t +{ +public: + GuardSendIterate(const View &view, const Interval &domain, + int toContext, int tag) + : Pooma::Iterate_t(Pooma::scheduler()), + toContext_m(toContext), + tag_m(tag), + view_m(view), + domain_m(domain) + { + hintAffinity(engineFunctor(view_m, + DataObjectRequest())); + +#if POOMA_REORDER_ITERATES + // Priority interface was added to r2 version of serial async so that + // message send iterates would run before any other iterates. + priority(-1); +#endif + + DataObjectRequest writeReq(*this); + DataObjectRequest readReq(writeReq); + engineFunctor(view_m, readReq); + } + + virtual void run() + { + // at this point we no longer can accept merging with other + // GuardSendIterates. + guardSendIterateMap_g.erase(GIMKey_t(toContext_m, view_m.dataObject())); + + typedef typename NewEngine >::Type_t View_t; + typedef Cheetah::Serialize Serialize_t; + + // take the view + View_t view(view_m, domain_m); + + // serialize and send buffer + int length = Serialize_t::size(view); + buffer_m = new char[length]; + Serialize_t::pack(view, buffer_m); + MPI_Request *request = Smarts::SystemContext::getMPIRequest(this); + int res = MPI_Isend(buffer_m, length, MPI_CHAR, toContext_m, tag_m, + MPI_COMM_WORLD, request); + PAssert(res == MPI_SUCCESS); + + // release locks + DataObjectRequest writeReq; + DataObjectRequest readReq(writeReq); + engineFunctor(view_m, readReq); + } + + virtual ~GuardSendIterate() + { + // cleanup temporary objects. + delete[] buffer_m; + } + + void addDomain(const Interval& domain) + { + if (contains(domain, domain_m)) + domain_m = domain; + else + PAssert(contains(domain_m, domain)); + } + +private: + + // Context we're sending the data to. + + int toContext_m; + + // A tag used to match the sent data with the right receive. + + int tag_m; + + // Communication buffer. + + char *buffer_m; + + // The data we're sending, a local patch with the domain to send + + View view_m; + Interval domain_m; +}; + + +/** + * ReceiveIterate requests a write lock on a piece of data. When that lock + * is granted, we register the data with the cheetah matching handler which + * will fill the block when a message arrives. The write lock is released + * by the matching handler. + */ + +template +class GuardReceiveIterate + : public Pooma::Iterate_t +{ +public: + + typedef GuardReceiveIterate This_t; + + GuardReceiveIterate(const View &view, const Interval &domain, + int fromContext, int tag) + : Pooma::Iterate_t(Pooma::scheduler()), + fromContext_m(fromContext), + tag_m(tag), buffer_m(NULL), + view_m(view), + domain_m(domain) + { + hintAffinity(engineFunctor(view, + DataObjectRequest())); + +#if POOMA_REORDER_ITERATES + // Priority interface was added to r2 version of serial async so that + // message receive iterates would run after any other iterates. + priority(-1); +#endif + + DataObjectRequest writeReq(*this); + engineFunctor(view, writeReq); + + Pooma::addIncomingMessage(); + } + + virtual void run() + { + // at this point we can no longer accept merges with other + // GuardReceiveIterates. + guardReceiveIterateMap_g.erase(GIMKey_t(fromContext_m, view_m.dataObject())); + + typedef typename NewEngine >::Type_t View_t; + + // take the view - maybe can optimize this, because we need it only + // for size calculation + View_t view(view_m, domain_m); + + int length = Cheetah::Serialize::size(view); + buffer_m = new char[length]; + MPI_Request *request = Smarts::SystemContext::getMPIRequest(this); + int res = MPI_Irecv(buffer_m, length, MPI_CHAR, fromContext_m, tag_m, + MPI_COMM_WORLD, request); + PAssert(res == MPI_SUCCESS); + } + + virtual ~GuardReceiveIterate() + { + typedef typename NewEngine >::Type_t View_t; + typedef Cheetah::Serialize Serialize_t; + + // take the view + View_t view(view_m, domain_m); + + // de-serialize into target view directly + Serialize_t::unpack(view, buffer_m); + + // cleanup temporary objects + delete[] buffer_m; + + // release locks + DataObjectRequest writeReq; + engineFunctor(view_m, writeReq); + + Pooma::gotIncomingMessage(); + } + + void addDomain(const Interval& domain) + { + if (contains(domain, domain_m)) + domain_m = domain; + else + PAssert(contains(domain_m, domain)); + } + +private: + + // Context we're sending the data to. + + int fromContext_m; + + // A tag used to match the sent data with the right send. + + int tag_m; + + // Communication buffer. + + char *buffer_m; + + // The place to put the data we're receiving, a local patch with + // the domain to receive to. + + View view_m; + Interval domain_m; +}; + +/** + * SendReceive contains two static functions, send(view, context) and + * receive(view, context). These functions encapsulate generating matching + * tags for the send and receive and launching the iterates to perform the + * send and receive. + */ + +struct GuardSend +{ + template + static + void send(const View &view, const Interval &domain, + int toContext) + { + PAssert(toContext >= 0 && toContext < Pooma::contexts()); + Pooma::Iterate_t* &it = guardSendIterateMap_g[GIMKey_t(toContext, view.dataObject())]; + if (!it) { + int tag = Pooma::sendTag(toContext); + it = new GuardSendIterate(view, domain, toContext, tag); + Pooma::scheduler().handOff(it); + } else { + static_cast*>(it)->addDomain(domain); + } + } +}; + +struct GuardReceive +{ + template + static + void receive(const View &view, const Interval &domain, + int fromContext) + { + PAssert(fromContext >= 0 && fromContext < Pooma::contexts()); + Pooma::Iterate_t* &it = guardReceiveIterateMap_g[GIMKey_t(fromContext, view.dataObject())]; + if (!it) { + int tag = Pooma::receiveTag(fromContext); + it = new GuardReceiveIterate(view, domain, fromContext, tag); + Pooma::scheduler().handOff(it); + } else { + static_cast*>(it)->addDomain(domain); + } + } +}; + + #else // not POOMA_MESSAGING --- /dev/null Tue May 18 17:20:27 2004 +++ src/Array/tests/array_test30.cpp Fri Jul 23 13:36:41 2004 @@ -0,0 +1,127 @@ +// -*- 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 + +//----------------------------------------------------------------------------- +// array_test30: verify correctness of igc updates +//----------------------------------------------------------------------------- + +// Include files + +#include "Pooma/Arrays.h" +#include "Utilities/Tester.h" +#include + + +template +bool test(Pooma::Tester& tester, + const A1& a_mp, const A1& b_mp, + const A2& a_sp, const A2& b_sp, + const Loc<2>& delta1, const Loc<2>& delta2) +{ + static int sequence = 0; + Interval<2> I; + + // initialize rhs arrays, ensure wrong igc values + // via sequence number. + I = b_sp.totalDomain(); + b_sp(I) = sequence + iota(I).comp(0) + I[0].size()*iota(I).comp(1); + b_mp.engine().setGuards(0); + b_mp(I) = b_sp(I); + + // do calculation both sp and mp + I = a_sp.physicalDomain(); + a_sp(I) = b_sp(I+delta1) - b_sp(I+delta2); + a_mp(I) = b_mp(I+delta1) - b_mp(I+delta2); + + // check the results are the same everywhere + bool res = all(a_sp(I) == a_mp(I)); + tester.out() << "For deltas " << delta1 + << " and " << delta2 << " "; + tester.check("result is", res); + if (!res) { + int n = b_mp.layout().sizeGlobal(); + for (int i=0; i > b(b_mp.engine().globalPatch(i)); + tester.out() << "Brick " << i << " " << intersect(b.domain(), b_mp.physicalDomain()) + << " is\n" << b(intersect(b.totalDomain(), b_mp.physicalDomain())) + << std::endl; + } + tester.out() << "Aborting." << std::endl; + return false; + } + + sequence++; + + return true; +} + + +int main(int argc, char *argv[]) +{ + // Initialize POOMA and output stream, using Tester class + Pooma::initialize(argc, argv); + Pooma::Tester tester(argc, argv); + + Interval<2> domain(12, 12); + UniformGridLayout<2> layout_mp(domain, Loc<2>(3, 3), + GuardLayers<2>(2), DistributedTag()); + DomainLayout<2> layout_sp(domain, GuardLayers<2>(2)); + + Array<2, int, MultiPatch > > + a_mp(layout_mp), b_mp(layout_mp); + Array<2, int, Brick> + a_sp(layout_sp), b_sp(layout_sp); + + // all 5^4 == 625 cases + for (int d1i = -2; d1i <= 2; ++d1i) + for (int d1j = -2; d1j <= 2; ++d1j) + for (int d2i = -2; d2i <= 2; ++d2i) + for (int d2j = -2; d2j <= 2; ++d2j) + if (!test(tester, a_mp, b_mp, a_sp, b_sp, + Loc<2>(d1i, d1j), Loc<2>(d2i, d2j))) + goto out; + out: + + // Expected results are + // passes with 1, 2, 9 + // fails with 3, 4, 5, 6, 7, 8 + // Which hints at problems with mixed local->local / local->remote igc updates + // for diagonal igc cells. + tester.out() << "Best testing is done with all 1 to 9 processes" << std::endl; + + int retval = tester.results("array_test30"); + Pooma::finalize(); + return retval; +} + +// ACL:rcsinfo +// ---------------------------------------------------------------------- +// $RCSfile: array_test29.cpp,v $ $Author: pooma $ +// $Revision: 1.1 $ $Date: 2004/07/20 18:41:00 $ +// ---------------------------------------------------------------------- +// ACL:rcsinfo