From JimC at proximation.com Tue May 1 20:07:07 2001 From: JimC at proximation.com (James Crotinger) Date: Tue, 1 May 2001 13:07:07 -0700 Subject: signed == signed - sizeof(...), and other warnings... (non-POOMA C++ questions) Message-ID: Hey Mark. Just a couple of C++ (non-Pooma related) questions. I was somewhat surprised that -Wall flagged the following code with a warning: void bar() { int a, b; (void)(a == b - sizeof(int)); } Compiling this gives: $ g++ -Wall -c foo.cpp foo.cpp: In function `void bar()': foo.cpp:4: warning: comparison between signed and unsigned Does this mean operator-(int,unsigned int) returns unsigned? That seem bizarre to say the least. Also, on the subject of warnings, awhile back I wrote about some destructor warnings and you replied: James> What it says is true and is by design. This particular James> class (and many like it) is reference counted and should James> never be deleted by an explicit call to delete. Rather, James> when all the references are released, the release function James> calls "delete this". This seems like a common enough James> idiom. Any idea why there is a warning? Mark> Normally, that warning fires on code like: Mark> Mark> class C { Mark> ~C (); Mark> }; Mark> Mark> Such a class isn't very useful, since you can't create an object of Mark> this type. (Why? Because when you construct an object, the Mark> destructor has to be accessible at the point of construction; so Mark> sayeth the standard.) GCC flags "C c;" as an error, but is happy with "C *pc = new C;". This is good or my code below wouldn't work, but I'm not sure I see the difference (for this simple case). Mark> However, the case you bring up (an overloaded operator `delete') Mark> should probably be an exception to the warning. Actually, I'm not overloading delete. Here's a short example code: class IA { public: virtual int release() = 0; }; class A : public IA { public: A() : count_m(0) { } int release() { --count_m; if (count_m == 0) { delete this; return 0; } return count_m; } private: ~A() { } int count_m; }; When I compile this: $ g++ -Wall -c bar.cpp bar.cpp:17: warning: \ `class A' only defines a private destructor and has no friends bar.cpp:17: warning: \ `class A' has virtual functions but non-virtual destructor You are right in that I can't do: int main() { A a; return 0; } But that is actually one of the reasons that I want to have the destructor private - I want to disallow this. You can however do: int main() { IA *pa = new A; pa->release(); return 0; } This compiles and works just fine. The proper destructor is called since it is called through the virtual function release(). But I still get the warning. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From JimC at proximation.com Tue May 1 20:10:27 2001 From: JimC at proximation.com (James Crotinger) Date: Tue, 1 May 2001 13:10:27 -0700 Subject: [pooma-dev] signed == signed - sizeof(...), and other warning s... (non-POOMA C++ questions) Message-ID: I guess this is just part of C's wonderful promotion rules - I found it in K&R. This is harmless, but annoying. Jim -----Original Message----- From: James Crotinger [mailto:JimC at proximation.com] Sent: Tuesday, May 01, 2001 2:07 PM To: Mark Mitchell (E-mail) Cc: 'pooma-dev at pooma.codesourcery.com' Subject: [pooma-dev] signed == signed - sizeof(...), and other warnings... (non-POOMA C++ questions) Hey Mark. Just a couple of C++ (non-Pooma related) questions. I was somewhat surprised that -Wall flagged the following code with a warning: void bar() { int a, b; (void)(a == b - sizeof(int)); } Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Tue May 1 20:25:38 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 1 May 2001 13:25:38 -0700 Subject: [pooma-dev] signed == signed - sizeof(...), and other warning s... (non-POOMA C++ questions) In-Reply-To: ; from JimC@proximation.com on Tue, May 01, 2001 at 01:10:27PM -0700 References: Message-ID: <20010501132538.A2800@codesourcery.com> On Tue, May 01, 2001 at 01:10:27PM -0700, James Crotinger wrote: > I guess this is just part of C's wonderful promotion rules - I found it in > K&R. This is harmless, but annoying. I like the signed vs. unsigned warnings because it reveals type mismatches. To prevent gcc from producing the warning, use the command-line option `-Wno-sign-compare'. > -----Original Message----- > From: James Crotinger [mailto:JimC at proximation.com] > Sent: Tuesday, May 01, 2001 2:07 PM > To: Mark Mitchell (E-mail) > Cc: 'pooma-dev at pooma.codesourcery.com' > Subject: [pooma-dev] signed == signed - sizeof(...), and other warnings... > (non-POOMA C++ questions) > > > > Hey Mark. Just a couple of C++ (non-Pooma related) questions. I was > somewhat surprised that -Wall flagged the following code with a > warning: > > void bar() > { > int a, b; > (void)(a == b - sizeof(int)); > } Thanks, Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Tue May 1 20:34:54 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 1 May 2001 13:34:54 -0700 Subject: [pooma-dev] signed == signed - sizeof(...), and other warnings... (non-POOMA C++ questions) In-Reply-To: ; from JimC@proximation.com on Tue, May 01, 2001 at 01:07:07PM -0700 References: Message-ID: <20010501133454.B2800@codesourcery.com> On Tue, May 01, 2001 at 01:07:07PM -0700, James Crotinger wrote: > > Mark> Normally, that warning fires on code like: > Mark> > Mark> class C { > Mark> ~C (); > Mark> }; > Mark> > Mark> Such a class isn't very useful, since you can't create an object of > Mark> this type. (Why? Because when you construct an object, the > Mark> destructor has to be accessible at the point of construction; so > Mark> sayeth the standard.) > > GCC flags "C c;" as an error, but is happy with "C *pc = new C;". This > is good or my code below wouldn't work, but I'm not sure I see the > difference (for this simple case). > > Mark> However, the case you bring up (an overloaded operator `delete') > Mark> should probably be an exception to the warning. > > Actually, I'm not overloading delete. Here's a short example code: > > class IA { public: virtual int release() = 0; }; > > class A : public IA > { > public: > A() : count_m(0) { } > > int release() > { > --count_m; > if (count_m == 0) { delete this; return 0; } > return count_m; > } > > private: > ~A() { } > int count_m; > }; > > When I compile this: > > $ g++ -Wall -c bar.cpp > bar.cpp:17: warning: \ > `class A' only defines a private destructor and has no friends > bar.cpp:17: warning: \ > `class A' has virtual functions but non-virtual destructor > > You are right in that I can't do: > > int main() > { > A a; > return 0; > } > > But that is actually one of the reasons that I want to have the > destructor private - I want to disallow this. You can however do: > > int main() > { > IA *pa = new A; > pa->release(); > return 0; > } > > This compiles and works just fine. The proper destructor is called > since it is called through the virtual function release(). But I still > get the warning. To eliminate the warnings, 1) add "virtual" in front of the destructor and 2) use the command line option -Wno-ctor-dtor-privacy when compiling. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From JimC at proximation.com Tue May 1 21:02:58 2001 From: JimC at proximation.com (James Crotinger) Date: Tue, 1 May 2001 14:02:58 -0700 Subject: [pooma-dev] signed == signed - sizeof(...), and other warning s... (non-POOMA C++ questions) Message-ID: > > To eliminate the warnings, > 1) add "virtual" in front of the destructor and > 2) use the command line option -Wno-ctor-dtor-privacy when compiling. I didn't know about the second one - thanks. As for the first, COM doesn't allow virtual destructors in interfaces, which are just abstract base classes like IA. Making the destructor virtual in A won't help if there isn't a slot for it in IA's vtable. And it doesn't need to be virtual since it is only called from the virtual release method. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Tue May 1 23:29:51 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Tue, 01 May 2001 16:29:51 -0700 Subject: signed == signed - sizeof(...), and other warnings... (non-POOMA C++ questions) In-Reply-To: References: Message-ID: <20010501162951W.mitchell@codesourcery.com> >>>>> "James" == James Crotinger writes: James> This compiles and works just fine. The proper destructor is James> called since it is called through the virtual function James> release(). But I still get the warning. Right. The compiler issues a warning because these kinds of things *typically* indicate a problem. (If they *always* indicated a problem, the committee would have made them illegal, and they'd probably be errors.) You can come up with a case where almost any warning is unjustified -- heck I can even show you cases where you really want to call functions without first providing a prototype for maximum portability. I don't think the problem is the warning per se; it's that G++ doesn't give you any way to say "look, I know what I'm doing with this class, please shut up". -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From wdn at lanl.gov Wed May 2 23:08:54 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Wed, 2 May 2001 17:08:54 -0600 (MDT) Subject: Question about how to do something with Pooma 2 Message-ID: <15088.35420.690070.279694@mutley.lanl.gov> I have a question which I hope someone can help me with. I posed this question to Scott Haney 2-3 years ago in the context of Pooma 1 and he said that what I wanted to do would be trivial to do with Pooma 2. Below, I have included a couple of files, PCG_Ctrl.hh and PCG_Ctrl.cc, which I wrote awhile back to interface to a Fortran 77 linear solver package. One of the key methods of the PCG_Ctrl class is the pcg_fe method which has the following signature. void pcg_fe( Mat1& x, Mat1& b, SP< PCG_MatVec >& pcg_matvec, SP< PCG_PreCond >& pcg_precond ); The Mat1 class is a data container class that Geoff Furnish wrote and it is templated on numeric precision type - such as double. It is a one dimensional array class and it had a constructor which he called an aliasing constructor. The aliasing constructor took a reference to a point in memory and an integer value that told how many elements of data you were dealing with. For a distributed field quantity, the Mat1s were pointing to the first element of data that was local to the processor it was on. The pcg package has a large work array called fwk which is also a Mat1 but has space allocated for lots of chunks of data equal to the amount of data which a field has on a given processor as well as other needed workspace. For the way in which I was using the pcg package, it required the user to supply his own function to perform a matrix-vector multiply operation and a preconditioning operation. To do this, the pcg package returns to the calling function and depending on the value of a flag, it gives you the offset into the 1D fwk array from a fortran perspective that identifies the location of the first element of the vector that it wants you to perform some operation on and the offset into the 1D fwk array that identifies the first element where the result vector goes. I would like to change the signature of the pcg_fe method and other methods to use Pooma 2 fields i.e. I would like the signature of pcg_fe to become: void pcg_fe( Field<...>& x, Field<...>& b, SP< PCG_MatVec >& pcg_matvec, SP< PCG_PreCond >& pcg_precond ); and, I would like fwk to be a 1D Pooma Field and be able to set up views into the fwk array that are similar to the way I am doing with the Mat1 class. Scott thought it would be easy to do this with the Pooma 2 View capability. I've discussed this with John Hall and he is not sure how to do this off the top of his head. One thing we need to do is make sure the guard cell data is not in the Field I am using with pcg because pcg does not know anything about guard cell data. However, I will need guard cell data in the matvec function and also possibly in the preconditioner functions. This probably means that I need at some point to copy from a Field with guard cells to one without and vice versa. Can anyone offer suggestions about how to do what I want using Pooma 2? Is my explanation of what I want to do clear enough? Looking at the pcg_fe function might also help to clarify things. Thanks for any advice you can offer. This will be my first real attempt to use Pooma 2. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 //----------------------------------*-C++-*----------------------------------// // PCG_Ctrl.hh // Dave Nystrom // Mon Jan 13 17:40:28 1997 //---------------------------------------------------------------------------// // @> //---------------------------------------------------------------------------// #ifndef __fldeqns_PCG_Ctrl_hh__ #define __fldeqns_PCG_Ctrl_hh__ #include "Mat.hh" #include "SP.hh" #include "fldeqns/pcg_DB.hh" #include "fldeqns/PCG_MatVec.hh" #include "fldeqns/PCG_PreCond.hh" //===========================================================================// // class PCG_Ctrl - // //===========================================================================// template class PCG_Ctrl : public pcg_DB { Mat1 iparm; Mat1 fparm; Mat1 iwk; Mat1 fwk; Mat1 xex; int nru; int ijob, ireq, iva, ivql, ivqr, ier; int itmeth, imatvec; public: // Constructor. PCG_Ctrl( pcg_DB& _pcg_db, int _nru ); // Destructor. ~PCG_Ctrl(); // Public Methods public: void pcg_fe( Mat1& x, Mat1& b, SP< PCG_MatVec >& pcg_matvec, SP< PCG_PreCond >& pcg_precond ); // Private Methods private: void set_default(); void set_nwi(); void set_nwf(); void it_method( Mat1& x, Mat1& b, Mat1& xex ); void print_params(); }; #endif // __fldeqns_PCG_Ctrl_hh__ //---------------------------------------------------------------------------// // end of fldeqns/PCG_Ctrl.hh //---------------------------------------------------------------------------// //----------------------------------*-C++-*----------------------------------// // PCG_Ctrl.cc // Dave Nystrom // Mon Jan 13 17:40:29 1997 //---------------------------------------------------------------------------// // @> //---------------------------------------------------------------------------// #include "fldeqns/PCG_Ctrl.hh" #include "fldeqns/PCG_Subroutines.hh" //---------------------------------------------------------------------------// // Destructor. //---------------------------------------------------------------------------// template PCG_Ctrl::~PCG_Ctrl() {} //---------------------------------------------------------------------------// // Constructor. //---------------------------------------------------------------------------// template PCG_Ctrl::PCG_Ctrl( pcg_DB& pcg_db, int _nru ) : pcg_DB(pcg_db), iparm(Bounds(1,50)), fparm(Bounds(1,30)), iwk(pcg_db.nwi), fwk(pcg_db.nwf), xex(1), nru(_nru) { // Test print. cout << "Entering PCG_Ctrl::PCG_Ctrl." << endl; // Initialize some stuff from pcg_DB. itmeth = pcg_db.itmeth; // Compute required size of iwk and fwk and resize them. set_nwi(); set_nwf(); iwk.redim( nwi ); fwk.redim( nwf ); // Initialize iparm and fparm arrays. set_default(); iparm(pcg::NOUT) = nout; iparm(pcg::LEVOUT) = levout; iparm(pcg::NRU) = nru; iparm(pcg::ITSMAX) = itsmax; iparm(pcg::MALLOC) = malloc; iparm(pcg::NWI) = nwi; iparm(pcg::NWF) = nwf; iparm(pcg::NTEST) = ntest; iparm(pcg::IQSIDE) = iqside; iparm(pcg::IUINIT) = iuinit; iparm(pcg::NEEDRC) = needrc; iparm(pcg::NS1) = ns1; iparm(pcg::NS2) = ns2; iparm(pcg::ICKSTG) = ickstg; iparm(pcg::IUEXAC) = iuexac; iparm(pcg::IDOT) = idot; iparm(pcg::ISTATS) = istats; fparm(pcg::CTIMER) = ctimer; fparm(pcg::RTIMER) = rtimer; fparm(pcg::FLOPSR) = flopsr; fparm(pcg::ZETA) = zeta; fparm(pcg::ALPHA) = alpha; // Print control parameters. print_params(); cout << "Done with PCG_Ctrl::PCG_Ctrl." << endl << flush; } //---------------------------------------------------------------------------// // Main controller method. //---------------------------------------------------------------------------// template void PCG_Ctrl::pcg_fe( Mat1& x, Mat1& b, SP< PCG_MatVec >& pcg_matvec, SP< PCG_PreCond >& pcg_precond ) { // Test print. cout << "Entering PCG_Ctrl::pcg_fe." << endl; // Initialize ijob. ijob = pcg::JINIT; // Call an iterative method. int done=0; while (!done) { it_method( x, b, xex ); ijob = pcg::JRUN; if( ireq == pcg::JTERM ) { done = 1; } else if( ireq == pcg::JAV ) { cout << "Preparing for MatVec." << endl << flush; Mat1 xmatvec(&fwk(ivqr-1),nru); Mat1 bmatvec(&fwk(iva-1), nru); pcg_matvec->MatVec(bmatvec,xmatvec); cout << "Done with MatVec." << endl << flush; } else if( ireq == pcg::JQLV ) { cout << "Preparing for Left_PreCond." << endl << flush; Mat1 xprecond(&fwk(ivql-1),nru); Mat1 bprecond(&fwk(iva-1), nru); pcg_precond->Left_PreCond(xprecond,bprecond); cout << "Done with Left_PreCond." << endl << flush; } else if( ireq == pcg::JQRV ) { Mat1 xprecond(&fwk(ivqr-1),nru); Mat1 bprecond(&fwk(ivql-1),nru); pcg_precond->Right_PreCond(xprecond,bprecond); } else if( ireq == pcg::JTEST ) { } else if( ireq == pcg::JATV ) { } else if( ireq == pcg::JQLTV ) { } else if( ireq == pcg::JQRTV ) { } } } //---------------------------------------------------------------------------// // Set default values for PCG iparm and fparm arrays. //---------------------------------------------------------------------------// template void PCG_Ctrl::set_default() { pcg::xdfalt( &iparm(1), &fparm(1) ); } //---------------------------------------------------------------------------// // Call a pcg iterative method. //---------------------------------------------------------------------------// template void PCG_Ctrl::it_method( Mat1& x, Mat1& b, Mat1& xex ) { if( itmeth == pcg::BASIC ) { pcg::xbasr( ijob, ireq, &x(0), &xex(0), &b(0), iva, ivql, ivqr, &iwk(0), &fwk(0), &iparm(1), &fparm(1), ier ); imatvec = pcg::TRUE; } else if( itmeth == pcg::GMRES ) { pcg::xgmrsr( ijob, ireq, &x(0), &xex(0), &b(0), iva, ivql, ivqr, &iwk(0), &fwk(0), &iparm(1), &fparm(1), ier ); imatvec = pcg::TRUE; } else { throw("Need to choose a valid pcg iterative method."); } } //---------------------------------------------------------------------------// // Set nwi. //---------------------------------------------------------------------------// template void PCG_Ctrl::set_nwi() { if( itmeth == pcg::BASIC ) nwi = 100; if( itmeth == pcg::BCGSTAB ) nwi = 100; if( itmeth == pcg::BCGSTAB2 ) nwi = 100; if( itmeth == pcg::BCGSTABL ) nwi = 100; if( itmeth == pcg::CGS ) nwi = 100; if( itmeth == pcg::TFQMR ) nwi = 100; if( itmeth == pcg::GMRES ) nwi = 100; if( itmeth == pcg::GMRES_H ) nwi = 100; if( itmeth == pcg::OMIN ) nwi = 100; if( itmeth == pcg::ORES ) nwi = 100; if( itmeth == pcg::IOM ) nwi = 100; if( itmeth == pcg::CG ) nwi = 100; if( itmeth == pcg::BCG ) nwi = 100; if( itmeth == 91 ) nwi = 100; if( itmeth == 92 ) nwi = 100; if( itmeth == 96 ) nwi = 100; if( malloc == pcg::TRUE ) nwi = 1; cout << "------------------------------------------" << endl; cout << "Test print from PCG_Ctrl::set_nwi." << endl; cout << "------------------------------------------" << endl; cout << " itmeth = " << itmeth << endl; cout << " nwi = " << nwi << endl; } //---------------------------------------------------------------------------// // Set nwf. //---------------------------------------------------------------------------// template void PCG_Ctrl::set_nwf() { int nrup2 = nru + 2; int nwfgenl = 31 + nrup2*2; int nwfit = 0; int nwfstat = 0; int nwftst = 0; if( itmeth == pcg::BASIC ) nwfit = 7 + nrup2*5; if( itmeth == pcg::BCGSTAB ) nwfit = 15 + nrup2*13; if( itmeth == pcg::BCGSTAB2 ) nwfit = 15 + nrup2*25; if( itmeth == pcg::BCGSTABL ) nwfit = 31 + nrup2*(2*ns2+8) + ns2*9 + ns2*ns2; if( itmeth == pcg::CGS ) nwfit = 12 + nrup2*11; if( itmeth == pcg::TFQMR ) nwfit = 16 + nrup2*18; if( itmeth == pcg::CG ) nwfit = 12 + nrup2*5; if( itmeth == pcg::BCG ) nwfit = 12 + nrup2*9; if( itmeth == 91 ) nwfit = 7 + nrup2*5; if( itmeth == 92 ) nwfit = 15 + nrup2*13; if( iqside >= pcg::QRIGHT ) { if( itmeth == pcg::GMRES ) nwfit = 31 + nrup2*(2*ns2+8) + ns2*9 + ns2*ns2; if( itmeth == pcg::GMRES_H ) nwfit = 26 + nrup2*(2*ns2+7) + ns2*7 + ns2*ns2; if( itmeth == pcg::OMIN ) nwfit = 13 + nrup2*(3*ns1+5) + ns1; if( itmeth == pcg::ORES ) nwfit = 12 + nrup2*(4*ns1+6) + ns1; if( itmeth == pcg::IOM ) nwfit = 31 + nrup2*(3*ns1+9) + ns1*5; if( itmeth == 96 ) nwfit = 31 + nrup2*(2*ns2+8) + ns2*9 + ns2*ns2; } else { if( itmeth == pcg::GMRES ) nwfit = 31 + nrup2*(1*ns2+4) + ns2*9 + ns2*ns2; if( itmeth == pcg::GMRES_H ) nwfit = 26 + nrup2*(2*ns2+7) + ns2*7 + ns2*ns2; if( itmeth == pcg::OMIN ) nwfit = 13 + nrup2*(2*ns1+3) + ns1; if( itmeth == pcg::ORES ) nwfit = 12 + nrup2*(2*ns1+4) + ns1; if( itmeth == pcg::IOM ) nwfit = 31 + nrup2*(2*ns1+7) + ns1*5; if( itmeth == 96 ) nwfit = 31 + nrup2*(1*ns2+4) + ns2*9 + ns2*ns2; } if( istats == 1 ) nwfstat = 20 + nrup2*4; if( ntest != pcg::TST0 && ntest != pcg::TSTDFA ) { nwftst = nrup2*2; } if( malloc == pcg::TRUE ) { nwf = 1; } else { nwf = nwfgenl + nwfstat + nwftst + nwfit; } cout << "------------------------------------------" << endl; cout << "Test print from PCG_Ctrl::set_nwf." << endl; cout << "------------------------------------------" << endl; cout << " itmeth = " << itmeth << endl; cout << " nwf = " << nwf << endl; // nwf = 1000000; } //---------------------------------------------------------------------------// // Print values for PCG iparm and fparm arrays. //---------------------------------------------------------------------------// template void PCG_Ctrl::print_params() { // Test print. cout << "Entering PCG_Ctrl::print_params." << endl; // Revcom level parameters. cout << "----------------------------------------------" << endl; cout << "Revcom level parameters." << endl; cout << "----------------------------------------------" << endl; cout << " nout = " << iparm(pcg::NOUT) << endl; cout << " levout = " << iparm(pcg::LEVOUT) << endl; cout << " nru = " << iparm(pcg::NRU) << endl; cout << " itsmax = " << iparm(pcg::ITSMAX) << endl; cout << " its = " << iparm(pcg::ITS) << endl; cout << " malloc = " << iparm(pcg::MALLOC) << endl; cout << " nwi = " << iparm(pcg::NWI) << endl; cout << " nwf = " << iparm(pcg::NWF) << endl; cout << " nwiusd = " << iparm(pcg::NWIUSD) << endl; cout << " nwfusd = " << iparm(pcg::NWFUSD) << endl; cout << " iptr = " << iparm(pcg::IPTR) << endl; cout << " ntest = " << iparm(pcg::NTEST) << endl; cout << " iqside = " << iparm(pcg::IQSIDE) << endl; cout << " iuinit = " << iparm(pcg::IUINIT) << endl; cout << " needrc = " << iparm(pcg::NEEDRC) << endl; cout << " ns1 = " << iparm(pcg::NS1) << endl; cout << " ns2 = " << iparm(pcg::NS2) << endl; cout << " ickstg = " << iparm(pcg::ICKSTG) << endl; cout << " iuexac = " << iparm(pcg::IUEXAC) << endl; cout << " idot = " << iparm(pcg::IDOT) << endl; cout << " istats = " << iparm(pcg::ISTATS) << endl; cout << " itimer = " << iparm(pcg::ITIMER) << endl; cout << " icomm = " << iparm(pcg::ICOMM) << endl; cout << " msgmin = " << iparm(pcg::MSGMIN) << endl; cout << " msgmax = " << iparm(pcg::MSGMAX) << endl; cout << " msgtyp = " << iparm(pcg::MSGTYP) << endl; cout << " iclev = " << iparm(pcg::ICLEV) << endl; cout << " " << endl; cout << " ctimer = " << fparm(pcg::CTIMER) << endl; cout << " rtimer = " << fparm(pcg::RTIMER) << endl; cout << " flopsr = " << fparm(pcg::FLOPSR) << endl; cout << " zeta = " << fparm(pcg::ZETA) << endl; cout << " stptst = " << fparm(pcg::STPTST) << endl; cout << " alpha = " << fparm(pcg::ALPHA) << endl; cout << " relrsd = " << fparm(pcg::RELRSD) << endl; cout << " relerr = " << fparm(pcg::RELERR) << endl; } //---------------------------------------------------------------------------// // end of PCG_Ctrl.cc //---------------------------------------------------------------------------// From wdn at lanl.gov Thu May 3 00:24:32 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Wed, 2 May 2001 18:24:32 -0600 (MDT) Subject: Explicit Instantiation Problem with Pooma 2 using KCC on RH 6.2 Linux Message-ID: <15088.38283.319770.777522@mutley.lanl.gov> Below is a file, X.cc, which I am unable to compile with KCC on a RH 6.2 Linux machine. Below that is the build log with the KCC error message that I receive when I try to compile it. The template which I am trying to explicitly instantiate is one that is referenced by our Pooma 2 application code and the KCC prelinker is able to instantiate it just fine. I have been able to determine which translation unit that the KCC prelinker chooses to instantiate this template in and have also tried to perform the explicit instantation in that same translation unit so that I could be sure that everything that KCC needed to see to perform the instantiation was in fact included and I get the same error message which I have included below. I made a -E output file of the translation unit in question and sent it off to Arch to look at. Arch looked at it and made a simpler test case which he sent off to EDG. The conclusion of Arch and EDG was that Pooma 2 has a problem which makes it susceptible to the point of instantiation of a template. Below is the reply from Arch and EDG. Also below is a copy of the test problem which Arch sent off to EDG which he felt was an accurate and simplifed version of the problem I was seeing. So, why do I care about this. Because I am trying to build a Pooma 2 template instantiation library specific to our new Pooma 2 application code so that I can speed up the compiles of developers working on our stuff. I did this with our Pooma 1 application in the secure a few months back and got alot of mileage out of it. It is not really difficult modulo these sorts of problems. In our current Pooma 2 application source code base the prelinker instantiates 1800-2000 of these View1,T4>::sv templates with different template parameters. Using xemacs and a keyboard macro, I can write instantiation requests for all 1800-2000 of them in about 15 minutes. With a little more sophistication, we could write a Perl tool that would make it even easier. This approach requires periodic maintenance but is not difficult especially if we took the time to write some Perl tools. And it pushes the compilation of Pooma 2 only templates down to the level of Pooma 2. That means that we only have to build the Pooma 2 instantiations library when we change/update Pooma 2 or add/delete instantiations to the instantiations library when we feel inclined to do so. So, could someone take a look at this problem and figure out what needs to be modified in Pooma 2 to make it possible to explicitly instantiate the View1,T4>::sv? Also, let me know if I have not explained anything clearly enough about the problem. Thanks for any help you can provide, -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 ------------------Arch's Test Problem Sent to EDG---------------------- It took the entire afternoon to reduce your example to a reasonable 41 lines and send it to EDG. Attached is the reduced case. I'll let you know when I hear from EDG. - Arch //--------------------------------------------------------------------- // Primary templates //--------------------------------------------------------------------- template class Field; template struct Melon; template struct Scene {}; template class Interval; //--------------------------------------------------------------------- // Partial specializations //--------------------------------------------------------------------- template struct Scene >; template struct Melon > { // line #X typedef T Trouble_t; }; template struct Scene > { typedef Field Subject_t; #ifndef NO_BUG typedef typename Subject_t::Domain_t Domain_t; #endif // "Melon" below should reference partial specialization on line = #X typedef typename Melon< Subject_t >::Trouble_t Trouble_t; static const bool sv = true; }; //--------------------------------------------------------------------- // Other miscellaneous definitions //--------------------------------------------------------------------- template struct Field { typedef Interval<3> Domain_t; typename Scene >::Trouble_t boil() const; }; const bool& Zebra = Scene >::sv; --------------------Final Reply of Arch and EDG-------------------------- My impression is that the Pooma 2 code has errors that are sensitive to the "point of instantiation", and it's just dumb luck that implicit instantiation works. - Arch -----Original Message----- From: Dave Nystrom [mailto:wdn at lanl.gov] Sent: Tuesday, April 10, 2001 12:24 PM To: Robison, Arch Cc: 'Dave Nystrom'; 'c++support at kai.com' Subject: RE: FW: [1C2901] RE: Problems trying to do explicit template instant iations OK, but now I am confused about what I need to do in the context of my original problem. When this is described as a programmer error, is that referring to the way in which I am trying to do the instantiation? Or does it mean that there is an error in the Pooma 2 code for the View1 template? Do you understand how to fix the "programmer error"? Do you understand why the prelinker is able to do the instantiation but my explicit instantiation attempt fails? Dave Robison, Arch writes: > Here's a resend. - Arch > > > -----Original Message----- > > From: Robison, Arch > > Sent: Wednesday, April 04, 2001 8:16 AM > > To: 'Dave Nystrom' > > Cc: 'KCC Support'; Robison, Arch > > Subject: RE: [1C2901] RE: Problems trying to do explicit template > > instantiations > > > > EDG says they are doing the right thing. See below. > > The references are to the example that I sent yesterday. > > > > After looking at this for a while, I believe that we are doing the right > > thing. > > > > As our message says: > > > > "t1.c", line 38: error: class "Scene>" has no member > > "Trouble_t" > > typename Scene >::Trouble_t boil() const; > > ^ > > detected during: > > instantiation of class "Field [with T=int]" at line 25 > > instantiation of class "Scene> [with T=int]" at line > > 41 > > > > > > The problem is that the instantiation of Field is initiated by during > > the > > instantiation of Scene>, but Field then makes reference to > > a member of Scene> that has not yet been declared (Trouble_t). > > > > Two other compilers (g++ and Borland) give similar messages on this > > example. > > > > This can be fixed by moving the declaration of Trouble_t to the point > > immediately following the declaration of Subject_t. > > > > So what you have is a code that is sensitive to the "point of > > instantiation". Since points > > of instantiation are defined by the ISO C++ standard, it's a programmer > > error, albeit > > an obscure and difficult to diagnose one. > > > > - Arch > --------------------------------X.cc------------------------------------- #include "Pooma/NewFields.h" // Test instantiation. #define T1 NoGeometry<(int)3> #define T2 int #define T3 CompressibleBrickView #define T4 Interval<(int)3> template View1,T4>::sv; #undef T1 #undef T2 #undef T3 #undef T4 -----------------------------Build-Log----------------------------------- cd /usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration/ date; /usr/bin/time -p make RECURSE=1 app Setting csh aliases for Blanca source environment v 4.0 on host: mutley Wed May 2 17:16:38 MDT 2001 COMPILING... See /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_DEBUG/Pooma2Integration_src/TecMesh/X.o_1.info KCC -c /usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration/Pooma2Integration_src/TecMesh/X.cc -o /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_DEBUG/Pooma2Integration_src/TecMesh/X.o --output_dependencies /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_DEBUG/Pooma2Integration_src/TecMesh/X.o.depend.mk.temp --diag_suppress 630 --COMPDO_fe_cc2c --pch_ignore_dir --use_pch /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_DEBUG/POOMA2INTEGRATION_1.pch -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_USE_EXCEPTIONS -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_SINGLE_BRICK -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 +K0 --no_kdebug "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Field.h", line 1013: error #135: class "View1, int, CompressibleBrickView>, Interval<3>>" has no member "ReadType_t" inline typename View1::ReadType_t ^ detected during: instantiation of class "Field [with GeometryTag=NoGeometry<3>, T=int, EngineTag=CompressibleBrickView]" at line 440 instantiation of class "View1, Sub1> [with GeometryTag=NoGeometry<3>, T=int, EngineTag=CompressibleBrickView, Sub1=Interval<3>]" at line 9 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrati onLayer/Pooma2Integration/Pooma2Integration_src/TecMesh/X .cc" "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Field.h", line 1020: error #135: class "View1, int, CompressibleBrickView>, Interval<3>>" has no member "ReadType_t" inline typename View1::ReadType_t ^ detected during: instantiation of class "Field [with GeometryTag=NoGeometry<3>, T=int, EngineTag=CompressibleBrickView]" at line 440 instantiation of class "View1, Sub1> [with GeometryTag=NoGeometry<3>, T=int, EngineTag=CompressibleBrickView, Sub1=Interval<3>]" at line 9 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrati onLayer/Pooma2Integration/Pooma2Integration_src/TecMesh/X .cc" "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Field.h", line 1051: error #135: class "View1, int, CompressibleBrickView>, Interval<3>>" has no member "Type_t" inline typename View1::Type_t ^ detected during: instantiation of class "Field [with GeometryTag=NoGeometry<3>, T=int, EngineTag=CompressibleBrickView]" at line 440 instantiation of class "View1, Sub1> [with GeometryTag=NoGeometry<3>, T=int, EngineTag=CompressibleBrickView, Sub1=Interval<3>]" at line 9 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrati onLayer/Pooma2Integration/Pooma2Integration_src/TecMesh/X .cc" "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Field.h", line 1058: error #135: class "View1, int, CompressibleBrickView>, Interval<3>>" has no member "Type_t" inline typename View1::Type_t ^ detected during: instantiation of class "Field [with GeometryTag=NoGeometry<3>, T=int, EngineTag=CompressibleBrickView]" at line 440 instantiation of class "View1, Sub1> [with GeometryTag=NoGeometry<3>, T=int, EngineTag=CompressibleBrickView, Sub1=Interval<3>]" at line 9 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrati onLayer/Pooma2Integration/Pooma2Integration_src/TecMesh/X .cc" "/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration/Pooma2Integration_src/TecMesh/X.cc", line 9: error #77-D: this declaration has no storage class or type specifier template View1,T4>::sv; ^ "/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration/Pooma2Integration_src/TecMesh/X.cc", line 9: error #147: declaration is incompatible with "const bool View1, Sub1>::sv [with GeometryTag=NoGeometry<3>, T=int, EngineTag=CompressibleBrickView, Sub1=Interval<3>]" (declared at line 446 of "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Field.h") template View1,T4>::sv; ^ 6 errors detected in the compilation of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration/Pooma2Integration_src/TecMesh/X.cc". KCC: Compilation failed. Command exited with non-zero status 2 real 18.00 user 12.97 sys 1.24 Error compiling /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_DEBUG/Pooma2Integration_src/TecMesh/X.o make: *** [/scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_DEBUG/Pooma2Integration_src/TecMesh/X.o] Error 9 Command exited with non-zero status 2 real 24.05 user 16.34 sys 1.44 Compilation exited abnormally with code 2 at Wed May 2 17:17:02 From oldham at codesourcery.com Thu May 3 15:07:13 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 3 May 2001 08:07:13 -0700 Subject: [pooma-dev] Explicit Instantiation Problem with Pooma 2 using KCC on RH 6.2 Linux In-Reply-To: <15088.38283.319770.777522@mutley.lanl.gov>; from wdn@lanl.gov on Wed, May 02, 2001 at 06:24:32PM -0600 References: <15088.38283.319770.777522@mutley.lanl.gov> Message-ID: <20010503080713.A20719@codesourcery.com> I am looking at this, assuming no one else has already resolved it. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Fri May 4 00:38:19 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 3 May 2001 17:38:19 -0700 Subject: [pooma-dev] Explicit Instantiation Problem with Pooma 2 using KCC on RH 6.2 Linux In-Reply-To: <15088.38283.319770.777522@mutley.lanl.gov>; from wdn@lanl.gov on Wed, May 02, 2001 at 06:24:32PM -0600 References: <15088.38283.319770.777522@mutley.lanl.gov> Message-ID: <20010503173819.A21135@codesourcery.com> Thursday, 2001May03 Dave Nyholm submitted a program equivalent to #include "Pooma/NewFields.h" template View1, int, CompressibleBrickView>, Interval<(int)3> >::sv; I fail to see why it should compile. To complete explicit instantiation of Field, View1, Domain_t>::ReadType_t Field::read() const; must be instantiated. Assume all of the class definition upto but excluding read() has been processed. Here is an excerpt of the relevant code: template class Field { public: typedef Field This_t; // ... inline typename View1::ReadType_t read() const { typedef View1 Ret_t; return Ret_t::makeRead(*this, physicalDomain()); } }; template struct View1, Sub1> { // Convenience typedef for the thing we're taking a view of. typedef Field Subject_t; // ... series of typedefs; Dispatch_t relies on Subject_t typedef typename Dispatch_t::ReadType_t ReadType_t; // ... }; Thus, View1, Domain_t> must be instantiated at least up to the definition of ReadType_t. Its first typedef requires instantiation of Field, which is being processed. Thus, compilation fails. We could try to rewrite View1, Domain_t> to just refer to Field's members, avoiding the initial typedef. Unfortunately, member function makeRead() has a Field argument. How should we solve the problem? Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Fri May 4 01:11:21 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 3 May 2001 18:11:21 -0700 Subject: RFA: Miscellaneous NewField Related Code Changes Message-ID: <20010503181121.A21167@codesourcery.com> When investigating Dave Nyholm's X.cc and related code, I came across minor errors corrected in the attached patch. OK to commit the changes? 2001-05-03 Jeffrey D. Oldham * Engine/IndexFunctionEngine.h (Full Description): Fix grammar error. * Layout/LayoutBase.h (LayoutBaseViewData::LayoutBaseViewData): Reorder initializers according to class declaration order. * Layout/Node.h (Node::Node): Likewise. * Layout/UniformGridLayout.h (UniformGridLayout::UniformGridLayout): Likewise. * NewField/FieldEngine/FieldEngine.NoGeometry.h (FieldEngine::physicalCellDomain): Modify return type by removing reference. Change second function call argument to match function prototype. (FieldEngine::totalCellDomain): Change second function call argument to match function prototype. * NewField/FieldEngine/FieldEngine.UR.h: Fix typographical errors in initial comments. * Utilities/DataBlockPtr.h (DataBlockController::DataBlockController): Reorder initializers according to class declaration order. * Utilities/RefCountedBlockPtr.h (RefBlockController::RefBlockController): Likewise. Tested using Linux gcc 3.0 single-threaded by compiling library Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Engine/IndexFunctionEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/IndexFunctionEngine.h,v retrieving revision 1.21 diff -c -p -r1.21 IndexFunctionEngine.h *** Engine/IndexFunctionEngine.h 2001/04/11 21:39:27 1.21 --- Engine/IndexFunctionEngine.h 2001/05/04 00:39:02 *************** *** 63,69 **** // Full Description: // // IndexFunction is just a tag class for the index-function-engine engine, ! // which makes function of indices look like an array. It takes a Functor // class type as a template argument. This functor is what turns indices // into function values. IndexFunctionView is the view analog of IndexFunction. // In addition to the function, this class includes the original dimension. --- 63,69 ---- // Full Description: // // IndexFunction is just a tag class for the index-function-engine engine, ! // which makes a function of indices look like an array. It takes a Functor // class type as a template argument. This functor is what turns indices // into function values. IndexFunctionView is the view analog of IndexFunction. // In addition to the function, this class includes the original dimension. Index: Layout/LayoutBase.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/LayoutBase.h,v retrieving revision 1.21 diff -c -p -r1.21 LayoutBase.h *** Layout/LayoutBase.h 2001/04/01 20:35:57 1.21 --- Layout/LayoutBase.h 2001/05/04 00:39:03 *************** public: *** 798,807 **** template LayoutBaseViewData(const L & layout, const Domain & dom) ! : layout_m(layout), indexer_m(dom), ! id_m(Unique::get()), subdomainsComputed_m(false), ! internalGuards_m(layout.internalGuards()), ! externalGuards_m(layout.externalGuards()) { // We cannot logically be a slice here. --- 798,808 ---- template LayoutBaseViewData(const L & layout, const Domain & dom) ! : id_m(Unique::get()), layout_m(layout), ! internalGuards_m(layout.internalGuards()), ! externalGuards_m(layout.externalGuards()), ! indexer_m(dom), ! subdomainsComputed_m(false) { // We cannot logically be a slice here. Index: Layout/Node.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v retrieving revision 1.34 diff -c -p -r1.34 Node.h *** Layout/Node.h 2001/04/11 21:39:27 1.34 --- Layout/Node.h 2001/05/04 00:39:04 *************** public: *** 162,170 **** // The copy constructor Node(const This_t &n) ! : domain_m(n.domain_m), context_m(n.context_m), allocated_m(n.allocated_m), ! global_m(n.global_m), local_m(n.local_m), ! affinity_m(n.affinity_m) { } --- 162,170 ---- // The copy constructor Node(const This_t &n) ! : domain_m(n.domain_m), allocated_m(n.allocated_m), ! local_m(n.local_m), global_m(n.global_m), ! context_m(n.context_m), affinity_m(n.affinity_m) { } Index: Layout/UniformGridLayout.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/UniformGridLayout.h,v retrieving revision 1.80 diff -c -p -r1.80 UniformGridLayout.h *** Layout/UniformGridLayout.h 2000/06/27 19:11:34 1.80 --- Layout/UniformGridLayout.h 2001/05/04 00:39:04 *************** UniformGridLayout(const Domain_t &gdom, *** 1826,1833 **** template inline UniformGridLayout:: UniformGridLayout(const This_t &model) ! : Observable(*this), ! LayoutBase >(model.pdata_m) { pdata_m->attach(*this); } --- 1826,1833 ---- template inline UniformGridLayout:: UniformGridLayout(const This_t &model) ! : LayoutBase >(model.pdata_m), ! Observable(*this) { pdata_m->attach(*this); } Index: NewField/FieldEngine/FieldEngine.NoGeometry.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v retrieving revision 1.4 diff -c -p -r1.4 FieldEngine.NoGeometry.h *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/04 00:39:06 *************** public: *** 254,267 **** // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 254,267 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrink(physicalDomain(), guards_m); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), guards_m); } Domain_t physicalDomain() const Index: NewField/FieldEngine/FieldEngine.UR.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.UR.h,v retrieving revision 1.5 diff -c -p -r1.5 FieldEngine.UR.h *** NewField/FieldEngine/FieldEngine.UR.h 2001/04/10 23:13:25 1.5 --- NewField/FieldEngine/FieldEngine.UR.h 2001/05/04 00:39:06 *************** *** 28,35 **** //----------------------------------------------------------------------------- // Classes: ! // UniformRectilinear ! // FieldEngine //----------------------------------------------------------------------------- #ifndef POOMA_NEWFIELD_FIELDENGINE_UR_H --- 28,35 ---- //----------------------------------------------------------------------------- // Classes: ! // UniformRectilinear ! // FieldEngine //----------------------------------------------------------------------------- #ifndef POOMA_NEWFIELD_FIELDENGINE_UR_H Index: NewField/tests/FieldTour1.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/tests/FieldTour1.cpp,v retrieving revision 1.4 diff -c -p -r1.4 FieldTour1.cpp *** NewField/tests/FieldTour1.cpp 2001/04/10 23:13:25 1.4 --- NewField/tests/FieldTour1.cpp 2001/05/04 00:39:06 *************** int main(int argc, char *argv[]) *** 51,61 **** // awhile. Also, it means that the same layout can be used for all // fields, regardless of centering. ! Interval<2> physicalVertexDomain(4, 4); ! Loc<2> blocks(1, 2); ! UniformGridPartition<2> partition(blocks, GuardLayers<2>(1)); ! UniformGridLayout<2> layout(physicalVertexDomain, partition, LayoutTag_t()); std::cout << layout << std::endl; std::cout << layout.domain() << std::endl; --- 51,61 ---- // awhile. Also, it means that the same layout can be used for all // fields, regardless of centering. ! Interval<2> physicalVertexDomain(4, 4); // 0..3 x 0..3 ! Loc<2> blocks(1, 2); // x-direction has one block, y-dir has two blocks ! UniformGridPartition<2> partition(blocks, GuardLayers<2>(1)); // add one layer of guard cells in each direction ! UniformGridLayout<2> layout(physicalVertexDomain, partition, ReplicatedTag()); std::cout << layout << std::endl; std::cout << layout.domain() << std::endl; *************** int main(int argc, char *argv[]) *** 77,85 **** // domain back because of the all-face centering. We can get the // face-domains by specifying the sub-fields. ! std::cout << f.physicalDomain() << std::endl; ! std::cout << f.physicalDomain(0) << std::endl; ! std::cout << f.physicalDomain(1) << std::endl; // Total domains work similarly. --- 77,85 ---- // domain back because of the all-face centering. We can get the // face-domains by specifying the sub-fields. ! std::cout << f.physicalDomain() << std::endl; // cell orientation ! std::cout << f.physicalDomain(0) << std::endl; // x face orientation ! std::cout << f.physicalDomain(1) << std::endl; // y face orientation // Total domains work similarly. *************** int main(int argc, char *argv[]) *** 89,96 **** // We can do a similar sort of thing by taking sub-field views. ! std::cout << f[0].physicalDomain() << std::endl; ! std::cout << f[1].physicalDomain() << std::endl; // Total domains work similarly. Note: taking a sub-field view doesn't // remove the guard layers. --- 89,96 ---- // We can do a similar sort of thing by taking sub-field views. ! std::cout << f[0].physicalDomain() << std::endl; // x faces ! std::cout << f[1].physicalDomain() << std::endl; // y faces // Total domains work similarly. Note: taking a sub-field view doesn't // remove the guard layers. *************** int main(int argc, char *argv[]) *** 122,128 **** // Check assignment of a scalar. ! f = -1.0; f(I, I) = -2.0; std::cout << f << std::endl; --- 122,128 ---- // Check assignment of a scalar. ! f = -1.0; // assign physical domain f(I, I) = -2.0; std::cout << f << std::endl; *************** int main(int argc, char *argv[]) *** 148,156 **** std::cout << h.fieldEngine().vertexPositions() << std::endl; ! // Try assigning to a field with a lagranigan mesh. ! h.all() = 3.0; h = -6.0; std::cout << h.all() << std::endl; --- 148,156 ---- std::cout << h.fieldEngine().vertexPositions() << std::endl; ! // Try assigning to a field with a Lagrangian mesh. ! h.all() = 3.0; // .all means also set guards as well as physical h = -6.0; std::cout << h.all() << std::endl; *************** int main(int argc, char *argv[]) *** 177,183 **** } // Play with updaters. - // f.addUpdaters(AllConstantFaceBC(-1.0)); f.addUpdaters(AllPosReflectFaceBC()); f.update(true); --- 177,182 ---- *************** int main(int argc, char *argv[]) *** 193,199 **** l.all() = Vector<2>(-1.0, 2.0); l = Vector<2>(4.0, 6.0); ! std::cout << l.all().comp(0) << std::endl; Pooma::finalize(); --- 192,198 ---- l.all() = Vector<2>(-1.0, 2.0); l = Vector<2>(4.0, 6.0); ! std::cout << l.all().comp(0) << std::endl; Pooma::finalize(); Index: NewField/tests/FieldTour2.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/tests/FieldTour2.cpp,v retrieving revision 1.1 diff -c -p -r1.1 FieldTour2.cpp *** NewField/tests/FieldTour2.cpp 2000/07/24 23:36:22 1.1 --- NewField/tests/FieldTour2.cpp 2001/05/04 00:39:06 *************** int main(int argc, char *argv[]) *** 49,56 **** // field with cell centering. typedef Field, double, Brick> Field_t; ! Field_t f(ReplicateSubFields(3), layout, Vector<2>(0.0), Vector<2>(1.0, 2.0)); // Set some data in the field. --- 49,57 ---- // field with cell centering. typedef Field, double, Brick> Field_t; ! Field_t f(ReplicateSubFields(3), layout, // 3 fields each Cell-centered Vector<2>(0.0), Vector<2>(1.0, 2.0)); + // are composable // Set some data in the field. Index: NewField/tests/ScalarCode.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/tests/ScalarCode.cpp,v retrieving revision 1.6 diff -c -p -r1.6 ScalarCode.cpp *** NewField/tests/ScalarCode.cpp 2001/04/10 23:13:25 1.6 --- NewField/tests/ScalarCode.cpp 2001/05/04 00:39:06 *************** int main(int argc, char *argv[]) *** 442,448 **** double check2 = sum(edgeValues * edgeValues); tester.out() << "check value: " << check2 << std::endl; ! tester.check("value from derivative computation", abs(check2 - 134.8) < 0.2); // final cases to consider: // 1) replicated fields --- 442,448 ---- double check2 = sum(edgeValues * edgeValues); tester.out() << "check value: " << check2 << std::endl; ! tester.check("value from derivative computation", std::abs(check2 - 134.8) < 0.2); // final cases to consider: // 1) replicated fields Index: Partition/UniformMapper.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Partition/UniformMapper.h,v retrieving revision 1.3 diff -c -p -r1.3 UniformMapper.h *** Partition/UniformMapper.h 2000/06/07 23:36:46 1.3 --- Partition/UniformMapper.h 2001/05/04 00:39:06 *************** public: *** 84,89 **** --- 84,91 ---- { } + virtual ~UniformMapper(){} + void map(const List_t&) const; // member data Index: Utilities/DataBlockPtr.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/DataBlockPtr.h,v retrieving revision 1.19 diff -c -p -r1.19 DataBlockPtr.h *** Utilities/DataBlockPtr.h 2000/12/29 03:00:23 1.19 --- Utilities/DataBlockPtr.h 2001/05/04 00:39:07 *************** public: *** 202,211 **** // Observable with the default constructor. DataBlockController(const DataBlockController &model) ! : Base_t(model), observable_m(), ! owned_m(model.dataObjectPtr_m ? true : false), dataObjectPtr_m(model.dataObjectPtr_m ? new DataObject_t(model.affinity()) : 0), dynamicID_m(ObserverEvent::nullID()) { } --- 202,212 ---- // Observable with the default constructor. DataBlockController(const DataBlockController &model) ! : Base_t(model), dataObjectPtr_m(model.dataObjectPtr_m ? new DataObject_t(model.affinity()) : 0), + owned_m(model.dataObjectPtr_m ? true : false), + observable_m(), dynamicID_m(ObserverEvent::nullID()) { } Index: Utilities/Observer.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/Observer.h,v retrieving revision 1.11 diff -c -p -r1.11 Observer.h *** Utilities/Observer.h 2001/03/29 19:06:45 1.11 --- Utilities/Observer.h 2001/05/04 00:39:07 *************** public: *** 126,135 **** // Destructors //============================================================ ! // The destructor is not made virtual, since we should not ever need ! // to delete an object via its Observer base class. ! ! ~Observer() { } --- 126,132 ---- // Destructors //============================================================ ! virtual ~Observer() { } Index: Utilities/RefCountedBlockPtr.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/RefCountedBlockPtr.h,v retrieving revision 1.59 diff -c -p -r1.59 RefCountedBlockPtr.h *** Utilities/RefCountedBlockPtr.h 2001/04/11 21:39:28 1.59 --- Utilities/RefCountedBlockPtr.h 2001/05/04 00:39:07 *************** public: *** 192,198 **** // class to zero. RefBlockController(const RefBlockController &model) ! : dealloc_m(false), pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0) { // Get the size ofs the logical and allocated storage: --- 192,198 ---- // class to zero. RefBlockController(const RefBlockController &model) ! : pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0), dealloc_m(false) { // Get the size ofs the logical and allocated storage: *************** protected: *** 1038,1045 **** // controllers, which may take additional constructor arguments. RefCountedBlockPtr(Controller *con) ! : blockControllerPtr_m(con), ! offset_m(0) { } // Utility function: Check bounds and throw assertion if --- 1038,1044 ---- // controllers, which may take additional constructor arguments. RefCountedBlockPtr(Controller *con) ! : offset_m(0), blockControllerPtr_m(con) { } // Utility function: Check bounds and throw assertion if From scotth at proximation.com Fri May 4 14:35:25 2001 From: scotth at proximation.com (Scott Haney) Date: Fri, 4 May 2001 08:35:25 -0600 Subject: [pooma-dev] RFA: Miscellaneous NewField Related Code Changes In-Reply-To: <20010503181121.A21167@codesourcery.com> Message-ID: Hi Jeffrey, This is fine except for one thing: ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 254,267 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrink(physicalDomain(), guards_m); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), guards_m); } Removing the reference is a good idea, but the "1"'s are correct. NoGeometry always has vertex centering and no guard cells so the totalCellDomain == physicalCellDomain and they both are 1 smaller than the vertex domain in each direction. Scott On Thursday, May 3, 2001, at 07:11 PM, Jeffrey Oldham wrote: > When investigating Dave Nyholm's X.cc and related code, I came across > minor errors corrected in the attached patch. OK to commit the changes? > > 2001-05-03 Jeffrey D. Oldham > > * Engine/IndexFunctionEngine.h (Full Description): Fix grammar > error. > * Layout/LayoutBase.h (LayoutBaseViewData::LayoutBaseViewData): > Reorder initializers according to class declaration order. > * Layout/Node.h (Node::Node): Likewise. > * Layout/UniformGridLayout.h > (UniformGridLayout::UniformGridLayout): Likewise. > * NewField/FieldEngine/FieldEngine.NoGeometry.h > (FieldEngine::physicalCellDomain): Modify return type by removing > reference. Change second function call argument to match function > prototype. > (FieldEngine::totalCellDomain): Change second function call > argument to match function prototype. > * NewField/FieldEngine/FieldEngine.UR.h: Fix typographical errors > in initial comments. > * Utilities/DataBlockPtr.h > (DataBlockController::DataBlockController): Reorder initializers > according to class declaration order. > * Utilities/RefCountedBlockPtr.h > (RefBlockController::RefBlockController): Likewise. > > Tested using Linux gcc 3.0 single-threaded by compiling library > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > > -- Scott W. Haney Development Manager Proximation LLC 2960 Rodeo Park Drive West Santa Fe, NM 87505 Voice: 505-424-3809 x101 FAX: 505-438-4161 -------------- next part -------------- Hi Jeffrey, This is fine except for one thing: ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 254,267 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrink(physicalDomain(), guards_m); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), guards_m); } Removing the reference is a good idea, but the "1"'s are correct. NoGeometry always has vertex centering and no guard cells so the totalCellDomain == physicalCellDomain and they both are 1 smaller than the vertex domain in each direction. Scott On Thursday, May 3, 2001, at 07:11 PM, Jeffrey Oldham wrote: > When investigating Dave Nyholm's X.cc and related code, I came across > minor errors corrected in the attached patch. OK to commit the changes? > > 2001-05-03 Jeffrey D. Oldham > > * Engine/IndexFunctionEngine.h (Full Description): Fix grammar > error. > * Layout/LayoutBase.h (LayoutBaseViewData::LayoutBaseViewData): > Reorder initializers according to class declaration order. > * Layout/Node.h (Node::Node): Likewise. > * Layout/UniformGridLayout.h > (UniformGridLayout::UniformGridLayout): Likewise. > * NewField/FieldEngine/FieldEngine.NoGeometry.h > (FieldEngine::physicalCellDomain): Modify return type by removing > reference. Change second function call argument to match function > prototype. > (FieldEngine::totalCellDomain): Change second function call > argument to match function prototype. > * NewField/FieldEngine/FieldEngine.UR.h: Fix typographical errors > in initial comments. > * Utilities/DataBlockPtr.h > (DataBlockController::DataBlockController): Reorder initializers > according to class declaration order. > * Utilities/RefCountedBlockPtr.h > (RefBlockController::RefBlockController): Likewise. > > Tested using Linux gcc 3.0 single-threaded by compiling library > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: 03May.patch Type: application/applefile Size: 71 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 03May.patch Type: application/text Size: 16429 bytes Desc: not available URL: -------------- next part -------------- > -- Scott W. Haney Development Manager Proximation LLC 2960 Rodeo Park Drive West Santa Fe, NM 87505 Voice: 505-424-3809 x101 FAX: 505-438-4161 From scotth at proximation.com Fri May 4 14:55:16 2001 From: scotth at proximation.com (Scott Haney) Date: Fri, 4 May 2001 08:55:16 -0600 Subject: [pooma-dev] Explicit Instantiation Problem with Pooma 2 using KCC on RH 6.2 Linux In-Reply-To: <20010503173819.A21135@codesourcery.com> Message-ID: On Thursday, May 3, 2001, at 06:38 PM, Jeffrey Oldham wrote: > Dave Nyholm submitted a program equivalent to > > #include "Pooma/NewFields.h" > > template View1, int, > CompressibleBrickView>, > Interval<(int)3> >::sv; > > I fail to see why it should compile. I've hit this problem before with Array. I guess I forgot to move this to Field. The solution is to not use View1 in the call to read(), but rather to make another class, View0, that handles this special case. This removes the circular dependency when pre-instantiating View1. This is inelegant and it might not always work, but it made KCC happy before. See Array.h. Scott -- Scott W. Haney Development Manager Proximation LLC 2960 Rodeo Park Drive West Santa Fe, NM 87505 Voice: 505-424-3809 x101 FAX: 505-438-4161 From oldham at codesourcery.com Fri May 4 15:44:51 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 4 May 2001 08:44:51 -0700 Subject: Patch: Miscellaneous NewField Changes Message-ID: <20010504084451.A14209@codesourcery.com> When investigating Dave Nyholm's X.cc and related code, I came across minor errors just corrected. 2001-05-04 Jeffrey D. Oldham * Engine/IndexFunctionEngine.h (Full Description): Fix grammar error. * Layout/LayoutBase.h (LayoutBaseViewData::LayoutBaseViewData): Reorder initializers according to class declaration order. * Layout/Node.h (Node::Node): Likewise. * Layout/UniformGridLayout.h (UniformGridLayout::UniformGridLayout): Likewise. * NewField/FieldEngine/FieldEngine.UR.h: Fix typographical errors in initial comments. * Utilities/DataBlockPtr.h (DataBlockController::DataBlockController): Reorder initializers according to class declaration order. * Utilities/RefCountedBlockPtr.h (RefBlockController::RefBlockController): Likewise. Tested using Linux gcc 3.0 single-threaded by compiling library Approved by Scott Haney (swhaney at earthlink.net) Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Engine/IndexFunctionEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/IndexFunctionEngine.h,v retrieving revision 1.21 diff -c -p -r1.21 IndexFunctionEngine.h *** Engine/IndexFunctionEngine.h 2001/04/11 21:39:27 1.21 --- Engine/IndexFunctionEngine.h 2001/05/04 15:37:03 *************** *** 63,69 **** // Full Description: // // IndexFunction is just a tag class for the index-function-engine engine, ! // which makes function of indices look like an array. It takes a Functor // class type as a template argument. This functor is what turns indices // into function values. IndexFunctionView is the view analog of IndexFunction. // In addition to the function, this class includes the original dimension. --- 63,69 ---- // Full Description: // // IndexFunction is just a tag class for the index-function-engine engine, ! // which makes a function of indices look like an array. It takes a Functor // class type as a template argument. This functor is what turns indices // into function values. IndexFunctionView is the view analog of IndexFunction. // In addition to the function, this class includes the original dimension. Index: Layout/LayoutBase.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/LayoutBase.h,v retrieving revision 1.21 diff -c -p -r1.21 LayoutBase.h *** Layout/LayoutBase.h 2001/04/01 20:35:57 1.21 --- Layout/LayoutBase.h 2001/05/04 15:37:04 *************** public: *** 798,807 **** template LayoutBaseViewData(const L & layout, const Domain & dom) ! : layout_m(layout), indexer_m(dom), ! id_m(Unique::get()), subdomainsComputed_m(false), ! internalGuards_m(layout.internalGuards()), ! externalGuards_m(layout.externalGuards()) { // We cannot logically be a slice here. --- 798,808 ---- template LayoutBaseViewData(const L & layout, const Domain & dom) ! : id_m(Unique::get()), layout_m(layout), ! internalGuards_m(layout.internalGuards()), ! externalGuards_m(layout.externalGuards()), ! indexer_m(dom), ! subdomainsComputed_m(false) { // We cannot logically be a slice here. Index: Layout/Node.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v retrieving revision 1.34 diff -c -p -r1.34 Node.h *** Layout/Node.h 2001/04/11 21:39:27 1.34 --- Layout/Node.h 2001/05/04 15:37:05 *************** public: *** 162,170 **** // The copy constructor Node(const This_t &n) ! : domain_m(n.domain_m), context_m(n.context_m), allocated_m(n.allocated_m), ! global_m(n.global_m), local_m(n.local_m), ! affinity_m(n.affinity_m) { } --- 162,170 ---- // The copy constructor Node(const This_t &n) ! : domain_m(n.domain_m), allocated_m(n.allocated_m), ! local_m(n.local_m), global_m(n.global_m), ! context_m(n.context_m), affinity_m(n.affinity_m) { } Index: Layout/UniformGridLayout.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/UniformGridLayout.h,v retrieving revision 1.81 diff -c -p -r1.81 UniformGridLayout.h *** Layout/UniformGridLayout.h 2001/04/18 02:20:36 1.81 --- Layout/UniformGridLayout.h 2001/05/04 15:37:06 *************** UniformGridLayout(const Domain_t &gdom, *** 1826,1833 **** template inline UniformGridLayout:: UniformGridLayout(const This_t &model) ! : Observable(*this), ! LayoutBase >(model.pdata_m) { pdata_m->attach(*this); } --- 1826,1833 ---- template inline UniformGridLayout:: UniformGridLayout(const This_t &model) ! : LayoutBase >(model.pdata_m), ! Observable(*this) { pdata_m->attach(*this); } Index: NewField/FieldEngine/FieldEngine.UR.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.UR.h,v retrieving revision 1.6 diff -c -p -r1.6 FieldEngine.UR.h *** NewField/FieldEngine/FieldEngine.UR.h 2001/04/27 22:50:22 1.6 --- NewField/FieldEngine/FieldEngine.UR.h 2001/05/04 15:37:06 *************** *** 28,35 **** //----------------------------------------------------------------------------- // Classes: ! // UniformRectilinear ! // FieldEngine //----------------------------------------------------------------------------- #ifndef POOMA_NEWFIELD_FIELDENGINE_UR_H --- 28,35 ---- //----------------------------------------------------------------------------- // Classes: ! // UniformRectilinear ! // FieldEngine //----------------------------------------------------------------------------- #ifndef POOMA_NEWFIELD_FIELDENGINE_UR_H Index: NewField/tests/FieldTour1.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/tests/FieldTour1.cpp,v retrieving revision 1.4 diff -c -p -r1.4 FieldTour1.cpp *** NewField/tests/FieldTour1.cpp 2001/04/10 23:13:25 1.4 --- NewField/tests/FieldTour1.cpp 2001/05/04 15:37:06 *************** int main(int argc, char *argv[]) *** 51,61 **** // awhile. Also, it means that the same layout can be used for all // fields, regardless of centering. ! Interval<2> physicalVertexDomain(4, 4); ! Loc<2> blocks(1, 2); ! UniformGridPartition<2> partition(blocks, GuardLayers<2>(1)); ! UniformGridLayout<2> layout(physicalVertexDomain, partition, LayoutTag_t()); std::cout << layout << std::endl; std::cout << layout.domain() << std::endl; --- 51,61 ---- // awhile. Also, it means that the same layout can be used for all // fields, regardless of centering. ! Interval<2> physicalVertexDomain(4, 4); // 0..3 x 0..3 ! Loc<2> blocks(1, 2); // x-direction has one block, y-dir has two blocks ! UniformGridPartition<2> partition(blocks, GuardLayers<2>(1)); // add one layer of guard cells in each direction ! UniformGridLayout<2> layout(physicalVertexDomain, partition, ReplicatedTag()); std::cout << layout << std::endl; std::cout << layout.domain() << std::endl; *************** int main(int argc, char *argv[]) *** 77,85 **** // domain back because of the all-face centering. We can get the // face-domains by specifying the sub-fields. ! std::cout << f.physicalDomain() << std::endl; ! std::cout << f.physicalDomain(0) << std::endl; ! std::cout << f.physicalDomain(1) << std::endl; // Total domains work similarly. --- 77,85 ---- // domain back because of the all-face centering. We can get the // face-domains by specifying the sub-fields. ! std::cout << f.physicalDomain() << std::endl; // cell orientation ! std::cout << f.physicalDomain(0) << std::endl; // x face orientation ! std::cout << f.physicalDomain(1) << std::endl; // y face orientation // Total domains work similarly. *************** int main(int argc, char *argv[]) *** 89,96 **** // We can do a similar sort of thing by taking sub-field views. ! std::cout << f[0].physicalDomain() << std::endl; ! std::cout << f[1].physicalDomain() << std::endl; // Total domains work similarly. Note: taking a sub-field view doesn't // remove the guard layers. --- 89,96 ---- // We can do a similar sort of thing by taking sub-field views. ! std::cout << f[0].physicalDomain() << std::endl; // x faces ! std::cout << f[1].physicalDomain() << std::endl; // y faces // Total domains work similarly. Note: taking a sub-field view doesn't // remove the guard layers. *************** int main(int argc, char *argv[]) *** 122,128 **** // Check assignment of a scalar. ! f = -1.0; f(I, I) = -2.0; std::cout << f << std::endl; --- 122,128 ---- // Check assignment of a scalar. ! f = -1.0; // assign physical domain f(I, I) = -2.0; std::cout << f << std::endl; *************** int main(int argc, char *argv[]) *** 148,156 **** std::cout << h.fieldEngine().vertexPositions() << std::endl; ! // Try assigning to a field with a lagranigan mesh. ! h.all() = 3.0; h = -6.0; std::cout << h.all() << std::endl; --- 148,156 ---- std::cout << h.fieldEngine().vertexPositions() << std::endl; ! // Try assigning to a field with a Lagrangian mesh. ! h.all() = 3.0; // .all means also set guards as well as physical h = -6.0; std::cout << h.all() << std::endl; *************** int main(int argc, char *argv[]) *** 177,183 **** } // Play with updaters. - // f.addUpdaters(AllConstantFaceBC(-1.0)); f.addUpdaters(AllPosReflectFaceBC()); f.update(true); --- 177,182 ---- *************** int main(int argc, char *argv[]) *** 193,199 **** l.all() = Vector<2>(-1.0, 2.0); l = Vector<2>(4.0, 6.0); ! std::cout << l.all().comp(0) << std::endl; Pooma::finalize(); --- 192,198 ---- l.all() = Vector<2>(-1.0, 2.0); l = Vector<2>(4.0, 6.0); ! std::cout << l.all().comp(0) << std::endl; Pooma::finalize(); Index: NewField/tests/FieldTour2.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/tests/FieldTour2.cpp,v retrieving revision 1.1 diff -c -p -r1.1 FieldTour2.cpp *** NewField/tests/FieldTour2.cpp 2000/07/24 23:36:22 1.1 --- NewField/tests/FieldTour2.cpp 2001/05/04 15:37:06 *************** int main(int argc, char *argv[]) *** 49,56 **** // field with cell centering. typedef Field, double, Brick> Field_t; ! Field_t f(ReplicateSubFields(3), layout, Vector<2>(0.0), Vector<2>(1.0, 2.0)); // Set some data in the field. --- 49,57 ---- // field with cell centering. typedef Field, double, Brick> Field_t; ! Field_t f(ReplicateSubFields(3), layout, // 3 fields each Cell-centered Vector<2>(0.0), Vector<2>(1.0, 2.0)); + // are composable // Set some data in the field. Index: NewField/tests/ScalarCode.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/tests/ScalarCode.cpp,v retrieving revision 1.6 diff -c -p -r1.6 ScalarCode.cpp *** NewField/tests/ScalarCode.cpp 2001/04/10 23:13:25 1.6 --- NewField/tests/ScalarCode.cpp 2001/05/04 15:37:07 *************** int main(int argc, char *argv[]) *** 442,448 **** double check2 = sum(edgeValues * edgeValues); tester.out() << "check value: " << check2 << std::endl; ! tester.check("value from derivative computation", abs(check2 - 134.8) < 0.2); // final cases to consider: // 1) replicated fields --- 442,448 ---- double check2 = sum(edgeValues * edgeValues); tester.out() << "check value: " << check2 << std::endl; ! tester.check("value from derivative computation", std::abs(check2 - 134.8) < 0.2); // final cases to consider: // 1) replicated fields Index: Partition/UniformMapper.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Partition/UniformMapper.h,v retrieving revision 1.3 diff -c -p -r1.3 UniformMapper.h *** Partition/UniformMapper.h 2000/06/07 23:36:46 1.3 --- Partition/UniformMapper.h 2001/05/04 15:37:07 *************** public: *** 84,89 **** --- 84,91 ---- { } + virtual ~UniformMapper(){} + void map(const List_t&) const; // member data Index: Utilities/DataBlockPtr.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/DataBlockPtr.h,v retrieving revision 1.19 diff -c -p -r1.19 DataBlockPtr.h *** Utilities/DataBlockPtr.h 2000/12/29 03:00:23 1.19 --- Utilities/DataBlockPtr.h 2001/05/04 15:37:07 *************** public: *** 202,211 **** // Observable with the default constructor. DataBlockController(const DataBlockController &model) ! : Base_t(model), observable_m(), ! owned_m(model.dataObjectPtr_m ? true : false), dataObjectPtr_m(model.dataObjectPtr_m ? new DataObject_t(model.affinity()) : 0), dynamicID_m(ObserverEvent::nullID()) { } --- 202,212 ---- // Observable with the default constructor. DataBlockController(const DataBlockController &model) ! : Base_t(model), dataObjectPtr_m(model.dataObjectPtr_m ? new DataObject_t(model.affinity()) : 0), + owned_m(model.dataObjectPtr_m ? true : false), + observable_m(), dynamicID_m(ObserverEvent::nullID()) { } Index: Utilities/Observer.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/Observer.h,v retrieving revision 1.11 diff -c -p -r1.11 Observer.h *** Utilities/Observer.h 2001/03/29 19:06:45 1.11 --- Utilities/Observer.h 2001/05/04 15:37:07 *************** public: *** 126,135 **** // Destructors //============================================================ ! // The destructor is not made virtual, since we should not ever need ! // to delete an object via its Observer base class. ! ! ~Observer() { } --- 126,132 ---- // Destructors //============================================================ ! virtual ~Observer() { } Index: Utilities/RefCountedBlockPtr.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/RefCountedBlockPtr.h,v retrieving revision 1.59 diff -c -p -r1.59 RefCountedBlockPtr.h *** Utilities/RefCountedBlockPtr.h 2001/04/11 21:39:28 1.59 --- Utilities/RefCountedBlockPtr.h 2001/05/04 15:37:07 *************** public: *** 192,198 **** // class to zero. RefBlockController(const RefBlockController &model) ! : dealloc_m(false), pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0) { // Get the size ofs the logical and allocated storage: --- 192,198 ---- // class to zero. RefBlockController(const RefBlockController &model) ! : pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0), dealloc_m(false) { // Get the size ofs the logical and allocated storage: *************** protected: *** 1038,1045 **** // controllers, which may take additional constructor arguments. RefCountedBlockPtr(Controller *con) ! : blockControllerPtr_m(con), ! offset_m(0) { } // Utility function: Check bounds and throw assertion if --- 1038,1044 ---- // controllers, which may take additional constructor arguments. RefCountedBlockPtr(Controller *con) ! : offset_m(0), blockControllerPtr_m(con) { } // Utility function: Check bounds and throw assertion if From oldham at codesourcery.com Fri May 4 16:05:37 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 4 May 2001 09:05:37 -0700 Subject: shrink() and FieldEngine.NoGeometry.h Compilation Message-ID: <20010504090537.B14209@codesourcery.com> Scott, Thanks for the quick patch approval. I committed the patch excepting the changes to src/NewField/FieldEngine.NoGeometry.h. I do not understand how FieldEngine.NoGeometry.h's FieldEngine, T, EngineTag> compiles. inline const Domain_t physicalCellDomain() const { return shrink(physicalDomain(), 1); } The only shrink() definition I could find is in src/Layout/GuardLayers.h: template inline Interval shrink(const Interval &dom, const GuardLayers &gcs) { Interval ret(dom); return shrinkInPlace(ret, gcs); } One can convert shrink()'s second argument `1' to a GuardLayers, but this cannot happen implicitly because the associated GuardLayers constructor is marked explicit: template class GuardLayers { public: explicit GuardLayers(int gcs = 0); Do you agree this is a problem? Is the attached patch acceptable? (I am experiencing compilation problems so I have not tested the patch.) 2001-05-04 Jeffrey D. Oldham * FieldEngine.NoGeometry.h (FieldEngine::physicalCellDomain): Modify return type by removing reference. Change second function call argument to match function prototype. (FieldEngine::totalCellDomain): Change second function call argument to match function prototype. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: FieldEngine.NoGeometry.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v retrieving revision 1.4 diff -c -p -r1.4 FieldEngine.NoGeometry.h *** FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 --- FieldEngine.NoGeometry.h 2001/05/04 16:03:48 *************** public: *** 254,267 **** // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 254,267 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrink(physicalDomain(), GuardLayers(1)); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), GuardLayers(1)); } Domain_t physicalDomain() const From oldham at codesourcery.com Fri May 4 16:25:04 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 4 May 2001 09:25:04 -0700 Subject: [pooma-dev] shrink() and FieldEngine.NoGeometry.h Compilation In-Reply-To: <20010504090537.B14209@codesourcery.com>; from oldham@codesourcery.com on Fri, May 04, 2001 at 09:05:37AM -0700 References: <20010504090537.B14209@codesourcery.com> Message-ID: <20010504092504.A14502@codesourcery.com> On Fri, May 04, 2001 at 09:05:37AM -0700, Jeffrey Oldham wrote: > > Do you agree this is a problem? Is the attached patch acceptable? (I > am experiencing compilation problems so I have not tested the patch.) I fixed the patch so it compiles. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: FieldEngine.NoGeometry.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v retrieving revision 1.4 diff -c -p -r1.4 FieldEngine.NoGeometry.h *** FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 --- FieldEngine.NoGeometry.h 2001/05/04 16:23:48 *************** public: *** 254,267 **** // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 254,267 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrink(physicalDomain(), GuardLayers(1)); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), GuardLayers(1)); } Domain_t physicalDomain() const From oldham at codesourcery.com Fri May 4 16:29:10 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 4 May 2001 09:29:10 -0700 Subject: What is Pooma::Updaters::DontCopyUpdaters? Message-ID: <20010504092910.B14502@codesourcery.com> I do not understand why this "copy constructor" should compile: NewField/FieldEngine/FieldEngine.UR.h: FieldEngine, T, EngineTag>:: FieldEngine(const This_t &model, const Pooma::Updaters::DontCopyUpdaters &d) I cannot find a definition of Pooma::Updaters::DontCopyUpdaters anywhere in the Pooma code. 1) Should we remove this "copy contructor"? (See the attached patch.) 2) Should we change the second argument to something else? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: FieldEngine.UR.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.UR.h,v retrieving revision 1.7 diff -c -p -r1.7 FieldEngine.UR.h *** FieldEngine.UR.h 2001/05/04 15:41:28 1.7 --- FieldEngine.UR.h 2001/05/04 16:25:40 *************** public: *** 172,185 **** spacings_m(model.spacings_m) { } - // Copy constructor (except for updaters). - - FieldEngine(const This_t &model, const Pooma::Updaters::DontCopyUpdaters &d) - : Base_t(model, d), - origin_m(model.origin_m), - spacings_m(model.spacings_m) - { } - // Sub-field constructor. template --- 172,177 ---- From oldham at codesourcery.com Fri May 4 16:36:11 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 4 May 2001 09:36:11 -0700 Subject: Testing Pooma Code Using Explicit Instantiations? Message-ID: <20010504093611.C14502@codesourcery.com> Dave Nyholm's explicit instantiation program exercised some previously unexercised code, revealing two handfuls of Pooma code errors. Since explicit instantiation of a class template forces instantiation of all member functions but implicit instantiation does not, should we exercise more Pooma code by explicitly instantiating more of it? We could ask Dave Nyholm for his testing code so we do not have to spend time enumerating the cases. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From swhaney at earthlink.net Fri May 4 17:54:04 2001 From: swhaney at earthlink.net (Scott Haney) Date: Fri, 4 May 2001 11:54:04 -0600 Subject: [pooma-dev] shrink() and FieldEngine.NoGeometry.h Compilation In-Reply-To: <20010504090537.B14209@codesourcery.com> Message-ID: On Friday, May 4, 2001, at 10:05 AM, Jeffrey Oldham wrote: > Do you agree this is a problem? Is the attached patch acceptable? (I > am experiencing compilation problems so I have not tested the patch.) Hi Jeffrey, Yes, I now see this. However, the patch is not correct. The right thing is to call shrinkRight (in Domain/Shrink.h) with "1". We only want to remove one value in each direction. Scott -- Scott W. Haney Development Manager Proximation LLC 2960 Rodeo Park Drive West Santa Fe, NM 87505 Voice: 505-424-3809 x101 FAX: 505-438-4161 From scotth at proximation.com Fri May 4 17:56:19 2001 From: scotth at proximation.com (Scott Haney) Date: Fri, 4 May 2001 11:56:19 -0600 Subject: [pooma-dev] What is Pooma::Updaters::DontCopyUpdaters? In-Reply-To: <20010504092910.B14502@codesourcery.com> Message-ID: On Friday, May 4, 2001, at 10:29 AM, Jeffrey Oldham wrote: > I do not understand why this "copy constructor" should compile: > > NewField/FieldEngine/FieldEngine.UR.h: > FieldEngine, T, > EngineTag>:: > FieldEngine(const This_t &model, const > Pooma::Updaters::DontCopyUpdaters &d) > > I cannot find a definition of Pooma::Updaters::DontCopyUpdaters > anywhere in the Pooma code. > > 1) Should we remove this "copy contructor"? (See the attached patch.) > 2) Should we change the second argument to something else? Hi Jeffrey, It is in NewField/Updater/UpdaterBase.h. The answer to (1) and (2) is no. These constructors are correct. Scott -- Scott W. Haney Development Manager Proximation LLC 2960 Rodeo Park Drive West Santa Fe, NM 87505 Voice: 505-424-3809 x101 FAX: 505-438-4161 From oldham at codesourcery.com Fri May 4 19:55:16 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 4 May 2001 12:55:16 -0700 Subject: [pooma-dev] shrink() and FieldEngine.NoGeometry.h Compilation In-Reply-To: <200105041755.KAA14673@oz.codesourcery.com>; from swhaney@earthlink.net on Fri, May 04, 2001 at 11:54:04AM -0600 References: <20010504090537.B14209@codesourcery.com> <200105041755.KAA14673@oz.codesourcery.com> Message-ID: <20010504125516.C14819@codesourcery.com> On Fri, May 04, 2001 at 11:54:04AM -0600, Scott Haney wrote: > On Friday, May 4, 2001, at 10:05 AM, Jeffrey Oldham wrote: > > > Do you agree this is a problem? Is the attached patch acceptable? (I > > am experiencing compilation problems so I have not tested the patch.) > > Hi Jeffrey, > > Yes, I now see this. However, the patch is not correct. The right thing > is to call shrinkRight (in Domain/Shrink.h) with "1". We only want to > remove one value in each direction. Is the attached patch acceptable to commit? 2001-05-04 Jeffrey D. Oldham * FieldEngine.NoGeometry.h (FieldEngine::physicalCellDomain): Modify return type by removing reference. Change second function call argument to match function prototype. (FieldEngine::totalCellDomain): Change second function call argument to match function prototype. Tested using Linux gcc 3.0 single-thread by compiling Dave Nystrom's code and building Pooma library Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: FieldEngine.NoGeometry.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v retrieving revision 1.4 diff -c -p -r1.4 FieldEngine.NoGeometry.h *** FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 --- FieldEngine.NoGeometry.h 2001/05/04 19:44:35 *************** public: *** 254,267 **** // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 254,267 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrinkRight(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrinkRight(engine_m.domain(), 1); } Domain_t physicalDomain() const From oldham at codesourcery.com Fri May 4 19:56:48 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 4 May 2001 12:56:48 -0700 Subject: [pooma-dev] Explicit Instantiation Problem with Pooma 2 using KCC on RH 6.2 Linux In-Reply-To: <200105041455.HAA14153@oz.codesourcery.com>; from scotth@proximation.com on Fri, May 04, 2001 at 08:55:16AM -0600 References: <20010503173819.A21135@codesourcery.com> <200105041455.HAA14153@oz.codesourcery.com> Message-ID: <20010504125648.D14819@codesourcery.com> On Fri, May 04, 2001 at 08:55:16AM -0600, Scott Haney wrote: > > On Thursday, May 3, 2001, at 06:38 PM, Jeffrey Oldham wrote: > > > Dave Nyholm submitted a program equivalent to > > > > #include "Pooma/NewFields.h" > > > > template View1, int, > > CompressibleBrickView>, > > Interval<(int)3> >::sv; > > > > I fail to see why it should compile. > > I've hit this problem before with Array. I guess I forgot to move this > to Field. The solution is to not use View1 in the call to read(), but > rather to make another class, View0, that handles this special case. > This removes the circular dependency when pre-instantiating View1. This > is inelegant and it might not always work, but it made KCC happy before. > See Array.h. OK, I will go look now, making changes if I understand. do not expect anything before late this evening since I am busy at Stanford this afternoon. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From wdn at lanl.gov Sat May 5 17:47:29 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Sat, 5 May 2001 11:47:29 -0600 (MDT) Subject: [pooma-dev] Testing Pooma Code Using Explicit Instantiations? In-Reply-To: <20010504093611.C14502@codesourcery.com> References: <20010504093611.C14502@codesourcery.com> Message-ID: <15092.14751.892087.752259@mutley.lanl.gov> Hi Jeff, Don't know how you got Nyholm but my last name is Nystrom. I'm not sure whether Pooma 2 has a goal of being able to instantiate all the members of a class. Perhaps Scott or Jim could comment on that. I don't think Pooma 1 was designed to support instantiating all the members of a class for all reasonable template arguments. I think it would be great if this were the case but I don't know enough about the design of Pooma 2 to know how feasible it is. Right now, my main interest is in being able to explicitly instantiate anything that the compiler is able to instantiate via the prelinker or whatever vendor specific method is used. I don't think you would benefit that much from my preinstantiation stuff but you are welcome to it. For the View1 problem for instance, I figured you would rather have one example with simple template arguments rather than 1800 with complex arguments that all give the same error. As I continue to try and finish up this exercise in explicit instantiation, I'll pass along problems I run into. Let me know if you want a copy of my instantiation library stuff. Right now on Linux with KCC, it produces a 233 MByte library for a debug build with exceptions turned on and takes a long time to compile:-). And, I'm for the most part just instantiating the individual member functions that KCC tells me we are using, not whole classes. Dave Jeffrey Oldham writes: > Dave Nyholm's explicit instantiation program exercised some previously > unexercised code, revealing two handfuls of Pooma code errors. Since > explicit instantiation of a class template forces instantiation of all > member functions but implicit instantiation does not, should we > exercise more Pooma code by explicitly instantiating more of it? We > could ask Dave Nyholm for his testing code so we do not have to spend > time enumerating the cases. > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > From JimC at proximation.com Mon May 7 15:42:49 2001 From: JimC at proximation.com (James Crotinger) Date: Mon, 7 May 2001 08:42:49 -0700 Subject: [pooma-dev] Testing Pooma Code Using Explicit Instantiations? Message-ID: There are definitely parts of r2 that were designed in such a way that explicit instantiation will not work - they rely on the fact that some functionality only make sense with certain types of engines, etc. For instance, MultiPatchEngine handles dynamic events, but the code that deals with these events only makes sense for patch engines that handle dynamic events. The event code is used for non-dynamic engines as well (for things like repartitioning a shared layout). The handling of dynamic events is delegated to a separate function dynamicHandler(...,WrappedInt). This is called as dynamicHandler(...,WrappedInt); in the event handler, and the dynamicHandler(...,WrappedInt) is just an empty stub. Since only the "false" version of this function is compiled for non-dynamic patch engines, this works. Explicit instantiation would attempt to compile both versions, and that would not work. The alternatives were to either make all engines support the dynamic interface, which would be a mess (and only makes sense in 1D), or to have a separate DynamicMultiPatch engine, which would mostly be a straight copy of MultiPatchEngine. Also, there are more than a few template member functions in r2, so explicit instantiation of classes is not enough to ensure that everything compiles. (Furthermore, many of these are inline due to problems with certain compilers/debuggers - it would be very nice to move these as many of them certainly don't need to be inline, but I think CW 6.0 still has trouble debugging template member functions that are defined outside of the class body [at least the beta did].) Jim > -----Original Message----- > From: Dave Nystrom [mailto:wdn at lanl.gov] > Sent: Saturday, May 05, 2001 11:47 AM > To: Jeffrey Oldham > Cc: pooma-dev at pooma.codesourcery.com; Dave Nystrom > Subject: RE: [pooma-dev] Testing Pooma Code Using Explicit > Instantiations? > > > Hi Jeff, > > Don't know how you got Nyholm but my last name is Nystrom. > I'm not sure > whether Pooma 2 has a goal of being able to instantiate all > the members of a > class. Perhaps Scott or Jim could comment on that> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdn at lanl.gov Tue May 8 19:24:54 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Tue, 8 May 2001 13:24:54 -0600 (MDT) Subject: [pooma-dev] Testing Pooma Code Using Explicit Instantiations? In-Reply-To: References: Message-ID: <15096.17403.63885.989194@mutley.lanl.gov> James Crotinger writes: > There are definitely parts of r2 that were designed in such a way that > explicit instantiation will not work - they rely on the fact that some > functionality only make sense with certain types of engines, etc. For Hi Jim, Don't you really mean here that there are parts of Pooma 2 that were designed in a way that precludes instantiating the whole class for a given set of template parameters whether it is done explicitly or otherwise? It seems important to me to make that distinction because the compiler only instantiates the actual methods that are referenced and if the compiler can instantiate a given templated method with specific template parameters, then it should be possible to explicitly instantiate the same method with the same template parameters. Being unfamiliar with the details of Pooma 2, I couldn't really comment on the feasibility of designing all the templated classes so that the whole class could be explicitly instantiated. But I thought I had heard either you or Scott say the same sorts of things previously that you are saying in this email i.e. it is very difficult to design all your classes so they can all be fully instantiated as classes for all the desired template parameters. I just want to be able to explicitly instantiate anything the compiler can instantiate. Dave > instance, MultiPatchEngine handles dynamic events, but the code that deals > with these events only makes sense for patch engines that handle dynamic > events. The event code is used for non-dynamic engines as well (for things > like repartitioning a shared layout). The handling of dynamic events is > delegated to a separate function dynamicHandler(...,WrappedInt). This > is called as > > dynamicHandler(...,WrappedInt); > > in the event handler, and the dynamicHandler(...,WrappedInt) is just > an empty stub. Since only the "false" version of this function is compiled > for non-dynamic patch engines, this works. Explicit instantiation would > attempt to compile both versions, and that would not work. The alternatives > were to either make all engines support the dynamic interface, which would > be a mess (and only makes sense in 1D), or to have a separate > DynamicMultiPatch engine, which would mostly be a straight copy of > MultiPatchEngine. > > Also, there are more than a few template member functions in r2, so explicit > instantiation of classes is not enough to ensure that everything compiles. > (Furthermore, many of these are inline due to problems with certain > compilers/debuggers - it would be very nice to move these as many of them > certainly don't need to be inline, but I think CW 6.0 still has trouble > debugging template member functions that are defined outside of the class > body [at least the beta did].) > > Jim > > > -----Original Message----- > > From: Dave Nystrom [mailto:wdn at lanl.gov] > > Sent: Saturday, May 05, 2001 11:47 AM > > To: Jeffrey Oldham > > Cc: pooma-dev at pooma.codesourcery.com; Dave Nystrom > > Subject: RE: [pooma-dev] Testing Pooma Code Using Explicit > > Instantiations? > > > > > > Hi Jeff, > > > > Don't know how you got Nyholm but my last name is Nystrom. > > I'm not sure > > whether Pooma 2 has a goal of being able to instantiate all > > the members of a > > class. Perhaps Scott or Jim could comment on that> > > > > > > RE: [pooma-dev] Testing Pooma Code Using Explicit Instantiations? > > > >

There are definitely parts of r2 that were designed in such a way that explicit instantiation will not work - they rely on the fact that some functionality only make sense with certain types of engines, etc. For instance, MultiPatchEngine handles dynamic events, but the code that deals with these events only makes sense for patch engines that handle dynamic events. The event code is used for non-dynamic engines as well (for things like repartitioning a shared layout). The handling of dynamic events is delegated to a separate function dynamicHandler(...,WrappedInt<true>). This is called as

> >

   dynamicHandler(...,WrappedInt<PatchEngine_t::dynamic>); >

> >

in the event handler, and the dynamicHandler(...,WrappedInt<false>) is just an empty stub. Since only the "false" version of this function is compiled for non-dynamic patch engines, this works. Explicit instantiation would attempt to compile both versions, and that would not work. The alternatives were to either make all engines support the dynamic interface, which would be a mess (and only makes sense in 1D), or to have a separate DynamicMultiPatch engine, which would mostly be a straight copy of MultiPatchEngine.

> >

Also, there are more than a few template member functions in r2, so explicit instantiation of classes is not enough to ensure that everything compiles. (Furthermore, many of these are inline due to problems with certain compilers/debuggers - it would be very nice to move these as many of them certainly don't need to be inline, but I think CW 6.0 still has trouble debugging template member functions that are defined outside of the class body [at least the beta did].)

> >

        Jim >

> >

> -----Original Message----- >
> From: Dave Nystrom [mailto:wdn at lanl.gov] >
> Sent: Saturday, May 05, 2001 11:47 AM >
> To: Jeffrey Oldham >
> Cc: pooma-dev at pooma.codesourcery.com; Dave Nystrom >
> Subject: RE: [pooma-dev] Testing Pooma Code Using Explicit >
> Instantiations? >
> >
> >
> Hi Jeff, >
> >
> Don't know how you got Nyholm but my last name is Nystrom.  >
> I'm not sure >
> whether Pooma 2 has a goal of being able to instantiate all >
> the members of a >
> class.  Perhaps Scott or Jim could comment on that> >

> > > From JimC at proximation.com Tue May 8 20:49:27 2001 From: JimC at proximation.com (James Crotinger) Date: Tue, 8 May 2001 13:49:27 -0700 Subject: [pooma-dev] Testing Pooma Code Using Explicit Instantiations? Message-ID: > Hi Jim, > > Don't you really mean here that there are parts of Pooma 2 > that were designed > in a way that precludes instantiating the whole class for a > given set of > template parameters whether it is done explicitly or > otherwise? It seems > important to me to make that distinction because the compiler only > instantiates the actual methods that are referenced and if > the compiler can > instantiate a given templated method with specific template > parameters, then > it should be possible to explicitly instantiate the same > method with the same > template parameters. That is, at least in theory, correct. Few things make my head hurt as bad as trying to understand all the template instantiation rules, though, so whether this is true in practice or not is difficult to say. This is not a particularly easy thing to test - perhaps getting your scripts for doing this would help perform this test. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdn at lanl.gov Wed May 9 20:19:58 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Wed, 9 May 2001 14:19:58 -0600 (MDT) Subject: Problem trying to build parallel application Message-ID: <15097.42238.862687.43355@mutley.lanl.gov> Hi Guys, I'm trying to build a parallel version of our application under RH Linux 6.2 using KCC-4.0d and am having compile problems. Below is part of the build log. Could someone take a look at this and see what the problem is? I think Stephen Smith might be a likely candidate. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 ---------------------------build-log------------------------------------- cd /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/ date; /usr/bin/time -p make RECURSE=1 PASS=MPI1 app Setting csh aliases for Blanca source environment v 4.0 on host: mutley Wed May 9 12:31:34 MDT 2001 COPYING... /usr/projects/blanca/packages/TecFramework/TecFramework_src/Main/main.cc to /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o_MPI1.info KCC -c /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/include/DemoPCH.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o.depend.mk.temp --diag_suppress 630 --create_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSupportBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBaseClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NOEX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug "/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/include/DemoPCH.cc": creating precompiled header file "/scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch" real 26.25 user 14.68 sys 4.94 Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o_MPI1.info KCC -c /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o.depend.mk.temp --diag_suppress 630 --COMPDO_fe_cc2c --pch_ignore_dir --use_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSupportBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBaseClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NOEX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug real 12.92 user 4.74 sys 0.56 Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o .........Stuff Deleted............ KCC -o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so --COMPO_ln -Wl,-noinhibit-exec --no_exceptions --parallel_build 1 /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/HydrodynamicsGroup.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/SymmetryRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/LagRadialVelocity.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetBrickCoordinates.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetFieldValues.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetVertexPoints.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/EOS/GammaLaw.o /scratch/wdn/obj_4.0/PHYSICSSUPPORTBETA/LINUX_KCC_CART_XYZ_MPI/libphysicssupportbeta.so /scratch/wdn/obj_4.0/PHYSICSBASECLASSES/LINUX_KCC_CART_XYZ_MPI/libphysicsbaseclasses.so /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_MPI/libpooma2integration.so /usr/projects/blanca/packages/TecFramework/lib/TECFRAMEWORK/LINUX_KCC_DEBUG_SHARED_NOEX/libtecframework.so /usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations/lib/POOMA2INSTANTIATIONS/LINUX_KCC_DEBUG_CHEETAH_SHARED_NOEX/libpooma2instantiations.so /usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations/lib/STLINSTANTIATIONS/LINUX_KCC_DEBUG_SHARED_NOEX/libstlinstantiations.so /usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX/libpooma.a cd "/home/wdn/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo" "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: class "Engine<1, poomalote::Real, Remote>" has no member "makeOwnCopy" data()[i].makeOwnCopy(); ^ detected during: instantiation of "Engine>::Engine_t &Engine>::makeOwnCopy() [with Dim=1, T=poomalote::Real, LayoutTag=GridTag, PatchTag=Remote]" at line 482 of "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi eldEngine/FieldEngineBase.h" instantiation of "void FieldEngineBase::makeOwnCopy(const Subject &) [with Dim=1, T=poomalote::Real, EngineTag=poomalote::ModelTraits>::EngineTag, Subject=Field>::MeshTag, poomalote::Real, poomalote::ModelTraits>::EngineTag>]" at line 983 of "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi eld.h" instantiation of "void Field::makeOwnCopy() [with GeometryTag=poomalote::ModelTraits>::MeshTag, T=poomalote::Real, EngineTag=poomalote::ModelTraits>::EngineTag]" at line 69 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC lasses/MMField.t.hh" instantiation of "void PhysicsBaseClasses::matMMWeightedAverage(const Field &, const Field &, const Field &, bool) [with MeshTag=poomalote::ModelTraits>::MeshTag, T=poomalote::Real, EngineTag=poomalote::ModelTraits>::EngineTag]" at line 579 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib leRelations.t.hh" instantiation of "void Hydrodynamics::CompatibleRelations::calcAvgQuanti ty(const Hydrodynamics::CompatibleRelations::ScalarField &, const Hydrodynamics::CompatibleRelations::ScalarField &, const Hydrodynamics::CompatibleRelations::ScalarField &) [with Traits=poomalote::OneDF]" "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: class "Engine<2, poomalote::Real, Remote>" has no member "makeOwnCopy" data()[i].makeOwnCopy(); ^ detected during: instantiation of "Engine>::Engine_t &Engine>::makeOwnCopy() [with Dim=2, T=poomalote::Real, LayoutTag=GridTag, PatchTag=Remote]" at line 482 of "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi eldEngine/FieldEngineBase.h" instantiation of "void FieldEngineBase::makeOwnCopy(const Subject &) [with Dim=2, T=poomalote::Real, EngineTag=poomalote::ModelTraits>::EngineTag, Subject=Field>::MeshTag, poomalote::Real, poomalote::ModelTraits>::EngineTag>]" at line 983 of "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi eld.h" instantiation of "void Field::makeOwnCopy() [with GeometryTag=poomalote::ModelTraits>::MeshTag, T=poomalote::Real, EngineTag=poomalote::ModelTraits>::EngineTag]" at line 69 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC lasses/MMField.t.hh" instantiation of "void PhysicsBaseClasses::matMMWeightedAverage(const Field &, const Field &, const Field &, bool) [with MeshTag=poomalote::ModelTraits>::MeshTag, T=poomalote::Real, EngineTag=poomalote::ModelTraits>::EngineTag]" at line 579 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib leRelations.t.hh" instantiation of "void Hydrodynamics::CompatibleRelations::calcAvgQuanti ty(const Hydrodynamics::CompatibleRelations::ScalarField &, const Hydrodynamics::CompatibleRelations::ScalarField &, const Hydrodynamics::CompatibleRelations::ScalarField &) [with Traits=poomalote::TwoDF]" "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: class "Engine<3, poomalote::Real, Remote>" has no member "makeOwnCopy" data()[i].makeOwnCopy(); ^ detected during: instantiation of "Engine>::Engine_t &Engine>::makeOwnCopy() [with Dim=3, T=poomalote::Real, LayoutTag=GridTag, PatchTag=Remote]" at line 482 of "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi eldEngine/FieldEngineBase.h" instantiation of "void FieldEngineBase::makeOwnCopy(const Subject &) [with Dim=3, T=poomalote::Real, EngineTag=poomalote::ModelTraits>::EngineTag, Subject=Field>::MeshTag, poomalote::Real, poomalote::ModelTraits>::EngineTag>]" at line 983 of "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi eld.h" instantiation of "void Field::makeOwnCopy() [with GeometryTag=poomalote::ModelTraits>::MeshTag, T=poomalote::Real, EngineTag=poomalote::ModelTraits>::EngineTag]" at line 69 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC lasses/MMField.t.hh" instantiation of "void PhysicsBaseClasses::matMMWeightedAverage(const Field &, const Field &, const Field &, bool) [with MeshTag=poomalote::ModelTraits>::MeshTag, T=poomalote::Real, EngineTag=poomalote::ModelTraits>::EngineTag]" at line 579 of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib leRelations.t.hh" instantiation of "void Hydrodynamics::CompatibleRelations::calcAvgQuanti ty(const Hydrodynamics::CompatibleRelations::ScalarField &, const Hydrodynamics::CompatibleRelations::ScalarField &, const Hydrodynamics::CompatibleRelations::ScalarField &) [with Traits=poomalote::ThreeDF]" 3 errors detected in the compilation of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.cc". driver: Compilation failed. Recompiling /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o Error: Unable to recompile /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o. Command exited with non-zero status 2 real 279.50 user 0.28 sys 0.01 mv: /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so: No such file or directory make[1]: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so] Error 1 make: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so] Error 2 Command exited with non-zero status 2 real 5983.14 user 2052.11 sys 160.74 Compilation exited abnormally with code 2 at Wed May 9 14:11:17 From oldham at codesourcery.com Fri May 11 03:01:58 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 10 May 2001 20:01:58 -0700 Subject: RFA: Patch: Miscellaneous Array, Engine, and Field Changes Message-ID: <20010510200158.A24329@codesourcery.com> OK to commit this patch? Attached is a patch of miscellaneous changes found when trying to explicitly instantiate various Arrays and Fields. I removed Array::innerDomain() because it invoked engines' innerDomain(), which did not seem to be defined. I used analogies to add domain() and makeOwnCopy(). 2001-05-10 Jeffrey D. Oldham * Array/Array.h: Add View0 to comment listing implemented classes. (Array::innerDomain): Remove the function since engines do not implement it. * Engine/CompressibleBlock.h (CompressibleBlockController::CompressibleBlockController): Reorder member initialization order. * Engine/CompressibleBrick.cpp (Engine::makeOwnCopy()): New function. * Engine/CompressibleBrick.h (Engine::domain()): Likewise. (Engine::domain()): Likewise. (Engine::makeOwnCopy()): New declaration. (ElementProperties >): New definition. * Layout/Node.h (Node::Node): Reorder member initialization order. * NewField/FieldEngine/FieldEngine.NoGeometry.h (FieldEngine, T, EngineTag>::physicalCellDomain): s/shrink/shrinkRight/ (FieldEngine, T, EngineTag>::totalCellDomain): Likewise. Tested on sequential Linux using g++ 3.0 by building library Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Array/Array.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v retrieving revision 1.139 diff -c -p -r1.139 Array.h *** Array/Array.h 2001/04/20 21:16:23 1.139 --- Array/Array.h 2001/05/11 02:37:11 *************** *** 29,34 **** --- 29,35 ---- //----------------------------------------------------------------------------- // Classes: // Array + // View0 // View[1-7] // LeafFunctor // LeafFunctor > *************** public: *** 1763,1773 **** inline Domain_t domain() const { return engine_m.domain(); - } - - inline Domain_t innerDomain() const - { - return engine_m.innerDomain(); } inline Domain_t physicalDomain() const --- 1764,1769 ---- Index: Engine/CompressibleBlock.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v retrieving revision 1.27 diff -c -p -r1.27 CompressibleBlock.h *** Engine/CompressibleBlock.h 2000/07/11 22:13:00 1.27 --- Engine/CompressibleBlock.h 2001/05/11 02:37:13 *************** private: *** 531,541 **** CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), - size_m(model.size_m), compressible_m(!Pooma::neverCompress()), dataObject_m(model.dataObject_m.affinity()), ! ucOffset_m(model.ucOffset_m), ! viewcount_m(0) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in --- 531,541 ---- CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), compressible_m(!Pooma::neverCompress()), + viewcount_m(0), dataObject_m(model.dataObject_m.affinity()), ! size_m(model.size_m), ! ucOffset_m(model.ucOffset_m) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in Index: Engine/CompressibleBrick.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v retrieving revision 1.24 diff -c -p -r1.24 CompressibleBrick.cpp *** Engine/CompressibleBrick.cpp 2000/07/11 23:06:40 1.24 --- Engine/CompressibleBrick.cpp 2001/05/11 02:37:13 *************** Engine(const Engine & makeOwnCopy() + // + // Causes the CompressibleBrickView-Engine to obtain a private copy of the data + // that it refers to. + // + //----------------------------------------------------------------------------- + + template + Engine &Engine::makeOwnCopy() + { + // JIM: This is probably not thread safe??? + // There is a race from checking isShared to getting into cblock's + // makeOwnCopy, which is thread safe. As a result, this should only + // be called after a blockAndEvaluate() to ensure that nobody else + // is messing with the underlying CBC while this is + // occuring. (Logically, this is necessary anyway since you probably + // want a copy of the data that results from all previous + // computations having taken place.) Also, as mentioned elsewhere, + // the current implementation results in copying uncompressed data + // in the parse thread, which will result in incorrect memory + // affinity. + + if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) + { + cblock_m.detach(this); + cblock_m.makeOwnCopy(); + cblock_m.attach(this); + + data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); + } + + return *this; + } + + //----------------------------------------------------------------------------- + // // Engine:: // elementsCompressed() const // Index: Engine/CompressibleBrick.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v retrieving revision 1.67 diff -c -p -r1.67 CompressibleBrick.h *** Engine/CompressibleBrick.h 2000/07/11 23:06:40 1.67 --- Engine/CompressibleBrick.h 2001/05/11 02:37:14 *************** public: *** 237,242 **** --- 237,250 ---- inline Layout_t layout() const { return Layout_t(domain_m); } + //--------------------------------------------------------------------------- + // Return the domain and base domain. + + inline const Domain_t &domain() const + { + return layout().domain(); + } + // Get a private copy of data viewed by this Engine. Engine_t &makeOwnCopy(); *************** public: *** 557,562 **** --- 565,582 ---- ElementRef_t operator()(const Loc &) const; Element_t read(const Loc &) const; + //--------------------------------------------------------------------------- + // Return the domain and base domain. + + inline const Domain_t &domain() const + { + return Layout_t(domain_m).domain(); + } + + // Get a private copy of data viewed by this Engine. + + Engine_t &makeOwnCopy(); + // Return the block controller (uncompressed). // See comments in CompressibleBrick above. *************** struct NewEngine struct ElementProperties > : public MakeOwnCopyProperties > + { }; + + template + struct ElementProperties > + : public MakeOwnCopyProperties > { }; Index: Layout/Node.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v retrieving revision 1.35 diff -c -p -r1.35 Node.h *** Layout/Node.h 2001/05/04 15:41:28 1.35 --- Layout/Node.h 2001/05/11 02:37:15 *************** public: *** 121,128 **** Node(const Domain_t &owned, const AllocatedDomain_t &allocated, Context_t c, ID_t gid, ID_t lid = (-1)) : domain_m(owned), allocated_m(allocated), ! context_m(c), global_m(gid), local_m(lid), ! affinity_m(-1) { PAssert(owned.size() >= 0); PAssert(allocated.size() >= 0); --- 121,128 ---- Node(const Domain_t &owned, const AllocatedDomain_t &allocated, Context_t c, ID_t gid, ID_t lid = (-1)) : domain_m(owned), allocated_m(allocated), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(-1) { PAssert(owned.size() >= 0); PAssert(allocated.size() >= 0); *************** public: *** 130,137 **** } Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), ! affinity_m(-1) { PAssert(d.size() >= 0); PAssert(gid >= 0); --- 130,138 ---- } Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(-1) { PAssert(d.size() >= 0); PAssert(gid >= 0); *************** public: *** 152,159 **** Node(int affinity, const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), ! affinity_m(affinity) { PAssert(d.size() >= 0); PAssert(gid >= 0); --- 153,161 ---- Node(int affinity, const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(affinity) { PAssert(d.size() >= 0); PAssert(gid >= 0); *************** public: *** 172,180 **** template Node(const Node &n) ! : domain_m(n.domain()), context_m(n.context()), allocated_m(n.allocated()), ! global_m(n.globalID()), local_m(n.localID()), ! affinity_m(n.affinity()) { } --- 174,182 ---- template Node(const Node &n) ! : domain_m(n.domain()), allocated_m(n.allocated()), ! local_m(n.localID()), global_m(n.globalID()), ! context_m(n.context()), affinity_m(n.affinity()) { } Index: NewField/FieldEngine/FieldEngine.NoGeometry.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v retrieving revision 1.4 diff -c -p -r1.4 FieldEngine.NoGeometry.h *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/11 02:37:15 *************** public: *** 254,267 **** // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 254,267 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrinkRight(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrinkRight(engine_m.domain(), 1); } Domain_t physicalDomain() const From mark at codesourcery.com Fri May 11 17:21:28 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 11 May 2001 10:21:28 -0700 Subject: Weekly Summaries Message-ID: <20010511102128M.mitchell@codesourcery.com> Send 'em in, please. Please try to highlight what you've done this week and what you're planning on for next week. Thank you, -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From wdn at lanl.gov Fri May 11 17:23:46 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Fri, 11 May 2001 11:23:46 -0600 (MDT) Subject: [pooma-dev] RFA: Patch: Miscellaneous Array, Engine, and Field Changes In-Reply-To: <20010510200158.A24329@codesourcery.com> References: <20010510200158.A24329@codesourcery.com> Message-ID: <15100.8161.859853.121891@mutley.lanl.gov> Hi Jeffrey, Do your changes fix the problems I was reporting with instantiation and also compiling for parallel with Cheetah? Thanks, Dave Jeffrey Oldham writes: > OK to commit this patch? > > Attached is a patch of miscellaneous changes found when trying to > explicitly instantiate various Arrays and Fields. I removed > Array::innerDomain() because it invoked engines' innerDomain(), which > did not seem to be defined. I used analogies to add domain() and > makeOwnCopy(). > > 2001-05-10 Jeffrey D. Oldham > > * Array/Array.h: Add View0 to comment listing implemented classes. > (Array::innerDomain): Remove the function since engines do not > implement it. > * Engine/CompressibleBlock.h > (CompressibleBlockController::CompressibleBlockController): > Reorder member initialization order. > * Engine/CompressibleBrick.cpp > (Engine::makeOwnCopy()): New > function. > * Engine/CompressibleBrick.h (Engine CompressibleBrick>::domain()): Likewise. > (Engine::domain()): Likewise. > (Engine::makeOwnCopy()): New > declaration. > (ElementProperties >): New > definition. > * Layout/Node.h (Node::Node): Reorder member initialization order. > * NewField/FieldEngine/FieldEngine.NoGeometry.h > (FieldEngine, T, EngineTag>::physicalCellDomain): > s/shrink/shrinkRight/ > (FieldEngine, T, EngineTag>::totalCellDomain): > Likewise. > > Tested on sequential Linux using g++ 3.0 by building library > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.comIndex: Array/Array.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v > retrieving revision 1.139 > diff -c -p -r1.139 Array.h > *** Array/Array.h 2001/04/20 21:16:23 1.139 > --- Array/Array.h 2001/05/11 02:37:11 > *************** > *** 29,34 **** > --- 29,35 ---- > //----------------------------------------------------------------------------- > // Classes: > // Array > + // View0 > // View[1-7] > // LeafFunctor > // LeafFunctor > > *************** public: > *** 1763,1773 **** > inline Domain_t domain() const > { > return engine_m.domain(); > - } > - > - inline Domain_t innerDomain() const > - { > - return engine_m.innerDomain(); > } > > inline Domain_t physicalDomain() const > --- 1764,1769 ---- > Index: Engine/CompressibleBlock.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v > retrieving revision 1.27 > diff -c -p -r1.27 CompressibleBlock.h > *** Engine/CompressibleBlock.h 2000/07/11 22:13:00 1.27 > --- Engine/CompressibleBlock.h 2001/05/11 02:37:13 > *************** private: > *** 531,541 **** > > CompressibleBlockController(const CompressibleBlockController& model) > : Observable(ptr_m), > - size_m(model.size_m), > compressible_m(!Pooma::neverCompress()), > dataObject_m(model.dataObject_m.affinity()), > ! ucOffset_m(model.ucOffset_m), > ! viewcount_m(0) > { > // Lock the model while we get information pertaining to it > // being compressed or not (such data can't be initialized in > --- 531,541 ---- > > CompressibleBlockController(const CompressibleBlockController& model) > : Observable(ptr_m), > compressible_m(!Pooma::neverCompress()), > + viewcount_m(0), > dataObject_m(model.dataObject_m.affinity()), > ! size_m(model.size_m), > ! ucOffset_m(model.ucOffset_m) > { > // Lock the model while we get information pertaining to it > // being compressed or not (such data can't be initialized in > Index: Engine/CompressibleBrick.cpp > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v > retrieving revision 1.24 > diff -c -p -r1.24 CompressibleBrick.cpp > *** Engine/CompressibleBrick.cpp 2000/07/11 23:06:40 1.24 > --- Engine/CompressibleBrick.cpp 2001/05/11 02:37:13 > *************** Engine(const Engine *** 501,506 **** > --- 501,542 ---- > > //----------------------------------------------------------------------------- > // > + // Engine & makeOwnCopy() > + // > + // Causes the CompressibleBrickView-Engine to obtain a private copy of the data > + // that it refers to. > + // > + //----------------------------------------------------------------------------- > + > + template > + Engine &Engine::makeOwnCopy() > + { > + // JIM: This is probably not thread safe??? > + // There is a race from checking isShared to getting into cblock's > + // makeOwnCopy, which is thread safe. As a result, this should only > + // be called after a blockAndEvaluate() to ensure that nobody else > + // is messing with the underlying CBC while this is > + // occuring. (Logically, this is necessary anyway since you probably > + // want a copy of the data that results from all previous > + // computations having taken place.) Also, as mentioned elsewhere, > + // the current implementation results in copying uncompressed data > + // in the parse thread, which will result in incorrect memory > + // affinity. > + > + if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) > + { > + cblock_m.detach(this); > + cblock_m.makeOwnCopy(); > + cblock_m.attach(this); > + > + data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); > + } > + > + return *this; > + } > + > + //----------------------------------------------------------------------------- > + // > // Engine:: > // elementsCompressed() const > // > Index: Engine/CompressibleBrick.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v > retrieving revision 1.67 > diff -c -p -r1.67 CompressibleBrick.h > *** Engine/CompressibleBrick.h 2000/07/11 23:06:40 1.67 > --- Engine/CompressibleBrick.h 2001/05/11 02:37:14 > *************** public: > *** 237,242 **** > --- 237,250 ---- > > inline Layout_t layout() const { return Layout_t(domain_m); } > > + //--------------------------------------------------------------------------- > + // Return the domain and base domain. > + > + inline const Domain_t &domain() const > + { > + return layout().domain(); > + } > + > // Get a private copy of data viewed by this Engine. > > Engine_t &makeOwnCopy(); > *************** public: > *** 557,562 **** > --- 565,582 ---- > ElementRef_t operator()(const Loc &) const; > Element_t read(const Loc &) const; > > + //--------------------------------------------------------------------------- > + // Return the domain and base domain. > + > + inline const Domain_t &domain() const > + { > + return Layout_t(domain_m).domain(); > + } > + > + // Get a private copy of data viewed by this Engine. > + > + Engine_t &makeOwnCopy(); > + > // Return the block controller (uncompressed). > // See comments in CompressibleBrick above. > > *************** struct NewEngine *** 801,806 **** > --- 821,831 ---- > template > struct ElementProperties > > : public MakeOwnCopyProperties > > + { }; > + > + template > + struct ElementProperties > > + : public MakeOwnCopyProperties > > { }; > > > Index: Layout/Node.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v > retrieving revision 1.35 > diff -c -p -r1.35 Node.h > *** Layout/Node.h 2001/05/04 15:41:28 1.35 > --- Layout/Node.h 2001/05/11 02:37:15 > *************** public: > *** 121,128 **** > Node(const Domain_t &owned, const AllocatedDomain_t &allocated, > Context_t c, ID_t gid, ID_t lid = (-1)) > : domain_m(owned), allocated_m(allocated), > ! context_m(c), global_m(gid), local_m(lid), > ! affinity_m(-1) > { > PAssert(owned.size() >= 0); > PAssert(allocated.size() >= 0); > --- 121,128 ---- > Node(const Domain_t &owned, const AllocatedDomain_t &allocated, > Context_t c, ID_t gid, ID_t lid = (-1)) > : domain_m(owned), allocated_m(allocated), > ! local_m(lid), global_m(gid), > ! context_m(c), affinity_m(-1) > { > PAssert(owned.size() >= 0); > PAssert(allocated.size() >= 0); > *************** public: > *** 130,137 **** > } > > Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), > ! affinity_m(-1) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > --- 130,138 ---- > } > > Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), > ! local_m(lid), global_m(gid), > ! context_m(c), affinity_m(-1) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > *************** public: > *** 152,159 **** > > Node(int affinity, const Domain_t &d, > Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), > ! affinity_m(affinity) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > --- 153,161 ---- > > Node(int affinity, const Domain_t &d, > Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), > ! local_m(lid), global_m(gid), > ! context_m(c), affinity_m(affinity) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > *************** public: > *** 172,180 **** > > template > Node(const Node &n) > ! : domain_m(n.domain()), context_m(n.context()), allocated_m(n.allocated()), > ! global_m(n.globalID()), local_m(n.localID()), > ! affinity_m(n.affinity()) > { > } > > --- 174,182 ---- > > template > Node(const Node &n) > ! : domain_m(n.domain()), allocated_m(n.allocated()), > ! local_m(n.localID()), global_m(n.globalID()), > ! context_m(n.context()), affinity_m(n.affinity()) > { > } > > Index: NewField/FieldEngine/FieldEngine.NoGeometry.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v > retrieving revision 1.4 > diff -c -p -r1.4 FieldEngine.NoGeometry.h > *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 > --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/11 02:37:15 > *************** public: > *** 254,267 **** > // This field-engine always has vert-centering and the total domain is > // given by the engine. > > ! inline const Domain_t &physicalCellDomain() const > { > ! return shrink(physicalDomain(), 1); > } > > inline Domain_t totalCellDomain() const > { > ! return shrink(engine_m.domain(), 1); > } > > Domain_t physicalDomain() const > --- 254,267 ---- > // This field-engine always has vert-centering and the total domain is > // given by the engine. > > ! inline const Domain_t physicalCellDomain() const > { > ! return shrinkRight(physicalDomain(), 1); > } > > inline Domain_t totalCellDomain() const > { > ! return shrinkRight(engine_m.domain(), 1); > } > > Domain_t physicalDomain() const From oldham at codesourcery.com Fri May 11 17:33:04 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 11 May 2001 10:33:04 -0700 Subject: [pooma-dev] RFA: Patch: Miscellaneous Array, Engine, and Field Changes In-Reply-To: <15100.8161.859853.121891@mutley.lanl.gov>; from wdn@lanl.gov on Fri, May 11, 2001 at 11:23:46AM -0600 References: <20010510200158.A24329@codesourcery.com> <15100.8161.859853.121891@mutley.lanl.gov> Message-ID: <20010511103304.A19061@codesourcery.com> On Fri, May 11, 2001 at 11:23:46AM -0600, Dave Nystrom wrote: > > Do your changes fix the problems I was reporting with instantiation and also > compiling for parallel with Cheetah? No, they attempt to fix difficulties I found when investigating on your explicit instantiation problem, but I still have not solved that problem. Scott Haney put your explicit instantiation problem in the short list of tasks to solve, but higher priority was finishing thinking about operators. I'm building Pooma on Irix6.5 using g++ and KCC right now to see if I can flush out more problems and then use KCC's error messages to see if I can make more progress on your difficulties. For you, does the Cheetah problem have higher or lower priority than the explicit instantiation problem? Thanks, Jeffrey D. Oldham oldham at codesourcery.com From wdn at lanl.gov Fri May 11 17:48:54 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Fri, 11 May 2001 11:48:54 -0600 (MDT) Subject: [pooma-dev] RFA: Patch: Miscellaneous Array, Engine, and Field Changes In-Reply-To: <20010511103304.A19061@codesourcery.com> References: <20010510200158.A24329@codesourcery.com> <15100.8161.859853.121891@mutley.lanl.gov> <20010511103304.A19061@codesourcery.com> Message-ID: <15100.9255.222216.431371@mutley.lanl.gov> Jeffrey Oldham writes: > On Fri, May 11, 2001 at 11:23:46AM -0600, Dave Nystrom wrote: > > > > Do your changes fix the problems I was reporting with instantiation and also > > compiling for parallel with Cheetah? > > No, they attempt to fix difficulties I found when investigating on > your explicit instantiation problem, but I still have not solved that > problem. Scott Haney put your explicit instantiation problem in the > short list of tasks to solve, but higher priority was finishing > thinking about operators. > > I'm building Pooma on Irix6.5 using g++ and KCC right now to see if I > can flush out more problems and then use KCC's error messages to see > if I can make more progress on your difficulties. For you, does the > Cheetah problem have higher or lower priority than the explicit > instantiation problem? The Cheetah problem is higher priority because it is keeping us from building a parallel version of the code and I think we need to start running in parallel as soon as possible. However, I think that problem will be easy to solve - because I think it is just a matter of a missing function or something like that. But I'm not sure. Stephen Smith might have some perspective on this. Solving the explicit instantiation problem will allow me to complete some work on trying to optimize/reduce compile times that developers see. That is something that is very important to me but is lower priority than fixing the problems that are keeping us from building a parallel version of our code to test. Thanks for the update. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 From oldham at codesourcery.com Fri May 11 18:52:48 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 11 May 2001 11:52:48 -0700 Subject: [pooma-dev] Problem trying to build parallel application In-Reply-To: <15097.42238.862687.43355@mutley.lanl.gov>; from wdn@lanl.gov on Wed, May 09, 2001 at 02:19:58PM -0600 References: <15097.42238.862687.43355@mutley.lanl.gov> Message-ID: <20010511115248.A19159@codesourcery.com> Perhaps yesterday's patch does resolve the makeOwnCopy() difficulty you experienced. Will you please try it again? I do not know where the source code is located to test it myself. Thanks, Jeffrey D. Oldham oldham at codesourcery.com On Wed, May 09, 2001 at 02:19:58PM -0600, Dave Nystrom wrote: > Hi Guys, > > I'm trying to build a parallel version of our application under RH Linux 6.2 > using KCC-4.0d and am having compile problems. Below is part of the build > log. Could someone take a look at this and see what the problem is? I think > Stephen Smith might be a likely candidate. > > -- > Dave Nystrom email: wdn at lanl.gov > LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > > ---------------------------build-log------------------------------------- > cd /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/ > date; /usr/bin/time -p make RECURSE=1 PASS=MPI1 app > > Setting csh aliases for Blanca source environment v 4.0 on host: mutley > Wed May 9 12:31:34 MDT 2001 > COPYING... /usr/projects/blanca/packages/TecFramework/TecFramework_src/Main/main.cc to /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc > > COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o_MPI1.info > > KCC -c /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/include/DemoPCH.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o.depend.mk.temp --diag_suppress 630 --create_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSupportBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBaseClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NOEX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/include/DemoPCH.cc": creating precompiled header file "/scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch" > real 26.25 > user 14.68 > sys 4.94 > > Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o > > COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o_MPI1.info > > KCC -c /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o.depend.mk.temp --diag_suppress 630 --COMPDO_fe_cc2c --pch_ignore_dir --use_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSupportBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBaseClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NOEX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug > > real 12.92 > user 4.74 > sys 0.56 > > Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o > > .........Stuff Deleted............ > > KCC -o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so --COMPO_ln -Wl,-noinhibit-exec --no_exceptions --parallel_build 1 /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/HydrodynamicsGroup.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/SymmetryRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/LagRadialVelocity.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetBrickCoordinates.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetFieldValues.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetVertexPoints.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/EOS/GammaLaw.o /scratch/wdn/obj_4.0/PHYSICSSUPPORTBETA/LINUX_KCC_CART_XYZ_MPI/libphysicssupportbeta.so /scratch/wdn/obj_4.0/PHYSICSBASECLASSES/LINUX_KCC_CART_XYZ_MPI/libphysicsbaseclasses.so /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_MPI/libpooma2integration.so /usr/projects/blanca/packages/TecFramework/lib/TECFRAMEWORK/LINUX_KCC_DEBUG_SHARED_NOEX/libtecframework.so /usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations/lib/POOMA2INSTANTIATIONS/LINUX_KCC_DEBUG_CHEETAH_SHARED_NOEX/libpooma2instantiations.so /usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations/lib/STLINSTANTIATIONS/LINUX_KCC_DEBUG_SHARED_NOEX/libstlinstantiations.so /usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX/libpooma.a > > cd "/home/wdn/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo" > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: > class "Engine<1, poomalote::Real, Remote>" has no > member "makeOwnCopy" > data()[i].makeOwnCopy(); > ^ > detected during: > instantiation of "Engine PatchTag>>::Engine_t &Engine MultiPatch>::makeOwnCopy() [with > Dim=1, T=poomalote::Real, LayoutTag=GridTag, > PatchTag=Remote]" at line 482 of > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > eldEngine/FieldEngineBase.h" > instantiation of "void FieldEngineBase EngineTag>::makeOwnCopy(const Subject &) [with Dim=1, > T=poomalote::Real, > EngineTag=poomalote::ModelTraits te::DefaultTraits>>::EngineTag, > Subject=Field malote::DefaultTraits>>::MeshTag, poomalote::Real, > poomalote::ModelTraits tTraits>>::EngineTag>]" at line 983 of > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > eld.h" > instantiation of "void Field EngineTag>::makeOwnCopy() [with > GeometryTag=poomalote::ModelTraits lote::DefaultTraits>>::MeshTag, T=poomalote::Real, > EngineTag=poomalote::ModelTraits te::DefaultTraits>>::EngineTag]" at line 69 of > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > lasses/MMField.t.hh" > instantiation of "void > PhysicsBaseClasses::matMMWeightedAverage(const Field T1, E1> &, const Field EngineTag> &, const Field &, bool) [with > MeshTag=poomalote::ModelTraits ::DefaultTraits>>::MeshTag, T=poomalote::Real, > EngineTag=poomalote::ModelTraits te::DefaultTraits>>::EngineTag]" at line 579 of > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > leRelations.t.hh" > instantiation of "void > Hydrodynamics::CompatibleRelations::calcAvgQuanti > ty(const > Hydrodynamics::CompatibleRelations::ScalarField > &, const > Hydrodynamics::CompatibleRelations::ScalarField > &, const > Hydrodynamics::CompatibleRelations::ScalarField > &) [with > Traits=poomalote::OneDF]" > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: > class "Engine<2, poomalote::Real, Remote>" has no > member "makeOwnCopy" > data()[i].makeOwnCopy(); > ^ > detected during: > instantiation of "Engine PatchTag>>::Engine_t &Engine MultiPatch>::makeOwnCopy() [with > Dim=2, T=poomalote::Real, LayoutTag=GridTag, > PatchTag=Remote]" at line 482 of > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > eldEngine/FieldEngineBase.h" > instantiation of "void FieldEngineBase EngineTag>::makeOwnCopy(const Subject &) [with Dim=2, > T=poomalote::Real, > EngineTag=poomalote::ModelTraits te::DefaultTraits>>::EngineTag, > Subject=Field malote::DefaultTraits>>::MeshTag, poomalote::Real, > poomalote::ModelTraits tTraits>>::EngineTag>]" at line 983 of > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > eld.h" > instantiation of "void Field EngineTag>::makeOwnCopy() [with > GeometryTag=poomalote::ModelTraits lote::DefaultTraits>>::MeshTag, T=poomalote::Real, > EngineTag=poomalote::ModelTraits te::DefaultTraits>>::EngineTag]" at line 69 of > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > lasses/MMField.t.hh" > instantiation of "void > PhysicsBaseClasses::matMMWeightedAverage(const Field T1, E1> &, const Field EngineTag> &, const Field &, bool) [with > MeshTag=poomalote::ModelTraits ::DefaultTraits>>::MeshTag, T=poomalote::Real, > EngineTag=poomalote::ModelTraits te::DefaultTraits>>::EngineTag]" at line 579 of > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > leRelations.t.hh" > instantiation of "void > Hydrodynamics::CompatibleRelations::calcAvgQuanti > ty(const > Hydrodynamics::CompatibleRelations::ScalarField > &, const > Hydrodynamics::CompatibleRelations::ScalarField > &, const > Hydrodynamics::CompatibleRelations::ScalarField > &) [with > Traits=poomalote::TwoDF]" > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: > class "Engine<3, poomalote::Real, Remote>" has no > member "makeOwnCopy" > data()[i].makeOwnCopy(); > ^ > detected during: > instantiation of "Engine PatchTag>>::Engine_t &Engine MultiPatch>::makeOwnCopy() [with > Dim=3, T=poomalote::Real, LayoutTag=GridTag, > PatchTag=Remote]" at line 482 of > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > eldEngine/FieldEngineBase.h" > instantiation of "void FieldEngineBase EngineTag>::makeOwnCopy(const Subject &) [with Dim=3, > T=poomalote::Real, > EngineTag=poomalote::ModelTraits lote::DefaultTraits>>::EngineTag, > Subject=Field oomalote::DefaultTraits>>::MeshTag, poomalote::Real, > poomalote::ModelTraits ultTraits>>::EngineTag>]" at line 983 of > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > eld.h" > instantiation of "void Field EngineTag>::makeOwnCopy() [with > GeometryTag=poomalote::ModelTraits malote::DefaultTraits>>::MeshTag, T=poomalote::Real, > EngineTag=poomalote::ModelTraits lote::DefaultTraits>>::EngineTag]" at line 69 of > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > lasses/MMField.t.hh" > instantiation of "void > PhysicsBaseClasses::matMMWeightedAverage(const Field T1, E1> &, const Field EngineTag> &, const Field &, bool) [with > MeshTag=poomalote::ModelTraits te::DefaultTraits>>::MeshTag, T=poomalote::Real, > EngineTag=poomalote::ModelTraits lote::DefaultTraits>>::EngineTag]" at line 579 of > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > leRelations.t.hh" > instantiation of "void > Hydrodynamics::CompatibleRelations::calcAvgQuanti > ty(const > Hydrodynamics::CompatibleRelations::ScalarField > &, const > Hydrodynamics::CompatibleRelations::ScalarField > &, const > Hydrodynamics::CompatibleRelations::ScalarField > &) [with > Traits=poomalote::ThreeDF]" > > 3 errors detected in the compilation of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.cc". > driver: Compilation failed. > Recompiling /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o > Error: Unable to recompile /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o. > Command exited with non-zero status 2 > real 279.50 > user 0.28 > sys 0.01 > mv: /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so: No such file or directory > make[1]: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so] Error 1 > make: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so] Error 2 > Command exited with non-zero status 2 > real 5983.14 > user 2052.11 > sys 160.74 > > Compilation exited abnormally with code 2 at Wed May 9 14:11:17 -- Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Array/Array.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v retrieving revision 1.139 diff -c -p -r1.139 Array.h *** Array/Array.h 2001/04/20 21:16:23 1.139 --- Array/Array.h 2001/05/11 02:37:11 *************** *** 29,34 **** --- 29,35 ---- //----------------------------------------------------------------------------- // Classes: // Array + // View0 // View[1-7] // LeafFunctor // LeafFunctor > *************** public: *** 1763,1773 **** inline Domain_t domain() const { return engine_m.domain(); - } - - inline Domain_t innerDomain() const - { - return engine_m.innerDomain(); } inline Domain_t physicalDomain() const --- 1764,1769 ---- Index: Engine/CompressibleBlock.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v retrieving revision 1.27 diff -c -p -r1.27 CompressibleBlock.h *** Engine/CompressibleBlock.h 2000/07/11 22:13:00 1.27 --- Engine/CompressibleBlock.h 2001/05/11 02:37:13 *************** private: *** 531,541 **** CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), - size_m(model.size_m), compressible_m(!Pooma::neverCompress()), dataObject_m(model.dataObject_m.affinity()), ! ucOffset_m(model.ucOffset_m), ! viewcount_m(0) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in --- 531,541 ---- CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), compressible_m(!Pooma::neverCompress()), + viewcount_m(0), dataObject_m(model.dataObject_m.affinity()), ! size_m(model.size_m), ! ucOffset_m(model.ucOffset_m) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in Index: Engine/CompressibleBrick.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v retrieving revision 1.24 diff -c -p -r1.24 CompressibleBrick.cpp *** Engine/CompressibleBrick.cpp 2000/07/11 23:06:40 1.24 --- Engine/CompressibleBrick.cpp 2001/05/11 02:37:13 *************** Engine(const Engine & makeOwnCopy() + // + // Causes the CompressibleBrickView-Engine to obtain a private copy of the data + // that it refers to. + // + //----------------------------------------------------------------------------- + + template + Engine &Engine::makeOwnCopy() + { + // JIM: This is probably not thread safe??? + // There is a race from checking isShared to getting into cblock's + // makeOwnCopy, which is thread safe. As a result, this should only + // be called after a blockAndEvaluate() to ensure that nobody else + // is messing with the underlying CBC while this is + // occuring. (Logically, this is necessary anyway since you probably + // want a copy of the data that results from all previous + // computations having taken place.) Also, as mentioned elsewhere, + // the current implementation results in copying uncompressed data + // in the parse thread, which will result in incorrect memory + // affinity. + + if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) + { + cblock_m.detach(this); + cblock_m.makeOwnCopy(); + cblock_m.attach(this); + + data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); + } + + return *this; + } + + //----------------------------------------------------------------------------- + // // Engine:: // elementsCompressed() const // Index: Engine/CompressibleBrick.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v retrieving revision 1.67 diff -c -p -r1.67 CompressibleBrick.h *** Engine/CompressibleBrick.h 2000/07/11 23:06:40 1.67 --- Engine/CompressibleBrick.h 2001/05/11 02:37:14 *************** public: *** 237,242 **** --- 237,250 ---- inline Layout_t layout() const { return Layout_t(domain_m); } + //--------------------------------------------------------------------------- + // Return the domain and base domain. + + inline const Domain_t &domain() const + { + return layout().domain(); + } + // Get a private copy of data viewed by this Engine. Engine_t &makeOwnCopy(); *************** public: *** 557,562 **** --- 565,582 ---- ElementRef_t operator()(const Loc &) const; Element_t read(const Loc &) const; + //--------------------------------------------------------------------------- + // Return the domain and base domain. + + inline const Domain_t &domain() const + { + return Layout_t(domain_m).domain(); + } + + // Get a private copy of data viewed by this Engine. + + Engine_t &makeOwnCopy(); + // Return the block controller (uncompressed). // See comments in CompressibleBrick above. *************** struct NewEngine struct ElementProperties > : public MakeOwnCopyProperties > + { }; + + template + struct ElementProperties > + : public MakeOwnCopyProperties > { }; Index: Layout/Node.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v retrieving revision 1.35 diff -c -p -r1.35 Node.h *** Layout/Node.h 2001/05/04 15:41:28 1.35 --- Layout/Node.h 2001/05/11 02:37:15 *************** public: *** 121,128 **** Node(const Domain_t &owned, const AllocatedDomain_t &allocated, Context_t c, ID_t gid, ID_t lid = (-1)) : domain_m(owned), allocated_m(allocated), ! context_m(c), global_m(gid), local_m(lid), ! affinity_m(-1) { PAssert(owned.size() >= 0); PAssert(allocated.size() >= 0); --- 121,128 ---- Node(const Domain_t &owned, const AllocatedDomain_t &allocated, Context_t c, ID_t gid, ID_t lid = (-1)) : domain_m(owned), allocated_m(allocated), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(-1) { PAssert(owned.size() >= 0); PAssert(allocated.size() >= 0); *************** public: *** 130,137 **** } Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), ! affinity_m(-1) { PAssert(d.size() >= 0); PAssert(gid >= 0); --- 130,138 ---- } Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(-1) { PAssert(d.size() >= 0); PAssert(gid >= 0); *************** public: *** 152,159 **** Node(int affinity, const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), ! affinity_m(affinity) { PAssert(d.size() >= 0); PAssert(gid >= 0); --- 153,161 ---- Node(int affinity, const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(affinity) { PAssert(d.size() >= 0); PAssert(gid >= 0); *************** public: *** 172,180 **** template Node(const Node &n) ! : domain_m(n.domain()), context_m(n.context()), allocated_m(n.allocated()), ! global_m(n.globalID()), local_m(n.localID()), ! affinity_m(n.affinity()) { } --- 174,182 ---- template Node(const Node &n) ! : domain_m(n.domain()), allocated_m(n.allocated()), ! local_m(n.localID()), global_m(n.globalID()), ! context_m(n.context()), affinity_m(n.affinity()) { } Index: NewField/FieldEngine/FieldEngine.NoGeometry.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v retrieving revision 1.4 diff -c -p -r1.4 FieldEngine.NoGeometry.h *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/11 02:37:15 *************** public: *** 254,267 **** // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 254,267 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrinkRight(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrinkRight(engine_m.domain(), 1); } Domain_t physicalDomain() const From wdn at lanl.gov Fri May 11 19:36:08 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Fri, 11 May 2001 13:36:08 -0600 (MDT) Subject: [pooma-dev] Problem trying to build parallel application In-Reply-To: <20010511115248.A19159@codesourcery.com> References: <15097.42238.862687.43355@mutley.lanl.gov> <20010511115248.A19159@codesourcery.com> Message-ID: <15100.16015.707995.228935@mutley.lanl.gov> Jeffrey Oldham writes: > Perhaps yesterday's patch does resolve the makeOwnCopy() > difficulty you experienced. Will you please try it again? I do not > know where the source code is located to test it myself. Have you committed your changes yet? I have not seen them committed yet. When you commit them, I can check them out and try them. I don't know how to deal with patches - if it is easy and you can tell me how to use your patch, I'd be happy to try it. Dave > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > > On Wed, May 09, 2001 at 02:19:58PM -0600, Dave Nystrom wrote: > > Hi Guys, > > > > I'm trying to build a parallel version of our application under RH Linux 6.2 > > using KCC-4.0d and am having compile problems. Below is part of the build > > log. Could someone take a look at this and see what the problem is? I think > > Stephen Smith might be a likely candidate. > > > > -- > > Dave Nystrom email: wdn at lanl.gov > > LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > > > > ---------------------------build-log------------------------------------- > > cd /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/ > > date; /usr/bin/time -p make RECURSE=1 PASS=MPI1 app > > > > Setting csh aliases for Blanca source environment v 4.0 on host: mutley > > Wed May 9 12:31:34 MDT 2001 > > COPYING... /usr/projects/blanca/packages/TecFramework/TecFramework_src/Main/main.cc to /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc > > > > COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o_MPI1.info > > > > KCC -c /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/include/DemoPCH.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o.depend.mk.temp --diag_suppress 630 --create_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSupportBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBaseClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NOEX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug > > > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/include/DemoPCH.cc": creating precompiled header file "/scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch" > > real 26.25 > > user 14.68 > > sys 4.94 > > > > Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o > > > > COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o_MPI1.info > > > > KCC -c /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o.depend.mk.temp --diag_suppress 630 --COMPDO_fe_cc2c --pch_ignore_dir --use_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSupportBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBaseClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NOEX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug > > > > real 12.92 > > user 4.74 > > sys 0.56 > > > > Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o > > > > .........Stuff Deleted............ > > > > KCC -o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so --COMPO_ln -Wl,-noinhibit-exec --no_exceptions --parallel_build 1 /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/HydrodynamicsGroup.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/SymmetryRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/LagRadialVelocity.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetBrickCoordinates.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetFieldValues.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetVertexPoints.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/EOS/GammaLaw.o /scratch/wdn/obj_4.0/PHYSICSSUPPORTBETA/LINUX_KCC_CART_XYZ_MPI/libphysicssupportbeta.so /scratch/wdn/obj_4.0/PHYSICSBASECLASSES/LINUX_KCC_CART_XYZ_MPI/libphysicsbaseclasses.so /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_MPI/libpooma2integration.so /usr/projects/blanca/packages/TecFramework/lib/TECFRAMEWORK/LINUX_KCC_DEBUG_SHARED_NOEX/libtecframework.so /usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations/lib/POOMA2INSTANTIATIONS/LINUX_KCC_DEBUG_CHEETAH_SHARED_NOEX/libpooma2instantiations.so /usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations/lib/STLINSTANTIATIONS/LINUX_KCC_DEBUG_SHARED_NOEX/libstlinstantiations.so /usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX/libpooma.a > > > > cd "/home/wdn/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo" > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: > > class "Engine<1, poomalote::Real, Remote>" has no > > member "makeOwnCopy" > > data()[i].makeOwnCopy(); > > ^ > > detected during: > > instantiation of "Engine > PatchTag>>::Engine_t &Engine > MultiPatch>::makeOwnCopy() [with > > Dim=1, T=poomalote::Real, LayoutTag=GridTag, > > PatchTag=Remote]" at line 482 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eldEngine/FieldEngineBase.h" > > instantiation of "void FieldEngineBase > EngineTag>::makeOwnCopy(const Subject &) [with Dim=1, > > T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag, > > Subject=Field > malote::DefaultTraits>>::MeshTag, poomalote::Real, > > poomalote::ModelTraits > tTraits>>::EngineTag>]" at line 983 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eld.h" > > instantiation of "void Field > EngineTag>::makeOwnCopy() [with > > GeometryTag=poomalote::ModelTraits > lote::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag]" at line 69 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > > lasses/MMField.t.hh" > > instantiation of "void > > PhysicsBaseClasses::matMMWeightedAverage(const Field > T1, E1> &, const Field > EngineTag> &, const Field &, bool) [with > > MeshTag=poomalote::ModelTraits > ::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag]" at line 579 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > > leRelations.t.hh" > > instantiation of "void > > Hydrodynamics::CompatibleRelations::calcAvgQuanti > > ty(const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &) [with > > Traits=poomalote::OneDF]" > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: > > class "Engine<2, poomalote::Real, Remote>" has no > > member "makeOwnCopy" > > data()[i].makeOwnCopy(); > > ^ > > detected during: > > instantiation of "Engine > PatchTag>>::Engine_t &Engine > MultiPatch>::makeOwnCopy() [with > > Dim=2, T=poomalote::Real, LayoutTag=GridTag, > > PatchTag=Remote]" at line 482 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eldEngine/FieldEngineBase.h" > > instantiation of "void FieldEngineBase > EngineTag>::makeOwnCopy(const Subject &) [with Dim=2, > > T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag, > > Subject=Field > malote::DefaultTraits>>::MeshTag, poomalote::Real, > > poomalote::ModelTraits > tTraits>>::EngineTag>]" at line 983 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eld.h" > > instantiation of "void Field > EngineTag>::makeOwnCopy() [with > > GeometryTag=poomalote::ModelTraits > lote::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag]" at line 69 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > > lasses/MMField.t.hh" > > instantiation of "void > > PhysicsBaseClasses::matMMWeightedAverage(const Field > T1, E1> &, const Field > EngineTag> &, const Field &, bool) [with > > MeshTag=poomalote::ModelTraits > ::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag]" at line 579 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > > leRelations.t.hh" > > instantiation of "void > > Hydrodynamics::CompatibleRelations::calcAvgQuanti > > ty(const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &) [with > > Traits=poomalote::TwoDF]" > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: > > class "Engine<3, poomalote::Real, Remote>" has no > > member "makeOwnCopy" > > data()[i].makeOwnCopy(); > > ^ > > detected during: > > instantiation of "Engine > PatchTag>>::Engine_t &Engine > MultiPatch>::makeOwnCopy() [with > > Dim=3, T=poomalote::Real, LayoutTag=GridTag, > > PatchTag=Remote]" at line 482 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eldEngine/FieldEngineBase.h" > > instantiation of "void FieldEngineBase > EngineTag>::makeOwnCopy(const Subject &) [with Dim=3, > > T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > lote::DefaultTraits>>::EngineTag, > > Subject=Field > oomalote::DefaultTraits>>::MeshTag, poomalote::Real, > > poomalote::ModelTraits > ultTraits>>::EngineTag>]" at line 983 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eld.h" > > instantiation of "void Field > EngineTag>::makeOwnCopy() [with > > GeometryTag=poomalote::ModelTraits > malote::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > lote::DefaultTraits>>::EngineTag]" at line 69 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > > lasses/MMField.t.hh" > > instantiation of "void > > PhysicsBaseClasses::matMMWeightedAverage(const Field > T1, E1> &, const Field > EngineTag> &, const Field &, bool) [with > > MeshTag=poomalote::ModelTraits > te::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > lote::DefaultTraits>>::EngineTag]" at line 579 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > > leRelations.t.hh" > > instantiation of "void > > Hydrodynamics::CompatibleRelations::calcAvgQuanti > > ty(const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &) [with > > Traits=poomalote::ThreeDF]" > > > > 3 errors detected in the compilation of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.cc". > > driver: Compilation failed. > > Recompiling /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o > > Error: Unable to recompile /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o. > > Command exited with non-zero status 2 > > real 279.50 > > user 0.28 > > sys 0.01 > > mv: /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so: No such file or directory > > make[1]: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so] Error 1 > > make: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so] Error 2 > > Command exited with non-zero status 2 > > real 5983.14 > > user 2052.11 > > sys 160.74 > > > > Compilation exited abnormally with code 2 at Wed May 9 14:11:17 > > -- > Jeffrey D. Oldham > oldham at codesourcery.comIndex: Array/Array.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v > retrieving revision 1.139 > diff -c -p -r1.139 Array.h > *** Array/Array.h 2001/04/20 21:16:23 1.139 > --- Array/Array.h 2001/05/11 02:37:11 > *************** > *** 29,34 **** > --- 29,35 ---- > //----------------------------------------------------------------------------- > // Classes: > // Array > + // View0 > // View[1-7] > // LeafFunctor > // LeafFunctor > > *************** public: > *** 1763,1773 **** > inline Domain_t domain() const > { > return engine_m.domain(); > - } > - > - inline Domain_t innerDomain() const > - { > - return engine_m.innerDomain(); > } > > inline Domain_t physicalDomain() const > --- 1764,1769 ---- > Index: Engine/CompressibleBlock.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v > retrieving revision 1.27 > diff -c -p -r1.27 CompressibleBlock.h > *** Engine/CompressibleBlock.h 2000/07/11 22:13:00 1.27 > --- Engine/CompressibleBlock.h 2001/05/11 02:37:13 > *************** private: > *** 531,541 **** > > CompressibleBlockController(const CompressibleBlockController& model) > : Observable(ptr_m), > - size_m(model.size_m), > compressible_m(!Pooma::neverCompress()), > dataObject_m(model.dataObject_m.affinity()), > ! ucOffset_m(model.ucOffset_m), > ! viewcount_m(0) > { > // Lock the model while we get information pertaining to it > // being compressed or not (such data can't be initialized in > --- 531,541 ---- > > CompressibleBlockController(const CompressibleBlockController& model) > : Observable(ptr_m), > compressible_m(!Pooma::neverCompress()), > + viewcount_m(0), > dataObject_m(model.dataObject_m.affinity()), > ! size_m(model.size_m), > ! ucOffset_m(model.ucOffset_m) > { > // Lock the model while we get information pertaining to it > // being compressed or not (such data can't be initialized in > Index: Engine/CompressibleBrick.cpp > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v > retrieving revision 1.24 > diff -c -p -r1.24 CompressibleBrick.cpp > *** Engine/CompressibleBrick.cpp 2000/07/11 23:06:40 1.24 > --- Engine/CompressibleBrick.cpp 2001/05/11 02:37:13 > *************** Engine(const Engine *** 501,506 **** > --- 501,542 ---- > > //----------------------------------------------------------------------------- > // > + // Engine & makeOwnCopy() > + // > + // Causes the CompressibleBrickView-Engine to obtain a private copy of the data > + // that it refers to. > + // > + //----------------------------------------------------------------------------- > + > + template > + Engine &Engine::makeOwnCopy() > + { > + // JIM: This is probably not thread safe??? > + // There is a race from checking isShared to getting into cblock's > + // makeOwnCopy, which is thread safe. As a result, this should only > + // be called after a blockAndEvaluate() to ensure that nobody else > + // is messing with the underlying CBC while this is > + // occuring. (Logically, this is necessary anyway since you probably > + // want a copy of the data that results from all previous > + // computations having taken place.) Also, as mentioned elsewhere, > + // the current implementation results in copying uncompressed data > + // in the parse thread, which will result in incorrect memory > + // affinity. > + > + if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) > + { > + cblock_m.detach(this); > + cblock_m.makeOwnCopy(); > + cblock_m.attach(this); > + > + data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); > + } > + > + return *this; > + } > + > + //----------------------------------------------------------------------------- > + // > // Engine:: > // elementsCompressed() const > // > Index: Engine/CompressibleBrick.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v > retrieving revision 1.67 > diff -c -p -r1.67 CompressibleBrick.h > *** Engine/CompressibleBrick.h 2000/07/11 23:06:40 1.67 > --- Engine/CompressibleBrick.h 2001/05/11 02:37:14 > *************** public: > *** 237,242 **** > --- 237,250 ---- > > inline Layout_t layout() const { return Layout_t(domain_m); } > > + //--------------------------------------------------------------------------- > + // Return the domain and base domain. > + > + inline const Domain_t &domain() const > + { > + return layout().domain(); > + } > + > // Get a private copy of data viewed by this Engine. > > Engine_t &makeOwnCopy(); > *************** public: > *** 557,562 **** > --- 565,582 ---- > ElementRef_t operator()(const Loc &) const; > Element_t read(const Loc &) const; > > + //--------------------------------------------------------------------------- > + // Return the domain and base domain. > + > + inline const Domain_t &domain() const > + { > + return Layout_t(domain_m).domain(); > + } > + > + // Get a private copy of data viewed by this Engine. > + > + Engine_t &makeOwnCopy(); > + > // Return the block controller (uncompressed). > // See comments in CompressibleBrick above. > > *************** struct NewEngine *** 801,806 **** > --- 821,831 ---- > template > struct ElementProperties > > : public MakeOwnCopyProperties > > + { }; > + > + template > + struct ElementProperties > > + : public MakeOwnCopyProperties > > { }; > > > Index: Layout/Node.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v > retrieving revision 1.35 > diff -c -p -r1.35 Node.h > *** Layout/Node.h 2001/05/04 15:41:28 1.35 > --- Layout/Node.h 2001/05/11 02:37:15 > *************** public: > *** 121,128 **** > Node(const Domain_t &owned, const AllocatedDomain_t &allocated, > Context_t c, ID_t gid, ID_t lid = (-1)) > : domain_m(owned), allocated_m(allocated), > ! context_m(c), global_m(gid), local_m(lid), > ! affinity_m(-1) > { > PAssert(owned.size() >= 0); > PAssert(allocated.size() >= 0); > --- 121,128 ---- > Node(const Domain_t &owned, const AllocatedDomain_t &allocated, > Context_t c, ID_t gid, ID_t lid = (-1)) > : domain_m(owned), allocated_m(allocated), > ! local_m(lid), global_m(gid), > ! context_m(c), affinity_m(-1) > { > PAssert(owned.size() >= 0); > PAssert(allocated.size() >= 0); > *************** public: > *** 130,137 **** > } > > Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), > ! affinity_m(-1) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > --- 130,138 ---- > } > > Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), > ! local_m(lid), global_m(gid), > ! context_m(c), affinity_m(-1) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > *************** public: > *** 152,159 **** > > Node(int affinity, const Domain_t &d, > Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), > ! affinity_m(affinity) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > --- 153,161 ---- > > Node(int affinity, const Domain_t &d, > Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), > ! local_m(lid), global_m(gid), > ! context_m(c), affinity_m(affinity) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > *************** public: > *** 172,180 **** > > template > Node(const Node &n) > ! : domain_m(n.domain()), context_m(n.context()), allocated_m(n.allocated()), > ! global_m(n.globalID()), local_m(n.localID()), > ! affinity_m(n.affinity()) > { > } > > --- 174,182 ---- > > template > Node(const Node &n) > ! : domain_m(n.domain()), allocated_m(n.allocated()), > ! local_m(n.localID()), global_m(n.globalID()), > ! context_m(n.context()), affinity_m(n.affinity()) > { > } > > Index: NewField/FieldEngine/FieldEngine.NoGeometry.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v > retrieving revision 1.4 > diff -c -p -r1.4 FieldEngine.NoGeometry.h > *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 > --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/11 02:37:15 > *************** public: > *** 254,267 **** > // This field-engine always has vert-centering and the total domain is > // given by the engine. > > ! inline const Domain_t &physicalCellDomain() const > { > ! return shrink(physicalDomain(), 1); > } > > inline Domain_t totalCellDomain() const > { > ! return shrink(engine_m.domain(), 1); > } > > Domain_t physicalDomain() const > --- 254,267 ---- > // This field-engine always has vert-centering and the total domain is > // given by the engine. > > ! inline const Domain_t physicalCellDomain() const > { > ! return shrinkRight(physicalDomain(), 1); > } > > inline Domain_t totalCellDomain() const > { > ! return shrinkRight(engine_m.domain(), 1); > } > > Domain_t physicalDomain() const From stephens at proximation.com Fri May 11 21:45:19 2001 From: stephens at proximation.com (Stephen Smith) Date: Fri, 11 May 2001 14:45:19 -0700 Subject: [pooma-dev] Problem trying to build parallel application Message-ID: I looked into this problem this afternoon. There are currently no field tests that use makeOwnCopy(). I added a test and the appropriate member functions in Remote Engine, but the code fails to produce a separate copy. I'll talk to Jim on Monday. Since he wrote the code that implements reference copying and shallow copies, he can probably find the problem quicker than I can. Stephen -----Original Message----- From: Dave Nystrom [mailto:wdn at lanl.gov] Sent: Friday, May 11, 2001 1:36 PM To: Jeffrey Oldham Cc: Dave Nystrom; pooma-dev Subject: Re: [pooma-dev] Problem trying to build parallel application Jeffrey Oldham writes: > Perhaps yesterday's patch does resolve the makeOwnCopy() > difficulty you experienced. Will you please try it again? I do not > know where the source code is located to test it myself. Have you committed your changes yet? I have not seen them committed yet. When you commit them, I can check them out and try them. I don't know how to deal with patches - if it is easy and you can tell me how to use your patch, I'd be happy to try it. Dave > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > > On Wed, May 09, 2001 at 02:19:58PM -0600, Dave Nystrom wrote: > > Hi Guys, > > > > I'm trying to build a parallel version of our application under RH Linux 6.2 > > using KCC-4.0d and am having compile problems. Below is part of the build > > log. Could someone take a look at this and see what the problem is? I think > > Stephen Smith might be a likely candidate. > > > > -- > > Dave Nystrom email: wdn at lanl.gov > > LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > > > > ---------------------------build-log------------------------------------- > > cd /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/ > > date; /usr/bin/time -p make RECURSE=1 PASS=MPI1 app > > > > Setting csh aliases for Blanca source environment v 4.0 on host: mutley > > Wed May 9 12:31:34 MDT 2001 > > COPYING... /usr/projects/blanca/packages/TecFramework/TecFramework_src/Main/main.cc to /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc > > > > COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o_ MPI1.info > > > > KCC -c /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/ include/DemoPCH.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o. depend.mk.temp --diag_suppress 630 --create_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSup portBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBas eClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Inte gration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NO EX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug > > > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src /include/DemoPCH.cc": creating precompiled header file "/scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch" > > real 26.25 > > user 14.68 > > sys 4.94 > > > > Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o > > > > COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o_MPI1.info > > > > KCC -c /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o.depend.mk.temp --diag_suppress 630 --COMPDO_fe_cc2c --pch_ignore_dir --use_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSup portBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBas eClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Inte gration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NO EX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug > > > > real 12.92 > > user 4.74 > > sys 0.56 > > > > Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o > > > > .........Stuff Deleted............ > > > > KCC -o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.s o --COMPO_ln -Wl,-noinhibit-exec --no_exceptions --parallel_build 1 /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ HydrodynamicsGroup.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ CompatibleHydro/SymmetryRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ CompatibleHydro/CompatibleRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ CompatibleHydro/Commands/LagRadialVelocity.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ CompatibleHydro/Commands/SetBrickCoordinates.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ CompatibleHydro/Commands/SetFieldValues.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ CompatibleHydro/Commands/SetVertexPoints.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ EOS/GammaLaw.o /scratch/wdn/obj_4.0/PHYSICSSUPPORTBETA/LINUX_KCC_CART_XYZ_MPI/libphysicssup portbeta.so /scratch/wdn/obj_4.0/PHYSICSBASECLASSES/LINUX_KCC_CART_XYZ_MPI/libphysicsbas eclasses.so /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_MPI/libpooma2integ ration.so /usr/projects/blanca/packages/TecFramework/lib/TECFRAMEWORK/LINUX_KCC_DEBUG_ SHARED_NOEX/libtecframework.so /usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations/lib/ POOMA2INSTANTIATIONS/LINUX_KCC_DEBUG_CHEETAH_SHARED_NOEX/libpooma2instantiat ions.so /usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations/lib/STL INSTANTIATIONS/LINUX_KCC_DEBUG_SHARED_NOEX/libstlinstantiations.so /usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX/li bpooma.a > > > > cd "/home/wdn/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo" > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: > > class "Engine<1, poomalote::Real, Remote>" has no > > member "makeOwnCopy" > > data()[i].makeOwnCopy(); > > ^ > > detected during: > > instantiation of "Engine > PatchTag>>::Engine_t &Engine > MultiPatch>::makeOwnCopy() [with > > Dim=1, T=poomalote::Real, LayoutTag=GridTag, > > PatchTag=Remote]" at line 482 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eldEngine/FieldEngineBase.h" > > instantiation of "void FieldEngineBase > EngineTag>::makeOwnCopy(const Subject &) [with Dim=1, > > T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag, > > Subject=Field > malote::DefaultTraits>>::MeshTag, poomalote::Real, > > poomalote::ModelTraits > tTraits>>::EngineTag>]" at line 983 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eld.h" > > instantiation of "void Field > EngineTag>::makeOwnCopy() [with > > GeometryTag=poomalote::ModelTraits > lote::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag]" at line 69 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > > lasses/MMField.t.hh" > > instantiation of "void > > PhysicsBaseClasses::matMMWeightedAverage(const Field > T1, E1> &, const Field > EngineTag> &, const Field &, bool) [with > > MeshTag=poomalote::ModelTraits > ::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag]" at line 579 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > > leRelations.t.hh" > > instantiation of "void > > Hydrodynamics::CompatibleRelations::calcAvgQuanti > > ty(const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &) [with > > Traits=poomalote::OneDF]" > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: > > class "Engine<2, poomalote::Real, Remote>" has no > > member "makeOwnCopy" > > data()[i].makeOwnCopy(); > > ^ > > detected during: > > instantiation of "Engine > PatchTag>>::Engine_t &Engine > MultiPatch>::makeOwnCopy() [with > > Dim=2, T=poomalote::Real, LayoutTag=GridTag, > > PatchTag=Remote]" at line 482 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eldEngine/FieldEngineBase.h" > > instantiation of "void FieldEngineBase > EngineTag>::makeOwnCopy(const Subject &) [with Dim=2, > > T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag, > > Subject=Field > malote::DefaultTraits>>::MeshTag, poomalote::Real, > > poomalote::ModelTraits > tTraits>>::EngineTag>]" at line 983 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eld.h" > > instantiation of "void Field > EngineTag>::makeOwnCopy() [with > > GeometryTag=poomalote::ModelTraits > lote::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag]" at line 69 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > > lasses/MMField.t.hh" > > instantiation of "void > > PhysicsBaseClasses::matMMWeightedAverage(const Field > T1, E1> &, const Field > EngineTag> &, const Field &, bool) [with > > MeshTag=poomalote::ModelTraits > ::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > te::DefaultTraits>>::EngineTag]" at line 579 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > > leRelations.t.hh" > > instantiation of "void > > Hydrodynamics::CompatibleRelations::calcAvgQuanti > > ty(const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &) [with > > Traits=poomalote::TwoDF]" > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: > > class "Engine<3, poomalote::Real, Remote>" has no > > member "makeOwnCopy" > > data()[i].makeOwnCopy(); > > ^ > > detected during: > > instantiation of "Engine > PatchTag>>::Engine_t &Engine > MultiPatch>::makeOwnCopy() [with > > Dim=3, T=poomalote::Real, LayoutTag=GridTag, > > PatchTag=Remote]" at line 482 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eldEngine/FieldEngineBase.h" > > instantiation of "void FieldEngineBase > EngineTag>::makeOwnCopy(const Subject &) [with Dim=3, > > T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > lote::DefaultTraits>>::EngineTag, > > Subject=Field > oomalote::DefaultTraits>>::MeshTag, poomalote::Real, > > poomalote::ModelTraits > ultTraits>>::EngineTag>]" at line 983 of > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > eld.h" > > instantiation of "void Field > EngineTag>::makeOwnCopy() [with > > GeometryTag=poomalote::ModelTraits > malote::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > lote::DefaultTraits>>::EngineTag]" at line 69 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > > lasses/MMField.t.hh" > > instantiation of "void > > PhysicsBaseClasses::matMMWeightedAverage(const Field > T1, E1> &, const Field > EngineTag> &, const Field &, bool) [with > > MeshTag=poomalote::ModelTraits > te::DefaultTraits>>::MeshTag, T=poomalote::Real, > > EngineTag=poomalote::ModelTraits > lote::DefaultTraits>>::EngineTag]" at line 579 of > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > > leRelations.t.hh" > > instantiation of "void > > Hydrodynamics::CompatibleRelations::calcAvgQuanti > > ty(const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &, const > > Hydrodynamics::CompatibleRelations::ScalarField > > &) [with > > Traits=poomalote::ThreeDF]" > > > > 3 errors detected in the compilation of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics/Hydr odynamics_src/CompatibleHydro/CompatibleRelations.cc". > > driver: Compilation failed. > > Recompiling /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ CompatibleHydro/CompatibleRelations.o > > Error: Unable to recompile /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ CompatibleHydro/CompatibleRelations.o. > > Command exited with non-zero status 2 > > real 279.50 > > user 0.28 > > sys 0.01 > > mv: /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.s o: No such file or directory > > make[1]: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics. so] Error 1 > > make: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics. so] Error 2 > > Command exited with non-zero status 2 > > real 5983.14 > > user 2052.11 > > sys 160.74 > > > > Compilation exited abnormally with code 2 at Wed May 9 14:11:17 > > -- > Jeffrey D. Oldham > oldham at codesourcery.comIndex: Array/Array.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v > retrieving revision 1.139 > diff -c -p -r1.139 Array.h > *** Array/Array.h 2001/04/20 21:16:23 1.139 > --- Array/Array.h 2001/05/11 02:37:11 > *************** > *** 29,34 **** > --- 29,35 ---- > //-------------------------------------------------------------------------- --- > // Classes: > // Array > + // View0 > // View[1-7] > // LeafFunctor > // LeafFunctor > > *************** public: > *** 1763,1773 **** > inline Domain_t domain() const > { > return engine_m.domain(); > - } > - > - inline Domain_t innerDomain() const > - { > - return engine_m.innerDomain(); > } > > inline Domain_t physicalDomain() const > --- 1764,1769 ---- > Index: Engine/CompressibleBlock.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v > retrieving revision 1.27 > diff -c -p -r1.27 CompressibleBlock.h > *** Engine/CompressibleBlock.h 2000/07/11 22:13:00 1.27 > --- Engine/CompressibleBlock.h 2001/05/11 02:37:13 > *************** private: > *** 531,541 **** > > CompressibleBlockController(const CompressibleBlockController& model) > : Observable(ptr_m), > - size_m(model.size_m), > compressible_m(!Pooma::neverCompress()), > dataObject_m(model.dataObject_m.affinity()), > ! ucOffset_m(model.ucOffset_m), > ! viewcount_m(0) > { > // Lock the model while we get information pertaining to it > // being compressed or not (such data can't be initialized in > --- 531,541 ---- > > CompressibleBlockController(const CompressibleBlockController& model) > : Observable(ptr_m), > compressible_m(!Pooma::neverCompress()), > + viewcount_m(0), > dataObject_m(model.dataObject_m.affinity()), > ! size_m(model.size_m), > ! ucOffset_m(model.ucOffset_m) > { > // Lock the model while we get information pertaining to it > // being compressed or not (such data can't be initialized in > Index: Engine/CompressibleBrick.cpp > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v > retrieving revision 1.24 > diff -c -p -r1.24 CompressibleBrick.cpp > *** Engine/CompressibleBrick.cpp 2000/07/11 23:06:40 1.24 > --- Engine/CompressibleBrick.cpp 2001/05/11 02:37:13 > *************** Engine(const Engine *** 501,506 **** > --- 501,542 ---- > > //-------------------------------------------------------------------------- --- > // > + // Engine & makeOwnCopy() > + // > + // Causes the CompressibleBrickView-Engine to obtain a private copy of the data > + // that it refers to. > + // > + //-------------------------------------------------------------------------- --- > + > + template > + Engine &Engine::makeOwnCopy() > + { > + // JIM: This is probably not thread safe??? > + // There is a race from checking isShared to getting into cblock's > + // makeOwnCopy, which is thread safe. As a result, this should only > + // be called after a blockAndEvaluate() to ensure that nobody else > + // is messing with the underlying CBC while this is > + // occuring. (Logically, this is necessary anyway since you probably > + // want a copy of the data that results from all previous > + // computations having taken place.) Also, as mentioned elsewhere, > + // the current implementation results in copying uncompressed data > + // in the parse thread, which will result in incorrect memory > + // affinity. > + > + if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) > + { > + cblock_m.detach(this); > + cblock_m.makeOwnCopy(); > + cblock_m.attach(this); > + > + data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); > + } > + > + return *this; > + } > + > + //-------------------------------------------------------------------------- --- > + // > // Engine:: > // elementsCompressed() const > // > Index: Engine/CompressibleBrick.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v > retrieving revision 1.67 > diff -c -p -r1.67 CompressibleBrick.h > *** Engine/CompressibleBrick.h 2000/07/11 23:06:40 1.67 > --- Engine/CompressibleBrick.h 2001/05/11 02:37:14 > *************** public: > *** 237,242 **** > --- 237,250 ---- > > inline Layout_t layout() const { return Layout_t(domain_m); } > > + //-------------------------------------------------------------------------- - > + // Return the domain and base domain. > + > + inline const Domain_t &domain() const > + { > + return layout().domain(); > + } > + > // Get a private copy of data viewed by this Engine. > > Engine_t &makeOwnCopy(); > *************** public: > *** 557,562 **** > --- 565,582 ---- > ElementRef_t operator()(const Loc &) const; > Element_t read(const Loc &) const; > > + //-------------------------------------------------------------------------- - > + // Return the domain and base domain. > + > + inline const Domain_t &domain() const > + { > + return Layout_t(domain_m).domain(); > + } > + > + // Get a private copy of data viewed by this Engine. > + > + Engine_t &makeOwnCopy(); > + > // Return the block controller (uncompressed). > // See comments in CompressibleBrick above. > > *************** struct NewEngine *** 801,806 **** > --- 821,831 ---- > template > struct ElementProperties > > : public MakeOwnCopyProperties > > + { }; > + > + template > + struct ElementProperties > > + : public MakeOwnCopyProperties > > { }; > > > Index: Layout/Node.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v > retrieving revision 1.35 > diff -c -p -r1.35 Node.h > *** Layout/Node.h 2001/05/04 15:41:28 1.35 > --- Layout/Node.h 2001/05/11 02:37:15 > *************** public: > *** 121,128 **** > Node(const Domain_t &owned, const AllocatedDomain_t &allocated, > Context_t c, ID_t gid, ID_t lid = (-1)) > : domain_m(owned), allocated_m(allocated), > ! context_m(c), global_m(gid), local_m(lid), > ! affinity_m(-1) > { > PAssert(owned.size() >= 0); > PAssert(allocated.size() >= 0); > --- 121,128 ---- > Node(const Domain_t &owned, const AllocatedDomain_t &allocated, > Context_t c, ID_t gid, ID_t lid = (-1)) > : domain_m(owned), allocated_m(allocated), > ! local_m(lid), global_m(gid), > ! context_m(c), affinity_m(-1) > { > PAssert(owned.size() >= 0); > PAssert(allocated.size() >= 0); > *************** public: > *** 130,137 **** > } > > Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), > ! affinity_m(-1) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > --- 130,138 ---- > } > > Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), > ! local_m(lid), global_m(gid), > ! context_m(c), affinity_m(-1) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > *************** public: > *** 152,159 **** > > Node(int affinity, const Domain_t &d, > Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), > ! affinity_m(affinity) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > --- 153,161 ---- > > Node(int affinity, const Domain_t &d, > Context_t c, ID_t gid, ID_t lid = (-1)) > ! : domain_m(d), allocated_m(d), > ! local_m(lid), global_m(gid), > ! context_m(c), affinity_m(affinity) > { > PAssert(d.size() >= 0); > PAssert(gid >= 0); > *************** public: > *** 172,180 **** > > template > Node(const Node &n) > ! : domain_m(n.domain()), context_m(n.context()), allocated_m(n.allocated()), > ! global_m(n.globalID()), local_m(n.localID()), > ! affinity_m(n.affinity()) > { > } > > --- 174,182 ---- > > template > Node(const Node &n) > ! : domain_m(n.domain()), allocated_m(n.allocated()), > ! local_m(n.localID()), global_m(n.globalID()), > ! context_m(n.context()), affinity_m(n.affinity()) > { > } > > Index: NewField/FieldEngine/FieldEngine.NoGeometry.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h, v > retrieving revision 1.4 > diff -c -p -r1.4 FieldEngine.NoGeometry.h > *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 > --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/11 02:37:15 > *************** public: > *** 254,267 **** > // This field-engine always has vert-centering and the total domain is > // given by the engine. > > ! inline const Domain_t &physicalCellDomain() const > { > ! return shrink(physicalDomain(), 1); > } > > inline Domain_t totalCellDomain() const > { > ! return shrink(engine_m.domain(), 1); > } > > Domain_t physicalDomain() const > --- 254,267 ---- > // This field-engine always has vert-centering and the total domain is > // given by the engine. > > ! inline const Domain_t physicalCellDomain() const > { > ! return shrinkRight(physicalDomain(), 1); > } > > inline Domain_t totalCellDomain() const > { > ! return shrinkRight(engine_m.domain(), 1); > } > > Domain_t physicalDomain() const -------------- next part -------------- An HTML attachment was scrubbed... URL: From wdn at lanl.gov Fri May 11 22:07:55 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Fri, 11 May 2001 16:07:55 -0600 (MDT) Subject: [pooma-dev] Problem trying to build parallel application In-Reply-To: References: Message-ID: <15100.25140.467121.117979@mutley.lanl.gov> Thanks. BTW, Stephen, John Hall and I are planning to come down to Proximation on Monday. We'll probably get there around 9-10. John will be coming straight there on his way back from Carlsbad and I will be coming down from Los Alamos. Dave Stephen Smith writes: > I looked into this problem this afternoon. There are currently no > field tests that use makeOwnCopy(). I added a test and the appropriate > member functions in Remote Engine, but the code fails to produce a > separate copy. I'll talk to Jim on Monday. Since he wrote the code > that implements reference copying and shallow copies, he can probably > find the problem quicker than I can. > > Stephen > > -----Original Message----- > From: Dave Nystrom [mailto:wdn at lanl.gov] > Sent: Friday, May 11, 2001 1:36 PM > To: Jeffrey Oldham > Cc: Dave Nystrom; pooma-dev > Subject: Re: [pooma-dev] Problem trying to build parallel application > > > Jeffrey Oldham writes: > > Perhaps yesterday's patch does resolve the makeOwnCopy() > > difficulty you experienced. Will you please try it again? I do not > > know where the source code is located to test it myself. > > Have you committed your changes yet? I have not seen them committed yet. > When you commit them, I can check them out and try them. I don't know how > to > deal with patches - if it is easy and you can tell me how to use your patch, > I'd be happy to try it. > > Dave > > > Thanks, > > Jeffrey D. Oldham > > oldham at codesourcery.com > > > > On Wed, May 09, 2001 at 02:19:58PM -0600, Dave Nystrom wrote: > > > Hi Guys, > > > > > > I'm trying to build a parallel version of our application under RH > Linux 6.2 > > > using KCC-4.0d and am having compile problems. Below is part of the > build > > > log. Could someone take a look at this and see what the problem is? I > think > > > Stephen Smith might be a likely candidate. > > > > > > -- > > > Dave Nystrom email: wdn at lanl.gov > > > LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > > > > > > > ---------------------------build-log------------------------------------- > > > cd /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/ > > > date; /usr/bin/time -p make RECURSE=1 PASS=MPI1 app > > > > > > Setting csh aliases for Blanca source environment v 4.0 on host: mutley > > > Wed May 9 12:31:34 MDT 2001 > > > COPYING... > /usr/projects/blanca/packages/TecFramework/TecFramework_src/Main/main.cc to > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc > > > > > > COMPILING... See > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o_ > MPI1.info > > > > > > KCC -c > /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/ > include/DemoPCH.cc -o > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o > --output_dependencies > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o. > depend.mk.temp --diag_suppress 630 --create_pch > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch > -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS > -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES > -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK > -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA > -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION > -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX > -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST > -DTEC_USE_PCH > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSup > portBeta > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBas > eClasses > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Inte > gration -I/usr/projects/blanca/packages/TecFramework > -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations > -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations > -I/usr/projects/blanca/packages/PoomaII/r2/src > -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX > -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src > -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NO > EX -I/home/wdn/packages/mpich-1.2.1/include > -I/usr/projects/blanca/packages/mm-1.1.1/include > -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic > --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug > > > > > > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src > /include/DemoPCH.cc": creating precompiled header file > "/scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch" > > > real 26.25 > > > user 14.68 > > > sys 4.94 > > > > > > Done compiling > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o > > > > > > COMPILING... See > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o_MPI1.info > > > > > > KCC -c /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc -o > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o > --output_dependencies > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o.depend.mk.temp > --diag_suppress 630 --COMPDO_fe_cc2c --pch_ignore_dir --use_pch > /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch > -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS > -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES > -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK > -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA > -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION > -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX > -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST > -DTEC_USE_PCH > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSup > portBeta > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBas > eClasses > -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Inte > gration -I/usr/projects/blanca/packages/TecFramework > -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations > -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations > -I/usr/projects/blanca/packages/PoomaII/r2/src > -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX > -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src > -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NO > EX -I/home/wdn/packages/mpich-1.2.1/include > -I/usr/projects/blanca/packages/mm-1.1.1/include > -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic > --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug > > > > > > real 12.92 > > > user 4.74 > > > sys 0.56 > > > > > > Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o > > > > > > .........Stuff Deleted............ > > > > > > KCC -o > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.s > o --COMPO_ln -Wl,-noinhibit-exec --no_exceptions --parallel_build 1 > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > HydrodynamicsGroup.o > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > CompatibleHydro/SymmetryRelations.o > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > CompatibleHydro/CompatibleRelations.o > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > CompatibleHydro/Commands/LagRadialVelocity.o > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > CompatibleHydro/Commands/SetBrickCoordinates.o > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > CompatibleHydro/Commands/SetFieldValues.o > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > CompatibleHydro/Commands/SetVertexPoints.o > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > EOS/GammaLaw.o > /scratch/wdn/obj_4.0/PHYSICSSUPPORTBETA/LINUX_KCC_CART_XYZ_MPI/libphysicssup > portbeta.so > /scratch/wdn/obj_4.0/PHYSICSBASECLASSES/LINUX_KCC_CART_XYZ_MPI/libphysicsbas > eclasses.so > /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_MPI/libpooma2integ > ration.so > /usr/projects/blanca/packages/TecFramework/lib/TECFRAMEWORK/LINUX_KCC_DEBUG_ > SHARED_NOEX/libtecframework.so > /usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations/lib/ > POOMA2INSTANTIATIONS/LINUX_KCC_DEBUG_CHEETAH_SHARED_NOEX/libpooma2instantiat > ions.so > /usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations/lib/STL > INSTANTIATIONS/LINUX_KCC_DEBUG_SHARED_NOEX/libstlinstantiations.so > /usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX/li > bpooma.a > > > > > > cd "/home/wdn/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo" > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", > line 252: error #135: > > > class "Engine<1, poomalote::Real, Remote>" > has no > > > member "makeOwnCopy" > > > data()[i].makeOwnCopy(); > > > ^ > > > detected during: > > > instantiation of "Engine > > PatchTag>>::Engine_t &Engine > > MultiPatch>::makeOwnCopy() > [with > > > Dim=1, T=poomalote::Real, LayoutTag=GridTag, > > > PatchTag=Remote]" at line 482 > of > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > > eldEngine/FieldEngineBase.h" > > > instantiation of "void FieldEngineBase > > EngineTag>::makeOwnCopy(const Subject &) [with > Dim=1, > > > T=poomalote::Real, > > > > EngineTag=poomalote::ModelTraits > > te::DefaultTraits>>::EngineTag, > > > > Subject=Field > > malote::DefaultTraits>>::MeshTag, > poomalote::Real, > > > > poomalote::ModelTraits > > tTraits>>::EngineTag>]" at line 983 of > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > > eld.h" > > > instantiation of "void Field > > EngineTag>::makeOwnCopy() [with > > > > GeometryTag=poomalote::ModelTraits > > lote::DefaultTraits>>::MeshTag, > T=poomalote::Real, > > > > EngineTag=poomalote::ModelTraits > > te::DefaultTraits>>::EngineTag]" at line 69 of > > > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > > > > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > > > lasses/MMField.t.hh" > > > instantiation of "void > > > PhysicsBaseClasses::matMMWeightedAverage(const > Field > > T1, E1> &, const Field > > EngineTag> &, const Field &, bool) > [with > > > > MeshTag=poomalote::ModelTraits > > ::DefaultTraits>>::MeshTag, T=poomalote::Real, > > > > EngineTag=poomalote::ModelTraits > > te::DefaultTraits>>::EngineTag]" at line 579 of > > > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > > > > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > > > leRelations.t.hh" > > > instantiation of "void > > > > Hydrodynamics::CompatibleRelations::calcAvgQuanti > > > ty(const > > > > Hydrodynamics::CompatibleRelations::ScalarField > > > &, const > > > > Hydrodynamics::CompatibleRelations::ScalarField > > > &, const > > > > Hydrodynamics::CompatibleRelations::ScalarField > > > &) [with > > > > Traits=poomalote::OneDF]" > > > > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", > line 252: error #135: > > > class "Engine<2, poomalote::Real, Remote>" > has no > > > member "makeOwnCopy" > > > data()[i].makeOwnCopy(); > > > ^ > > > detected during: > > > instantiation of "Engine > > PatchTag>>::Engine_t &Engine > > MultiPatch>::makeOwnCopy() > [with > > > Dim=2, T=poomalote::Real, LayoutTag=GridTag, > > > PatchTag=Remote]" at line 482 > of > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > > eldEngine/FieldEngineBase.h" > > > instantiation of "void FieldEngineBase > > EngineTag>::makeOwnCopy(const Subject &) [with > Dim=2, > > > T=poomalote::Real, > > > > EngineTag=poomalote::ModelTraits > > te::DefaultTraits>>::EngineTag, > > > > Subject=Field > > malote::DefaultTraits>>::MeshTag, > poomalote::Real, > > > > poomalote::ModelTraits > > tTraits>>::EngineTag>]" at line 983 of > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > > eld.h" > > > instantiation of "void Field > > EngineTag>::makeOwnCopy() [with > > > > GeometryTag=poomalote::ModelTraits > > lote::DefaultTraits>>::MeshTag, > T=poomalote::Real, > > > > EngineTag=poomalote::ModelTraits > > te::DefaultTraits>>::EngineTag]" at line 69 of > > > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > > > > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > > > lasses/MMField.t.hh" > > > instantiation of "void > > > PhysicsBaseClasses::matMMWeightedAverage(const > Field > > T1, E1> &, const Field > > EngineTag> &, const Field &, bool) > [with > > > > MeshTag=poomalote::ModelTraits > > ::DefaultTraits>>::MeshTag, T=poomalote::Real, > > > > EngineTag=poomalote::ModelTraits > > te::DefaultTraits>>::EngineTag]" at line 579 of > > > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > > > > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > > > leRelations.t.hh" > > > instantiation of "void > > > > Hydrodynamics::CompatibleRelations::calcAvgQuanti > > > ty(const > > > > Hydrodynamics::CompatibleRelations::ScalarField > > > &, const > > > > Hydrodynamics::CompatibleRelations::ScalarField > > > &, const > > > > Hydrodynamics::CompatibleRelations::ScalarField > > > &) [with > > > > Traits=poomalote::TwoDF]" > > > > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", > line 252: error #135: > > > class "Engine<3, poomalote::Real, Remote>" > has no > > > member "makeOwnCopy" > > > data()[i].makeOwnCopy(); > > > ^ > > > detected during: > > > instantiation of "Engine > > PatchTag>>::Engine_t &Engine > > MultiPatch>::makeOwnCopy() > [with > > > Dim=3, T=poomalote::Real, LayoutTag=GridTag, > > > PatchTag=Remote]" at line 482 > of > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > > eldEngine/FieldEngineBase.h" > > > instantiation of "void FieldEngineBase > > EngineTag>::makeOwnCopy(const Subject &) [with > Dim=3, > > > T=poomalote::Real, > > > > EngineTag=poomalote::ModelTraits > > lote::DefaultTraits>>::EngineTag, > > > > Subject=Field > > oomalote::DefaultTraits>>::MeshTag, > poomalote::Real, > > > > poomalote::ModelTraits > > ultTraits>>::EngineTag>]" at line 983 of > > > > "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi > > > eld.h" > > > instantiation of "void Field > > EngineTag>::makeOwnCopy() [with > > > > GeometryTag=poomalote::ModelTraits > > malote::DefaultTraits>>::MeshTag, > T=poomalote::Real, > > > > EngineTag=poomalote::ModelTraits > > lote::DefaultTraits>>::EngineTag]" at line 69 of > > > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo > > > > rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC > > > lasses/MMField.t.hh" > > > instantiation of "void > > > PhysicsBaseClasses::matMMWeightedAverage(const > Field > > T1, E1> &, const Field > > EngineTag> &, const Field &, bool) > [with > > > > MeshTag=poomalote::ModelTraits > > te::DefaultTraits>>::MeshTag, T=poomalote::Real, > > > > EngineTag=poomalote::ModelTraits > > lote::DefaultTraits>>::EngineTag]" at line 579 of > > > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer > > > > /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib > > > leRelations.t.hh" > > > instantiation of "void > > > > Hydrodynamics::CompatibleRelations::calcAvgQuanti > > > ty(const > > > > Hydrodynamics::CompatibleRelations::ScalarField > > > &, const > > > > Hydrodynamics::CompatibleRelations::ScalarField > > > &, const > > > > Hydrodynamics::CompatibleRelations::ScalarField > > > &) [with > > > > Traits=poomalote::ThreeDF]" > > > > > > 3 errors detected in the compilation of > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics/Hydr > odynamics_src/CompatibleHydro/CompatibleRelations.cc". > > > driver: Compilation failed. > > > Recompiling > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > CompatibleHydro/CompatibleRelations.o > > > Error: Unable to recompile > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/ > CompatibleHydro/CompatibleRelations.o. > > > Command exited with non-zero status 2 > > > real 279.50 > > > user 0.28 > > > sys 0.01 > > > mv: > /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.s > o: No such file or directory > > > make[1]: *** > [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics. > so] Error 1 > > > make: *** > [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics. > so] Error 2 > > > Command exited with non-zero status 2 > > > real 5983.14 > > > user 2052.11 > > > sys 160.74 > > > > > > Compilation exited abnormally with code 2 at Wed May 9 14:11:17 > > > > -- > > Jeffrey D. Oldham > > oldham at codesourcery.comIndex: Array/Array.h > > =================================================================== > > RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v > > retrieving revision 1.139 > > diff -c -p -r1.139 Array.h > > *** Array/Array.h 2001/04/20 21:16:23 1.139 > > --- Array/Array.h 2001/05/11 02:37:11 > > *************** > > *** 29,34 **** > > --- 29,35 ---- > > > //-------------------------------------------------------------------------- > --- > > // Classes: > > // Array > > + // View0 > > // View[1-7] > > // LeafFunctor > > // LeafFunctor > > > *************** public: > > *** 1763,1773 **** > > inline Domain_t domain() const > > { > > return engine_m.domain(); > > - } > > - > > - inline Domain_t innerDomain() const > > - { > > - return engine_m.innerDomain(); > > } > > > > inline Domain_t physicalDomain() const > > --- 1764,1769 ---- > > Index: Engine/CompressibleBlock.h > > =================================================================== > > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v > > retrieving revision 1.27 > > diff -c -p -r1.27 CompressibleBlock.h > > *** Engine/CompressibleBlock.h 2000/07/11 22:13:00 1.27 > > --- Engine/CompressibleBlock.h 2001/05/11 02:37:13 > > *************** private: > > *** 531,541 **** > > > > CompressibleBlockController(const CompressibleBlockController& > model) > > : Observable(ptr_m), > > - size_m(model.size_m), > > compressible_m(!Pooma::neverCompress()), > > dataObject_m(model.dataObject_m.affinity()), > > ! ucOffset_m(model.ucOffset_m), > > ! viewcount_m(0) > > { > > // Lock the model while we get information pertaining to it > > // being compressed or not (such data can't be initialized in > > --- 531,541 ---- > > > > CompressibleBlockController(const CompressibleBlockController& > model) > > : Observable(ptr_m), > > compressible_m(!Pooma::neverCompress()), > > + viewcount_m(0), > > dataObject_m(model.dataObject_m.affinity()), > > ! size_m(model.size_m), > > ! ucOffset_m(model.ucOffset_m) > > { > > // Lock the model while we get information pertaining to it > > // being compressed or not (such data can't be initialized in > > Index: Engine/CompressibleBrick.cpp > > =================================================================== > > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v > > retrieving revision 1.24 > > diff -c -p -r1.24 CompressibleBrick.cpp > > *** Engine/CompressibleBrick.cpp 2000/07/11 23:06:40 1.24 > > --- Engine/CompressibleBrick.cpp 2001/05/11 02:37:13 > > *************** Engine(const Engine > *** 501,506 **** > > --- 501,542 ---- > > > > > //-------------------------------------------------------------------------- > --- > > // > > + // Engine & makeOwnCopy() > > + // > > + // Causes the CompressibleBrickView-Engine to obtain a private copy of > the data > > + // that it refers to. > > + // > > + > //-------------------------------------------------------------------------- > --- > > + > > + template > > + Engine > &Engine::makeOwnCopy() > > + { > > + // JIM: This is probably not thread safe??? > > + // There is a race from checking isShared to getting into cblock's > > + // makeOwnCopy, which is thread safe. As a result, this should only > > + // be called after a blockAndEvaluate() to ensure that nobody else > > + // is messing with the underlying CBC while this is > > + // occuring. (Logically, this is necessary anyway since you probably > > + // want a copy of the data that results from all previous > > + // computations having taken place.) Also, as mentioned elsewhere, > > + // the current implementation results in copying uncompressed data > > + // in the parse thread, which will result in incorrect memory > > + // affinity. > > + > > + if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) > > + { > > + cblock_m.detach(this); > > + cblock_m.makeOwnCopy(); > > + cblock_m.attach(this); > > + > > + data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : > baseOffset()); > > + } > > + > > + return *this; > > + } > > + > > + > //-------------------------------------------------------------------------- > --- > > + // > > // Engine:: > > // elementsCompressed() const > > // > > Index: Engine/CompressibleBrick.h > > =================================================================== > > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v > > retrieving revision 1.67 > > diff -c -p -r1.67 CompressibleBrick.h > > *** Engine/CompressibleBrick.h 2000/07/11 23:06:40 1.67 > > --- Engine/CompressibleBrick.h 2001/05/11 02:37:14 > > *************** public: > > *** 237,242 **** > > --- 237,250 ---- > > > > inline Layout_t layout() const { return Layout_t(domain_m); } > > > > + > //-------------------------------------------------------------------------- > - > > + // Return the domain and base domain. > > + > > + inline const Domain_t &domain() const > > + { > > + return layout().domain(); > > + } > > + > > // Get a private copy of data viewed by this Engine. > > > > Engine_t &makeOwnCopy(); > > *************** public: > > *** 557,562 **** > > --- 565,582 ---- > > ElementRef_t operator()(const Loc &) const; > > Element_t read(const Loc &) const; > > > > + > //-------------------------------------------------------------------------- > - > > + // Return the domain and base domain. > > + > > + inline const Domain_t &domain() const > > + { > > + return Layout_t(domain_m).domain(); > > + } > > + > > + // Get a private copy of data viewed by this Engine. > > + > > + Engine_t &makeOwnCopy(); > > + > > // Return the block controller (uncompressed). > > // See comments in CompressibleBrick above. > > > > *************** struct NewEngine > *** 801,806 **** > > --- 821,831 ---- > > template > > struct ElementProperties > > > : public MakeOwnCopyProperties > > > + { }; > > + > > + template > > + struct ElementProperties > > > + : public MakeOwnCopyProperties > > > > { }; > > > > > > Index: Layout/Node.h > > =================================================================== > > RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v > > retrieving revision 1.35 > > diff -c -p -r1.35 Node.h > > *** Layout/Node.h 2001/05/04 15:41:28 1.35 > > --- Layout/Node.h 2001/05/11 02:37:15 > > *************** public: > > *** 121,128 **** > > Node(const Domain_t &owned, const AllocatedDomain_t &allocated, > > Context_t c, ID_t gid, ID_t lid = (-1)) > > : domain_m(owned), allocated_m(allocated), > > ! context_m(c), global_m(gid), local_m(lid), > > ! affinity_m(-1) > > { > > PAssert(owned.size() >= 0); > > PAssert(allocated.size() >= 0); > > --- 121,128 ---- > > Node(const Domain_t &owned, const AllocatedDomain_t &allocated, > > Context_t c, ID_t gid, ID_t lid = (-1)) > > : domain_m(owned), allocated_m(allocated), > > ! local_m(lid), global_m(gid), > > ! context_m(c), affinity_m(-1) > > { > > PAssert(owned.size() >= 0); > > PAssert(allocated.size() >= 0); > > *************** public: > > *** 130,137 **** > > } > > > > Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) > > ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), > local_m(lid), > > ! affinity_m(-1) > > { > > PAssert(d.size() >= 0); > > PAssert(gid >= 0); > > --- 130,138 ---- > > } > > > > Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) > > ! : domain_m(d), allocated_m(d), > > ! local_m(lid), global_m(gid), > > ! context_m(c), affinity_m(-1) > > { > > PAssert(d.size() >= 0); > > PAssert(gid >= 0); > > *************** public: > > *** 152,159 **** > > > > Node(int affinity, const Domain_t &d, > > Context_t c, ID_t gid, ID_t lid = (-1)) > > ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), > local_m(lid), > > ! affinity_m(affinity) > > { > > PAssert(d.size() >= 0); > > PAssert(gid >= 0); > > --- 153,161 ---- > > > > Node(int affinity, const Domain_t &d, > > Context_t c, ID_t gid, ID_t lid = (-1)) > > ! : domain_m(d), allocated_m(d), > > ! local_m(lid), global_m(gid), > > ! context_m(c), affinity_m(affinity) > > { > > PAssert(d.size() >= 0); > > PAssert(gid >= 0); > > *************** public: > > *** 172,180 **** > > > > template > > Node(const Node &n) > > ! : domain_m(n.domain()), context_m(n.context()), > allocated_m(n.allocated()), > > ! global_m(n.globalID()), local_m(n.localID()), > > ! affinity_m(n.affinity()) > > { > > } > > > > --- 174,182 ---- > > > > template > > Node(const Node &n) > > ! : domain_m(n.domain()), allocated_m(n.allocated()), > > ! local_m(n.localID()), global_m(n.globalID()), > > ! context_m(n.context()), affinity_m(n.affinity()) > > { > > } > > > > Index: NewField/FieldEngine/FieldEngine.NoGeometry.h > > =================================================================== > > RCS file: > /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h, > v > > retrieving revision 1.4 > > diff -c -p -r1.4 FieldEngine.NoGeometry.h > > *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 > 1.4 > > --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/11 02:37:15 > > *************** public: > > *** 254,267 **** > > // This field-engine always has vert-centering and the total domain > is > > // given by the engine. > > > > ! inline const Domain_t &physicalCellDomain() const > > { > > ! return shrink(physicalDomain(), 1); > > } > > > > inline Domain_t totalCellDomain() const > > { > > ! return shrink(engine_m.domain(), 1); > > } > > > > Domain_t physicalDomain() const > > --- 254,267 ---- > > // This field-engine always has vert-centering and the total domain > is > > // given by the engine. > > > > ! inline const Domain_t physicalCellDomain() const > > { > > ! return shrinkRight(physicalDomain(), 1); > > } > > > > inline Domain_t totalCellDomain() const > > { > > ! return shrinkRight(engine_m.domain(), 1); > > } > > > > Domain_t physicalDomain() const > > > > > > RE: [pooma-dev] Problem trying to build parallel application > > > >

I looked into this problem this afternoon.  There are currently no >
field tests that use makeOwnCopy().  I added a test and the appropriate >
member functions in Remote Engine, but the code fails to produce a >
separate copy.  I'll talk to Jim on Monday.  Since he wrote the code >
that implements reference copying and shallow copies, he can probably >
find the problem quicker than I can. >

> >

    Stephen >

> >

-----Original Message----- >
From: Dave Nystrom [mailto:wdn at lanl.gov] >
Sent: Friday, May 11, 2001 1:36 PM >
To: Jeffrey Oldham >
Cc: Dave Nystrom; pooma-dev >
Subject: Re: [pooma-dev] Problem trying to build parallel application >

>
> >

Jeffrey Oldham writes: >
 >      Perhaps yesterday's patch does resolve the makeOwnCopy() >
 > difficulty you experienced.  Will you please try it again?  I do not >
 > know where the source code is located to test it myself. >

> >

Have you committed your changes yet?  I have not seen them committed yet. >
When you commit them, I can check them out and try them.  I don't know how to >
deal with patches - if it is easy and you can tell me how to use your patch, >
I'd be happy to try it. >

> >

Dave >

> >

 > Thanks, >
 > Jeffrey D. Oldham >
 > oldham at codesourcery.com >
 > >
 > On Wed, May 09, 2001 at 02:19:58PM -0600, Dave Nystrom wrote: >
 > > Hi Guys, >
 > > >
 > > I'm trying to build a parallel version of our application under RH Linux 6.2 >
 > > using KCC-4.0d and am having compile problems.  Below is part of the build >
 > > log.  Could someone take a look at this and see what the problem is?  I think >
 > > Stephen Smith might be a likely candidate. >
 > > >
 > > -- >
 > > Dave Nystrom                       email: wdn at lanl.gov >
 > > LANL X-3                   phone: 505-667-7913     fax: 505-665-3046 >
 > > >
 > > ---------------------------build-log------------------------------------- >
 > > cd /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/ >
 > > date; /usr/bin/time -p make RECURSE=1 PASS=MPI1 app >
 > > >
 > > Setting csh aliases for Blanca source environment v 4.0 on host: mutley >
 > > Wed May  9 12:31:34 MDT 2001 >
 > > COPYING... /usr/projects/blanca/packages/TecFramework/TecFramework_src/Main/main.cc to /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc

> >

 > > >
 > > COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o_MPI1.info >
 > > >
 > > KCC -c /usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/include/DemoPCH.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o.depend.mk.temp --diag_suppress 630 --create_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSupportBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBaseClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NOEX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug

> >

 > > >
 > > "/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo/Demo_src/include/DemoPCH.cc": creating precompiled header file "/scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch"

> >

 > > real 26.25 >
 > > user 14.68 >
 > > sys 4.94 >
 > > >
 > > Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/Demo_src/include/DemoPCH.o >
 > > >
 > > COMPILING... See /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o_MPI1.info >
 > > >
 > > KCC -c /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.cc -o /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o --output_dependencies /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o.depend.mk.temp --diag_suppress 630 --COMPDO_fe_cc2c --pch_ignore_dir --use_pch /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/DEMO_MPI1.pch -DTEC_USE_DEMO -DTEC_USE_PHYSICSBETA -DTEC_USE_HYDRODYNAMICS -DTEC_USE_PHYSICSSUPPORTBETA -DTEC_USE_PHYSICSBASECLASSES -DTEC_USE_POOMA2INTEGRATION -DTEC_USE_TECFRAMEWORK -DTEC_USE_POOMA2INSTANTIATIONS -DTEC_USE_STLINSTANTIATIONS -DTEC_USE_POOMA -DTEC_USE_CHEETAH -DTEC_USE_MM -DTEC_USE_PCG -DCART_XYZ -DDOUBLE_PRECISION -DPETE -DV034 -DTEC_NEW_POOMA_COMPRESSION -DTEC_LINUX -DTEC_USING_KCC_DEFINES -DTEC_KCC_INFINITE_COMPILE_TIME -DTEC_INST -DTEC_USE_PCH -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/PhysicsBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsSupportBeta -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSupportLayer/PhysicsBaseClasses -I/usr/projects/blanca/usr/wdn/blanca_src_4.0/TecIntegrationLayer/Pooma2Integration -I/usr/projects/blanca/packages/TecFramework -I/usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations -I/usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations -I/usr/projects/blanca/packages/PoomaII/r2/src -I/usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/src -I/usr/projects/blanca/packages/Cheetah/cheetah-1.0.0/lib/LINUX_KCC_DEBUG_NOEX -I/home/wdn/packages/mpich-1.2.1/include -I/usr/projects/blanca/packages/mm-1.1.1/include -I/usr/projects/blanca/packages/pcg/pcg_f77 --display_error_number -fpic --strict -D__KAI_STRICT --diag_suppress 450 --no_exceptions +K0 --no_kdebug

> >

 > > >
 > > real 12.92 >
 > > user 4.74 >
 > > sys 0.56 >
 > > >
 > > Done compiling /scratch/wdn/obj_4.0/DEMO/LINUX_KCC_CART_XYZ_MPI/main.o >
 > > >
 > > .........Stuff Deleted............ >
 > > >
 > > KCC -o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so --COMPO_ln -Wl,-noinhibit-exec --no_exceptions --parallel_build 1 /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/HydrodynamicsGroup.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/SymmetryRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/LagRadialVelocity.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetBrickCoordinates.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetFieldValues.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/Commands/SetVertexPoints.o /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/EOS/GammaLaw.o /scratch/wdn/obj_4.0/PHYSICSSUPPORTBETA/LINUX_KCC_CART_XYZ_MPI/libphysicssupportbeta.so /scratch/wdn/obj_4.0/PHYSICSBASECLASSES/LINUX_KCC_CART_XYZ_MPI/libphysicsbaseclasses.so /scratch/wdn/obj_4.0/POOMA2INTEGRATION/LINUX_KCC_CART_XYZ_MPI/libpooma2integration.so /usr/projects/blanca/packages/TecFramework/lib/TECFRAMEWORK/LINUX_KCC_DEBUG_SHARED_NOEX/libtecframework.so /usr/projects/blanca/packages/BlancaInstantiations/Pooma2Instantiations/lib/POOMA2INSTANTIATIONS/LINUX_KCC_DEBUG_CHEETAH_SHARED_NOEX/libpooma2instantiations.so /usr/projects/blanca/packages/BlancaInstantiations/STLInstantiations/lib/STLINSTANTIATIONS/LINUX_KCC_DEBUG_SHARED_NOEX/libstlinstantiations.so /usr/projects/blanca/packages/PoomaII/r2/lib/LINUX_KCC_DEBUG_CHEETAH_NOEX/libpooma.a

> >

 > > >
 > >    cd "/home/wdn/blanca/usr/wdn/blanca_src_4.0/ApplicationsLayer/Demo" >
 > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: >
 > >           class "Engine<1, poomalote::Real, Remote<CompressibleBrick>>" has no >
 > >           member "makeOwnCopy" >
 > >       data()[i].makeOwnCopy(); >
 > >                 ^ >
 > >           detected during: >
 > >             instantiation of "Engine<Dim, T, MultiPatch<LayoutTag, >
 > >                       PatchTag>>::Engine_t &Engine<Dim, T, >
 > >                       MultiPatch<LayoutTag, PatchTag>>::makeOwnCopy() [with >
 > >                       Dim=1, T=poomalote::Real, LayoutTag=GridTag, >
 > >                       PatchTag=Remote<CompressibleBrick>]" at line 482 of >
 > >                       "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi >
 > >                       eldEngine/FieldEngineBase.h" >
 > >             instantiation of "void FieldEngineBase<Dim, T, >
 > >                       EngineTag>::makeOwnCopy(const Subject &) [with Dim=1, >
 > >                       T=poomalote::Real, >
 > >                       EngineTag=poomalote::ModelTraits<poomalote::OneDF<poomalo >
 > >                       te::DefaultTraits>>::EngineTag, >
 > >                       Subject=Field<poomalote::ModelTraits<poomalote::OneDF<poo >
 > >                       malote::DefaultTraits>>::MeshTag, poomalote::Real, >
 > >                       poomalote::ModelTraits<poomalote::OneDF<poomalote::Defaul >
 > >                       tTraits>>::EngineTag>]" at line 983 of >
 > >                       "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi >
 > >                       eld.h" >
 > >             instantiation of "void Field<GeometryTag, T, >
 > >                       EngineTag>::makeOwnCopy() [with >
 > >                       GeometryTag=poomalote::ModelTraits<poomalote::OneDF<pooma >
 > >                       lote::DefaultTraits>>::MeshTag, T=poomalote::Real, >
 > >                       EngineTag=poomalote::ModelTraits<poomalote::OneDF<poomalo >
 > >                       te::DefaultTraits>>::EngineTag]" at line 69 of >
 > >                       "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo >
 > >                       rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC >
 > >                       lasses/MMField.t.hh" >
 > >             instantiation of "void >
 > >                       PhysicsBaseClasses::matMMWeightedAverage(const Field<G1, >
 > >                       T1, E1> &, const Field<MeshTag, poomalote::Real, >
 > >                       EngineTag> &, const Field<G1, T1, E1> &, bool) [with >
 > >                       MeshTag=poomalote::ModelTraits<poomalote::OneDF<poomalote >
 > >                       ::DefaultTraits>>::MeshTag, T=poomalote::Real, >
 > >                       EngineTag=poomalote::ModelTraits<poomalote::OneDF<poomalo >
 > >                       te::DefaultTraits>>::EngineTag]" at line 579 of >
 > >                       "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer >
 > >                       /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib >
 > >                       leRelations.t.hh" >
 > >             instantiation of "void >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::calcAvgQuanti >
 > >                       ty(const >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::ScalarField >
 > >                       &, const >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::ScalarField >
 > >                       &, const >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::ScalarField >
 > >                       &) [with >
 > >                       Traits=poomalote::OneDF<poomalote::DefaultTraits>]" >
 > > >
 > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: >
 > >           class "Engine<2, poomalote::Real, Remote<CompressibleBrick>>" has no >
 > >           member "makeOwnCopy" >
 > >       data()[i].makeOwnCopy(); >
 > >                 ^ >
 > >           detected during: >
 > >             instantiation of "Engine<Dim, T, MultiPatch<LayoutTag, >
 > >                       PatchTag>>::Engine_t &Engine<Dim, T, >
 > >                       MultiPatch<LayoutTag, PatchTag>>::makeOwnCopy() [with >
 > >                       Dim=2, T=poomalote::Real, LayoutTag=GridTag, >
 > >                       PatchTag=Remote<CompressibleBrick>]" at line 482 of >
 > >                       "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi >
 > >                       eldEngine/FieldEngineBase.h" >
 > >             instantiation of "void FieldEngineBase<Dim, T, >
 > >                       EngineTag>::makeOwnCopy(const Subject &) [with Dim=2, >
 > >                       T=poomalote::Real, >
 > >                       EngineTag=poomalote::ModelTraits<poomalote::TwoDF<poomalo >
 > >                       te::DefaultTraits>>::EngineTag, >
 > >                       Subject=Field<poomalote::ModelTraits<poomalote::TwoDF<poo >
 > >                       malote::DefaultTraits>>::MeshTag, poomalote::Real, >
 > >                       poomalote::ModelTraits<poomalote::TwoDF<poomalote::Defaul >
 > >                       tTraits>>::EngineTag>]" at line 983 of >
 > >                       "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi >
 > >                       eld.h" >
 > >             instantiation of "void Field<GeometryTag, T, >
 > >                       EngineTag>::makeOwnCopy() [with >
 > >                       GeometryTag=poomalote::ModelTraits<poomalote::TwoDF<pooma >
 > >                       lote::DefaultTraits>>::MeshTag, T=poomalote::Real, >
 > >                       EngineTag=poomalote::ModelTraits<poomalote::TwoDF<poomalo >
 > >                       te::DefaultTraits>>::EngineTag]" at line 69 of >
 > >                       "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo >
 > >                       rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC >
 > >                       lasses/MMField.t.hh" >
 > >             instantiation of "void >
 > >                       PhysicsBaseClasses::matMMWeightedAverage(const Field<G1, >
 > >                       T1, E1> &, const Field<MeshTag, poomalote::Real, >
 > >                       EngineTag> &, const Field<G1, T1, E1> &, bool) [with >
 > >                       MeshTag=poomalote::ModelTraits<poomalote::TwoDF<poomalote >
 > >                       ::DefaultTraits>>::MeshTag, T=poomalote::Real, >
 > >                       EngineTag=poomalote::ModelTraits<poomalote::TwoDF<poomalo >
 > >                       te::DefaultTraits>>::EngineTag]" at line 579 of >
 > >                       "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer >
 > >                       /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib >
 > >                       leRelations.t.hh" >
 > >             instantiation of "void >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::calcAvgQuanti >
 > >                       ty(const >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::ScalarField >
 > >                       &, const >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::ScalarField >
 > >                       &, const >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::ScalarField >
 > >                       &) [with >
 > >                       Traits=poomalote::TwoDF<poomalote::DefaultTraits>]" >
 > > >
 > > "/usr/projects/blanca/packages/PoomaII/r2/src/Engine/MultiPatchEngine.cpp", line 252: error #135: >
 > >           class "Engine<3, poomalote::Real, Remote<CompressibleBrick>>" has no >
 > >           member "makeOwnCopy" >
 > >       data()[i].makeOwnCopy(); >
 > >                 ^ >
 > >           detected during: >
 > >             instantiation of "Engine<Dim, T, MultiPatch<LayoutTag, >
 > >                       PatchTag>>::Engine_t &Engine<Dim, T, >
 > >                       MultiPatch<LayoutTag, PatchTag>>::makeOwnCopy() [with >
 > >                       Dim=3, T=poomalote::Real, LayoutTag=GridTag, >
 > >                       PatchTag=Remote<CompressibleBrick>]" at line 482 of >
 > >                       "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi >
 > >                       eldEngine/FieldEngineBase.h" >
 > >             instantiation of "void FieldEngineBase<Dim, T, >
 > >                       EngineTag>::makeOwnCopy(const Subject &) [with Dim=3, >
 > >                       T=poomalote::Real, >
 > >                       EngineTag=poomalote::ModelTraits<poomalote::ThreeDF<pooma >
 > >                       lote::DefaultTraits>>::EngineTag, >
 > >                       Subject=Field<poomalote::ModelTraits<poomalote::ThreeDF<p >
 > >                       oomalote::DefaultTraits>>::MeshTag, poomalote::Real, >
 > >                       poomalote::ModelTraits<poomalote::ThreeDF<poomalote::Defa >
 > >                       ultTraits>>::EngineTag>]" at line 983 of >
 > >                       "/usr/projects/blanca/packages/PoomaII/r2/src/NewField/Fi >
 > >                       eld.h" >
 > >             instantiation of "void Field<GeometryTag, T, >
 > >                       EngineTag>::makeOwnCopy() [with >
 > >                       GeometryTag=poomalote::ModelTraits<poomalote::ThreeDF<poo >
 > >                       malote::DefaultTraits>>::MeshTag, T=poomalote::Real, >
 > >                       EngineTag=poomalote::ModelTraits<poomalote::ThreeDF<pooma >
 > >                       lote::DefaultTraits>>::EngineTag]" at line 69 of >
 > >                       "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsSuppo >
 > >                       rtLayer/PhysicsBaseClasses/PhysicsBaseClasses_src/HelperC >
 > >                       lasses/MMField.t.hh" >
 > >             instantiation of "void >
 > >                       PhysicsBaseClasses::matMMWeightedAverage(const Field<G1, >
 > >                       T1, E1> &, const Field<MeshTag, poomalote::Real, >
 > >                       EngineTag> &, const Field<G1, T1, E1> &, bool) [with >
 > >                       MeshTag=poomalote::ModelTraits<poomalote::ThreeDF<poomalo >
 > >                       te::DefaultTraits>>::MeshTag, T=poomalote::Real, >
 > >                       EngineTag=poomalote::ModelTraits<poomalote::ThreeDF<pooma >
 > >                       lote::DefaultTraits>>::EngineTag]" at line 579 of >
 > >                       "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer >
 > >                       /Hydrodynamics/Hydrodynamics_src/CompatibleHydro/Compatib >
 > >                       leRelations.t.hh" >
 > >             instantiation of "void >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::calcAvgQuanti >
 > >                       ty(const >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::ScalarField >
 > >                       &, const >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::ScalarField >
 > >                       &, const >
 > >                       Hydrodynamics::CompatibleRelations<Traits>::ScalarField >
 > >                       &) [with >
 > >                       Traits=poomalote::ThreeDF<poomalote::DefaultTraits>]" >
 > > >
 > > 3 errors detected in the compilation of "/usr/projects/blanca/usr/wdn/blanca_src_4.0/PhysicsLayer/Hydrodynamics/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.cc".

> >

 > > driver: Compilation failed. >
 > >    Recompiling /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o

> >

 > > Error: Unable to recompile /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/Hydrodynamics_src/CompatibleHydro/CompatibleRelations.o.

> >

 > > Command exited with non-zero status 2 >
 > > real 279.50 >
 > > user 0.28 >
 > > sys 0.01 >
 > > mv: /scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so: No such file or directory >
 > > make[1]: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so] Error 1 >
 > > make: *** [/scratch/wdn/obj_4.0/HYDRODYNAMICS/LINUX_KCC_CART_XYZ_MPI/libhydrodynamics.so] Error 2 >
 > > Command exited with non-zero status 2 >
 > > real 5983.14 >
 > > user 2052.11 >
 > > sys 160.74 >
 > > >
 > > Compilation exited abnormally with code 2 at Wed May  9 14:11:17 >
 > >
 > -- >
 > Jeffrey D. Oldham >
 > oldham at codesourcery.comIndex: Array/Array.h >
 > =================================================================== >
 > RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v >
 > retrieving revision 1.139 >
 > diff -c -p -r1.139 Array.h >
 > *** Array/Array.h    2001/04/20 21:16:23     1.139 >
 > --- Array/Array.h    2001/05/11 02:37:11 >
 > *************** >
 > *** 29,34 **** >
 > --- 29,35 ---- >
 >   //----------------------------------------------------------------------------- >
 >   // Classes: >
 >   //   Array >
 > + //   View0 >
 >   //   View[1-7]<Array,various domains> >
 >   //   LeafFunctor<Array, DomainFunctorTag> >
 >   //   LeafFunctor<Array, ViewFunctorTag<Domain> > >
 > *************** public: >
 > *** 1763,1773 **** >
 >     inline Domain_t domain() const >
 >       { >
 >         return engine_m.domain(); >
 > -     } >
 > - >
 > -   inline Domain_t innerDomain() const >
 > -     { >
 > -       return engine_m.innerDomain(); >
 >       } >
 >   >
 >     inline Domain_t physicalDomain() const >
 > --- 1764,1769 ---- >
 > Index: Engine/CompressibleBlock.h >
 > =================================================================== >
 > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v >
 > retrieving revision 1.27 >
 > diff -c -p -r1.27 CompressibleBlock.h >
 > *** Engine/CompressibleBlock.h       2000/07/11 22:13:00     1.27 >
 > --- Engine/CompressibleBlock.h       2001/05/11 02:37:13 >
 > *************** private: >
 > *** 531,541 **** >
 >       >
 >       CompressibleBlockController(const CompressibleBlockController& model) >
 >         : Observable<T*>(ptr_m), >
 > -         size_m(model.size_m), >
 >           compressible_m(!Pooma::neverCompress()), >
 >           dataObject_m(model.dataObject_m.affinity()), >
 > !    ucOffset_m(model.ucOffset_m), >
 > !    viewcount_m(0) >
 >       { >
 >         // Lock the model while we get information pertaining to it >
 >         // being compressed or not (such data can't be initialized in >
 > --- 531,541 ---- >
 >       >
 >       CompressibleBlockController(const CompressibleBlockController& model) >
 >         : Observable<T*>(ptr_m), >
 >           compressible_m(!Pooma::neverCompress()), >
 > +    viewcount_m(0), >
 >           dataObject_m(model.dataObject_m.affinity()), >
 > !         size_m(model.size_m), >
 > !    ucOffset_m(model.ucOffset_m) >
 >       { >
 >         // Lock the model while we get information pertaining to it >
 >         // being compressed or not (such data can't be initialized in >
 > Index: Engine/CompressibleBrick.cpp >
 > =================================================================== >
 > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v >
 > retrieving revision 1.24 >
 > diff -c -p -r1.24 CompressibleBrick.cpp >
 > *** Engine/CompressibleBrick.cpp     2000/07/11 23:06:40     1.24 >
 > --- Engine/CompressibleBrick.cpp     2001/05/11 02:37:13 >
 > *************** Engine(const Engine<Dim,T,CompressibleBr >
 > *** 501,506 **** >
 > --- 501,542 ---- >
 >   >
 >   //----------------------------------------------------------------------------- >
 >   // >
 > + // Engine<Dim,T,CompressibleBrickView> & makeOwnCopy() >
 > + // >
 > + // Causes the CompressibleBrickView-Engine to obtain a private copy of the data >
 > + // that it refers to. >
 > + // >
 > + //----------------------------------------------------------------------------- >
 > + >
 > + template <int Dim, class T> >
 > + Engine<Dim,T,CompressibleBrickView> &Engine<Dim,T,CompressibleBrickView>::makeOwnCopy() >
 > + { >
 > +   // JIM: This is probably not thread safe??? >
 > +   // There is a race from checking isShared to getting into cblock's >
 > +   // makeOwnCopy, which is thread safe. As a result, this should only >
 > +   // be called after a blockAndEvaluate() to ensure that nobody else >
 > +   // is messing with the underlying CBC while this is >
 > +   // occuring. (Logically, this is necessary anyway since you probably >
 > +   // want a copy of the data that results from all previous >
 > +   // computations having taken place.)  Also, as mentioned elsewhere, >
 > +   // the current implementation results in copying uncompressed data >
 > +   // in the parse thread, which will result in incorrect memory >
 > +   // affinity. >
 > +   >
 > +   if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) >
 > +     { >
 > +       cblock_m.detach(this); >
 > +       cblock_m.makeOwnCopy(); >
 > +       cblock_m.attach(this); >
 > + >
 > +       data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); >
 > +     } >
 > + >
 > +   return *this; >
 > + } >
 > + >
 > + //----------------------------------------------------------------------------- >
 > + // >
 >   // Engine<Dim, T, CompressibleBrickView>:: >
 >   // elementsCompressed() const >
 >   // >
 > Index: Engine/CompressibleBrick.h >
 > =================================================================== >
 > RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v >
 > retrieving revision 1.67 >
 > diff -c -p -r1.67 CompressibleBrick.h >
 > *** Engine/CompressibleBrick.h       2000/07/11 23:06:40     1.67 >
 > --- Engine/CompressibleBrick.h       2001/05/11 02:37:14 >
 > *************** public: >
 > *** 237,242 **** >
 > --- 237,250 ---- >
 >   >
 >     inline Layout_t layout() const { return Layout_t(domain_m); } >
 >   >
 > +   //--------------------------------------------------------------------------- >
 > +   // Return the domain and base domain. >
 > + >
 > +   inline const Domain_t &domain() const >
 > +   { >
 > +     return layout().domain(); >
 > +   } >
 > + >
 >     // Get a private copy of data viewed by this Engine. >
 >   >
 >     Engine_t &makeOwnCopy(); >
 > *************** public: >
 > *** 557,562 **** >
 > --- 565,582 ---- >
 >     ElementRef_t operator()(const Loc<Dim> &) const; >
 >     Element_t read(const Loc<Dim> &) const; >
 >     >
 > +   //--------------------------------------------------------------------------- >
 > +   // Return the domain and base domain. >
 > + >
 > +   inline const Domain_t &domain() const >
 > +   { >
 > +     return Layout_t(domain_m).domain(); >
 > +   } >
 > + >
 > +   // Get a private copy of data viewed by this Engine. >
 > + >
 > +   Engine_t &makeOwnCopy(); >
 > + >
 >     // Return the block controller (uncompressed). >
 >     // See comments in CompressibleBrick above. >
 >     >
 > *************** struct NewEngine<Engine<Dim,T,Compressib >
 > *** 801,806 **** >
 > --- 821,831 ---- >
 >   template <int Dim, class T> >
 >   struct ElementProperties<Engine<Dim, T, CompressibleBrick> > >
 >     : public MakeOwnCopyProperties<Engine<Dim, T, CompressibleBrick> > >
 > + { }; >
 > + >
 > + template <int Dim, class T> >
 > + struct ElementProperties<Engine<Dim, T, CompressibleBrickView> > >
 > +   : public MakeOwnCopyProperties<Engine<Dim, T, CompressibleBrickView> > >
 >   { }; >
 >   >
 >   >
 > Index: Layout/Node.h >
 > =================================================================== >
 > RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v >
 > retrieving revision 1.35 >
 > diff -c -p -r1.35 Node.h >
 > *** Layout/Node.h    2001/05/04 15:41:28     1.35 >
 > --- Layout/Node.h    2001/05/11 02:37:15 >
 > *************** public: >
 > *** 121,128 **** >
 >     Node(const Domain_t &owned, const AllocatedDomain_t &allocated, >
 >          Context_t c, ID_t gid, ID_t lid = (-1)) >
 >       : domain_m(owned), allocated_m(allocated), >
 > !       context_m(c), global_m(gid), local_m(lid), >
 > !       affinity_m(-1) >
 >     { >
 >       PAssert(owned.size() >= 0); >
 >       PAssert(allocated.size() >= 0); >
 > --- 121,128 ---- >
 >     Node(const Domain_t &owned, const AllocatedDomain_t &allocated, >
 >          Context_t c, ID_t gid, ID_t lid = (-1)) >
 >       : domain_m(owned), allocated_m(allocated), >
 > !       local_m(lid), global_m(gid), >
 > !       context_m(c), affinity_m(-1) >
 >     { >
 >       PAssert(owned.size() >= 0); >
 >       PAssert(allocated.size() >= 0); >
 > *************** public: >
 > *** 130,137 **** >
 >     } >
 >   >
 >     Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) >
 > !     : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), >
 > !       affinity_m(-1) >
 >     { >
 >       PAssert(d.size() >= 0); >
 >       PAssert(gid >= 0); >
 > --- 130,138 ---- >
 >     } >
 >   >
 >     Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) >
 > !     : domain_m(d), allocated_m(d), >
 > !       local_m(lid), global_m(gid), >
 > !       context_m(c), affinity_m(-1) >
 >     { >
 >       PAssert(d.size() >= 0); >
 >       PAssert(gid >= 0); >
 > *************** public: >
 > *** 152,159 **** >
 >   >
 >     Node(int affinity, const Domain_t &d, >
 >          Context_t c, ID_t gid, ID_t lid = (-1)) >
 > !     : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), >
 > !       affinity_m(affinity) >
 >     { >
 >       PAssert(d.size() >= 0); >
 >       PAssert(gid >= 0); >
 > --- 153,161 ---- >
 >   >
 >     Node(int affinity, const Domain_t &d, >
 >          Context_t c, ID_t gid, ID_t lid = (-1)) >
 > !     : domain_m(d), allocated_m(d), >
 > !       local_m(lid), global_m(gid), >
 > !       context_m(c), affinity_m(affinity) >
 >     { >
 >       PAssert(d.size() >= 0); >
 >       PAssert(gid >= 0); >
 > *************** public: >
 > *** 172,180 **** >
 >     >
 >     template<class ODom, class OAlloc> >
 >     Node(const Node<ODom,OAlloc> &n) >
 > !     : domain_m(n.domain()), context_m(n.context()), allocated_m(n.allocated()), >
 > !       global_m(n.globalID()), local_m(n.localID()), >
 > !       affinity_m(n.affinity()) >
 >     { >
 >     } >
 >   >
 > --- 174,182 ---- >
 >     >
 >     template<class ODom, class OAlloc> >
 >     Node(const Node<ODom,OAlloc> &n) >
 > !     : domain_m(n.domain()), allocated_m(n.allocated()), >
 > !       local_m(n.localID()), global_m(n.globalID()), >
 > !       context_m(n.context()), affinity_m(n.affinity()) >
 >     { >
 >     } >
 >   >
 > Index: NewField/FieldEngine/FieldEngine.NoGeometry.h >
 > =================================================================== >
 > RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v >
 > retrieving revision 1.4 >
 > diff -c -p -r1.4 FieldEngine.NoGeometry.h >
 > *** NewField/FieldEngine/FieldEngine.NoGeometry.h    2001/04/10 23:13:25     1.4 >
 > --- NewField/FieldEngine/FieldEngine.NoGeometry.h    2001/05/11 02:37:15 >
 > *************** public: >
 > *** 254,267 **** >
 >     // This field-engine always has vert-centering and the total domain is >
 >     // given by the engine. >
 >           >
 > !   inline const Domain_t &physicalCellDomain() const >
 >       { >
 > !       return shrink(physicalDomain(), 1); >
 >       } >
 >           >
 >     inline Domain_t totalCellDomain() const >
 >       { >
 > !       return shrink(engine_m.domain(), 1); >
 >       } >
 >   >
 >     Domain_t physicalDomain() const >
 > --- 254,267 ---- >
 >     // This field-engine always has vert-centering and the total domain is >
 >     // given by the engine. >
 >           >
 > !   inline const Domain_t physicalCellDomain() const >
 >       { >
 > !       return shrinkRight(physicalDomain(), 1); >
 >       } >
 >           >
 >     inline Domain_t totalCellDomain() const >
 >       { >
 > !       return shrinkRight(engine_m.domain(), 1); >
 >       } >
 >   >
 >     Domain_t physicalDomain() const >

> > > From oldham at codesourcery.com Fri May 11 22:11:30 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 11 May 2001 15:11:30 -0700 Subject: RFA: Patch: More NewField Related Pooma Code Changes Message-ID: <20010511151130.A20200@codesourcery.com> Ok to commit this patch? Attached is a patch of miscellaneous changes found when trying to explicitly instantiate various Fields. 2001-05-11 Jeffrey D. Oldham * Domain/DomainTraits.Region.h (DomainTraits >::empty(): Remove name of unused parameter. * Engine/CompressibleBlock.h (CompressibleBlockController::CompressibleBlockController): Reorder member initializations to reflect declaration order. * Engine/RemoteEngine.h (Engine >::Engine): Likewise. * NewField/Field.h (Field::physicalCellDomain): Remove unnecessary return reference. * NewField/FieldEngine/FieldEngineBase.ExprEngine.h (FieldEngineBase::physicalCellDomain): Likewise. * NewField/FieldEngine/FieldEngineBase.h (FieldEngineBase::physicalCellDomain): Likewise. * Tulip/RemoteProxy.h (RemoteProxy::RemoteProxy): Conditionally declaration variable. * Utilities/RefCountedBlockPtr.h (RefBlockController::RefBlockController): Reorder member initializations to reflect declaration order. Tested on sequential Linux using g++ by building library Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Domain/DomainTraits.Region.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/DomainTraits.Region.h,v retrieving revision 1.12 diff -c -p -r1.12 DomainTraits.Region.h *** Domain/DomainTraits.Region.h 2001/04/13 02:12:59 1.12 --- Domain/DomainTraits.Region.h 2001/05/11 21:49:09 *************** struct DomainTraits< Region<1,POOMA_DEFA *** 407,413 **** static Element_t max(const Storage_t &d) { return (length(d) >= 0 ? last(d) : first(d)); } ! static bool empty(const Storage_t &d) { return false; } static int loop(const Storage_t &) { return 0; } // get the Nth value of the domain, where value # 0 is first(), etc. --- 407,413 ---- static Element_t max(const Storage_t &d) { return (length(d) >= 0 ? last(d) : first(d)); } ! static bool empty(const Storage_t &) { return false; } static int loop(const Storage_t &) { return 0; } // get the Nth value of the domain, where value # 0 is first(), etc. Index: Engine/CompressibleBlock.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v retrieving revision 1.27 diff -c -p -r1.27 CompressibleBlock.h *** Engine/CompressibleBlock.h 2000/07/11 22:13:00 1.27 --- Engine/CompressibleBlock.h 2001/05/11 21:49:10 *************** private: *** 451,463 **** explicit CompressibleBlockController(int size) : Observable(ptr_m), size_m(size), - compressible_m(true), ptr_m(&compressedData_m), ! dataObject_m(-1), ! ucOffset_m(-1), ! viewcount_m(0), ! countUncompressed_m(0) { ElementProperties::construct(&compressedData_m); --- 451,463 ---- explicit CompressibleBlockController(int size) : Observable(ptr_m), + compressible_m(true), + countUncompressed_m(0), + viewcount_m(0), + dataObject_m(-1), size_m(size), ptr_m(&compressedData_m), ! ucOffset_m(-1) { ElementProperties::construct(&compressedData_m); *************** private: *** 474,486 **** CompressibleBlockController(int size, int affinity) : Observable(ptr_m), - size_m(size), compressible_m(true), ! ptr_m(&compressedData_m), ! dataObject_m(affinity), ! ucOffset_m(-1), viewcount_m(0), ! countUncompressed_m(0) { ElementProperties::construct(&compressedData_m); --- 474,486 ---- CompressibleBlockController(int size, int affinity) : Observable(ptr_m), compressible_m(true), ! countUncompressed_m(0), viewcount_m(0), ! dataObject_m(affinity), ! size_m(size), ! ptr_m(&compressedData_m), ! ucOffset_m(-1) { ElementProperties::construct(&compressedData_m); *************** private: *** 497,509 **** CompressibleBlockController(int size, int affinity, const T& value) : Observable(ptr_m), - size_m(size), compressible_m(true), ! ptr_m(&compressedData_m), ! dataObject_m(affinity), ! ucOffset_m(-1), viewcount_m(0), ! countUncompressed_m(0) { ElementProperties::construct(&compressedData_m,value); --- 497,509 ---- CompressibleBlockController(int size, int affinity, const T& value) : Observable(ptr_m), compressible_m(true), ! countUncompressed_m(0), viewcount_m(0), ! dataObject_m(affinity), ! size_m(size), ! ptr_m(&compressedData_m), ! ucOffset_m(-1) { ElementProperties::construct(&compressedData_m,value); *************** private: *** 531,541 **** CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), - size_m(model.size_m), compressible_m(!Pooma::neverCompress()), dataObject_m(model.dataObject_m.affinity()), ! ucOffset_m(model.ucOffset_m), ! viewcount_m(0) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in --- 531,541 ---- CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), compressible_m(!Pooma::neverCompress()), + viewcount_m(0), dataObject_m(model.dataObject_m.affinity()), ! size_m(model.size_m), ! ucOffset_m(model.ucOffset_m) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in Index: Engine/RemoteEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/RemoteEngine.h,v retrieving revision 1.31 diff -c -p -r1.31 RemoteEngine.h *** Engine/RemoteEngine.h 2001/03/29 00:41:21 1.31 --- Engine/RemoteEngine.h 2001/05/11 21:49:12 *************** Engine >::Engine() *** 609,616 **** template Engine >::Engine(const Node &node) ! : owningContext_m(node.context()), ! domain_m(node.allocated()) { PAssert(owningContext_m < Pooma::contexts()); --- 609,616 ---- template Engine >::Engine(const Node &node) ! : domain_m(node.allocated()), ! owningContext_m(node.context()) { PAssert(owningContext_m < Pooma::contexts()); *************** Engine >::Engine(con *** 634,641 **** template Engine >::Engine(const Layout_t &layout) ! : owningContext_m(0), ! domain_m(layout.node().allocated()) { PAssert(owningContext_m < Pooma::contexts()); --- 634,641 ---- template Engine >::Engine(const Layout_t &layout) ! : domain_m(layout.node().allocated()), ! owningContext_m(0) { PAssert(owningContext_m < Pooma::contexts()); *************** Engine >::Engine(con *** 659,665 **** template Engine >::Engine(const Domain_t &dom) ! : owningContext_m(0), domain_m(dom) { if (engineIsLocal()) { --- 659,665 ---- template Engine >::Engine(const Domain_t &dom) ! : domain_m(dom), owningContext_m(0) { if (engineIsLocal()) { *************** Engine >::Engine(con *** 676,683 **** template Engine >::Engine(int owningContext, const Domain_t &dom) ! : owningContext_m(owningContext), ! domain_m(dom) { if (engineIsLocal()) { --- 676,683 ---- template Engine >::Engine(int owningContext, const Domain_t &dom) ! : domain_m(dom), ! owningContext_m(owningContext) { if (engineIsLocal()) { *************** Engine >::Engine(int *** 698,704 **** template Engine >::Engine(const Domain_t &dom, const T& model) ! : owningContext_m(0), domain_m(dom) { if (engineIsLocal()) { --- 698,704 ---- template Engine >::Engine(const Domain_t &dom, const T& model) ! : domain_m(dom), owningContext_m(0) { if (engineIsLocal()) { *************** Engine >::Engine(con *** 718,725 **** template Engine >:: Engine(const Engine > &modelEngine) ! : owningContext_m(modelEngine.owningContext()), ! domain_m(modelEngine.domain()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } --- 718,725 ---- template Engine >:: Engine(const Engine > &modelEngine) ! : domain_m(modelEngine.domain()), ! owningContext_m(modelEngine.owningContext()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } *************** template *** 728,735 **** Engine >:: Engine(const Engine > &modelEngine, const EngineConstructTag &) ! : owningContext_m(modelEngine.owningContext()), ! domain_m(modelEngine.domain()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } --- 728,735 ---- Engine >:: Engine(const Engine > &modelEngine, const EngineConstructTag &) ! : domain_m(modelEngine.domain()), ! owningContext_m(modelEngine.owningContext()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } Index: NewField/Field.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/Field.h,v retrieving revision 1.12 diff -c -p -r1.12 Field.h *** NewField/Field.h 2001/04/27 22:52:44 1.12 --- NewField/Field.h 2001/05/11 21:49:13 *************** public: *** 933,939 **** return fieldEngine_m.numSubFields(); } ! inline const Domain_t &physicalCellDomain() const { return fieldEngine_m.physicalCellDomain(); } --- 933,939 ---- return fieldEngine_m.numSubFields(); } ! inline const Domain_t physicalCellDomain() const { return fieldEngine_m.physicalCellDomain(); } Index: NewField/FieldEngine/FieldEngineBase.ExprEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.ExprEngine.h,v retrieving revision 1.10 diff -c -p -r1.10 FieldEngineBase.ExprEngine.h *** NewField/FieldEngine/FieldEngineBase.ExprEngine.h 2000/12/13 20:48:29 1.10 --- NewField/FieldEngine/FieldEngineBase.ExprEngine.h 2001/05/11 21:49:13 *************** public: *** 261,267 **** //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t &physicalCellDomain() const { return referenceField_m.physicalCellDomain(); } --- 261,267 ---- //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t physicalCellDomain() const { return referenceField_m.physicalCellDomain(); } Index: NewField/FieldEngine/FieldEngineBase.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.h,v retrieving revision 1.11 diff -c -p -r1.11 FieldEngineBase.h *** NewField/FieldEngine/FieldEngineBase.h 2001/04/27 22:50:27 1.11 --- NewField/FieldEngine/FieldEngineBase.h 2001/05/11 21:49:13 *************** public: *** 429,435 **** //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t &physicalCellDomain() const { return physicalCellDomain_m; } --- 429,435 ---- //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t physicalCellDomain() const { return physicalCellDomain_m; } Index: Tulip/RemoteProxy.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Tulip/RemoteProxy.h,v retrieving revision 1.13 diff -c -p -r1.13 RemoteProxy.h *** Tulip/RemoteProxy.h 2000/06/08 22:16:59 1.13 --- Tulip/RemoteProxy.h 2001/05/11 21:49:13 *************** public: *** 112,118 **** --- 112,120 ---- RemoteProxy(T &val, int owningContext = 0) { + #if POOMA_CHEETAH int tag = RemoteProxyBase::tag_m++; + #endif if (Pooma::context() == owningContext) { value_m = &val; Index: Utilities/RefCountedBlockPtr.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/RefCountedBlockPtr.h,v retrieving revision 1.60 diff -c -p -r1.60 RefCountedBlockPtr.h *** Utilities/RefCountedBlockPtr.h 2001/05/04 15:41:29 1.60 --- Utilities/RefCountedBlockPtr.h 2001/05/11 21:49:14 *************** public: *** 145,151 **** } RefBlockController(size_t size, const T & model) ! : dealloc_m(false), pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0) { // Allocate memory, and set pointers to beginning and ending. This // also sets the dealloc_m flag to true. --- 145,151 ---- } RefBlockController(size_t size, const T & model) ! : pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0), dealloc_m(false) { // Allocate memory, and set pointers to beginning and ending. This // also sets the dealloc_m flag to true. From oldham at codesourcery.com Mon May 14 19:42:49 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Mon, 14 May 2001 12:42:49 -0700 Subject: RFA: Permit NoGeometry Fields to Instantiate Message-ID: <20010514124249.A13621@codesourcery.com> OK to commit? These changes with my two previous proposed patches permit compiling this program: #include "Pooma/NewFields.h" #define T1 NoGeometry<(int)3> #define T2 int #define T3 CompressibleBrick #define T4 Interval<(int)3> template class Field; template class View1,T4>; This program adds the "class Field" line to what Dave Nystrom originally requested. This reflects circular references in the definition of View1. Please carefully check the patch to see if its semantics match those you believe they should. 2001-05-14 Jeffrey D. Oldham * NewField/FieldEngine/FieldEngine.NoGeometry.h (FieldEngine, T, EngineTag>): Add a default constructor. (FieldEngine, T, EngineTag>)::physicalDomain): New function. (FieldEngine, T, EngineTag>)::totalDomain): Likewise. Tested on sequential Linux gcc 3.0 by compiling Pooma library Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: NewField/FieldEngine/FieldEngine.NoGeometry.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v retrieving revision 1.4 diff -c -p -r1.4 FieldEngine.NoGeometry.h *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/14 19:23:56 *************** public: *** 129,134 **** --- 129,141 ---- // There is no sub-field constructor because this field-engine can't have // subfields. + // Default constructor. + FieldEngine() + : engine_m(Pooma::NoInit()), + guards_m(0), + updaters_m() + { } + // Copy constructor. FieldEngine(const This_t &model) *************** public: *** 274,280 **** return engine_m.domain(); } ! //--------------------------------------------------------------------------- // Make a distinct copy of this fieldEngineBase. --- 281,299 ---- return engine_m.domain(); } ! Domain_t physicalDomain(int iSubField) const ! { ! // This field engine cannot have subfields. ! return physicalDomain(); ! } ! ! Domain_t totalDomain(int iSubField) const ! { ! // This field engine cannot have subfields. ! return engine_m.domain(); ! } ! ! //--------------------------------------------------------------------------- // Make a distinct copy of this fieldEngineBase. From oldham at codesourcery.com Mon May 14 20:01:46 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Mon, 14 May 2001 13:01:46 -0700 Subject: RFA: Permit NoGeometry Fields to Instantiate Message-ID: <20010514130146.B13621@codesourcery.com> OK to commit? This patch, composed of the three previous patches plus one minor tweak, obviates those patches. It permits compiling this program: #include "Pooma/NewFields.h" #define T1 NoGeometry<(int)3> #define T2 int #define T3 CompressibleBrick #define T4 Interval<(int)3> template class Field; template class View1,T4>; This program adds the "class Field" line to what Dave Nystrom originally requested. This reflects circular references in the definition of View1. Next, I will work on eliminating the need to add the line. 2001-05-14 Jeffrey D. Oldham * Array/Array.h: Add View0 to comment listing implemented classes. (Array::innerDomain): Remove the function since engines do not implement it. * Domain/DomainTraits.Region.h (DomainTraits >::empty(): Remove name of unused parameter. * Engine/CompressibleBlock.h (CompressibleBlockController::CompressibleBlockController): Reorder member initialization order. * Engine/CompressibleBrick.cpp (Engine::makeOwnCopy()): New function. * Engine/CompressibleBrick.h (Engine::domain()): Likewise. (Engine::domain()): Likewise. (Engine::makeOwnCopy()): New declaration. (ElementProperties >): New definition. * Engine/RemoteEngine.h (Engine >::Engine): Likewise. * Layout/Node.h (Node::Node): Reorder member initialization order. * NewField/Field.h (Field::physicalCellDomain): Remove unnecessary return reference. * NewField/FieldEngine/FieldEngine.NoGeometry.h (FieldEngine, T, EngineTag>): Add a default constructor. (FieldEngine, T, EngineTag>::physicalCellDomain): s/shrink/shrinkRight/ (FieldEngine, T, EngineTag>::totalCellDomain): Likewise. (FieldEngine, T, EngineTag>)::physicalDomain): New function. (FieldEngine, T, EngineTag>)::totalDomain): Likewise. * NewField/FieldEngine/FieldEngineBase.ExprEngine.h (FieldEngineBase::physicalCellDomain): Likewise. * NewField/FieldEngine/FieldEngineBase.h (FieldEngineBase::physicalCellDomain): Likewise. * Tulip/RemoteProxy.h (RemoteProxy::RemoteProxy): Conditionally declaration variable. * Utilities/RefCountedBlockPtr.h (RefBlockController::RefBlockController): Reorder member initializations to reflect declaration order. Tested on sequential Linux gcc 3.0 by compiling Pooma library and the above program Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- ? LINUXgcc ? May10.patch ? foo ? May10.ChangeLog ? May14.ChangeLog ? May11.patch ? May11.ChangeLog ? May14.patch ? differences-2001May14 ? Array/tests/LINUXgcc ? BConds/tests/LINUXgcc ? Connect/LINUXgcc ? Connect/Lux/LINUXgcc ? Connect/Lux/tests/LINUXgcc ? Connect/Paws/LINUXgcc ? Connect/Paws/tests/LINUXgcc ? CoordinateSystems/tests/LINUXgcc ? DataBrowser/LINUXgcc ? DataBrowser/tests/LINUXgcc ? Domain/LINUXgcc ? Domain/tests/LINUXgcc ? DynamicArray/tests/LINUXgcc ? Engine/LINUXgcc ? Engine/CompressibleBrick.h.patch ? Engine/tests/LINUXgcc ? Evaluator/tests/LINUXgcc ? Field/DiffOps/tests/LINUXgcc ? Field/tests/LINUXgcc ? Functions/tests/LINUXgcc ? Geometry/LINUXgcc ? Geometry/tests/LINUXgcc ? IO/LINUXgcc ? IO/tests/LINUXgcc ? Layout/LINUXgcc ? Layout/tests/LINUXgcc ? Meshes/tests/LINUXgcc ? NewField/Field.h.diff ? NewField/FieldEngine/FieldEngine.NoGeometry.h.patch ? NewField/FieldEngine/FieldEngine.NoGeometry.h.ChangeLog ? NewField/tests/LINUXgcc ? NewField/tests/StencilTests.cpp.patch ? Particles/LINUXgcc ? Particles/tests/LINUXgcc ? Partition/LINUXgcc ? Partition/tests/LINUXgcc ? Pooma/LINUXgcc ? Pooma/tests/LINUXgcc ? Threads/LINUXgcc ? Threads/IterateSchedulers/LINUXgcc ? Threads/tests/LINUXgcc ? Tiny/tests/LINUXgcc ? Transform/tests/LINUXgcc ? Tulip/LINUXgcc ? Tulip/tests/LINUXgcc ? Utilities/LINUXgcc ? Utilities/tests/LINUXgcc Index: Array/Array.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v retrieving revision 1.139 diff -c -p -r1.139 Array.h *** Array/Array.h 2001/04/20 21:16:23 1.139 --- Array/Array.h 2001/05/14 19:56:51 *************** *** 29,34 **** --- 29,35 ---- //----------------------------------------------------------------------------- // Classes: // Array + // View0 // View[1-7] // LeafFunctor // LeafFunctor > *************** public: *** 1763,1773 **** inline Domain_t domain() const { return engine_m.domain(); - } - - inline Domain_t innerDomain() const - { - return engine_m.innerDomain(); } inline Domain_t physicalDomain() const --- 1764,1769 ---- Index: Domain/DomainTraits.Region.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/DomainTraits.Region.h,v retrieving revision 1.12 diff -c -p -r1.12 DomainTraits.Region.h *** Domain/DomainTraits.Region.h 2001/04/13 02:12:59 1.12 --- Domain/DomainTraits.Region.h 2001/05/14 19:56:53 *************** struct DomainTraits< Region<1,POOMA_DEFA *** 407,413 **** static Element_t max(const Storage_t &d) { return (length(d) >= 0 ? last(d) : first(d)); } ! static bool empty(const Storage_t &d) { return false; } static int loop(const Storage_t &) { return 0; } // get the Nth value of the domain, where value # 0 is first(), etc. --- 407,413 ---- static Element_t max(const Storage_t &d) { return (length(d) >= 0 ? last(d) : first(d)); } ! static bool empty(const Storage_t &) { return false; } static int loop(const Storage_t &) { return 0; } // get the Nth value of the domain, where value # 0 is first(), etc. Index: Engine/CompressibleBlock.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v retrieving revision 1.27 diff -c -p -r1.27 CompressibleBlock.h *** Engine/CompressibleBlock.h 2000/07/11 22:13:00 1.27 --- Engine/CompressibleBlock.h 2001/05/14 19:56:53 *************** private: *** 451,463 **** explicit CompressibleBlockController(int size) : Observable(ptr_m), size_m(size), - compressible_m(true), ptr_m(&compressedData_m), ! dataObject_m(-1), ! ucOffset_m(-1), ! viewcount_m(0), ! countUncompressed_m(0) { ElementProperties::construct(&compressedData_m); --- 451,463 ---- explicit CompressibleBlockController(int size) : Observable(ptr_m), + compressible_m(true), + countUncompressed_m(0), + viewcount_m(0), + dataObject_m(-1), size_m(size), ptr_m(&compressedData_m), ! ucOffset_m(-1) { ElementProperties::construct(&compressedData_m); *************** private: *** 474,486 **** CompressibleBlockController(int size, int affinity) : Observable(ptr_m), - size_m(size), compressible_m(true), ! ptr_m(&compressedData_m), ! dataObject_m(affinity), ! ucOffset_m(-1), viewcount_m(0), ! countUncompressed_m(0) { ElementProperties::construct(&compressedData_m); --- 474,486 ---- CompressibleBlockController(int size, int affinity) : Observable(ptr_m), compressible_m(true), ! countUncompressed_m(0), viewcount_m(0), ! dataObject_m(affinity), ! size_m(size), ! ptr_m(&compressedData_m), ! ucOffset_m(-1) { ElementProperties::construct(&compressedData_m); *************** private: *** 497,509 **** CompressibleBlockController(int size, int affinity, const T& value) : Observable(ptr_m), - size_m(size), compressible_m(true), ! ptr_m(&compressedData_m), ! dataObject_m(affinity), ! ucOffset_m(-1), viewcount_m(0), ! countUncompressed_m(0) { ElementProperties::construct(&compressedData_m,value); --- 497,509 ---- CompressibleBlockController(int size, int affinity, const T& value) : Observable(ptr_m), compressible_m(true), ! countUncompressed_m(0), viewcount_m(0), ! dataObject_m(affinity), ! size_m(size), ! ptr_m(&compressedData_m), ! ucOffset_m(-1) { ElementProperties::construct(&compressedData_m,value); *************** private: *** 531,541 **** CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), - size_m(model.size_m), compressible_m(!Pooma::neverCompress()), dataObject_m(model.dataObject_m.affinity()), ! ucOffset_m(model.ucOffset_m), ! viewcount_m(0) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in --- 531,541 ---- CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), compressible_m(!Pooma::neverCompress()), + viewcount_m(0), dataObject_m(model.dataObject_m.affinity()), ! size_m(model.size_m), ! ucOffset_m(model.ucOffset_m) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in Index: Engine/CompressibleBrick.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v retrieving revision 1.24 diff -c -p -r1.24 CompressibleBrick.cpp *** Engine/CompressibleBrick.cpp 2000/07/11 23:06:40 1.24 --- Engine/CompressibleBrick.cpp 2001/05/14 19:56:54 *************** Engine(const Engine & makeOwnCopy() + // + // Causes the CompressibleBrickView-Engine to obtain a private copy of the data + // that it refers to. + // + //----------------------------------------------------------------------------- + + template + Engine &Engine::makeOwnCopy() + { + // JIM: This is probably not thread safe??? + // There is a race from checking isShared to getting into cblock's + // makeOwnCopy, which is thread safe. As a result, this should only + // be called after a blockAndEvaluate() to ensure that nobody else + // is messing with the underlying CBC while this is + // occuring. (Logically, this is necessary anyway since you probably + // want a copy of the data that results from all previous + // computations having taken place.) Also, as mentioned elsewhere, + // the current implementation results in copying uncompressed data + // in the parse thread, which will result in incorrect memory + // affinity. + + if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) + { + cblock_m.detach(this); + cblock_m.makeOwnCopy(); + cblock_m.attach(this); + + data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); + } + + return *this; + } + + //----------------------------------------------------------------------------- + // // Engine:: // elementsCompressed() const // Index: Engine/CompressibleBrick.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v retrieving revision 1.67 diff -c -p -r1.67 CompressibleBrick.h *** Engine/CompressibleBrick.h 2000/07/11 23:06:40 1.67 --- Engine/CompressibleBrick.h 2001/05/14 19:56:54 *************** public: *** 237,242 **** --- 237,250 ---- inline Layout_t layout() const { return Layout_t(domain_m); } + //--------------------------------------------------------------------------- + // Return the domain and base domain. + + inline const Domain_t &domain() const + { + return layout().domain(); + } + // Get a private copy of data viewed by this Engine. Engine_t &makeOwnCopy(); *************** public: *** 557,562 **** --- 565,582 ---- ElementRef_t operator()(const Loc &) const; Element_t read(const Loc &) const; + //--------------------------------------------------------------------------- + // Return the domain and base domain. + + inline const Domain_t &domain() const + { + return Layout_t(domain_m).domain(); + } + + // Get a private copy of data viewed by this Engine. + + Engine_t &makeOwnCopy(); + // Return the block controller (uncompressed). // See comments in CompressibleBrick above. *************** struct NewEngine struct ElementProperties > : public MakeOwnCopyProperties > + { }; + + template + struct ElementProperties > + : public MakeOwnCopyProperties > { }; Index: Engine/RemoteEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/RemoteEngine.h,v retrieving revision 1.31 diff -c -p -r1.31 RemoteEngine.h *** Engine/RemoteEngine.h 2001/03/29 00:41:21 1.31 --- Engine/RemoteEngine.h 2001/05/14 19:56:55 *************** Engine >::Engine() *** 609,616 **** template Engine >::Engine(const Node &node) ! : owningContext_m(node.context()), ! domain_m(node.allocated()) { PAssert(owningContext_m < Pooma::contexts()); --- 609,616 ---- template Engine >::Engine(const Node &node) ! : domain_m(node.allocated()), ! owningContext_m(node.context()) { PAssert(owningContext_m < Pooma::contexts()); *************** Engine >::Engine(con *** 634,641 **** template Engine >::Engine(const Layout_t &layout) ! : owningContext_m(0), ! domain_m(layout.node().allocated()) { PAssert(owningContext_m < Pooma::contexts()); --- 634,641 ---- template Engine >::Engine(const Layout_t &layout) ! : domain_m(layout.node().allocated()), ! owningContext_m(0) { PAssert(owningContext_m < Pooma::contexts()); *************** Engine >::Engine(con *** 659,665 **** template Engine >::Engine(const Domain_t &dom) ! : owningContext_m(0), domain_m(dom) { if (engineIsLocal()) { --- 659,665 ---- template Engine >::Engine(const Domain_t &dom) ! : domain_m(dom), owningContext_m(0) { if (engineIsLocal()) { *************** Engine >::Engine(con *** 676,683 **** template Engine >::Engine(int owningContext, const Domain_t &dom) ! : owningContext_m(owningContext), ! domain_m(dom) { if (engineIsLocal()) { --- 676,683 ---- template Engine >::Engine(int owningContext, const Domain_t &dom) ! : domain_m(dom), ! owningContext_m(owningContext) { if (engineIsLocal()) { *************** Engine >::Engine(int *** 698,704 **** template Engine >::Engine(const Domain_t &dom, const T& model) ! : owningContext_m(0), domain_m(dom) { if (engineIsLocal()) { --- 698,704 ---- template Engine >::Engine(const Domain_t &dom, const T& model) ! : domain_m(dom), owningContext_m(0) { if (engineIsLocal()) { *************** Engine >::Engine(con *** 718,725 **** template Engine >:: Engine(const Engine > &modelEngine) ! : owningContext_m(modelEngine.owningContext()), ! domain_m(modelEngine.domain()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } --- 718,725 ---- template Engine >:: Engine(const Engine > &modelEngine) ! : domain_m(modelEngine.domain()), ! owningContext_m(modelEngine.owningContext()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } *************** template *** 728,735 **** Engine >:: Engine(const Engine > &modelEngine, const EngineConstructTag &) ! : owningContext_m(modelEngine.owningContext()), ! domain_m(modelEngine.domain()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } --- 728,735 ---- Engine >:: Engine(const Engine > &modelEngine, const EngineConstructTag &) ! : domain_m(modelEngine.domain()), ! owningContext_m(modelEngine.owningContext()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } Index: Layout/Node.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v retrieving revision 1.35 diff -c -p -r1.35 Node.h *** Layout/Node.h 2001/05/04 15:41:28 1.35 --- Layout/Node.h 2001/05/14 19:56:55 *************** public: *** 121,128 **** Node(const Domain_t &owned, const AllocatedDomain_t &allocated, Context_t c, ID_t gid, ID_t lid = (-1)) : domain_m(owned), allocated_m(allocated), ! context_m(c), global_m(gid), local_m(lid), ! affinity_m(-1) { PAssert(owned.size() >= 0); PAssert(allocated.size() >= 0); --- 121,128 ---- Node(const Domain_t &owned, const AllocatedDomain_t &allocated, Context_t c, ID_t gid, ID_t lid = (-1)) : domain_m(owned), allocated_m(allocated), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(-1) { PAssert(owned.size() >= 0); PAssert(allocated.size() >= 0); *************** public: *** 130,137 **** } Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), ! affinity_m(-1) { PAssert(d.size() >= 0); PAssert(gid >= 0); --- 130,138 ---- } Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(-1) { PAssert(d.size() >= 0); PAssert(gid >= 0); *************** public: *** 152,159 **** Node(int affinity, const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), ! affinity_m(affinity) { PAssert(d.size() >= 0); PAssert(gid >= 0); --- 153,161 ---- Node(int affinity, const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(affinity) { PAssert(d.size() >= 0); PAssert(gid >= 0); *************** public: *** 172,180 **** template Node(const Node &n) ! : domain_m(n.domain()), context_m(n.context()), allocated_m(n.allocated()), ! global_m(n.globalID()), local_m(n.localID()), ! affinity_m(n.affinity()) { } --- 174,182 ---- template Node(const Node &n) ! : domain_m(n.domain()), allocated_m(n.allocated()), ! local_m(n.localID()), global_m(n.globalID()), ! context_m(n.context()), affinity_m(n.affinity()) { } Index: NewField/Field.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/Field.h,v retrieving revision 1.12 diff -c -p -r1.12 Field.h *** NewField/Field.h 2001/04/27 22:52:44 1.12 --- NewField/Field.h 2001/05/14 19:56:56 *************** public: *** 933,939 **** return fieldEngine_m.numSubFields(); } ! inline const Domain_t &physicalCellDomain() const { return fieldEngine_m.physicalCellDomain(); } --- 933,939 ---- return fieldEngine_m.numSubFields(); } ! inline const Domain_t physicalCellDomain() const { return fieldEngine_m.physicalCellDomain(); } Index: NewField/FieldEngine/FieldEngine.NoGeometry.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v retrieving revision 1.4 diff -c -p -r1.4 FieldEngine.NoGeometry.h *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/14 19:56:56 *************** public: *** 129,134 **** --- 129,141 ---- // There is no sub-field constructor because this field-engine can't have // subfields. + // Default constructor. + FieldEngine() + : engine_m(Pooma::NoInit()), + guards_m(0), + updaters_m() + { } + // Copy constructor. FieldEngine(const This_t &model) *************** public: *** 254,267 **** // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 261,274 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrinkRight(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrinkRight(engine_m.domain(), 1); } Domain_t physicalDomain() const *************** public: *** 274,280 **** return engine_m.domain(); } ! //--------------------------------------------------------------------------- // Make a distinct copy of this fieldEngineBase. --- 281,301 ---- return engine_m.domain(); } ! Domain_t physicalDomain(int iSubField) const ! { ! // This field engine cannot have subfields. ! PAssert(iSubField == 0); ! return physicalDomain(); ! } ! ! Domain_t totalDomain(int iSubField) const ! { ! // This field engine cannot have subfields. ! PAssert(iSubField == 0); ! return engine_m.domain(); ! } ! ! //--------------------------------------------------------------------------- // Make a distinct copy of this fieldEngineBase. Index: NewField/FieldEngine/FieldEngineBase.ExprEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.ExprEngine.h,v retrieving revision 1.10 diff -c -p -r1.10 FieldEngineBase.ExprEngine.h *** NewField/FieldEngine/FieldEngineBase.ExprEngine.h 2000/12/13 20:48:29 1.10 --- NewField/FieldEngine/FieldEngineBase.ExprEngine.h 2001/05/14 19:56:56 *************** public: *** 261,267 **** //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t &physicalCellDomain() const { return referenceField_m.physicalCellDomain(); } --- 261,267 ---- //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t physicalCellDomain() const { return referenceField_m.physicalCellDomain(); } Index: NewField/FieldEngine/FieldEngineBase.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.h,v retrieving revision 1.11 diff -c -p -r1.11 FieldEngineBase.h *** NewField/FieldEngine/FieldEngineBase.h 2001/04/27 22:50:27 1.11 --- NewField/FieldEngine/FieldEngineBase.h 2001/05/14 19:56:56 *************** public: *** 429,435 **** //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t &physicalCellDomain() const { return physicalCellDomain_m; } --- 429,435 ---- //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t physicalCellDomain() const { return physicalCellDomain_m; } Index: NewField/tests/StencilTests.cpp =================================================================== RCS file: StencilTests.cpp diff -N StencilTests.cpp *** /dev/null Tue May 5 14:32:27 1998 --- StencilTests.cpp Mon May 14 13:56:57 2001 *************** *** 0 **** --- 1,131 ---- + // -*- 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 + + //----------------------------------------------------------------------------- + // Test the use of some field stencils. + //----------------------------------------------------------------------------- + + ////////////////////////////////////////////////////////////////////// + + //----------------------------------------------------------------------------- + // Overview: + //----------------------------------------------------------------------------- + + //----------------------------------------------------------------------------- + // Typedefs: + //----------------------------------------------------------------------------- + + //----------------------------------------------------------------------------- + // Includes: + //----------------------------------------------------------------------------- + + #include "Pooma/Pooma.h" + #include "Utilities/Tester.h" + #include "Pooma/NewFields.h" + + #include "NewField/DiffOps/Div.h" + #include "NewField/DiffOps/Div.UR.h" + + #include + #include + + #if POOMA_CHEETAH + typedef DistributedTag LayoutTag_t; + typedef Remote BrickTag_t; + #else + typedef ReplicatedTag LayoutTag_t; + typedef Brick BrickTag_t; + #endif + + //----------------------------------------------------------------------------- + // Forward Declarations: + //----------------------------------------------------------------------------- + + int main(int argc, char *argv[]) + { + Pooma::initialize(argc, argv); + Pooma::Tester tester(argc, argv); + + Interval<2> physicalVertexDomain(10, 10); + + Loc<2> blocks(2, 2); + UniformGridPartition<2> partition(blocks, GuardLayers<2>(1)); + UniformGridLayout<2> layout(physicalVertexDomain, partition, + LayoutTag_t()); + + // Now, we can declare fields. + + AllFace allFace; + Cell cell; + Vert vertex; + + typedef UniformRectilinear<2> Geometry_t; + + typedef + Field > + Field_t; + + typedef + Field, MultiPatch > + VField_t; + + Vector<2> origin(0.0, 0.0); + Vector<2> spacings(1.0, 1.0); + + VField_t vfield(vertex, layout, origin, spacings); + Field_t cfield(cell, layout, origin, spacings); + Field_t facefield(allFace, layout, origin, spacings); + + DomainLayout<2> layoutDom(physicalVertexDomain, GuardLayers<2>(1)); + XField::Type_t x(vertex, layoutDom, origin, spacings); + setXField(x); + + vfield = x; + + tester.out() << vfield << std::endl; + + cfield = divVertToCell(vfield); + + tester.out() << cfield << std::endl; + + tester.check("divergence is 2", sum(cfield -2) == 0); + + int ret = tester.results("StencilTests"); + Pooma::finalize(); + return ret; + } + + + + + // ACL:rcsinfo + // ---------------------------------------------------------------------- + // $RCSfile: WhereTest.cpp,v $ $Author: sasmith $ + // $Revision: 1.3 $ $Date: 2001/04/10 23:13:25 $ + // ---------------------------------------------------------------------- + // ACL:rcsinfo Index: NewField/tests/makefile =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/tests/makefile,v retrieving revision 1.9 diff -c -p -r1.9 makefile *** NewField/tests/makefile 2001/04/10 23:13:25 1.9 --- NewField/tests/makefile 2001/05/14 19:56:57 *************** run_tests: tests *** 52,57 **** --- 52,58 ---- $(ODIR)/WhereTest $(TSTOPTS) 1>WhereTest.out 2>&1 $(ODIR)/VectorTest $(TSTOPTS) 1>VectorTest.out 2>&1 $(ODIR)/ScalarCode $(TSTOPTS) 1>ScalarCode.out 2>&1 + $(ODIR)/StencilTests $(TSTOPTS) 1>StencilTests.out 2>&1 $(ODIR)/ExpressionTest $(TSTOPTS) 1>ExpressionTest.out 2>&1 field_tests:: $(ODIR)/BasicTest1 $(ODIR)/BasicTest2 \ *************** $(ODIR)/CrossBox: $(ODIR)/CrossBox.o *** 130,135 **** --- 131,143 ---- ScalarCode: $(ODIR)/ScalarCode $(ODIR)/ScalarCode: $(ODIR)/ScalarCode.o + $(LinkToSuite) + + .PHONY: StencilTests + + StencilTests: $(ODIR)/StencilTests + + $(ODIR)/StencilTests: $(ODIR)/StencilTests.o $(LinkToSuite) Index: Tulip/RemoteProxy.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Tulip/RemoteProxy.h,v retrieving revision 1.13 diff -c -p -r1.13 RemoteProxy.h *** Tulip/RemoteProxy.h 2000/06/08 22:16:59 1.13 --- Tulip/RemoteProxy.h 2001/05/14 19:56:57 *************** public: *** 112,118 **** --- 112,120 ---- RemoteProxy(T &val, int owningContext = 0) { + #if POOMA_CHEETAH int tag = RemoteProxyBase::tag_m++; + #endif if (Pooma::context() == owningContext) { value_m = &val; Index: Utilities/RefCountedBlockPtr.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/RefCountedBlockPtr.h,v retrieving revision 1.60 diff -c -p -r1.60 RefCountedBlockPtr.h *** Utilities/RefCountedBlockPtr.h 2001/05/04 15:41:29 1.60 --- Utilities/RefCountedBlockPtr.h 2001/05/14 19:56:57 *************** public: *** 145,151 **** } RefBlockController(size_t size, const T & model) ! : dealloc_m(false), pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0) { // Allocate memory, and set pointers to beginning and ending. This // also sets the dealloc_m flag to true. --- 145,151 ---- } RefBlockController(size_t size, const T & model) ! : pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0), dealloc_m(false) { // Allocate memory, and set pointers to beginning and ending. This // also sets the dealloc_m flag to true. From scotth at proximation.com Mon May 14 21:01:47 2001 From: scotth at proximation.com (Scott Haney) Date: Mon, 14 May 2001 15:01:47 -0600 Subject: [pooma-dev] RFA: Permit NoGeometry Fields to Instantiate In-Reply-To: <20010514130146.B13621@codesourcery.com> Message-ID: These look fine to me. Scott On Monday, May 14, 2001, at 02:01 PM, Jeffrey Oldham wrote: > OK to commit? > > This patch, composed of the three previous patches plus one minor > tweak, obviates those patches. It permits compiling this program: > > #include "Pooma/NewFields.h" > > #define T1 NoGeometry<(int)3> > #define T2 int > #define T3 CompressibleBrick > #define T4 Interval<(int)3> > template class Field; > template class View1,T4>; > > This program adds the "class Field" line to what Dave Nystrom > originally requested. This reflects circular references in the > definition of View1. Next, I will work on eliminating the need to add > the line. > > 2001-05-14 Jeffrey D. Oldham > > * Array/Array.h: Add View0 to comment listing implemented classes. > (Array::innerDomain): Remove the function since engines do not > implement it. > * Domain/DomainTraits.Region.h > (DomainTraits >::empty(): > Remove name of unused parameter. > * Engine/CompressibleBlock.h > (CompressibleBlockController::CompressibleBlockController): > Reorder member initialization order. > * Engine/CompressibleBrick.cpp > (Engine::makeOwnCopy()): New > function. > * Engine/CompressibleBrick.h (Engine CompressibleBrick>::domain()): Likewise. > (Engine::domain()): Likewise. > (Engine::makeOwnCopy()): New > declaration. > (ElementProperties >): New > definition. > * Engine/RemoteEngine.h (Engine >::Engine): > Likewise. > * Layout/Node.h (Node::Node): Reorder member initialization order. > * NewField/Field.h (Field::physicalCellDomain): Remove unnecessary > return reference. > * NewField/FieldEngine/FieldEngine.NoGeometry.h > (FieldEngine, T, EngineTag>): Add a default > constructor. > (FieldEngine, T, EngineTag>::physicalCellDomain): > s/shrink/shrinkRight/ > (FieldEngine, T, EngineTag>::totalCellDomain): > Likewise. > (FieldEngine, T, EngineTag>)::physicalDomain): New > function. > (FieldEngine, T, EngineTag>)::totalDomain): > Likewise. > * NewField/FieldEngine/FieldEngineBase.ExprEngine.h > (FieldEngineBase::physicalCellDomain): Likewise. > * NewField/FieldEngine/FieldEngineBase.h > (FieldEngineBase::physicalCellDomain): Likewise. > * Tulip/RemoteProxy.h (RemoteProxy::RemoteProxy): Conditionally > declaration variable. > * Utilities/RefCountedBlockPtr.h > (RefBlockController::RefBlockController): Reorder member > initializations to reflect declaration order. > > Tested on sequential Linux gcc 3.0 by compiling Pooma library and > the above program > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > > -------------- next part -------------- These look fine to me. Scott On Monday, May 14, 2001, at 02:01 PM, Jeffrey Oldham wrote: > OK to commit? > > This patch, composed of the three previous patches plus one minor > tweak, obviates those patches. It permits compiling this program: > > #include "Pooma/NewFields.h" > > #define T1 NoGeometry<(int)3> > #define T2 int > #define T3 CompressibleBrick > #define T4 Interval<(int)3> > template class Field; > template class View1,T4>; > > This program adds the "class Field" line to what Dave Nystrom > originally requested. This reflects circular references in the > definition of View1. Next, I will work on eliminating the need to add > the line. > > 2001-05-14 Jeffrey D. Oldham > > * Array/Array.h: Add View0 to comment listing implemented classes. > (Array::innerDomain): Remove the function since engines do not > implement it. > * Domain/DomainTraits.Region.h > (DomainTraits >::empty(): > Remove name of unused parameter. > * Engine/CompressibleBlock.h > (CompressibleBlockController::CompressibleBlockController): > Reorder member initialization order. > * Engine/CompressibleBrick.cpp > (Engine::makeOwnCopy()): New > function. > * Engine/CompressibleBrick.h (Engine CompressibleBrick>::domain()): Likewise. > (Engine::domain()): Likewise. > (Engine::makeOwnCopy()): New > declaration. > (ElementProperties >): New > definition. > * Engine/RemoteEngine.h (Engine >::Engine): > Likewise. > * Layout/Node.h (Node::Node): Reorder member initialization order. > * NewField/Field.h (Field::physicalCellDomain): Remove unnecessary > return reference. > * NewField/FieldEngine/FieldEngine.NoGeometry.h > (FieldEngine, T, EngineTag>): Add a default > constructor. > (FieldEngine, T, EngineTag>::physicalCellDomain): > s/shrink/shrinkRight/ > (FieldEngine, T, EngineTag>::totalCellDomain): > Likewise. > (FieldEngine, T, EngineTag>)::physicalDomain): New > function. > (FieldEngine, T, EngineTag>)::totalDomain): > Likewise. > * NewField/FieldEngine/FieldEngineBase.ExprEngine.h > (FieldEngineBase::physicalCellDomain): Likewise. > * NewField/FieldEngine/FieldEngineBase.h > (FieldEngineBase::physicalCellDomain): Likewise. > * Tulip/RemoteProxy.h (RemoteProxy::RemoteProxy): Conditionally > declaration variable. > * Utilities/RefCountedBlockPtr.h > (RefBlockController::RefBlockController): Reorder member > initializations to reflect declaration order. > > Tested on sequential Linux gcc 3.0 by compiling Pooma library and > the above program > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- A non-text attachment was scrubbed... Name: May14b.patch Type: application/applefile Size: 72 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: May14b.patch Type: application/text Size: 30240 bytes Desc: not available URL: -------------- next part -------------- > From oldham at codesourcery.com Mon May 14 21:14:56 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Mon, 14 May 2001 14:14:56 -0700 Subject: Patch: Permit NoGeometry Field to Instantiate Message-ID: <20010514141456.A18315@codesourcery.com> This patch permits compiling this program: #include "Pooma/NewFields.h" #define T1 NoGeometry<(int)3> #define T2 int #define T3 CompressibleBrick #define T4 Interval<(int)3> template class Field; template class View1,T4>; This program adds the "class Field" line to what Dave Nystrom originally requested. This reflects circular references in the definition of View1. Next, I will work on eliminating the need to add the line. 2001-05-14 Jeffrey D. Oldham * Array/Array.h: Add View0 to comment listing implemented classes. (Array::innerDomain): Remove the function since engines do not implement it. * Domain/DomainTraits.Region.h (DomainTraits >::empty(): Remove name of unused parameter. * Engine/CompressibleBlock.h (CompressibleBlockController::CompressibleBlockController): Reorder member initialization order. * Engine/CompressibleBrick.cpp (Engine::makeOwnCopy()): New function. * Engine/CompressibleBrick.h (Engine::domain()): Likewise. (Engine::domain()): Likewise. (Engine::makeOwnCopy()): New declaration. (ElementProperties >): New definition. * Engine/RemoteEngine.h (Engine >::Engine): Likewise. * Layout/Node.h (Node::Node): Reorder member initialization order. * NewField/Field.h (Field::physicalCellDomain): Remove unnecessary return reference. * NewField/FieldEngine/FieldEngine.NoGeometry.h (FieldEngine, T, EngineTag>): Add a default constructor. (FieldEngine, T, EngineTag>::physicalCellDomain): s/shrink/shrinkRight/ (FieldEngine, T, EngineTag>::totalCellDomain): Likewise. (FieldEngine, T, EngineTag>)::physicalDomain): New function. (FieldEngine, T, EngineTag>)::totalDomain): Likewise. * NewField/FieldEngine/FieldEngineBase.ExprEngine.h (FieldEngineBase::physicalCellDomain): Likewise. * NewField/FieldEngine/FieldEngineBase.h (FieldEngineBase::physicalCellDomain): Likewise. * Tulip/RemoteProxy.h (RemoteProxy::RemoteProxy): Conditionally declaration variable. * Utilities/RefCountedBlockPtr.h (RefBlockController::RefBlockController): Reorder member initializations to reflect declaration order. Tested on sequential Linux gcc 3.0 by compiling Pooma library and the +above program Approved by Scott Haney (swhaney at earthlink.net) Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Array/Array.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v retrieving revision 1.139 diff -c -p -r1.139 Array.h *** Array/Array.h 2001/04/20 21:16:23 1.139 --- Array/Array.h 2001/05/14 19:56:51 *************** *** 29,34 **** --- 29,35 ---- //----------------------------------------------------------------------------- // Classes: // Array + // View0 // View[1-7] // LeafFunctor // LeafFunctor > *************** public: *** 1763,1773 **** inline Domain_t domain() const { return engine_m.domain(); - } - - inline Domain_t innerDomain() const - { - return engine_m.innerDomain(); } inline Domain_t physicalDomain() const --- 1764,1769 ---- Index: Domain/DomainTraits.Region.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/DomainTraits.Region.h,v retrieving revision 1.12 diff -c -p -r1.12 DomainTraits.Region.h *** Domain/DomainTraits.Region.h 2001/04/13 02:12:59 1.12 --- Domain/DomainTraits.Region.h 2001/05/14 19:56:53 *************** struct DomainTraits< Region<1,POOMA_DEFA *** 407,413 **** static Element_t max(const Storage_t &d) { return (length(d) >= 0 ? last(d) : first(d)); } ! static bool empty(const Storage_t &d) { return false; } static int loop(const Storage_t &) { return 0; } // get the Nth value of the domain, where value # 0 is first(), etc. --- 407,413 ---- static Element_t max(const Storage_t &d) { return (length(d) >= 0 ? last(d) : first(d)); } ! static bool empty(const Storage_t &) { return false; } static int loop(const Storage_t &) { return 0; } // get the Nth value of the domain, where value # 0 is first(), etc. Index: Engine/CompressibleBlock.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBlock.h,v retrieving revision 1.27 diff -c -p -r1.27 CompressibleBlock.h *** Engine/CompressibleBlock.h 2000/07/11 22:13:00 1.27 --- Engine/CompressibleBlock.h 2001/05/14 19:56:53 *************** private: *** 451,463 **** explicit CompressibleBlockController(int size) : Observable(ptr_m), size_m(size), - compressible_m(true), ptr_m(&compressedData_m), ! dataObject_m(-1), ! ucOffset_m(-1), ! viewcount_m(0), ! countUncompressed_m(0) { ElementProperties::construct(&compressedData_m); --- 451,463 ---- explicit CompressibleBlockController(int size) : Observable(ptr_m), + compressible_m(true), + countUncompressed_m(0), + viewcount_m(0), + dataObject_m(-1), size_m(size), ptr_m(&compressedData_m), ! ucOffset_m(-1) { ElementProperties::construct(&compressedData_m); *************** private: *** 474,486 **** CompressibleBlockController(int size, int affinity) : Observable(ptr_m), - size_m(size), compressible_m(true), ! ptr_m(&compressedData_m), ! dataObject_m(affinity), ! ucOffset_m(-1), viewcount_m(0), ! countUncompressed_m(0) { ElementProperties::construct(&compressedData_m); --- 474,486 ---- CompressibleBlockController(int size, int affinity) : Observable(ptr_m), compressible_m(true), ! countUncompressed_m(0), viewcount_m(0), ! dataObject_m(affinity), ! size_m(size), ! ptr_m(&compressedData_m), ! ucOffset_m(-1) { ElementProperties::construct(&compressedData_m); *************** private: *** 497,509 **** CompressibleBlockController(int size, int affinity, const T& value) : Observable(ptr_m), - size_m(size), compressible_m(true), ! ptr_m(&compressedData_m), ! dataObject_m(affinity), ! ucOffset_m(-1), viewcount_m(0), ! countUncompressed_m(0) { ElementProperties::construct(&compressedData_m,value); --- 497,509 ---- CompressibleBlockController(int size, int affinity, const T& value) : Observable(ptr_m), compressible_m(true), ! countUncompressed_m(0), viewcount_m(0), ! dataObject_m(affinity), ! size_m(size), ! ptr_m(&compressedData_m), ! ucOffset_m(-1) { ElementProperties::construct(&compressedData_m,value); *************** private: *** 531,541 **** CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), - size_m(model.size_m), compressible_m(!Pooma::neverCompress()), dataObject_m(model.dataObject_m.affinity()), ! ucOffset_m(model.ucOffset_m), ! viewcount_m(0) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in --- 531,541 ---- CompressibleBlockController(const CompressibleBlockController& model) : Observable(ptr_m), compressible_m(!Pooma::neverCompress()), + viewcount_m(0), dataObject_m(model.dataObject_m.affinity()), ! size_m(model.size_m), ! ucOffset_m(model.ucOffset_m) { // Lock the model while we get information pertaining to it // being compressed or not (such data can't be initialized in Index: Engine/CompressibleBrick.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v retrieving revision 1.24 diff -c -p -r1.24 CompressibleBrick.cpp *** Engine/CompressibleBrick.cpp 2000/07/11 23:06:40 1.24 --- Engine/CompressibleBrick.cpp 2001/05/14 19:56:54 *************** Engine(const Engine & makeOwnCopy() + // + // Causes the CompressibleBrickView-Engine to obtain a private copy of the data + // that it refers to. + // + //----------------------------------------------------------------------------- + + template + Engine &Engine::makeOwnCopy() + { + // JIM: This is probably not thread safe??? + // There is a race from checking isShared to getting into cblock's + // makeOwnCopy, which is thread safe. As a result, this should only + // be called after a blockAndEvaluate() to ensure that nobody else + // is messing with the underlying CBC while this is + // occuring. (Logically, this is necessary anyway since you probably + // want a copy of the data that results from all previous + // computations having taken place.) Also, as mentioned elsewhere, + // the current implementation results in copying uncompressed data + // in the parse thread, which will result in incorrect memory + // affinity. + + if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) + { + cblock_m.detach(this); + cblock_m.makeOwnCopy(); + cblock_m.attach(this); + + data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); + } + + return *this; + } + + //----------------------------------------------------------------------------- + // // Engine:: // elementsCompressed() const // Index: Engine/CompressibleBrick.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v retrieving revision 1.67 diff -c -p -r1.67 CompressibleBrick.h *** Engine/CompressibleBrick.h 2000/07/11 23:06:40 1.67 --- Engine/CompressibleBrick.h 2001/05/14 19:56:54 *************** public: *** 237,242 **** --- 237,250 ---- inline Layout_t layout() const { return Layout_t(domain_m); } + //--------------------------------------------------------------------------- + // Return the domain and base domain. + + inline const Domain_t &domain() const + { + return layout().domain(); + } + // Get a private copy of data viewed by this Engine. Engine_t &makeOwnCopy(); *************** public: *** 557,562 **** --- 565,582 ---- ElementRef_t operator()(const Loc &) const; Element_t read(const Loc &) const; + //--------------------------------------------------------------------------- + // Return the domain and base domain. + + inline const Domain_t &domain() const + { + return Layout_t(domain_m).domain(); + } + + // Get a private copy of data viewed by this Engine. + + Engine_t &makeOwnCopy(); + // Return the block controller (uncompressed). // See comments in CompressibleBrick above. *************** struct NewEngine struct ElementProperties > : public MakeOwnCopyProperties > + { }; + + template + struct ElementProperties > + : public MakeOwnCopyProperties > { }; Index: Engine/RemoteEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/RemoteEngine.h,v retrieving revision 1.31 diff -c -p -r1.31 RemoteEngine.h *** Engine/RemoteEngine.h 2001/03/29 00:41:21 1.31 --- Engine/RemoteEngine.h 2001/05/14 19:56:55 *************** Engine >::Engine() *** 609,616 **** template Engine >::Engine(const Node &node) ! : owningContext_m(node.context()), ! domain_m(node.allocated()) { PAssert(owningContext_m < Pooma::contexts()); --- 609,616 ---- template Engine >::Engine(const Node &node) ! : domain_m(node.allocated()), ! owningContext_m(node.context()) { PAssert(owningContext_m < Pooma::contexts()); *************** Engine >::Engine(con *** 634,641 **** template Engine >::Engine(const Layout_t &layout) ! : owningContext_m(0), ! domain_m(layout.node().allocated()) { PAssert(owningContext_m < Pooma::contexts()); --- 634,641 ---- template Engine >::Engine(const Layout_t &layout) ! : domain_m(layout.node().allocated()), ! owningContext_m(0) { PAssert(owningContext_m < Pooma::contexts()); *************** Engine >::Engine(con *** 659,665 **** template Engine >::Engine(const Domain_t &dom) ! : owningContext_m(0), domain_m(dom) { if (engineIsLocal()) { --- 659,665 ---- template Engine >::Engine(const Domain_t &dom) ! : domain_m(dom), owningContext_m(0) { if (engineIsLocal()) { *************** Engine >::Engine(con *** 676,683 **** template Engine >::Engine(int owningContext, const Domain_t &dom) ! : owningContext_m(owningContext), ! domain_m(dom) { if (engineIsLocal()) { --- 676,683 ---- template Engine >::Engine(int owningContext, const Domain_t &dom) ! : domain_m(dom), ! owningContext_m(owningContext) { if (engineIsLocal()) { *************** Engine >::Engine(int *** 698,704 **** template Engine >::Engine(const Domain_t &dom, const T& model) ! : owningContext_m(0), domain_m(dom) { if (engineIsLocal()) { --- 698,704 ---- template Engine >::Engine(const Domain_t &dom, const T& model) ! : domain_m(dom), owningContext_m(0) { if (engineIsLocal()) { *************** Engine >::Engine(con *** 718,725 **** template Engine >:: Engine(const Engine > &modelEngine) ! : owningContext_m(modelEngine.owningContext()), ! domain_m(modelEngine.domain()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } --- 718,725 ---- template Engine >:: Engine(const Engine > &modelEngine) ! : domain_m(modelEngine.domain()), ! owningContext_m(modelEngine.owningContext()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } *************** template *** 728,735 **** Engine >:: Engine(const Engine > &modelEngine, const EngineConstructTag &) ! : owningContext_m(modelEngine.owningContext()), ! domain_m(modelEngine.domain()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } --- 728,735 ---- Engine >:: Engine(const Engine > &modelEngine, const EngineConstructTag &) ! : domain_m(modelEngine.domain()), ! owningContext_m(modelEngine.owningContext()), localEnginePtr_m(modelEngine.localEnginePtr_m) { } Index: Layout/Node.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Layout/Node.h,v retrieving revision 1.35 diff -c -p -r1.35 Node.h *** Layout/Node.h 2001/05/04 15:41:28 1.35 --- Layout/Node.h 2001/05/14 19:56:55 *************** public: *** 121,128 **** Node(const Domain_t &owned, const AllocatedDomain_t &allocated, Context_t c, ID_t gid, ID_t lid = (-1)) : domain_m(owned), allocated_m(allocated), ! context_m(c), global_m(gid), local_m(lid), ! affinity_m(-1) { PAssert(owned.size() >= 0); PAssert(allocated.size() >= 0); --- 121,128 ---- Node(const Domain_t &owned, const AllocatedDomain_t &allocated, Context_t c, ID_t gid, ID_t lid = (-1)) : domain_m(owned), allocated_m(allocated), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(-1) { PAssert(owned.size() >= 0); PAssert(allocated.size() >= 0); *************** public: *** 130,137 **** } Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), ! affinity_m(-1) { PAssert(d.size() >= 0); PAssert(gid >= 0); --- 130,138 ---- } Node(const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(-1) { PAssert(d.size() >= 0); PAssert(gid >= 0); *************** public: *** 152,159 **** Node(int affinity, const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), context_m(c), global_m(gid), local_m(lid), ! affinity_m(affinity) { PAssert(d.size() >= 0); PAssert(gid >= 0); --- 153,161 ---- Node(int affinity, const Domain_t &d, Context_t c, ID_t gid, ID_t lid = (-1)) ! : domain_m(d), allocated_m(d), ! local_m(lid), global_m(gid), ! context_m(c), affinity_m(affinity) { PAssert(d.size() >= 0); PAssert(gid >= 0); *************** public: *** 172,180 **** template Node(const Node &n) ! : domain_m(n.domain()), context_m(n.context()), allocated_m(n.allocated()), ! global_m(n.globalID()), local_m(n.localID()), ! affinity_m(n.affinity()) { } --- 174,182 ---- template Node(const Node &n) ! : domain_m(n.domain()), allocated_m(n.allocated()), ! local_m(n.localID()), global_m(n.globalID()), ! context_m(n.context()), affinity_m(n.affinity()) { } Index: NewField/Field.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/Field.h,v retrieving revision 1.12 diff -c -p -r1.12 Field.h *** NewField/Field.h 2001/04/27 22:52:44 1.12 --- NewField/Field.h 2001/05/14 19:56:56 *************** public: *** 933,939 **** return fieldEngine_m.numSubFields(); } ! inline const Domain_t &physicalCellDomain() const { return fieldEngine_m.physicalCellDomain(); } --- 933,939 ---- return fieldEngine_m.numSubFields(); } ! inline const Domain_t physicalCellDomain() const { return fieldEngine_m.physicalCellDomain(); } Index: NewField/FieldEngine/FieldEngine.NoGeometry.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngine.NoGeometry.h,v retrieving revision 1.4 diff -c -p -r1.4 FieldEngine.NoGeometry.h *** NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/04/10 23:13:25 1.4 --- NewField/FieldEngine/FieldEngine.NoGeometry.h 2001/05/14 19:56:56 *************** public: *** 129,134 **** --- 129,141 ---- // There is no sub-field constructor because this field-engine can't have // subfields. + // Default constructor. + FieldEngine() + : engine_m(Pooma::NoInit()), + guards_m(0), + updaters_m() + { } + // Copy constructor. FieldEngine(const This_t &model) *************** public: *** 254,267 **** // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t &physicalCellDomain() const { ! return shrink(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrink(engine_m.domain(), 1); } Domain_t physicalDomain() const --- 261,274 ---- // This field-engine always has vert-centering and the total domain is // given by the engine. ! inline const Domain_t physicalCellDomain() const { ! return shrinkRight(physicalDomain(), 1); } inline Domain_t totalCellDomain() const { ! return shrinkRight(engine_m.domain(), 1); } Domain_t physicalDomain() const *************** public: *** 274,280 **** return engine_m.domain(); } ! //--------------------------------------------------------------------------- // Make a distinct copy of this fieldEngineBase. --- 281,301 ---- return engine_m.domain(); } ! Domain_t physicalDomain(int iSubField) const ! { ! // This field engine cannot have subfields. ! PAssert(iSubField == 0); ! return physicalDomain(); ! } ! ! Domain_t totalDomain(int iSubField) const ! { ! // This field engine cannot have subfields. ! PAssert(iSubField == 0); ! return engine_m.domain(); ! } ! ! //--------------------------------------------------------------------------- // Make a distinct copy of this fieldEngineBase. Index: NewField/FieldEngine/FieldEngineBase.ExprEngine.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.ExprEngine.h,v retrieving revision 1.10 diff -c -p -r1.10 FieldEngineBase.ExprEngine.h *** NewField/FieldEngine/FieldEngineBase.ExprEngine.h 2000/12/13 20:48:29 1.10 --- NewField/FieldEngine/FieldEngineBase.ExprEngine.h 2001/05/14 19:56:56 *************** public: *** 261,267 **** //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t &physicalCellDomain() const { return referenceField_m.physicalCellDomain(); } --- 261,267 ---- //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t physicalCellDomain() const { return referenceField_m.physicalCellDomain(); } Index: NewField/FieldEngine/FieldEngineBase.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/FieldEngine/FieldEngineBase.h,v retrieving revision 1.11 diff -c -p -r1.11 FieldEngineBase.h *** NewField/FieldEngine/FieldEngineBase.h 2001/04/27 22:50:27 1.11 --- NewField/FieldEngine/FieldEngineBase.h 2001/05/14 19:56:56 *************** public: *** 429,435 **** //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t &physicalCellDomain() const { return physicalCellDomain_m; } --- 429,435 ---- //--------------------------------------------------------------------------- // Domain accessor functions. ! inline const Domain_t physicalCellDomain() const { return physicalCellDomain_m; } Index: NewField/tests/StencilTests.cpp =================================================================== RCS file: StencilTests.cpp diff -N StencilTests.cpp *** /dev/null Tue May 5 14:32:27 1998 --- StencilTests.cpp Mon May 14 13:56:57 2001 *************** *** 0 **** --- 1,131 ---- + // -*- 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 + + //----------------------------------------------------------------------------- + // Test the use of some field stencils. + //----------------------------------------------------------------------------- + + ////////////////////////////////////////////////////////////////////// + + //----------------------------------------------------------------------------- + // Overview: + //----------------------------------------------------------------------------- + + //----------------------------------------------------------------------------- + // Typedefs: + //----------------------------------------------------------------------------- + + //----------------------------------------------------------------------------- + // Includes: + //----------------------------------------------------------------------------- + + #include "Pooma/Pooma.h" + #include "Utilities/Tester.h" + #include "Pooma/NewFields.h" + + #include "NewField/DiffOps/Div.h" + #include "NewField/DiffOps/Div.UR.h" + + #include + #include + + #if POOMA_CHEETAH + typedef DistributedTag LayoutTag_t; + typedef Remote BrickTag_t; + #else + typedef ReplicatedTag LayoutTag_t; + typedef Brick BrickTag_t; + #endif + + //----------------------------------------------------------------------------- + // Forward Declarations: + //----------------------------------------------------------------------------- + + int main(int argc, char *argv[]) + { + Pooma::initialize(argc, argv); + Pooma::Tester tester(argc, argv); + + Interval<2> physicalVertexDomain(10, 10); + + Loc<2> blocks(2, 2); + UniformGridPartition<2> partition(blocks, GuardLayers<2>(1)); + UniformGridLayout<2> layout(physicalVertexDomain, partition, + LayoutTag_t()); + + // Now, we can declare fields. + + AllFace allFace; + Cell cell; + Vert vertex; + + typedef UniformRectilinear<2> Geometry_t; + + typedef + Field > + Field_t; + + typedef + Field, MultiPatch > + VField_t; + + Vector<2> origin(0.0, 0.0); + Vector<2> spacings(1.0, 1.0); + + VField_t vfield(vertex, layout, origin, spacings); + Field_t cfield(cell, layout, origin, spacings); + Field_t facefield(allFace, layout, origin, spacings); + + DomainLayout<2> layoutDom(physicalVertexDomain, GuardLayers<2>(1)); + XField::Type_t x(vertex, layoutDom, origin, spacings); + setXField(x); + + vfield = x; + + tester.out() << vfield << std::endl; + + cfield = divVertToCell(vfield); + + tester.out() << cfield << std::endl; + + tester.check("divergence is 2", sum(cfield -2) == 0); + + int ret = tester.results("StencilTests"); + Pooma::finalize(); + return ret; + } + + + + + // ACL:rcsinfo + // ---------------------------------------------------------------------- + // $RCSfile: WhereTest.cpp,v $ $Author: sasmith $ + // $Revision: 1.3 $ $Date: 2001/04/10 23:13:25 $ + // ---------------------------------------------------------------------- + // ACL:rcsinfo Index: NewField/tests/makefile =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/tests/makefile,v retrieving revision 1.9 diff -c -p -r1.9 makefile *** NewField/tests/makefile 2001/04/10 23:13:25 1.9 --- NewField/tests/makefile 2001/05/14 19:56:57 *************** run_tests: tests *** 52,57 **** --- 52,58 ---- $(ODIR)/WhereTest $(TSTOPTS) 1>WhereTest.out 2>&1 $(ODIR)/VectorTest $(TSTOPTS) 1>VectorTest.out 2>&1 $(ODIR)/ScalarCode $(TSTOPTS) 1>ScalarCode.out 2>&1 + $(ODIR)/StencilTests $(TSTOPTS) 1>StencilTests.out 2>&1 $(ODIR)/ExpressionTest $(TSTOPTS) 1>ExpressionTest.out 2>&1 field_tests:: $(ODIR)/BasicTest1 $(ODIR)/BasicTest2 \ *************** $(ODIR)/CrossBox: $(ODIR)/CrossBox.o *** 130,135 **** --- 131,143 ---- ScalarCode: $(ODIR)/ScalarCode $(ODIR)/ScalarCode: $(ODIR)/ScalarCode.o + $(LinkToSuite) + + .PHONY: StencilTests + + StencilTests: $(ODIR)/StencilTests + + $(ODIR)/StencilTests: $(ODIR)/StencilTests.o $(LinkToSuite) Index: Tulip/RemoteProxy.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Tulip/RemoteProxy.h,v retrieving revision 1.13 diff -c -p -r1.13 RemoteProxy.h *** Tulip/RemoteProxy.h 2000/06/08 22:16:59 1.13 --- Tulip/RemoteProxy.h 2001/05/14 19:56:57 *************** public: *** 112,118 **** --- 112,120 ---- RemoteProxy(T &val, int owningContext = 0) { + #if POOMA_CHEETAH int tag = RemoteProxyBase::tag_m++; + #endif if (Pooma::context() == owningContext) { value_m = &val; Index: Utilities/RefCountedBlockPtr.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/RefCountedBlockPtr.h,v retrieving revision 1.60 diff -c -p -r1.60 RefCountedBlockPtr.h *** Utilities/RefCountedBlockPtr.h 2001/05/04 15:41:29 1.60 --- Utilities/RefCountedBlockPtr.h 2001/05/14 19:56:57 *************** public: *** 145,151 **** } RefBlockController(size_t size, const T & model) ! : dealloc_m(false), pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0) { // Allocate memory, and set pointers to beginning and ending. This // also sets the dealloc_m flag to true. --- 145,151 ---- } RefBlockController(size_t size, const T & model) ! : pBegin_m(0), pEnd_m(0), pEndOfStorage_m(0), dealloc_m(false) { // Allocate memory, and set pointers to beginning and ending. This // also sets the dealloc_m flag to true. From jcrotinger at mac.com Tue May 15 13:22:06 2001 From: jcrotinger at mac.com (James Crotinger) Date: Tue, 15 May 2001 07:22:06 -0600 Subject: [pooma-cvs] CVS update: pooma In-Reply-To: <20010514211123.20800.qmail@merlin.codesourcery.com> Message-ID: > (Engine::makeOwnCopy()): New > declaration. "View" engines aren't supposed to have makeOwnCopy(). I'm not exactly sure what this would mean in general since, in a sense, they don't own their data in the first place. Jim From oldham at codesourcery.com Tue May 15 14:33:29 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 15 May 2001 07:33:29 -0700 Subject: [pooma-dev] CompressibleBrickView's makeOwnCopy In-Reply-To: ; from jcrotinger@mac.com on Tue, May 15, 2001 at 07:22:06AM -0600 References: <20010514211123.20800.qmail@merlin.codesourcery.com> Message-ID: <20010515073329.A31570@codesourcery.com> On Tue, May 15, 2001 at 07:22:06AM -0600, James Crotinger wrote: > > > (Engine::makeOwnCopy()): New > > declaration. > > > "View" engines aren't supposed to have makeOwnCopy(). I'm not exactly sure > what this would mean in general since, in a sense, they don't own their data > in the first place. OK to commit the following patch to eliminate CompressibleBrickView's makeOwnCopy()? Will the resulting code still solve Dave Nystrom's makeOwnCopy() problem? 2001-05-15 Jeffrey D. Oldham * Engine/CompressibleBrick.cpp (Engine::makeOwnCopy()): Remove this incorrectly introduced function. * Engine/CompressibleBrick.h (Engine::makeOwnCopy()): Likewise. Tested on sequential Linux gcc 3.0 by compiling library Approved by ???Jim Crotinger??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: CompressibleBrick.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v retrieving revision 1.25 diff -c -p -r1.25 CompressibleBrick.cpp *** CompressibleBrick.cpp 2001/05/14 21:11:23 1.25 --- CompressibleBrick.cpp 2001/05/15 14:20:24 *************** Engine(const Engine & makeOwnCopy() - // - // Causes the CompressibleBrickView-Engine to obtain a private copy of the data - // that it refers to. - // - //----------------------------------------------------------------------------- - - template - Engine &Engine::makeOwnCopy() - { - // JIM: This is probably not thread safe??? - // There is a race from checking isShared to getting into cblock's - // makeOwnCopy, which is thread safe. As a result, this should only - // be called after a blockAndEvaluate() to ensure that nobody else - // is messing with the underlying CBC while this is - // occuring. (Logically, this is necessary anyway since you probably - // want a copy of the data that results from all previous - // computations having taken place.) Also, as mentioned elsewhere, - // the current implementation results in copying uncompressed data - // in the parse thread, which will result in incorrect memory - // affinity. - - if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) - { - cblock_m.detach(this); - cblock_m.makeOwnCopy(); - cblock_m.attach(this); - - data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); - } - - return *this; - } - - //----------------------------------------------------------------------------- - // // Engine:: // elementsCompressed() const // --- 501,506 ---- Index: CompressibleBrick.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v retrieving revision 1.68 diff -c -p -r1.68 CompressibleBrick.h *** CompressibleBrick.h 2001/05/14 21:11:23 1.68 --- CompressibleBrick.h 2001/05/15 14:20:25 *************** public: *** 573,582 **** return Layout_t(domain_m).domain(); } - // Get a private copy of data viewed by this Engine. - - Engine_t &makeOwnCopy(); - // Return the block controller (uncompressed). // See comments in CompressibleBrick above. --- 573,578 ---- *************** struct NewEngine struct ElementProperties > : public MakeOwnCopyProperties > - { }; - - template - struct ElementProperties > - : public MakeOwnCopyProperties > { }; --- 817,822 ---- From scotth at proximation.com Tue May 15 14:40:44 2001 From: scotth at proximation.com (Scott Haney) Date: Tue, 15 May 2001 08:40:44 -0600 Subject: [pooma-dev] CompressibleBrickView's makeOwnCopy In-Reply-To: <20010515073329.A31570@codesourcery.com> Message-ID: Hi Jeffrey, Whoa, let's wait a second here. If you remove this code, can you explicitly instantiate View1 as in your little example? Jim's point is a good one, but removing it might not be the right answer either. To support explicit instantiation, we might want to have the function, but simply have a PAssert in the body in case it ever gets called. Scott On Tuesday, May 15, 2001, at 08:33 AM, Jeffrey Oldham wrote: > On Tue, May 15, 2001 at 07:22:06AM -0600, James Crotinger wrote: >> >>> (Engine::makeOwnCopy()): New >>> declaration. >> >> >> "View" engines aren't supposed to have makeOwnCopy(). I'm not exactly >> sure >> what this would mean in general since, in a sense, they don't own >> their data >> in the first place. > > OK to commit the following patch to eliminate CompressibleBrickView's > makeOwnCopy()? Will the resulting code still solve Dave Nystrom's > makeOwnCopy() problem? > > 2001-05-15 Jeffrey D. Oldham > > * Engine/CompressibleBrick.cpp > (Engine::makeOwnCopy()): Remove > this > incorrectly introduced function. > * Engine/CompressibleBrick.h > (Engine::makeOwnCopy()): Likewise. > > Tested on sequential Linux gcc 3.0 by compiling library > Approved by ???Jim Crotinger??? From oldham at codesourcery.com Tue May 15 15:09:28 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 15 May 2001 08:09:28 -0700 Subject: [pooma-dev] CompressibleBrickView's makeOwnCopy In-Reply-To: <200105151445.HAA00980@oz.codesourcery.com>; from scotth@proximation.com on Tue, May 15, 2001 at 08:40:44AM -0600 References: <20010515073329.A31570@codesourcery.com> <200105151445.HAA00980@oz.codesourcery.com> Message-ID: <20010515080928.A1024@codesourcery.com> On Tue, May 15, 2001 at 08:40:44AM -0600, Scott Haney wrote: > Hi Jeffrey, > > Whoa, let's wait a second here. > > If you remove this code, can you explicitly instantiate View1 as in your > little example? Jim's point is a good one, but removing it might not be > the right answer either. To support explicit instantiation, we might > want to have the function, but simply have a PAssert in the body in case > it ever gets called. #include "Pooma/NewFields.h" #define T1 NoGeometry<(int)3> #define T2 int #define T3 CompressibleBrick #define T4 Interval<(int)3> template class Field; template class View1,T4>; still compiles. Perhaps we should wait reversing the patch until I finish modifying the code to eliminate the need for explicitly instantiating 'class Field'. I made some progress, but I also made a mistake somewhere. Jeffrey D. Oldham oldham at codesourcery.com > On Tuesday, May 15, 2001, at 08:33 AM, Jeffrey Oldham wrote: > > > On Tue, May 15, 2001 at 07:22:06AM -0600, James Crotinger wrote: > >> > >>> (Engine::makeOwnCopy()): New > >>> declaration. > >> > >> > >> "View" engines aren't supposed to have makeOwnCopy(). I'm not exactly > >> sure > >> what this would mean in general since, in a sense, they don't own > >> their data > >> in the first place. > > > > OK to commit the following patch to eliminate CompressibleBrickView's > > makeOwnCopy()? Will the resulting code still solve Dave Nystrom's > > makeOwnCopy() problem? > > > > 2001-05-15 Jeffrey D. Oldham > > > > * Engine/CompressibleBrick.cpp > > (Engine::makeOwnCopy()): Remove > > this > > incorrectly introduced function. > > * Engine/CompressibleBrick.h > > (Engine::makeOwnCopy()): Likewise. > > > > Tested on sequential Linux gcc 3.0 by compiling library > > Approved by ???Jim Crotinger??? From oldham at codesourcery.com Tue May 15 18:33:55 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 15 May 2001 11:33:55 -0700 Subject: Explicit Instantiation: Stuck Message-ID: <200105151833.LAA07403@oz.codesourcery.com> I am trying to rewrite `class Field' to avoid the explicit instantiation problem demonstrated by View1,int,CompressibleBrick>,Interval<(int)3> > by modifying Pooma's src/NewField/Field.h, but I am stuck. If someone is available to talk about how to fix the problem, please telephone me at 650.968.0703. I would appreciate some advise how to split Field into conceptually separate pieces that the compiler will accept. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From JimC at proximation.com Tue May 15 20:42:28 2001 From: JimC at proximation.com (James Crotinger) Date: Tue, 15 May 2001 13:42:28 -0700 Subject: [pooma-dev] CompressibleBrickView's makeOwnCopy Message-ID: The change looks fine. I'm generally against leaving functions in with { PAssert(false); } as their bodies. To me this indicates that we don't have the abstractions right. If preinstantiation were a requirement I might feel differently, but I don't think preinstantiation of Field probably buys you all that much. Indeed, there is no Field.cpp, so everything in Field is inline, so there is nothing to preinstantiate. Of course, this is also true for View1 - what exactly happens when you "preinstantiate" a class that has no non-inline functions? Doesn't the compiler still have to compile these functions in every file that uses them? I'm confused. Jim > -----Original Message----- > OK to commit the following patch to eliminate CompressibleBrickView's > makeOwnCopy()? Will the resulting code still solve Dave Nystrom's > makeOwnCopy() problem? > > 2001-05-15 Jeffrey D. Oldham > > * Engine/CompressibleBrick.cpp > (Engine::makeOwnCopy()): > Remove this > incorrectly introduced function. > * Engine/CompressibleBrick.h > (Engine::makeOwnCopy()): Likewise. > > Tested on sequential Linux gcc 3.0 by compiling library > Approved by ???Jim Crotinger??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephens at proximation.com Tue May 15 20:54:15 2001 From: stephens at proximation.com (Stephen Smith) Date: Tue, 15 May 2001 13:54:15 -0700 Subject: [pooma-dev] Problem trying to build parallel application Message-ID: Actually it's a separate issue. The makeOwnCopy in compressible brick was causing a problem with preinstantiation, whereas RemoteEngine was just plain missing the function, which meant their code wouldn't compile to run in parallel. Attached is a patch that fixes the problem Dave had with Remote engines. The patch was reviewed by Jim Crotinger. I'll check it in later today. Changes: MultiPatchEngine.h -fixed a problem with makeOwnCopy (it needed to occur at the level of the patch list instead of the individual patches). RemoteDynamicEngine.h RemoteEngine.h -added missing makeOwnCopy() functions. Engine/tests/makefile Engine/tests/makeOwnCopy.cpp -added a test to make sure makeOwnCopy semantics works on remote, multipatch and dynamic engines. Stephen -----Original Message----- From: Jeffrey Oldham [mailto:oldham at codesourcery.com] Sent: Friday, May 11, 2001 12:53 PM To: Dave Nystrom Cc: pooma-dev Subject: Re: [pooma-dev] Problem trying to build parallel application Perhaps yesterday's patch does resolve the makeOwnCopy() difficulty you experienced. Will you please try it again? I do not know where the source code is located to test it myself. Thanks, Jeffrey D. Oldham oldham at codesourcery.com On Wed, May 09, 2001 at 02:19:58PM -0600, Dave Nystrom wrote: > Hi Guys, > > I'm trying to build a parallel version of our application under RH Linux 6.2 > using KCC-4.0d and am having compile problems. Below is part of the build > log. Could someone take a look at this and see what the problem is? I think > Stephen Smith might be a likely candidate. > > -- > Dave Nystrom email: wdn at lanl.gov > LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > -- Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: May15.patch Type: application/octet-stream Size: 4645 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: makeOwnCopy.cpp Type: application/octet-stream Size: 4451 bytes Desc: not available URL: From wdn at lanl.gov Tue May 15 21:04:22 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Tue, 15 May 2001 15:04:22 -0600 (MDT) Subject: [pooma-dev] CompressibleBrickView's makeOwnCopy In-Reply-To: References: Message-ID: <15105.38321.716519.755775@mutley.lanl.gov> I'd just like to make it clear that I am not trying to instantiate the View1 class. Instead, I am only trying to explicitly instantiate what the prelinker does which is: View1, T4>::sv For our source code base, the prelinker discovers 1800-2000 combinations of these template parameters. Also, on a source code base like ours, to get a significant reduction in compile time through explicit instantiation, you have to reduce the number of translation units that the prelinker is recompiling. If the prelinker chooses to assign even one template to a given translation unit, it will be recompiled. So, it takes some tedious work to benefit from explicit instantiation on a source code base like ours but it does pay off based on my experience with doing this on the r1 version of our code. I'm not totally sure just what compilers do regarding template instantiation of non-inline functions. I've communicated with Arch Robison some about this regarding KCC. I think this is what happens with KCC. If you are doing a debug compile then nothing is inlined but every function that would have been inlined is given internal linkage in any translation unit which references it. But I'm not sure what this implies if you explicitly instantiate a class containing these methods. Maybe Mark could comment on this - or maybe every compiler has there own solution. Dave James Crotinger writes: > > The change looks fine. > > I'm generally against leaving functions in with { PAssert(false); } as their > bodies. To me this indicates that we don't have the abstractions right. If > preinstantiation were a requirement I might feel differently, but I don't > think preinstantiation of Field probably buys you all that much. Indeed, > there is no Field.cpp, so everything in Field is inline, so there is nothing > to preinstantiate. > > Of course, this is also true for View1 - what exactly happens when you > "preinstantiate" a class that has no non-inline functions? Doesn't the > compiler still have to compile these functions in every file that uses them? > I'm confused. > > Jim > > > -----Original Message----- > > > OK to commit the following patch to eliminate CompressibleBrickView's > > makeOwnCopy()? Will the resulting code still solve Dave Nystrom's > > makeOwnCopy() problem? > > > > 2001-05-15 Jeffrey D. Oldham > > > > * Engine/CompressibleBrick.cpp > > (Engine::makeOwnCopy()): > > Remove this > > incorrectly introduced function. > > * Engine/CompressibleBrick.h > > (Engine::makeOwnCopy()): Likewise. > > > > Tested on sequential Linux gcc 3.0 by compiling library > > Approved by ???Jim Crotinger??? > > > > Thanks, > > Jeffrey D. Oldham > > oldham at codesourcery.com > > > > > > > > RE: [pooma-dev] CompressibleBrickView's makeOwnCopy > > >
> >

The change looks fine. >

> >

I'm generally against leaving functions in with { PAssert(false); } as their bodies. To me this indicates that we don't have the abstractions right. If preinstantiation were a requirement I might feel differently, but I don't think preinstantiation of Field probably buys you all that much. Indeed, there is no Field.cpp, so everything in Field is inline, so there is nothing to preinstantiate.

> >

Of course, this is also true for View1 - what exactly happens when you "preinstantiate" a class that has no non-inline functions? Doesn't the compiler still have to compile these functions in every file that uses them? I'm confused.

> >

        Jim >

> >

> -----Original Message----- >

> >

> OK to commit the following patch to eliminate CompressibleBrickView's >
> makeOwnCopy()?  Will the resulting code still solve Dave Nystrom's >
> makeOwnCopy() problem? >
> >
> 2001-05-15  Jeffrey D. Oldham  <oldham at codesourcery.com> >
> >
>         * Engine/CompressibleBrick.cpp >
>         (Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()): >
> Remove this >
>       incorrectly introduced function. >
>         * Engine/CompressibleBrick.h >
>       (Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()): Likewise. >
> >
> Tested on     sequential Linux gcc 3.0 by compiling library >
> Approved by   ???Jim Crotinger??? >
> >
> Thanks, >
> Jeffrey D. Oldham >
> oldham at codesourcery.com >
> >

> > > -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 From JimC at proximation.com Wed May 16 16:55:58 2001 From: JimC at proximation.com (James Crotinger) Date: Wed, 16 May 2001 09:55:58 -0700 Subject: [pooma-dev] CompressibleBrickView's makeOwnCopy Message-ID: > I'd just like to make it clear that I am not trying to > instantiate the View1 > class. Instead, I am only trying to explicitly instantiate what the > prelinker does which is: > > View1, T4>::sv One question - is sv even supposed to be public? It is a "static const bool" (so this is what I'd call a definition, not a preinstantiation, but that's a nit). I'm guessing sv is not really supposed to be exported, or we would have given it a more meaningful name. Rather, it looks like it is just a shortcut to simplify the rest of the code. We do this all the time with typedefs, which I've always assumed had no great cost in compile time. It is rare to do it with const parameters like this, but it is done to improve readability. I guess I had always figured that the compiler would optimize the definition away (would it if it were private?). Anyway, if it isn't supposed to be public, we could make it go away altogether. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Thu May 17 07:11:59 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Thu, 17 May 2001 00:11:59 -0700 Subject: POOMA Web Site Message-ID: <20010517001159P.mitchell@codesourcery.com> In Santa Fe, we discussed creating a new web-site for POOMA, with the hope of growing the user-base, and thereby the set of POOMA stakeholders. I've completed a preliminary version of the web-site. Point your browser at www.pooma.com to check it out. It is pretty bare-bones. Ideas for additional content, or actual HTML, would be useful. Jeffrey, since you have eagle eyes for typos, it would be great if you could at least spot-check the site. Right now, nothing else on the web links here, so it is unlikely anyone will find it. In a couple of days, once I have everyone's comments, I will create a link from our main web page, which will drive additional traffic, and allow the search engines to find the site. It would also be great if the old POOMA web-page (http://www.acl.lanl.gov/pooma/) could be updated to point to, or at least mention, the new web-site. Thank you, -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From JimC at proximation.com Thu May 17 18:07:48 2001 From: JimC at proximation.com (James Crotinger) Date: Thu, 17 May 2001 11:07:48 -0700 Subject: [pooma-admin] POOMA Web Site Message-ID: Mark, on the download page it says: "If you wish to use the parallel features of POOMA, you must also downloads SMARTS." This is not quite correct - SMARTS is only necessary if you want to achieve parallelism via threads. Pooma 2.3 also supports parallelism through multiprocessing and message passing. In order to use those features, you need Cheetah (at one point you needed Cheetah regardless, but perhaps that is no longer true). We should probably put the Cheetah release on our web site along with a link to the Cheetah web page. Otherwise, I think this looks pretty good. Once we get our Nirvana accounts back, we may be able to update the old POOMA web page (depending on who owns these pages now). Jim > -----Original Message----- > From: Mark Mitchell [mailto:mark at codesourcery.com] > Sent: Thursday, May 17, 2001 1:12 AM > To: pooma-dev at pooma.codesourcery.com; > pooma-admin at pooma.codesourcery.com > Subject: [pooma-admin] POOMA Web Site > > > > In Santa Fe, we discussed creating a new web-site for POOMA, with > the hope of growing the user-base, and thereby the set of POOMA > stakeholders. > > I've completed a preliminary version of the web-site. Point your > browser at www.pooma.com to check it out. > > It is pretty bare-bones. Ideas for additional content, or actual > HTML, would be useful. Jeffrey, since you have eagle eyes for typos, > it would be great if you could at least spot-check the site. > > Right now, nothing else on the web links here, so it is unlikely > anyone will find it. In a couple of days, once I have everyone's > comments, I will create a link from our main web page, which will > drive additional traffic, and allow the search engines to find the > site. > > It would also be great if the old POOMA web-page > (http://www.acl.lanl.gov/pooma/) could be updated to point to, or at > least mention, the new web-site. > > Thank you, > > -- > Mark Mitchell mark at codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Thu May 17 18:22:16 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Thu, 17 May 2001 11:22:16 -0700 Subject: [pooma-admin] POOMA Web Site In-Reply-To: References: Message-ID: <20010517112216K.mitchell@codesourcery.com> >>>>> "James" == James Crotinger writes: James> This is not quite correct - SMARTS is only necessary if you James> want to achieve parallelism via threads. Pooma 2.3 also James> supports parallelism through multiprocessing and message James> passing. OK, I'll add Cheetah. James> Once we get our Nirvana accounts back, we may be able to James> update the old POOMA web page (depending on who owns these James> pages now). Do you remember where the pages are? I am in the `pooma' group, and I do have a Nirvana account. Thanks, -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From JimC at proximation.com Thu May 17 18:28:47 2001 From: JimC at proximation.com (James Crotinger) Date: Thu, 17 May 2001 11:28:47 -0700 Subject: [pooma-admin] POOMA Web Site Message-ID: > Do you remember where the pages are? I am in the `pooma' group, and I > do have a Nirvana account. Not off the top of my head. You actually have to log into the web server and transfer the files there. I can't remember the details, but perhaps they'll come back if I can poke around. Or maybe Scott remembers. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Thu May 17 18:34:45 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 17 May 2001 11:34:45 -0700 Subject: [pooma-dev] RE: [pooma-admin] POOMA Web Site In-Reply-To: <20010517112216K.mitchell@codesourcery.com>; from mark@codesourcery.com on Thu, May 17, 2001 at 11:22:16AM -0700 References: <20010517112216K.mitchell@codesourcery.com> Message-ID: <20010517113445.A10264@codesourcery.com> On Thu, May 17, 2001 at 11:22:16AM -0700, Mark Mitchell wrote: > >>>>> "James" == James Crotinger writes: > > James> This is not quite correct - SMARTS is only necessary if you > James> want to achieve parallelism via threads. Pooma 2.3 also > James> supports parallelism through multiprocessing and message > James> passing. > > OK, I'll add Cheetah. > > James> Once we get our Nirvana accounts back, we may be able to > James> update the old POOMA web page (depending on who owns these > James> pages now). > > Do you remember where the pages are? I am in the `pooma' group, and I > do have a Nirvana account. The files in n02:/am/father/vol/vol1/frameworks/pooma/framework/website look suspiciously up-to-date but they are all named *,v. I do not know where the served files are located. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From JimC at proximation.com Thu May 17 18:40:46 2001 From: JimC at proximation.com (James Crotinger) Date: Thu, 17 May 2001 11:40:46 -0700 Subject: [pooma-dev] RE: [pooma-admin] POOMA Web Site Message-ID: > The files in > n02:/am/father/vol/vol1/frameworks/pooma/framework/website > look suspiciously up-to-date but they are all named *,v. I do not > know where the served files are located. That's probably where the website's CVS repository is now. The actual server is on a different machine since the nirvana machines aren't reachable from the outside world. I think the server used to be called something like server.acl.lanl.gov, but there was some special procedure for updating it and I can't recall those details. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Fri May 18 09:11:10 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 18 May 2001 02:11:10 -0700 Subject: QMTrack Message-ID: <20010518021110S.mitchell@codesourcery.com> I have set up a QMTrack bug-tracking server for use by the POOMA project. All the POOMA developers, plus John and Jean have accounts. Your username and password are your last name. Very secure, I know. The URL for the server is: http://pooma.codesourcery.com:4242/track/ Note the trailing slash. Bookmark it! After a few days of testing, I'll connect the www.pooma.com site to this server. Please try to use QMTrack to keep track of bugs and enhancement requests for POOMA. This will provide a structured means for the Blanca developers to communicate with the POOMA developers, thereby making sure nothing falls through the cracks. -- QMTrack is the open-source issue-tracking software that CodeSourcery is building as part of the Software Carpentry project, also sponsored by LANL. POOMA is the first guinea pig for QMTrack. At this point, QMTrack provides basic functionality and is relatively robust, but we are still very early in the development effort, so there are lots of missing features, and undoubtedly lots bugs. Please be critical, but gently so -- we don't claim it's done. At this point, if you notice problems with QMTrack, you should send them directoy to: Alex Samuel Alex is the principal developer of QMTrack. (There is a QMTrack server for tracking bugs in QMTrack, but it's not exposed to the outside world yet.) We will get some synergy between these projects. QMTrack will make it easier to keep track of POOMA issues. QMTest will allow us to perform automated testing of POOMA. And your use of QMTrack and QMTest will help us make them better tools. -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From mark at codesourcery.com Fri May 18 21:59:22 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 18 May 2001 14:59:22 -0700 Subject: Weekly Status Message-ID: <20010518145922D.mitchell@codesourcery.com> Folks -- I realize that at some point I asked you to send weekly summaries to me personally. I think it would actually be better to post them here to make sure that everyone can see what everyone else is doing. Please try to make sure that you're communicating what you're doing with your (distributed) teammates, so that everyone can participate in what's going on. Thanks! -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From oldham at codesourcery.com Fri May 18 22:42:24 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 18 May 2001 15:42:24 -0700 Subject: Oldham's Weekly Pooma Report Message-ID: <200105182242.PAA08454@oz.codesourcery.com> For Pooma, this week: Created and submitted Pooma patches to expand permissible set of explicit template instantiations. This also fixed Dave Nystrom's makeOwnCopy() parallel build problem. This fixed a variant of Dave Nystrom's explicit template instantiation code. Work on fixing Pooma array test execution problems. Discuss interpolation and restriction operator implementation with Stephen Smith. Next week: Work with Stephen Smith on interpolation and restriction operators, mainly by using his code to implement operators for kernels. With someone's help, completely fix Dave Nystrom's explicit instantiation problem. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From cummings at linkline.com Sat May 19 05:45:44 2001 From: cummings at linkline.com (Julian C. Cummings) Date: Fri, 18 May 2001 22:45:44 -0700 Subject: weekly status report Message-ID: Hi All, My Pooma hours have been few and far between the past few weeks, and that will continue until June 1st, when my class is finished and we have had our Caltech ASCI Research Review. I did manage to spend a few hours today solving some problems with Particle Boundary Conditions in Nolen's MC++ code kernel. It is apparent that I need to fix the deferred destroy lists in Particles so that they are actually sorted lists of indices in ascending order. I am thinking to use STL map containers for this. The next big thing to do is try to modify this MC++ kernel to use multiple patches and then run with threads and/or MPI. One thing Nolen and I are interested in is seeing if we can create Fields that are replicated across contexts rather than being distributed. We'd like to emulate what MCNP does with distributing particles evenly across processors and storing the whole Field on every processor. If I understand things correctly, the present version of RemoteEngine will not do this for us, because it operates under the assumption that if the data is remote, there must be a corresponding RemoteEngine on some other processor that has the data locally. But I think we can just declare a single-patch Field in each context and achieve the desired effect. The only tricky part is how to do global reductions of this Field across contexts. Helpful ideas would be appreciated! Thanks, Julian C. Dr. Julian C. Cummings Staff Scientist, CACR/Caltech (626) 395-2543 cummings at cacr.caltech.edu From allan at stokes.ca Sat May 19 08:06:55 2001 From: allan at stokes.ca (Allan Stokes) Date: Sat, 19 May 2001 01:06:55 -0700 Subject: weekly status report In-Reply-To: Message-ID: Hello all, First I wish to apologize for falling under the radar for the past several weeks. The first two weeks of April I was completing another project which I had taken on to fill in the gap before the Pooma work started. During this period I tried out a new therapy (mostly vitamins) for the muscle spasms which I sometimes experience while sleeping. It seemed to help, but it left me feeling very tired, and the fatigue became cumulative. By the middle of April I was walking around in a thick mental fog. I gave up the treatment, but the fog persisted, the back spasms soon returned, my sleep was terrible, and I was pretty much ready to fold up the tent on my small corner of the universe. These last few weeks remind me of my canoe trip last September. It poured buckets for the first three days. On the forth day the sky became less black and we figured maybe the sun would come out. Then it poured for another two days. On the sixth day we saw the sun for a couple of hours. Just long enough to remember what dry felt like. Then it poured and blew and sprayed for five more days. The rain cleared an hour before we pulled ourselves up onto the beach at the end of the lake. We drove home under a beautiful sky. It wasn't until last week I started to feel myself again. The whole time it had seemed like the sun would burst through any minute, and it went on like that for a darn long time. This week I've been reinflating my sail. The hours I put in were devoted to setting up the DocBook authoring environment and planning the conceptual documentation. Next week I will begin the process of documenting something. I have plenty of notes from my explorations in March of the Pooma domain/layout code, and I expect something will emerge from that to get me started. Part of the process will be to generate some discussion about what kind of documentation people find most useful. Jeffrey has already made some requests which I will follow up next week. KAI's latest release for Redhat 7.1 was due today. Back in March I installed a version of KAI experimentally under a Redhat 6.2 virtual machine (VMWare) under w2k. It worked OK for compiling stuff, but it didn't allow useful performance testing, so I rebuilt the machine as a multiboot system. Next week I will install the new KAI on a native Redhat partition and that will become my primary environment. If the sun shines I am also interested in taking a look at the performance characteristics of Jeffrey's hydrodynamics kernel. I haven't spent much time yet observing Pooma in operation. Allan From JimC at proximation.com Mon May 21 17:26:38 2001 From: JimC at proximation.com (James Crotinger) Date: Mon, 21 May 2001 10:26:38 -0700 Subject: weekly status report Message-ID: I put in a small amount of time last week working with the LANL folks on some issues relating to interfacing with Fortran, and working on the makeOwnCopy bug in multi-patch engine. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From scotth at proximation.com Mon May 21 17:27:44 2001 From: scotth at proximation.com (Scott Haney) Date: Mon, 21 May 2001 11:27:44 -0600 Subject: Particles and NewField In-Reply-To: Message-ID: Hi Julian, Do particles now work with the new Field class? Scott From scotth at proximation.com Mon May 21 17:29:43 2001 From: scotth at proximation.com (Scott Haney) Date: Mon, 21 May 2001 11:29:43 -0600 Subject: Progress report Message-ID: I worked on designing and implementing the POOMA equivalent of the Blanca relation package. I also added the notion of priority to the updater package. I'll post more details about the design when I get further along. Scott From cummings at linkline.com Mon May 21 19:35:40 2001 From: cummings at linkline.com (Julian C. Cummings) Date: Mon, 21 May 2001 12:35:40 -0700 Subject: [pooma-dev] Particles and NewField In-Reply-To: <20010521172749.23F80153629@smtp2.linkline.com> Message-ID: Hi Scott, No, I have not tackled that yet. I did study the issues involved and sent a note around on this list a few weeks ago about what I thought was needed. I just need a few solid chunks of several hours each to sit and do the work. I should have time for it after June 1st. (If it is extremely pressing to do this sooner, I can try, but life will be better after my class and the Caltech ASCI research review are over.) The one thing I could use from the NewFields (I think I mentioned this in my earlier note) is a simple interface for determining if a Field is cell or vert centered along a given dimension. This is encoded in the offset values, but a simple query function would be helpful. The work to be done is essentially (a) modifying items used by Particles to eliminate the centering or geometry template parameter, and (b) rewriting the particle/field interpolator code to handle centering at run-time. Most Particles code will not change at all. Julian C. > -----Original Message----- > From: Scott Haney [mailto:scotth at proximation.com] > Sent: Monday, May 21, 2001 10:28 AM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] Particles and NewField > > > Hi Julian, > > Do particles now work with the new Field class? > > Scott > From stephens at proximation.com Mon May 21 21:25:15 2001 From: stephens at proximation.com (Stephen Smith) Date: Mon, 21 May 2001 14:25:15 -0700 Subject: weekly status Message-ID: I spent most of last week working on POOMA. Monday I met with John Hall and Dave Nystrom to help them compile and run POOMA with messaging. I spent a day implementing makeOwnCopy for remote engines and tracking down some problems in other engines with Jim. I read some of Blanca's code related to centerings and Jeffrey Oldham's version of their hydro code. Later this week I plan to spend two days working on getting Field stencils to support various centerings and discuss the issues with Oldham. Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Tue May 22 18:33:44 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 22 May 2001 11:33:44 -0700 Subject: Expanding Supported Explicit Instantiations Message-ID: <20010522113344.A7933@codesourcery.com> OK to commit this patch? Dave Nystrom desired to explicitly instantiate this program: #include "Pooma/NewFields.h" #define T1 NoGeometry<(int)3> #define T2 int #define T3 CompressibleBrick #define T4 Interval<(int)3> template View1,T4>::sv; I do not know the correct syntax for explicitly instantiating View1's const static bool `sv' if this is even legal. The attached patch permits instantiating #include "Pooma/NewFields.h" #define T1 NoGeometry<(int)3> #define T2 int #define T3 CompressibleBrick #define T4 Interval<(int)3> template class View1,T4>; It also permits template View0 >; without first explicitly instantiating Array<2,T2,T3>; The main idea is to break mutually recursive class definitions by defining alternative `View' classes that contain all the type definitions of their corresponding `View' classes but omit the member functions. These alternative classes provide the return type for non-templated member functions of Array and Field classes. These member functions' bodies still use the View classes. Since the alternative classes' definitions are the same as for the View classes, this trickery works. If a View class's code changes, the corresponding alternative class's code must also be changed. This might lead to future maintenance problems. Stephen Smith provided the insight for the patch so he deserves all positive credit. Send all criticisms to Jeffrey. 2001-05-22 Jeffrey D. Oldham * Array/Array.h (View0): Modify initial comment to indicate changes should also be made to AltView0. (AltView0): New class to avoid explicit instantiation problems. (ComponentView): Modify initial comment to indicate class should not be explicitly instantiated. (Array::read()): Change return type to AltView0. (Array::operator()()): Likewise. * NewField/Field.h (View1): Modify initial comment to indicate changes should also be made to AltView1. (AltView1): New class to avoid explicit instantiation problems. (Field::read()): Change return type to AltView1. (Field::readAll()): Likewise. (Field::read(s1)): Likewise. (Field::operator()()): Likewise. (Field::all()): Likewise. (Field::operator()(s1)): Likewise. Tested on sequential Linux using gcc 3.0 Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Array/Array.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v retrieving revision 1.140 diff -c -p -r1.140 Array.h *** Array/Array.h 2001/05/14 21:11:22 1.140 --- Array/Array.h 2001/05/22 17:56:30 *************** struct View1, D *** 642,647 **** --- 642,649 ---- // an existing engine cannot be any kind of slice domain. // Also, bounds checking would make no sense because it would // reduce to contains(a.domain(), a.domain()); + // + // Any changes to this class should also be made to AltView0. template struct View0 > *************** struct View0 > *** 686,691 **** --- 688,728 ---- } }; + // AltView0 avoids an instantiation problem that arises when two + // classes use each other. This class's definition should be exactly + // the same as View0 except omitting member functions. + // + // Do NOT explicitly instantiate this class. + + template + struct AltView0; + + template + struct AltView0 > + { + // Convenience typedef for the thing we're taking a view of. + + typedef Array Subject_t; + + // Deduce domains for the output type. + // At some point, we need to fix NewDomain1; until then, use + // the temporary version from Array.h. + + typedef typename Subject_t::Engine_t Engine_t; + typedef typename Subject_t::Domain_t Domain_t; + + // Deduce the template parameters for the output type. + + typedef typename NewEngine::Type_t NewEngine_t; + enum { newDim = NewEngine_t::dimensions }; + typedef typename NewEngine_t::Tag_t NewEngineTag_t; + + // The output types. + + typedef Array Type_t; + typedef Type_t ReadType_t; + }; + template struct View1, int> { *************** struct Patch > *** 1278,1283 **** --- 1315,1321 ---- //----------------------------------------------------------------------------- // ComponentView specialization for Array. + // Changes to ComponentView should also be made to AltComponentView. //----------------------------------------------------------------------------- template *************** struct ComponentView --- 1352,1362 ---- }; //----------------------------------------------------------------------------- ! // AltComponentView avoids an instantiation problem that arises when ! // two classes use each other. These classes' definitions should be ! // exactly the same as ComponentView except omitting member functions. ! // ! // Do NOT explicitly instantiate these alternative classes. //----------------------------------------------------------------------------- template *************** public: *** 1785,1791 **** // A zero-argument version of operator(), which takes a view of // array's domain, is also supplied. ! typename View0::ReadType_t read() const { typedef View0 Ret_t; --- 1826,1832 ---- // A zero-argument version of operator(), which takes a view of // array's domain, is also supplied. ! typename AltView0::ReadType_t read() const { typedef View0 Ret_t; *************** public: *** 1855,1861 **** return Ret_t::makeRead(*this, s1, s2, s3, s4, s5, s6, s7); } ! typename View0::Type_t operator()() const { typedef View0 Ret_t; --- 1896,1902 ---- return Ret_t::makeRead(*this, s1, s2, s3, s4, s5, s6, s7); } ! typename AltView0::Type_t operator()() const { typedef View0 Ret_t; Index: NewField/Field.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/Field.h,v retrieving revision 1.13 diff -c -p -r1.13 Field.h *** NewField/Field.h 2001/05/14 21:11:24 1.13 --- NewField/Field.h 2001/05/22 17:56:34 *************** struct View1Implementation specialization for indexing a field with a single domain. + // + // Any changes to View1 should also be made to AltView1. //----------------------------------------------------------------------------- template *************** struct View1 specialization for indexing a field with an int. + // + // Any changes to View1 should also be made to AltView1. //----------------------------------------------------------------------------- template *************** struct View1 + struct AltView1; + + template + struct AltView1, Sub1> + { + // Convenience typedef for the thing we're taking a view of. + + typedef Field Subject_t; + + // Deduce domains for the output type. + // At some point, we need to fix NewDomain1; until then, use + // the temporary version from NewDomain.h. + + typedef typename Subject_t::Domain_t Domain_t; + typedef TemporaryNewDomain1 NewDomain_t; + typedef typename NewDomain_t::SliceType_t SDomain_t; + + // Deduce appropriate version of implementation to dispatch to. + + static const bool sv = DomainTraits::singleValued; + typedef View1Implementation Dispatch_t; + + // The optimized domain combiner. + + typedef CombineDomainOpt Combine_t; + + // The return types. + + typedef typename Dispatch_t::ReadType_t ReadType_t; + typedef typename Dispatch_t::Type_t Type_t; + }; + + + //----------------------------------------------------------------------------- + // AltView1 avoids an instantiation problem that arises when two + // classes use each other. This class's definition should be exactly + // the same as View1 except omitting member functions. + // + // Do NOT explicitly instantiate this class. + //----------------------------------------------------------------------------- + + template + struct AltView1, int> + { + // Convenience typedef for the thing we're taking a view of. + + typedef Field Subject_t; + + // The return types. + + typedef typename Subject_t::Element_t ReadType_t; + typedef typename Subject_t::ElementRef_t Type_t; + + }; + + + //----------------------------------------------------------------------------- // View2 specialization for indexing a field with two // domains. //----------------------------------------------------------------------------- *************** public: *** 1010,1023 **** // version returns a view of the physical domain and the 'All'-suffixed // versions return a view of the total domain. ! inline typename View1::ReadType_t read() const { typedef View1 Ret_t; return Ret_t::makeRead(*this, physicalDomain()); } ! inline typename View1::ReadType_t readAll() const { typedef View1 Ret_t; --- 1079,1092 ---- // version returns a view of the physical domain and the 'All'-suffixed // versions return a view of the total domain. ! inline typename AltView1::ReadType_t read() const { typedef View1 Ret_t; return Ret_t::makeRead(*this, physicalDomain()); } ! inline typename AltView1::ReadType_t readAll() const { typedef View1 Ret_t; *************** public: *** 1025,1031 **** } template ! inline typename View1::ReadType_t read(const Sub1 &s1) const { typedef View1 Ret_t; --- 1094,1100 ---- } template ! inline typename AltView1::ReadType_t read(const Sub1 &s1) const { typedef View1 Ret_t; *************** public: *** 1048,1061 **** return Ret_t::makeRead(*this, s1, s2, s3); } ! inline typename View1::Type_t operator()() const { typedef View1 Ret_t; return Ret_t::make(*this, physicalDomain()); } ! inline typename View1::Type_t all() const { typedef View1 Ret_t; --- 1117,1130 ---- return Ret_t::makeRead(*this, s1, s2, s3); } ! inline typename AltView1::Type_t operator()() const { typedef View1 Ret_t; return Ret_t::make(*this, physicalDomain()); } ! inline typename AltView1::Type_t all() const { typedef View1 Ret_t; *************** public: *** 1063,1069 **** } template ! inline typename View1::Type_t operator()(const Sub1 &s1) const { typedef View1 Ret_t; --- 1132,1138 ---- } template ! inline typename AltView1::Type_t operator()(const Sub1 &s1) const { typedef View1 Ret_t; From wdn at lanl.gov Tue May 22 19:04:34 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Tue, 22 May 2001 13:04:34 -0600 (MDT) Subject: [pooma-dev] Expanding Supported Explicit Instantiations In-Reply-To: <20010522113344.A7933@codesourcery.com> References: <20010522113344.A7933@codesourcery.com> Message-ID: <15114.46869.343683.400751@mutley.lanl.gov> Jeffrey Oldham writes: > OK to commit this patch? > > Dave Nystrom desired to explicitly instantiate this program: > > #include "Pooma/NewFields.h" > > #define T1 NoGeometry<(int)3> > #define T2 int > #define T3 CompressibleBrick > #define T4 Interval<(int)3> > template View1,T4>::sv; > > I do not know the correct syntax for explicitly instantiating View1's > const static bool `sv' if this is even legal. The attached patch > permits instantiating I first interacted with Arch Robison at KAI about this instantiation problem and he did not comment that the syntax was wrong. Also, the KCC prelinker only instantiates the const static bool 'sv', not anything else. I'm also curious whether Jim Crotinger's idea of making 'sv' private in the hope that the compiler could optimize it away was worth considering. > #include "Pooma/NewFields.h" > > #define T1 NoGeometry<(int)3> > #define T2 int > #define T3 CompressibleBrick > #define T4 Interval<(int)3> > template class View1,T4>; > > It also permits > > template View0 >; > > without first explicitly instantiating Array<2,T2,T3>; > > The main idea is to break mutually recursive class definitions by > defining alternative `View' classes that contain all the type > definitions of their corresponding `View' classes but omit the member > functions. These alternative classes provide the return type for > non-templated member functions of Array and Field classes. These > member functions' bodies still use the View classes. Since the > alternative classes' definitions are the same as for the View classes, > this trickery works. If a View class's code changes, the > corresponding alternative class's code must also be changed. This > might lead to future maintenance problems. > > Stephen Smith provided the insight for the patch so he deserves all > positive credit. Send all criticisms to Jeffrey. > > 2001-05-22 Jeffrey D. Oldham > * Array/Array.h (View0): Modify initial comment to indicate > changes should also be made to AltView0. > (AltView0): New class to avoid explicit instantiation problems. > (ComponentView): Modify initial comment to indicate class should > not be explicitly instantiated. > (Array::read()): Change return type to AltView0. > (Array::operator()()): Likewise. > > * NewField/Field.h (View1): Modify initial comment to indicate > changes should also be made to AltView1. > (AltView1): New class to avoid explicit instantiation problems. > (Field::read()): Change return type to AltView1. > (Field::readAll()): Likewise. > (Field::read(s1)): Likewise. > (Field::operator()()): Likewise. > (Field::all()): Likewise. > (Field::operator()(s1)): Likewise. > > Tested on sequential Linux using gcc 3.0 > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.comIndex: Array/Array.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v > retrieving revision 1.140 > diff -c -p -r1.140 Array.h > *** Array/Array.h 2001/05/14 21:11:22 1.140 > --- Array/Array.h 2001/05/22 17:56:30 > *************** struct View1, D > *** 642,647 **** > --- 642,649 ---- > // an existing engine cannot be any kind of slice domain. > // Also, bounds checking would make no sense because it would > // reduce to contains(a.domain(), a.domain()); > + // > + // Any changes to this class should also be made to AltView0. > > template > struct View0 > > *************** struct View0 > > *** 686,691 **** > --- 688,728 ---- > } > }; > > + // AltView0 avoids an instantiation problem that arises when two > + // classes use each other. This class's definition should be exactly > + // the same as View0 except omitting member functions. > + // > + // Do NOT explicitly instantiate this class. > + > + template > + struct AltView0; > + > + template > + struct AltView0 > > + { > + // Convenience typedef for the thing we're taking a view of. > + > + typedef Array Subject_t; > + > + // Deduce domains for the output type. > + // At some point, we need to fix NewDomain1; until then, use > + // the temporary version from Array.h. > + > + typedef typename Subject_t::Engine_t Engine_t; > + typedef typename Subject_t::Domain_t Domain_t; > + > + // Deduce the template parameters for the output type. > + > + typedef typename NewEngine::Type_t NewEngine_t; > + enum { newDim = NewEngine_t::dimensions }; > + typedef typename NewEngine_t::Tag_t NewEngineTag_t; > + > + // The output types. > + > + typedef Array Type_t; > + typedef Type_t ReadType_t; > + }; > + > template > struct View1, int> > { > *************** struct Patch > > *** 1278,1283 **** > --- 1315,1321 ---- > > //----------------------------------------------------------------------------- > // ComponentView specialization for Array. > + // Changes to ComponentView should also be made to AltComponentView. > //----------------------------------------------------------------------------- > > template > *************** struct ComponentView *** 1314,1321 **** > }; > > //----------------------------------------------------------------------------- > ! // AltComponentView gets around the problem that instantiation problem that > ! // arises when two classes use each other. > //----------------------------------------------------------------------------- > > template > --- 1352,1362 ---- > }; > > //----------------------------------------------------------------------------- > ! // AltComponentView avoids an instantiation problem that arises when > ! // two classes use each other. These classes' definitions should be > ! // exactly the same as ComponentView except omitting member functions. > ! // > ! // Do NOT explicitly instantiate these alternative classes. > //----------------------------------------------------------------------------- > > template > *************** public: > *** 1785,1791 **** > // A zero-argument version of operator(), which takes a view of > // array's domain, is also supplied. > > ! typename View0::ReadType_t > read() const > { > typedef View0 Ret_t; > --- 1826,1832 ---- > // A zero-argument version of operator(), which takes a view of > // array's domain, is also supplied. > > ! typename AltView0::ReadType_t > read() const > { > typedef View0 Ret_t; > *************** public: > *** 1855,1861 **** > return Ret_t::makeRead(*this, s1, s2, s3, s4, s5, s6, s7); > } > > ! typename View0::Type_t > operator()() const > { > typedef View0 Ret_t; > --- 1896,1902 ---- > return Ret_t::makeRead(*this, s1, s2, s3, s4, s5, s6, s7); > } > > ! typename AltView0::Type_t > operator()() const > { > typedef View0 Ret_t; > Index: NewField/Field.h > =================================================================== > RCS file: /home/pooma/Repository/r2/src/NewField/Field.h,v > retrieving revision 1.13 > diff -c -p -r1.13 Field.h > *** NewField/Field.h 2001/05/14 21:11:24 1.13 > --- NewField/Field.h 2001/05/22 17:56:34 > *************** struct View1Implementation *** 424,429 **** > --- 424,431 ---- > > //----------------------------------------------------------------------------- > // View1 specialization for indexing a field with a single domain. > + // > + // Any changes to View1 should also be made to AltView1. > //----------------------------------------------------------------------------- > > template > *************** struct View1 *** 473,478 **** > --- 475,482 ---- > > //----------------------------------------------------------------------------- > // View1 specialization for indexing a field with an int. > + // > + // Any changes to View1 should also be made to AltView1. > //----------------------------------------------------------------------------- > > template > *************** struct View1 *** 516,521 **** > --- 520,590 ---- > > > //----------------------------------------------------------------------------- > + // AltView1 avoids an instantiation problem that arises when two > + // classes use each other. This class's definition should be exactly > + // the same as View1 except omitting member functions. > + // > + // Do NOT explicitly instantiate this class. > + //----------------------------------------------------------------------------- > + > + template > + struct AltView1; > + > + template > + struct AltView1, Sub1> > + { > + // Convenience typedef for the thing we're taking a view of. > + > + typedef Field Subject_t; > + > + // Deduce domains for the output type. > + // At some point, we need to fix NewDomain1; until then, use > + // the temporary version from NewDomain.h. > + > + typedef typename Subject_t::Domain_t Domain_t; > + typedef TemporaryNewDomain1 NewDomain_t; > + typedef typename NewDomain_t::SliceType_t SDomain_t; > + > + // Deduce appropriate version of implementation to dispatch to. > + > + static const bool sv = DomainTraits::singleValued; > + typedef View1Implementation Dispatch_t; > + > + // The optimized domain combiner. > + > + typedef CombineDomainOpt Combine_t; > + > + // The return types. > + > + typedef typename Dispatch_t::ReadType_t ReadType_t; > + typedef typename Dispatch_t::Type_t Type_t; > + }; > + > + > + //----------------------------------------------------------------------------- > + // AltView1 avoids an instantiation problem that arises when two > + // classes use each other. This class's definition should be exactly > + // the same as View1 except omitting member functions. > + // > + // Do NOT explicitly instantiate this class. > + //----------------------------------------------------------------------------- > + > + template > + struct AltView1, int> > + { > + // Convenience typedef for the thing we're taking a view of. > + > + typedef Field Subject_t; > + > + // The return types. > + > + typedef typename Subject_t::Element_t ReadType_t; > + typedef typename Subject_t::ElementRef_t Type_t; > + > + }; > + > + > + //----------------------------------------------------------------------------- > // View2 specialization for indexing a field with two > // domains. > //----------------------------------------------------------------------------- > *************** public: > *** 1010,1023 **** > // version returns a view of the physical domain and the 'All'-suffixed > // versions return a view of the total domain. > > ! inline typename View1::ReadType_t > read() const > { > typedef View1 Ret_t; > return Ret_t::makeRead(*this, physicalDomain()); > } > > ! inline typename View1::ReadType_t > readAll() const > { > typedef View1 Ret_t; > --- 1079,1092 ---- > // version returns a view of the physical domain and the 'All'-suffixed > // versions return a view of the total domain. > > ! inline typename AltView1::ReadType_t > read() const > { > typedef View1 Ret_t; > return Ret_t::makeRead(*this, physicalDomain()); > } > > ! inline typename AltView1::ReadType_t > readAll() const > { > typedef View1 Ret_t; > *************** public: > *** 1025,1031 **** > } > > template > ! inline typename View1::ReadType_t > read(const Sub1 &s1) const > { > typedef View1 Ret_t; > --- 1094,1100 ---- > } > > template > ! inline typename AltView1::ReadType_t > read(const Sub1 &s1) const > { > typedef View1 Ret_t; > *************** public: > *** 1048,1061 **** > return Ret_t::makeRead(*this, s1, s2, s3); > } > > ! inline typename View1::Type_t > operator()() const > { > typedef View1 Ret_t; > return Ret_t::make(*this, physicalDomain()); > } > > ! inline typename View1::Type_t > all() const > { > typedef View1 Ret_t; > --- 1117,1130 ---- > return Ret_t::makeRead(*this, s1, s2, s3); > } > > ! inline typename AltView1::Type_t > operator()() const > { > typedef View1 Ret_t; > return Ret_t::make(*this, physicalDomain()); > } > > ! inline typename AltView1::Type_t > all() const > { > typedef View1 Ret_t; > *************** public: > *** 1063,1069 **** > } > > template > ! inline typename View1::Type_t > operator()(const Sub1 &s1) const > { > typedef View1 Ret_t; > --- 1132,1138 ---- > } > > template > ! inline typename AltView1::Type_t > operator()(const Sub1 &s1) const > { > typedef View1 Ret_t; From oldham at codesourcery.com Tue May 22 19:14:05 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 22 May 2001 12:14:05 -0700 Subject: [pooma-dev] Expanding Supported Explicit Instantiations In-Reply-To: <15114.46869.343683.400751@mutley.lanl.gov>; from wdn@lanl.gov on Tue, May 22, 2001 at 01:04:34PM -0600 References: <20010522113344.A7933@codesourcery.com> <15114.46869.343683.400751@mutley.lanl.gov> Message-ID: <20010522121405.B8071@codesourcery.com> On Tue, May 22, 2001 at 01:04:34PM -0600, Dave Nystrom wrote: > Jeffrey Oldham writes: > > OK to commit this patch? > > > > Dave Nystrom desired to explicitly instantiate this program: > > > > #include "Pooma/NewFields.h" > > > > #define T1 NoGeometry<(int)3> > > #define T2 int > > #define T3 CompressibleBrick > > #define T4 Interval<(int)3> > > template View1,T4>::sv; > > > > I do not know the correct syntax for explicitly instantiating View1's > > const static bool `sv' if this is even legal. The attached patch > > permits instantiating > > I first interacted with Arch Robison at KAI about this instantiation problem > and he did not comment that the syntax was wrong. Also, the KCC prelinker > only instantiates the const static bool 'sv', not anything else. I was using gcc 3.0, not KCC. My comment about the correct syntax follows from Stroustrup's Appendix C.13.10 of \emph{The C++ Programming Language}, Special Edition. If I remember correctly, gcc 3.0 supports your original syntax, but it seems better to me to follow the rules Stroustrup advises. > I'm also curious whether Jim Crotinger's idea of making 'sv' private in the > hope that the compiler could optimize it away was worth considering. I think this is probably the right thing to do, but I defer to him or you to make that change. **************** Ignoring the syntax issue, does the patch permit you to do what you want? Thanks, Jeffrey D. Oldham oldham at codesourcery.com From wdn at lanl.gov Tue May 22 19:34:54 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Tue, 22 May 2001 13:34:54 -0600 (MDT) Subject: [pooma-dev] Expanding Supported Explicit Instantiations In-Reply-To: <20010522121405.B8071@codesourcery.com> References: <20010522113344.A7933@codesourcery.com> <15114.46869.343683.400751@mutley.lanl.gov> <20010522121405.B8071@codesourcery.com> Message-ID: <15114.48173.114418.948197@mutley.lanl.gov> Jeffrey Oldham writes: > On Tue, May 22, 2001 at 01:04:34PM -0600, Dave Nystrom wrote: > > Jeffrey Oldham writes: > > > OK to commit this patch? > > > > > > Dave Nystrom desired to explicitly instantiate this program: > > > > > > #include "Pooma/NewFields.h" > > > > > > #define T1 NoGeometry<(int)3> > > > #define T2 int > > > #define T3 CompressibleBrick > > > #define T4 Interval<(int)3> > > > template View1,T4>::sv; > > > > > > I do not know the correct syntax for explicitly instantiating View1's > > > const static bool `sv' if this is even legal. The attached patch > > > permits instantiating > > > > I first interacted with Arch Robison at KAI about this instantiation problem > > and he did not comment that the syntax was wrong. Also, the KCC prelinker > > only instantiates the const static bool 'sv', not anything else. > > I was using gcc 3.0, not KCC. My comment about the correct syntax > follows from Stroustrup's Appendix C.13.10 of \emph{The C++ > Programming Language}, Special Edition. If I remember correctly, gcc > 3.0 supports your original syntax, but it seems better to me to follow > the rules Stroustrup advises. I read through this section of Stroustrup again and I'm not sure what you are getting at here regarding the syntax. I would view "sv" as a member variable. Stroustrup specifically addresses in his 3 examples how to explicitly instantiate a member function. I was assuming that the prescription for a member variable was analagous based on his section and also by studying the demangled entry in the KCC .ii file. But, I'm not a language lawyer and I don't know if I am missing something here in the point you are trying to make. > > I'm also curious whether Jim Crotinger's idea of making 'sv' private in the > > hope that the compiler could optimize it away was worth considering. > > I think this is probably the right thing to do, but I defer to him or > you to make that change. I would defer to Jim since he knows Pooma 2 and I really don't at this stage. > **************** > > Ignoring the syntax issue, does the patch permit you to do what you > want? I'll have to try it out and see. One rationale for just instantiating "sv" is to minimize code bloat and compile time. The rationale for instantiating the whole class is that I don't then have to worry about someone coming along later and using other members of the View1 class that are not currently being used and then forcing the compiler to do more prelinking. It will certainly be more preferable to me to instantiate the whole View1 class than to let the prelinker scatter 1800+ instantiations of View1<...>:sv over several translation units. Also, at some point I'd like to know more about how gcc handles template instantiation when the user does not opt for explicit instantiation. I'll probably wait to explore this until I get my new laptop which will have more disk space and will be running RedHat 7.1. > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > From oldham at codesourcery.com Wed May 23 16:02:00 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 09:02:00 -0700 Subject: [pooma-dev] Expanding Supported Explicit Instantiations In-Reply-To: <15114.48173.114418.948197@mutley.lanl.gov>; from wdn@lanl.gov on Tue, May 22, 2001 at 01:34:54PM -0600 References: <20010522113344.A7933@codesourcery.com> <15114.46869.343683.400751@mutley.lanl.gov> <20010522121405.B8071@codesourcery.com> <15114.48173.114418.948197@mutley.lanl.gov> Message-ID: <20010523090200.B8277@codesourcery.com> On Tue, May 22, 2001 at 01:34:54PM -0600, Dave Nystrom wrote: > Jeffrey Oldham writes: > > On Tue, May 22, 2001 at 01:04:34PM -0600, Dave Nystrom wrote: > > > Jeffrey Oldham writes: > > > > OK to commit this patch? > > > > > > > > Dave Nystrom desired to explicitly instantiate this program: > > > > > > > > #include "Pooma/NewFields.h" > > > > > > > > #define T1 NoGeometry<(int)3> > > > > #define T2 int > > > > #define T3 CompressibleBrick > > > > #define T4 Interval<(int)3> > > > > template View1,T4>::sv; > > > > > > > > I do not know the correct syntax for explicitly instantiating View1's > > > > const static bool `sv' if this is even legal. The attached patch > > > > permits instantiating > > > > > > I first interacted with Arch Robison at KAI about this instantiation problem > > > and he did not comment that the syntax was wrong. Also, the KCC prelinker > > > only instantiates the const static bool 'sv', not anything else. > > > > I was using gcc 3.0, not KCC. My comment about the correct syntax > > follows from Stroustrup's Appendix C.13.10 of \emph{The C++ > > Programming Language}, Special Edition. If I remember correctly, gcc > > 3.0 supports your original syntax, but it seems better to me to follow > > the rules Stroustrup advises. > > I read through this section of Stroustrup again and I'm not sure what you are > getting at here regarding the syntax. I would view "sv" as a member > variable. Stroustrup specifically addresses in his 3 examples how to > explicitly instantiate a member function. I was assuming that the > prescription for a member variable was analagous based on his section and > also by studying the demangled entry in the KCC .ii file. But, I'm not a > language lawyer and I don't know if I am missing something here in the point > you are trying to make. According to the C++ standard, everything after "template" needs to be a declaration. Thus, I would write template bool View1,T4>::sv; Thanks, Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Wed May 23 16:38:18 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 09:38:18 -0700 Subject: RFA: Patch: Reverse Overzealous makeOwnCopy() Changes Message-ID: <20010523093818.A8449@codesourcery.com> OK to commit? Jim Crotinger pointed out that "View" engines aren't supposed to have makeOwnCopy(). Thus, I suggest reversing part of my overzealous makeOwnCopy() patch. With the patch (and with the patch I sent out yesterday), Dave Nystrom's explicit instantiation code still compiles. Also, the Pooma library and all the array_test tests still compile. 2001-05-23 Jeffrey D. Oldham * Engine/CompressibleBrick.cpp (Engine::makeOwnCopy()): Remove this incorrectly introduced function. * Engine/CompressibleBrick.h (Engine::makeOwnCopy()): Likewise. Tested on sequential Linux using gcc 3.0 Approved by ???Jim Crotinger (jcrotinger at mac.com)??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: CompressibleBrick.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v retrieving revision 1.25 diff -c -p -r1.25 CompressibleBrick.cpp *** CompressibleBrick.cpp 2001/05/14 21:11:23 1.25 --- CompressibleBrick.cpp 2001/05/15 14:20:24 *************** Engine(const Engine & makeOwnCopy() - // - // Causes the CompressibleBrickView-Engine to obtain a private copy of the data - // that it refers to. - // - //----------------------------------------------------------------------------- - - template - Engine &Engine::makeOwnCopy() - { - // JIM: This is probably not thread safe??? - // There is a race from checking isShared to getting into cblock's - // makeOwnCopy, which is thread safe. As a result, this should only - // be called after a blockAndEvaluate() to ensure that nobody else - // is messing with the underlying CBC while this is - // occuring. (Logically, this is necessary anyway since you probably - // want a copy of the data that results from all previous - // computations having taken place.) Also, as mentioned elsewhere, - // the current implementation results in copying uncompressed data - // in the parse thread, which will result in incorrect memory - // affinity. - - if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) - { - cblock_m.detach(this); - cblock_m.makeOwnCopy(); - cblock_m.attach(this); - - data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); - } - - return *this; - } - - //----------------------------------------------------------------------------- - // // Engine:: // elementsCompressed() const // --- 501,506 ---- Index: CompressibleBrick.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v retrieving revision 1.68 diff -c -p -r1.68 CompressibleBrick.h *** CompressibleBrick.h 2001/05/14 21:11:23 1.68 --- CompressibleBrick.h 2001/05/15 14:20:25 *************** public: *** 573,582 **** return Layout_t(domain_m).domain(); } - // Get a private copy of data viewed by this Engine. - - Engine_t &makeOwnCopy(); - // Return the block controller (uncompressed). // See comments in CompressibleBrick above. --- 573,578 ---- *************** struct NewEngine struct ElementProperties > : public MakeOwnCopyProperties > - { }; - - template - struct ElementProperties > - : public MakeOwnCopyProperties > { }; --- 817,822 ---- From oldham at codesourcery.com Wed May 23 18:02:54 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 11:02:54 -0700 Subject: RFA: src/Connect/Lux/LuxConnection.h: Add two preprocessor inclusions. Message-ID: <20010523110254.A15581@codesourcery.com> OK to commit? When trying to compile testcases in src/Connect/Lux/tests, gcc 3.0 complained that some types were unavailable. I fixed the problem by adding two #include lines. Would someone plese confirm this is the file where the two lines should be added? 2001 May 23 Jeffrey D. Oldham * LuxConnection.h: Add two inclusion preprocessor lines. Tested on sequential Linux using gcc 3.0 by compiling the test cases Approved by ???you ??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: LuxConnection.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Connect/Lux/LuxConnection.h,v retrieving revision 1.3 diff -c -p -r1.3 LuxConnection.h *** LuxConnection.h 2000/03/07 13:16:18 1.3 --- LuxConnection.h 2001/05/23 17:55:43 *************** *** 50,55 **** --- 50,57 ---- //----------------------------------------------------------------------------- #include "Connect/Connection.h" + #include "Connect/ConnectPair.h" + #include "Connect/Connector.h" #include "Connect/Lux/LuxAppPointer.h" #include "Utilities/PAssert.h" From mark at codesourcery.com Wed May 23 18:57:46 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Wed, 23 May 2001 11:57:46 -0700 Subject: [pooma-dev] Expanding Supported Explicit Instantiations In-Reply-To: <15114.46869.343683.400751@mutley.lanl.gov> References: <15114.46869.343683.400751@mutley.lanl.gov> Message-ID: <20010523115746X.mitchell@codesourcery.com> >>>>> "Dave" == Dave Nystrom writes: Dave> I'm also curious whether Jim Crotinger's idea of making 'sv' Dave> private in the hope that the compiler could optimize it away Dave> was worth considering. Probably not. Compilers generally pay little heed to `private'. In order to do the optimization, you would to prove that there is no way for the address of the static variable to escape the class, which requires looking at the bodies of all of the functions in the class. -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From JimC at proximation.com Wed May 23 19:28:18 2001 From: JimC at proximation.com (James Crotinger) Date: Wed, 23 May 2001 12:28:18 -0700 Subject: [pooma-dev] Expanding Supported Explicit Instantiations Message-ID: I'm skeptical of a compiler removing it as well. My main point was that if it really should be private, then WE can remove it by hand. Scoped macros sure would be nice. Jim > -----Original Message----- > From: Mark Mitchell [mailto:mark at codesourcery.com] > Sent: Wednesday, May 23, 2001 12:58 PM > To: wdn at lanl.gov > Cc: oldham at codesourcery.com; pooma-dev at pooma.codesourcery.com > Subject: RE: [pooma-dev] Expanding Supported Explicit Instantiations > > > >>>>> "Dave" == Dave Nystrom writes: > > Dave> I'm also curious whether Jim Crotinger's idea of making 'sv' > Dave> private in the hope that the compiler could optimize it away > Dave> was worth considering. > > Probably not. Compilers generally pay little heed to `private'. In > order to do the optimization, you would to prove that there is no way > for the address of the static variable to escape the class, which > requires looking at the bodies of all of the functions in the class. > > -- > Mark Mitchell mark at codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Wed May 23 19:41:11 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 12:41:11 -0700 Subject: RFA: Vector.h: s/iosfwd/ios/ Message-ID: <20010523124111.A17219@codesourcery.com> OK to commit? When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, gcc 3.0 complained about this line from src/Tiny/Vector.h: std::ios::fmtflags incomingFormatFlags = out.flags(); This is resolved by replacing by . 2001 May 23 Jeffrey D. Oldham * Vector.h: Replace by . Tested on sequential Linux using gcc 3.0 by compiling CartesianTest1.cpp Approved by ???you??? **************** Please be skeptical of this patch. I do not understand why was not the original choice. Also, I have not extensively tested the change. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Vector.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Tiny/Vector.h,v retrieving revision 1.25 diff -c -p -r1.25 Vector.h *** Vector.h 2000/04/28 00:04:02 1.25 --- Vector.h 2001/05/23 19:34:11 *************** class Full; *** 56,62 **** #include "Tiny/VectorEngine.h" #include "Tiny/VectorElements.h" #include "Tiny/VectorOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: --- 56,62 ---- #include "Tiny/VectorEngine.h" #include "Tiny/VectorElements.h" #include "Tiny/VectorOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: From oldham at codesourcery.com Wed May 23 19:52:26 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 12:52:26 -0700 Subject: RFA: DomainIterator.h: Add DomainTraits Specialization Message-ID: <20010523125226.A18926@codesourcery.com> OK to commit? When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, gcc 3.0 complained that a DomainTraits specialization (which one I no longer remember) was declared after the general DomainTraits. This patch resolve the problem. 2001 May 23 Jeffrey D. Oldham * DomainIterator.h: Add DomainTraits.int.h inclusion. Tested on sequential Linux using gcc 3.0 by compiling CartesianTest1.cpp and the Pooma library Approved by ???you??? Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: DomainIterator.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/DomainIterator.h,v retrieving revision 1.9 diff -c -p -r1.9 DomainIterator.h *** DomainIterator.h 2001/04/13 02:12:59 1.9 --- DomainIterator.h 2001/05/23 19:41:56 *************** *** 46,51 **** --- 46,52 ---- #include "Utilities/PAssert.h" #include "Domain/DomainTraits.h" + #include "Domain/DomainTraits.int.h" #include // ptrdiff_t #include From JimC at proximation.com Wed May 23 20:03:10 2001 From: JimC at proximation.com (James Crotinger) Date: Wed, 23 May 2001 13:03:10 -0700 Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits Specializ ation Message-ID: Since DomainIterator doesn't explicitly use the "int" specialization, it seems like this include shouldn't go here - rather it should probably go with whatever decided to use an "int" as a domain. Jim > -----Original Message----- > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > Sent: Wednesday, May 23, 2001 1:52 PM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits > Specialization > > > OK to commit? > > When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, > gcc 3.0 complained that a DomainTraits specialization (which one I no > longer remember) was declared after the general DomainTraits. This > patch resolve the problem. > > 2001 May 23 Jeffrey D. Oldham > > * DomainIterator.h: Add DomainTraits.int.h inclusion. > > Tested on sequential Linux using gcc 3.0 by compiling > CartesianTest1.cpp and the Pooma library > Approved by ???you??? > > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Wed May 23 21:14:22 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 14:14:22 -0700 Subject: Patch: Reverse Overzealous makeOwnCopy() Changes Message-ID: <20010523141422.A24461@codesourcery.com> Jim Crotinger pointed out that "View" engines aren't supposed to have makeOwnCopy(). Thus, I suggest reversing part of my overzealous makeOwnCopy() patch. With the patch (and with the patch I sent out yesterday), Dave Nystrom's explicit instantiation code still compiles. Also, the Pooma library and all the array_test tests still compile. 2001-05-23 Jeffrey D. Oldham * Engine/CompressibleBrick.cpp (Engine::makeOwnCopy()): Remove this incorrectly introduced function. * Engine/CompressibleBrick.h (Engine::makeOwnCopy()): Likewise. Tested on sequential Linux using gcc 3.0 Approved by Jim Crotinger (jcrotinger at mac.com) Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: CompressibleBrick.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.cpp,v retrieving revision 1.25 diff -c -p -r1.25 CompressibleBrick.cpp *** CompressibleBrick.cpp 2001/05/14 21:11:23 1.25 --- CompressibleBrick.cpp 2001/05/23 21:11:13 *************** Engine(const Engine & makeOwnCopy() - // - // Causes the CompressibleBrickView-Engine to obtain a private copy of the data - // that it refers to. - // - //----------------------------------------------------------------------------- - - template - Engine &Engine::makeOwnCopy() - { - // JIM: This is probably not thread safe??? - // There is a race from checking isShared to getting into cblock's - // makeOwnCopy, which is thread safe. As a result, this should only - // be called after a blockAndEvaluate() to ensure that nobody else - // is messing with the underlying CBC while this is - // occuring. (Logically, this is necessary anyway since you probably - // want a copy of the data that results from all previous - // computations having taken place.) Also, as mentioned elsewhere, - // the current implementation results in copying uncompressed data - // in the parse thread, which will result in incorrect memory - // affinity. - - if (cblock_m.isControllerValidUnlocked() && cblock_m.isShared()) - { - cblock_m.detach(this); - cblock_m.makeOwnCopy(); - cblock_m.attach(this); - - data0_m = cblock_m.data() + (cblock_m.compressed() ? 0 : baseOffset()); - } - - return *this; - } - - //----------------------------------------------------------------------------- - // // Engine:: // elementsCompressed() const // --- 501,506 ---- Index: CompressibleBrick.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Engine/CompressibleBrick.h,v retrieving revision 1.69 diff -c -p -r1.69 CompressibleBrick.h *** CompressibleBrick.h 2001/05/16 21:21:06 1.69 --- CompressibleBrick.h 2001/05/23 21:11:13 *************** public: *** 573,582 **** return domain_m; } - // Get a private copy of data viewed by this Engine. - - Engine_t &makeOwnCopy(); - // Return the block controller (uncompressed). // See comments in CompressibleBrick above. --- 573,578 ---- *************** struct NewEngine struct ElementProperties > : public MakeOwnCopyProperties > - { }; - - template - struct ElementProperties > - : public MakeOwnCopyProperties > { }; --- 817,822 ---- From oldham at codesourcery.com Wed May 23 22:16:32 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 15:16:32 -0700 Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits Specializ ation In-Reply-To: ; from JimC@proximation.com on Wed, May 23, 2001 at 01:03:10PM -0700 References: Message-ID: <20010523151632.A25831@codesourcery.com> On Wed, May 23, 2001 at 01:03:10PM -0700, James Crotinger wrote: > Since DomainIterator doesn't explicitly use the "int" specialization, it > seems like this include shouldn't go here - rather it should probably go > with whatever decided to use an "int" as a domain. > > Jim How about this? OK to commit? When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, gcc 3.0 complained that a DomainTraits specialization was declared after the general DomainTraits. This patch resolve the problem. 2001 May 23 Jeffrey D. Oldham * Domain.h: Add DomainTraits.int.h inclusion. Tested on sequential Linux using gcc 3.0 by compiling CartesianTest1.cpp and the Pooma library Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Domain.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/Domain.h,v retrieving revision 1.31 diff -c -p -r1.31 Domain.h *** Domain.h 2001/04/13 02:12:58 1.31 --- Domain.h 2001/05/23 22:13:28 *************** *** 62,67 **** --- 62,68 ---- #include "Domain/DomainBase.h" #include "Domain/DomainTraits.h" + #include "Domain/DomainTraits.int.h" #include "Utilities/NoInit.h" #include "Utilities/PAssert.h" From JimC at proximation.com Wed May 23 22:28:34 2001 From: JimC at proximation.com (James Crotinger) Date: Wed, 23 May 2001 15:28:34 -0700 Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits Specializ ation Message-ID: I don't think that's it either - the question is, who is directly causing DomainIterator to be instantiated? Jim > -----Original Message----- > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > Sent: Wednesday, May 23, 2001 4:17 PM > To: James Crotinger > Cc: pooma-dev at pooma.codesourcery.com > Subject: Re: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits > Specializ ation > > > On Wed, May 23, 2001 at 01:03:10PM -0700, James Crotinger wrote: > > Since DomainIterator doesn't explicitly use the "int" > specialization, it > > seems like this include shouldn't go here - rather it > should probably go > > with whatever decided to use an "int" as a domain. > > > > Jim > > How about this? OK to commit? > > When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, > gcc 3.0 complained that a DomainTraits specialization was declared > after the general DomainTraits. This patch resolve the problem. > > 2001 May 23 Jeffrey D. Oldham > > * Domain.h: Add DomainTraits.int.h inclusion. > > Tested on sequential Linux using gcc 3.0 by compiling > CartesianTest1.cpp and the Pooma library > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Wed May 23 22:59:55 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 15:59:55 -0700 Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits Specialization In-Reply-To: ; from JimC@proximation.com on Wed, May 23, 2001 at 03:28:34PM -0700 References: Message-ID: <20010523155955.A27740@codesourcery.com> On Wed, May 23, 2001 at 03:28:34PM -0700, James Crotinger wrote: > I don't think that's it either - the question is, who is directly causing > DomainIterator to be instantiated? I do not know. Starting with CoordinateSystems/tests/CartesianTest1.cpp with an empty main(), I repeatedly replaced header files while the problem continued to exist until I ended with #include "Domain/NewDomain.h" // problem in here? #include "Domain/DomainTraits.int.h" int main() { } Replacing the first line with the header files it includes makes the problem disappear. Thus, I conclude that the use is in Domain/NewDomain.h, not in files it includes. Every use of DomainTraits<...> uses a template parameter so I do not know what is being instantiated. Do you know of a way to have a compiler list all the templates it is instantiating? **************** How about this? OK to commit? When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, gcc 3.0 complained that a DomainTraits specialization was declared after the general DomainTraits. This patch resolve the problem. 2001 May 23 Jeffrey D. Oldham * NewDomain.h: Add DomainTraits.int.h inclusion. Tested on sequential Linux using gcc 3.0 by compiling CartesianTest1.cpp Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: NewDomain.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/NewDomain.h,v retrieving revision 1.30 diff -c -p -r1.30 NewDomain.h *** NewDomain.h 2001/04/13 02:12:59 1.30 --- NewDomain.h 2001/05/23 22:50:43 *************** *** 60,65 **** --- 60,66 ---- //----------------------------------------------------------------------------- #include "Domain/DomainTraits.h" + #include "Domain/DomainTraits.int.h" #include "Utilities/PAssert.h" //----------------------------------------------------------------------------- From oldham at codesourcery.com Wed May 23 23:32:11 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 16:32:11 -0700 Subject: View2, ...> Question Message-ID: <200105232332.QAA29742@oz.codesourcery.com> Consider class View2,int,CompressibleBrick>, Interval<2>, Interval<1> >; Must the Interval dimensions sum to a number at most 3 because the field has a dimension of 3? Thanks for the information, Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Wed May 23 23:55:25 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 16:55:25 -0700 Subject: RFA: std::ify Pooma.cpp Message-ID: <20010523165525.A30853@codesourcery.com> OK to commit this change to src/Pooma/tests/pooma.cpp? 2001 May 23 Jeffrey D. Oldham * pooma.cpp: Prepend "cerr" and "endl" with "std::". Tested on sequential Linux using gcc 3.0 by compiling the program Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: pooma.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Pooma/tests/pooma.cpp,v retrieving revision 1.3 diff -c -p -r1.3 pooma.cpp *** pooma.cpp 2000/07/21 00:10:19 1.3 --- pooma.cpp 2001/05/23 23:49:49 *************** *** 50,56 **** void newAbortHandler() { ! cerr << "Running newly installed abort handler." << endl; } --- 50,56 ---- void newAbortHandler() { ! std::cerr << "Running newly installed abort handler." << std::endl; } *************** int main(int argc, char *argv[]) *** 60,111 **** // Print out argc, argv before initialization. ! cerr << "Before initialize: argc = " << argc << ", " << endl; for (i=0; i < argc; ++i) ! cerr << " argv[" << i << "] = '" << argv[i] << "'" << endl; // Initialize POOMA ! cerr << "Initializing POOMA ..." << endl; Pooma::initialize(argc, argv); ! cerr << "After initialize: argc = " << argc << ", " << endl; for (i=0; i < argc; ++i) ! cerr << " argv[" << i << "] = '" << argv[i] << "'" << endl; // Print out some results of POOMA calls to the different POOMA streams ! POOMA_PRINT(Pooma::pinfo, "POOMA version = " << Pooma::version() << endl); ! POOMA_PRINT(Pooma::pwarn, "POOMA build date = " << Pooma::buildDate()<; from oldham@codesourcery.com on Wed, May 23, 2001 at 12:41:11PM -0700 References: <20010523124111.A17219@codesourcery.com> Message-ID: <20010523172150.A32698@codesourcery.com> I revise the request to modify Tiny/Vector.h by adding the same change to Tiny/TinyMatrix.h. OK to commit? When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, gcc 3.0 complained about this line from src/Tiny/Vector.h: std::ios::fmtflags incomingFormatFlags = out.flags(); This is resolved by replacing by . A similar problem in TinyMatrix.h was demonstrated by src/Utilities/LINUXgcc/delete_test1.cpp. 2001 May 23 Jeffrey D. Oldham * TinyMatrix.h: Replace by . * Vector.h: Likewise. Tested on sequential Linux using gcc 3.0 by compiling CartesianTest1.cpp Approved by ???you??? I do not understand why was not the original choice. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: TinyMatrix.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Tiny/TinyMatrix.h,v retrieving revision 1.11 diff -c -p -r1.11 TinyMatrix.h *** TinyMatrix.h 2001/04/05 09:34:47 1.11 --- TinyMatrix.h 2001/05/24 00:18:15 *************** class Full; *** 56,62 **** #include "Tiny/TinyMatrixEngine.h" #include "Tiny/TinyMatrixElements.h" #include "Tiny/TinyMatrixOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: --- 56,62 ---- #include "Tiny/TinyMatrixEngine.h" #include "Tiny/TinyMatrixElements.h" #include "Tiny/TinyMatrixOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: Index: Vector.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Tiny/Vector.h,v retrieving revision 1.25 diff -c -p -r1.25 Vector.h *** Vector.h 2000/04/28 00:04:02 1.25 --- Vector.h 2001/05/24 00:18:15 *************** class Full; *** 56,62 **** #include "Tiny/VectorEngine.h" #include "Tiny/VectorElements.h" #include "Tiny/VectorOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: --- 56,62 ---- #include "Tiny/VectorEngine.h" #include "Tiny/VectorElements.h" #include "Tiny/VectorOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: From oldham at codesourcery.com Thu May 24 00:33:02 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Wed, 23 May 2001 17:33:02 -0700 Subject: RFA: delete_test1 Modifications Message-ID: <20010523173302.B32698@codesourcery.com> OK to commit? Compiling src/Utilities/tests/delete_test1.cpp showed that the vector type `Array_t' was declared to store doubles but actually stored integers. Also, a call to std::memmove() illegally converted vector iterators to pointers. The alternative call to std::copy() is instead used. 2001 May 23 Jeffrey D. Oldham * delete_test1.cpp (Array_t): s/vector/vector/ (delete_shiftup_test2): Remove "optimization" call to memmove. Tested on sequential Linux using gcc 3.0 by compiling the program Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: delete_test1.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/tests/delete_test1.cpp,v retrieving revision 1.7 diff -c -p -r1.7 delete_test1.cpp *** delete_test1.cpp 2001/03/21 00:56:09 1.7 --- delete_test1.cpp 2001/05/24 00:22:49 *************** int main(int argc, char *argv[]) *** 94,100 **** typedef std::vector KillList_t; ! typedef std::vector Array_t; void delete_shiftup_orig (Array_t &data, const KillList_t &killList); void delete_shiftup_test1(Array_t &data, const KillList_t &killList); --- 94,100 ---- typedef std::vector KillList_t; ! typedef std::vector Array_t; void delete_shiftup_orig (Array_t &data, const KillList_t &killList); void delete_shiftup_test1(Array_t &data, const KillList_t &killList); *************** void delete_shiftup_test2(Array_t &data, *** 618,635 **** if (inext < killed) copy_end_index = killList[inext]; ! const int length = copy_end_index - copy_begin_index; ! ! if (length < 100) ! std::copy(data_begin + copy_begin_index, ! data_begin + copy_end_index, ! data_begin + insert_index); ! else ! std::memmove(data_begin + insert_index, ! data_begin + copy_begin_index, ! sizeof(Array_t::value_type)*length); ! ! insert_index += length; } } --- 618,627 ---- if (inext < killed) copy_end_index = killList[inext]; ! std::copy(data_begin + copy_begin_index, ! data_begin + copy_end_index, ! data_begin + insert_index); ! insert_index += copy_end_index - copy_begin_index; } } From allan at stokes.ca Thu May 24 11:57:23 2001 From: allan at stokes.ca (Allan Stokes) Date: Thu, 24 May 2001 04:57:23 -0700 Subject: docbook overview Message-ID: Hello everyone, Back at the Proximation meeting it was suggested that the Pooma documentation be prepared in DocBook format. Not everyone there was familiar with DocBook so I'd like to take a few minutes to describe DocBook and the authoring process so everyone understands the document format. About ten years ago SGML (Generalized Markup Language) became an official standard for document markup. This is an extremely rich structure which does not lend itself to simple applications. For example, in SGML you can redeclare the characters which function as markup delimiters. There isn't much you take for granted without a full parse. HTML is a simplified language which includes a subset of all possible SGML documents. The HTML subset was designed to exclude SGML mechanisms which complicate parsing so that HTML documents would be simple to read and process. Unfortunately, the markup elements included in HTML conflate structure with layout. Tags such as

and

    express paragraph and list document elements. But you also find stuff like this (as on the Pooma.com home page):
    The table structure and the visual presentation are hopelessly mangled together. This makes HTML a poor choice for creating portable documents. TeX also suffers from unnatural commingling, which is one of several reasons people find TeX unpleasant to use. In the case of TeX, the problem was partly addressed by creating LaTeX as a document language. LaTeX allows the author to describe the structure of the document directly and (mostly) keeps the visual mechanics behind the curtains. DocBook was invented to solve the same problem with HTML: separating structure from presentation. The structure DocBook describes is everything you might want to put in a book. Here is a small scrap which I created while testing my DocBook tools to give the flavour of the notation. Allan's First DocBook Book Allan Stokes 2001 Allan Stokes Foreward I survived PSGML. chapters MUST have a title The location of the PSGML tutorial is www.lysator.liu.se And so it goes. This is a valid SGML document. The first line declares the document data type (DTD) which governs the structure of the rest of the document. The DTD formally defines what markup elements are legal, required, optional, etc. If you run this scrap through a formal SGML validator, the validator will be able to tell you if your document obeys the rules imposed by the DTD. This fragment references the DocBook DTD for DocBook version 4.1. With this background I can now define what DocBook is. DocBook is an SGML DTD. Presently the DocBook DTD is about 300,000 characters of SGML in SGML DTD syntax which defines the vast majority of document elements which any technical book might wish to include. O'Reilly has published high quality technical books directly from DocBook sources. DocBook is also used for electronic documentation. The Linux Documentation Project (LDP) has standardized on DocBook, and FreeBSD is in the process of converting much of their own online documentation into DocBook format. The tools required to work with DocBook are now standard components on many of these platforms, so DocBook has become exceptionally portable. A common stumbling block in understanding DocBook is that DocBook itself provides no tools. DocBook is an SGML DTD. The DocBook DTD is essentially an SGML document in its own right. (In the SGML world, everything is a document. When you have a hammer ...) The core tool for working with DocBook is the SGML validator. A formal SGML validator parses the DTD to determine the rules which govern the document instance which follows. The validator will tell you if your DocBook document is a legal document. In the purest sense, DocBook defines a subset of all possible SGML documents as being legal DocBook documents. The semantics of the markup are defined by the tools used in the postproduction. All DocBook gives us is a structure for composing well-formed documents. We need to address the issue of publishing the document separately. To do this you need an SGML processor which is capable of converting the DocBook source document into a backend format. There are many tools out there which can manipulate SGML so there are many ways to publish a DocBook document. In the non-commercial world, DocBook publishing is usually done with Jade (a free tool written by James Clark). Jade comes with a set of standard stylesheets for a variety of backend formats. The quality of output is quite acceptable using the default stylesheets. It is unlikely that we will wish to make any changes to the standard stylesheets for publishing the Pooma documentation. You can typically use Jade without having to deal with much of Jade's complexity. But I'll describe Jade anyway. There are a variety of standards for specifying stylesheets. Jade supports the DSSSL standard. DSSSL stylesheets are written in a Scheme-like language. DSSSL processing reminds me of Pooma. The DocBook document is an SGML tree structure (much like a Pooma template expression), and DSSSL behaves like an expression template which walks the tree structure and transforms it (decorates, trims, etc.) into a new tree structure, then finally you flatten the whole thing for output (e.g. evaluate). DSSSL is a functional language which iterates via tail recursion. A DSSSL stylesheet, surprise, is itself a valid SGML document. (It is even possible to use Jade to transform DSSSL stylesheets into other DSSSL stylesheets. It's this kind of thing which gives DSSSL a cult reputation. Let go of your mouse and back away quietly.) The primary backend formats supported by Jade are HTML, RTF, TeX. The TeX produced by Jade is suitable for conversion into high quality Postscript or PDF. Jade is easy enough to use, but configuring Jade involves a couple of frustrating steps. SGML contains several methods of indirection which are used extensively to modularize the implementation of the DocBook DTD and the DSSSL stylesheets. Most SGML entities are reference via public identifiers (as opposed to host filenames). Most SGML tools resolve the public identifiers by searching site-local files called catalogs. The catalog files supply local mappings to names which can be resolved on the local file system. Most SGML toolsets expect the catalog configuration to be done manually before all the SGML magic will work. Invoking Jade with the right combinations of stylesheets and backend formats is moderately tricky as well. The "DocBook Definitive Guide" presents a solution to this problem which demonstrates typical DSSSL trickery. A DSSSL stylesheet is an SGML document whose structure is defined by a DSSSL DTD. What they do is modify the standard DSSSL DTD to allow annotations to be placed inside the DSSSL stylesheet which define what combinations of stylesheets and backends are appropriate. Then they supply a Perl script which uses Jade to look inside the DSSSL stylesheet to find the annotations which govern how the backend format specified on the command line should be produced. The whole thing is slick when it works, but initially you get a severe dose of abstraction shock trying to figure out which bit of syntax functions at what level. I have most of this stuff working in my own environment. Once I figure out how I accomplished this feat I think it would be a good idea to document my Jade configuration and publishing process. Perhaps these notes would be suitable for a web page somewhere on pooma.com. (Is that stuff under source control?) The final piece of the puzzle is the authoring process. Generally, everything I've found on the web about authoring DocBook applies to emacs. emacs has a psgml package which defines a major mode for editing DocBook documents. psgml defines several menus and many keystrokes for applying syntax directed markup. When you load your DocBook document, psgml parses the DocBook DTD to determine the required markup structure for your document. It will prompt you on legal completions when you get lost in tricky annotations. It also has hooks to run external SGML validators to find errors in your markup. You can also automate the process of publishing your documents using Jade by commands invoked from within emacs. There are also a number of commercial applications which provide the same capabilities (syntax directed editing of SGML documents). psgml is a generic setup. I discovered that I needed to apply a number of tweaks to emacs to make the configuration usable. For example, psgml doesn't necessarily know how you have your catalog files set up when invoking external tools. Maintaining an existing DocBook document manually (e.g. without setting up psgml) is not much worse than maintaining HTML manually. However, I doubt anyone would want to crank new material without the support of something like psgml. There's another aspect of DocBook which I should mention briefly because many of the web materials talk about it. So far I've described the SGML version of DocBook and the tools appropriate for publishing SGML DocBook (Jade/DSSSL). There is also a parallel version of DocBook in XML format. XML is also an SGML language, simplified even more than HTML. The SGML version of DocBook is slightly more human friendly so most people write in the SGML dialect. The interconversion is mechanical. Jade and DSSSL are mature tools (with many limitations) which are no longer being aggressively developed, in part because DSSSL/Scheme is regarded as overkill. The ongoing work is mostly in the XML camp now. XML defines several different stylesheets languages (e.g. CSS) and different transformation tools (e.g. XSL/XSLT). When browsers fully support HTML/CSS it will be possible to publish XML DocBook documents directly to the web. The web browser will do the presentation directly from the style sheet. The XML version of DocBook uses an XML syntax for declaring the DocBook DTD. If I understand the situation correctly, the XML syntax is slightly less expressive than the SGML syntax, so the two DocBook DTDs are not presently formally equivalent. The next major version of DocBook is supposed to address this issue. The XML tools at this point are mostly experimental. Within the next few years it is anticipated that the new XML model will largely supplant the Jade/DSSSL process. It will be a different way of publishing the same source documents. I hope that gives people a good overview of what DocBook is, where it is going, and how the process fits together. Once I finish collecting my installation notes I'll set up my document framework for the Pooma concepts. Allan From JimC at proximation.com Thu May 24 16:30:08 2001 From: JimC at proximation.com (James Crotinger) Date: Thu, 24 May 2001 09:30:08 -0700 Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits Specializ ation Message-ID: > Do you know of a way to have a compiler list all > the templates it is instantiating? No, but one of the features I really like about KCC is that when it gets an error while instantiating a template it gives you a full list of what it was instantiating when the error occurred, which is usually sufficient to figure these things out. It would be nice for GCC to do something similar instead of just giving the line number of the error. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From JimC at proximation.com Thu May 24 16:33:45 2001 From: JimC at proximation.com (James Crotinger) Date: Thu, 24 May 2001 09:33:45 -0700 Subject: [pooma-dev] RFA: delete_test1 Modifications Message-ID: The memmove optimization was fairly substantial when I tested it. I think it would be better to modify the code to pass addresses to memmove - again this gets to the question of whether it is really OK to use &a.begin()[0] to be the address of the 0th element, etc. Jim > -----Original Message----- > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > Sent: Wednesday, May 23, 2001 6:33 PM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] RFA: delete_test1 Modifications > > > OK to commit? > > Compiling src/Utilities/tests/delete_test1.cpp showed that the vector > type `Array_t' was declared to store doubles but actually stored > integers. Also, a call to std::memmove() illegally converted vector > iterators to pointers. The alternative call to std::copy() is instead > used. > > 2001 May 23 Jeffrey D. Oldham > > * delete_test1.cpp (Array_t): s/vector/vector/ > (delete_shiftup_test2): Remove "optimization" call to memmove. > > Tested on sequential Linux using gcc 3.0 by compiling the program > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Thu May 24 16:45:39 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 24 May 2001 09:45:39 -0700 Subject: [pooma-dev] RFA: delete_test1 Modifications In-Reply-To: ; from JimC@proximation.com on Thu, May 24, 2001 at 09:33:45AM -0700 References: Message-ID: <20010524094539.A448@codesourcery.com> On Thu, May 24, 2001 at 09:33:45AM -0700, James Crotinger wrote: > The memmove optimization was fairly substantial when I tested it. I think it > would be better to modify the code to pass addresses to memmove - again this > gets to the question of whether it is really OK to use &a.begin()[0] to be > the address of the 0th element, etc. Yes, I imagine that memmove() is significantly faster than copy(), but I would prefer to have code that is guaranteed to compile rather than fast code that compiles only for certain platforms. > > -----Original Message----- > > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > > Sent: Wednesday, May 23, 2001 6:33 PM > > To: pooma-dev at pooma.codesourcery.com > > Subject: [pooma-dev] RFA: delete_test1 Modifications > > > > > > OK to commit? > > > > Compiling src/Utilities/tests/delete_test1.cpp showed that the vector > > type `Array_t' was declared to store doubles but actually stored > > integers. Also, a call to std::memmove() illegally converted vector > > iterators to pointers. The alternative call to std::copy() is instead > > used. > > > > 2001 May 23 Jeffrey D. Oldham > > > > * delete_test1.cpp (Array_t): s/vector/vector/ > > (delete_shiftup_test2): Remove "optimization" call to memmove. > > > > Tested on sequential Linux using gcc 3.0 by compiling the program > > Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com From JimC at proximation.com Thu May 24 16:48:07 2001 From: JimC at proximation.com (James Crotinger) Date: Thu, 24 May 2001 09:48:07 -0700 Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits Specializ ation Message-ID: Actually, will the problem be fixed if you include DomainTraits.h and DomainTraits.int.h in Array.h and NewField/Field.h? These look like the culprits - they define these ViewN structs, which make use of the DomainTraits template, but the DomainTraits template and its specializations are never included. Further, these are used to implement the generic operator(), which is the main place where we need to detect if someone is passing an int as an argument. (The general DomainTraits template is always included implicitly by the client who uses a particular Domain, but the int specialization is not - I don't know why this works with other compilers.) Jim > -----Original Message----- > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > Sent: Thursday, May 24, 2001 10:09 AM > To: JimC at proximation.com > Cc: pooma-dev at pooma.codesourcery.com > Subject: Re: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits > Specialization > > > On Wed, May 23, 2001 at 03:28:34PM -0700, James Crotinger wrote: > > I don't think that's it either - the question is, who is > directly causing > > DomainIterator to be instantiated? > > I do not know. Starting with > CoordinateSystems/tests/CartesianTest1.cpp with an empty main(), I > repeatedly replaced header files while the problem continued to exist > until I ended with > > #include "Domain/NewDomain.h" // problem in here? > #include "Domain/DomainTraits.int.h" > > int main() > { > } > > Replacing the first line with the header files it includes makes the > problem disappear. Thus, I conclude that the use is in > Domain/NewDomain.h, not in files it includes. Every use of > DomainTraits<...> uses a template parameter so I do not know what is > being instantiated. Do you know of a way to have a compiler list all > the templates it is instantiating? > > **************** > > How about this? OK to commit? > > When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, > gcc 3.0 complained that a DomainTraits specialization was declared > after the general DomainTraits. This patch resolve the problem. > > 2001 May 23 Jeffrey D. Oldham > > * NewDomain.h: Add DomainTraits.int.h inclusion. > > Tested on sequential Linux using gcc 3.0 by compiling > CartesianTest1.cpp > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JimC at proximation.com Thu May 24 16:49:24 2001 From: JimC at proximation.com (James Crotinger) Date: Thu, 24 May 2001 09:49:24 -0700 Subject: [pooma-dev] RFA: delete_test1 Modifications Message-ID: Actually, I think "fast code" is one of our prime directives. We should try to find a way to do both. Jim > -----Original Message----- > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > Sent: Thursday, May 24, 2001 10:46 AM > To: James Crotinger > Cc: pooma-dev at pooma.codesourcery.com > Subject: Re: [pooma-dev] RFA: delete_test1 Modifications > > > On Thu, May 24, 2001 at 09:33:45AM -0700, James Crotinger wrote: > > The memmove optimization was fairly substantial when I > tested it. I think it > > would be better to modify the code to pass addresses to > memmove - again this > > gets to the question of whether it is really OK to use > &a.begin()[0] to be > > the address of the 0th element, etc. > > Yes, I imagine that memmove() is significantly faster than copy(), but > I would prefer to have code that is guaranteed to compile rather than > fast code that compiles only for certain platforms. > > > > -----Original Message----- > > > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > > > Sent: Wednesday, May 23, 2001 6:33 PM > > > To: pooma-dev at pooma.codesourcery.com > > > Subject: [pooma-dev] RFA: delete_test1 Modifications > > > > > > > > > OK to commit? > > > > > > Compiling src/Utilities/tests/delete_test1.cpp showed > that the vector > > > type `Array_t' was declared to store doubles but actually stored > > > integers. Also, a call to std::memmove() illegally > converted vector > > > iterators to pointers. The alternative call to > std::copy() is instead > > > used. > > > > > > 2001 May 23 Jeffrey D. Oldham > > > > > > * delete_test1.cpp (Array_t): s/vector/vector/ > > > (delete_shiftup_test2): Remove "optimization" call to memmove. > > > > > > Tested on sequential Linux using gcc 3.0 by compiling the program > > > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephens at proximation.com Thu May 24 17:06:41 2001 From: stephens at proximation.com (Stephen Smith) Date: Thu, 24 May 2001 10:06:41 -0700 Subject: [pooma-dev] RFA: std::ify Pooma.cpp Message-ID: This looks fine. I'm kind of surprised the code compiled in the first place. (Actually it's kind of disturbing that include "Pooma/Pooma.h" brings in .) OK to commit. Stephen -----Original Message----- From: Jeffrey Oldham [mailto:oldham at codesourcery.com] Sent: Wednesday, May 23, 2001 5:55 PM To: pooma-dev at pooma.codesourcery.com Subject: [pooma-dev] RFA: std::ify Pooma.cpp OK to commit this change to src/Pooma/tests/pooma.cpp? 2001 May 23 Jeffrey D. Oldham * pooma.cpp: Prepend "cerr" and "endl" with "std::". Tested on sequential Linux using gcc 3.0 by compiling the program Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From JimC at proximation.com Thu May 24 17:09:48 2001 From: JimC at proximation.com (James Crotinger) Date: Thu, 24 May 2001 10:09:48 -0700 Subject: [pooma-dev] RFA: std::ify Pooma.cpp Message-ID: It shouldn't - his change was to a test, not to Pooma.h. Jim -----Original Message----- From: Stephen Smith [mailto:stephens at proximation.com] Sent: Thursday, May 24, 2001 11:07 AM To: 'Jeffrey Oldham'; pooma-dev at pooma.codesourcery.com Subject: RE: [pooma-dev] RFA: std::ify Pooma.cpp This looks fine. I'm kind of surprised the code compiled in the first place. (Actually it's kind of disturbing that include "Pooma/Pooma.h" brings in .) OK to commit. Stephen -----Original Message----- From: Jeffrey Oldham [ mailto:oldham at codesourcery.com ] Sent: Wednesday, May 23, 2001 5:55 PM To: pooma-dev at pooma.codesourcery.com Subject: [pooma-dev] RFA: std::ify Pooma.cpp OK to commit this change to src/Pooma/tests/pooma.cpp? 2001 May 23 Jeffrey D. Oldham * pooma.cpp: Prepend "cerr" and "endl" with "std::". Tested on sequential Linux using gcc 3.0 by compiling the program Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephens at proximation.com Thu May 24 17:17:32 2001 From: stephens at proximation.com (Stephen Smith) Date: Thu, 24 May 2001 10:17:32 -0700 Subject: [pooma-dev] RFA: src/Connect/Lux/LuxConnection.h: Add two pre processor inclusions. Message-ID: OK to commit. The includes are necessary. The Connection directories are somewhat experimental, since you need PAWS and LUX to really test the code, and they are still under development at LANL. (PAWS is a high performance package for shipping data between running parallel applications, and LUX is parallel rendering tool.) Stephen -----Original Message----- From: Jeffrey Oldham [mailto:oldham at codesourcery.com] Sent: Wednesday, May 23, 2001 12:03 PM To: pooma-dev at pooma.codesourcery.com Subject: [pooma-dev] RFA: src/Connect/Lux/LuxConnection.h: Add two preprocessor inclusions. OK to commit? When trying to compile testcases in src/Connect/Lux/tests, gcc 3.0 complained that some types were unavailable. I fixed the problem by adding two #include lines. Would someone plese confirm this is the file where the two lines should be added? 2001 May 23 Jeffrey D. Oldham * LuxConnection.h: Add two inclusion preprocessor lines. Tested on sequential Linux using gcc 3.0 by compiling the test cases Approved by ???you ??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Thu May 24 17:20:13 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 24 May 2001 10:20:13 -0700 Subject: Patch: std::ify pooma.cpp Message-ID: <20010524102013.B448@codesourcery.com> 2001 May 24 Jeffrey D. Oldham * pooma.cpp: Prepend "cerr" and "endl" with "std::". Tested on sequential Linux using gcc 3.0 by compiling the program Approved by Stephen Smith Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: pooma.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Pooma/tests/pooma.cpp,v retrieving revision 1.3 diff -c -p -r1.3 pooma.cpp *** pooma.cpp 2000/07/21 00:10:19 1.3 --- pooma.cpp 2001/05/23 23:49:49 *************** *** 50,56 **** void newAbortHandler() { ! cerr << "Running newly installed abort handler." << endl; } --- 50,56 ---- void newAbortHandler() { ! std::cerr << "Running newly installed abort handler." << std::endl; } *************** int main(int argc, char *argv[]) *** 60,111 **** // Print out argc, argv before initialization. ! cerr << "Before initialize: argc = " << argc << ", " << endl; for (i=0; i < argc; ++i) ! cerr << " argv[" << i << "] = '" << argv[i] << "'" << endl; // Initialize POOMA ! cerr << "Initializing POOMA ..." << endl; Pooma::initialize(argc, argv); ! cerr << "After initialize: argc = " << argc << ", " << endl; for (i=0; i < argc; ++i) ! cerr << " argv[" << i << "] = '" << argv[i] << "'" << endl; // Print out some results of POOMA calls to the different POOMA streams ! POOMA_PRINT(Pooma::pinfo, "POOMA version = " << Pooma::version() << endl); ! POOMA_PRINT(Pooma::pwarn, "POOMA build date = " << Pooma::buildDate()<; from JimC@proximation.com on Thu, May 24, 2001 at 10:09:48AM -0700 References: Message-ID: <20010524102307.C448@codesourcery.com> Pooma/Pooma.h includes Utilities/Inform.h includes so is included by Pooma.h. Thanks, Jeffrey D. Oldham oldham at codesourcery.com On Thu, May 24, 2001 at 10:09:48AM -0700, James Crotinger wrote: > It shouldn't - his change was to a test, not to Pooma.h. > > Jim > > -----Original Message----- > From: Stephen Smith [mailto:stephens at proximation.com] > Sent: Thursday, May 24, 2001 11:07 AM > To: 'Jeffrey Oldham'; pooma-dev at pooma.codesourcery.com > Subject: RE: [pooma-dev] RFA: std::ify Pooma.cpp > > > > This looks fine. I'm kind of surprised the code compiled > in the first place. (Actually it's kind of disturbing > that include "Pooma/Pooma.h" brings in .) > > OK to commit. > > Stephen > > -----Original Message----- > From: Jeffrey Oldham [ mailto:oldham at codesourcery.com > ] > Sent: Wednesday, May 23, 2001 5:55 PM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] RFA: std::ify Pooma.cpp > > > OK to commit this change to src/Pooma/tests/pooma.cpp? > > 2001 May 23 Jeffrey D. Oldham > > * pooma.cpp: Prepend "cerr" and "endl" with "std::". > > Tested on sequential Linux using gcc 3.0 by compiling the program > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -- Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Thu May 24 17:39:09 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 24 May 2001 10:39:09 -0700 Subject: Patch LuxConnection.h: Add Two Inclusion Lines Message-ID: <20010524103909.B1064@codesourcery.com> When trying to compile testcases in src/Connect/Lux/tests, gcc 3.0 complained that some types were unavailable. I fixed the problem by adding two #include lines. 2001 May 24 Jeffrey D. Oldham * LuxConnection.h: Add two inclusion preprocessor lines. Tested on sequential Linux using gcc 3.0 by compiling the test cases Approved by Stephen Smith Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: LuxConnection.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Connect/Lux/LuxConnection.h,v retrieving revision 1.3 diff -c -p -r1.3 LuxConnection.h *** LuxConnection.h 2000/03/07 13:16:18 1.3 --- LuxConnection.h 2001/05/23 17:55:43 *************** *** 50,55 **** --- 50,57 ---- //----------------------------------------------------------------------------- #include "Connect/Connection.h" + #include "Connect/ConnectPair.h" + #include "Connect/Connector.h" #include "Connect/Lux/LuxAppPointer.h" #include "Utilities/PAssert.h" From oldham at codesourcery.com Thu May 24 20:48:33 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 24 May 2001 13:48:33 -0700 Subject: [pooma-dev] RFA: delete_test1 Modifications In-Reply-To: ; from JimC@proximation.com on Thu, May 24, 2001 at 09:49:24AM -0700 References: Message-ID: <20010524134833.A1897@codesourcery.com> For those skipping intermediary emails, the discussion is whether memmove() is faster than copy(). Attached is a program that constructs a vector, copies its contents to another vector, and then checks the copy for correctness. On Linux/gcc3.0 and Irix6.5/KCC, I cannot find any significant speed difference between std::copy and std::memmove for vectors of doubles. Given this result, may we use std::copy() everywhere since it is guaranteed to compile? Thanks, Jeffrey D. Oldham oldham at codesourcery.com On Thu, May 24, 2001 at 09:49:24AM -0700, James Crotinger wrote: > Actually, I think "fast code" is one of our prime directives. We should try > to find a way to do both. > > Jim > > > -----Original Message----- > > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > > Sent: Thursday, May 24, 2001 10:46 AM > > To: James Crotinger > > Cc: pooma-dev at pooma.codesourcery.com > > Subject: Re: [pooma-dev] RFA: delete_test1 Modifications > > > > > > On Thu, May 24, 2001 at 09:33:45AM -0700, James Crotinger wrote: > > > The memmove optimization was fairly substantial when I > > tested it. I think it > > > would be better to modify the code to pass addresses to > > memmove - again this > > > gets to the question of whether it is really OK to use > > &a.begin()[0] to be > > > the address of the 0th element, etc. > > > > Yes, I imagine that memmove() is significantly faster than copy(), but > > I would prefer to have code that is guaranteed to compile rather than > > fast code that compiles only for certain platforms. > > > > > > -----Original Message----- > > > > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > > > > Sent: Wednesday, May 23, 2001 6:33 PM > > > > To: pooma-dev at pooma.codesourcery.com > > > > Subject: [pooma-dev] RFA: delete_test1 Modifications > > > > > > > > > > > > OK to commit? > > > > > > > > Compiling src/Utilities/tests/delete_test1.cpp showed > > that the vector > > > > type `Array_t' was declared to store doubles but actually stored > > > > integers. Also, a call to std::memmove() illegally > > converted vector > > > > iterators to pointers. The alternative call to > > std::copy() is instead > > > > used. > > > > > > > > 2001 May 23 Jeffrey D. Oldham > > > > > > > > * delete_test1.cpp (Array_t): s/vector/vector/ > > > > (delete_shiftup_test2): Remove "optimization" call to memmove. > > > > > > > > Tested on sequential Linux using gcc 3.0 by compiling the program > > > > Approved by ???you??? > > > > Thanks, > > Jeffrey D. Oldham > > oldham at codesourcery.com > > -- Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- // Program to compare times for std::copy, std::copy_n, and // std::memmove. If copying from one vector to the other fails, // either a nonzero return value is returned (if printing is turned // off) or a message is printed out. // Command-line arguments: // 1. size of vector to copy // 2. name of function to use: "copy" or "copy_n" or "memmove" // To print information while the program is running, compile with // "PRINT" defined. #include #include #include #include #include // has equal() and copy() #include // has strcasecmp() int main(int argc, char *argv[]) { typedef std::vector vector_t; // Process the command-line arguments. if (argc != 3) { std::cerr << argv[0] << ": vector_size copy_function\n"; return EXIT_FAILURE; } vector_t::size_type vectorSize = strtoul(argv[1], static_cast(0), 0); // Construct the original vector. vector_t v; vector_t vCopy (vectorSize); for (vector_t::size_type size = vectorSize; size > 0; --size) v.push_back(size); #ifdef PRINT std::cout << "Hello, world" << std::endl; std::cout << "v's size: " << v.size () << std::endl; // TMP typedef vector_t::iterator iter_t; // TMP fix the warning of unused variable. It has no space. std::iterator_traits::pointer ptr; std::cout << "v contains:\n"; std::copy(v.begin(), v.end(), std::ostream_iterator(std::cout, " ")); std::cout << std::endl; #endif // PRINT // Copy the vector. if (strcasecmp (argv[2], "copy") == 0) std::copy(v.begin(), v.end(), vCopy.begin()); else if (strcasecmp (argv[2], "copy_n") == 0) std::copy_n(v.begin(), vectorSize, vCopy.begin()); else { // std::memmove vector_t::pointer vBegin = &(v[0]); vector_t::pointer vCopyBegin = &(vCopy[0]); std::memmove(static_cast(vBegin), static_cast(vCopyBegin), vectorSize * sizeof(vector_t::value_type)); } // Check the copy for correctness. if (std::equal(v.begin(), v.end(), vCopy.begin())) { #ifdef PRINT std::cout << "Copied vector equals the original vector.\n"; #else ; #endif // PRINT } else { #ifndef PRINT return EXIT_FAILURE; #else std::cout << "Oops! Copied vector does not equal the original vector.\n"; std::cout << "Original vector:\n"; std::copy(v.begin(), v.end(), std::ostream_iterator(std::cout, " ")); std::cout << std::endl; std::cout << "Copied vector:\n"; std::copy(vCopy.begin(), vCopy.end(), std::ostream_iterator(std::cout, " ")); std::cout << std::endl; #endif // PRINT } #ifdef PRINT std::cout << "Goodbye, world" << std::endl; #endif // PRINT return 0; } From JimC at proximation.com Thu May 24 23:17:54 2001 From: JimC at proximation.com (James Crotinger) Date: Thu, 24 May 2001 16:17:54 -0700 Subject: [pooma-dev] RFA: delete_test1 Modifications Message-ID: copy doesn't have the same semantics as memmove and so it is potentially faster (it can only copy overlapping regions if the destination is before the source, which is the case in the shift-up copies, which almost always involve overlapping regions). However, I did a lot of testing with KCC on the SGI and found that for larger moves, memmove was faster. This is why I put a test into the delete_shiftup algorithm to use copy only if the length of the copy was less than 100 (a good round number). Someone (named julianc) has since commented out that code without leaving a comment in the source as to the reason. Looking at the log I see that it was due to VC++ not having a proper std::advance. This should have just been coded around. At any rate, I didn't add this complication lightly. Now perhaps KCC has since written copy to use memmove so I don't know if my investigations from early 2000 are still valid. Jim > For those skipping intermediary emails, the discussion is whether > memmove() is faster than copy(). > > Attached is a program that constructs a vector, copies its contents to > another vector, and then checks the copy for correctness. On > Linux/gcc3.0 and Irix6.5/KCC, I cannot find any significant speed > difference between std::copy and std::memmove for vectors of doubles. > Given this result, may we use std::copy() everywhere since it is > guaranteed to compile? -------------- next part -------------- An HTML attachment was scrubbed... URL: From oldham at codesourcery.com Fri May 25 01:32:48 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 24 May 2001 18:32:48 -0700 Subject: [pooma-dev] RFA: delete_test1 Modifications In-Reply-To: ; from JimC@proximation.com on Thu, May 24, 2001 at 04:17:54PM -0700 References: Message-ID: <20010524183248.A2528@codesourcery.com> On Thu, May 24, 2001 at 04:17:54PM -0700, James Crotinger wrote: > copy doesn't have the same semantics as memmove and so it is potentially > faster (it can only copy overlapping regions if the destination is before > the source, which is the case in the shift-up copies, which almost always > involve overlapping regions). However, I did a lot of testing with KCC on > the SGI and found that for larger moves, memmove was faster. This is why I > put a test into the delete_shiftup algorithm to use copy only if the length > of the copy was less than 100 (a good round number). Someone (named julianc) > has since commented out that code without leaving a comment in the source as > to the reason. Looking at the log I see that it was due to VC++ not having a > proper std::advance. This should have just been coded around. At any rate, I > didn't add this complication lightly. Now perhaps KCC has since written copy > to use memmove so I don't know if my investigations from early 2000 are > still valid. > > Jim > > > For those skipping intermediary emails, the discussion is whether > > memmove() is faster than copy(). > > > > Attached is a program that constructs a vector, copies its contents to > > another vector, and then checks the copy for correctness. On > > Linux/gcc3.0 and Irix6.5/KCC, I cannot find any significant speed > > difference between std::copy and std::memmove for vectors of doubles. > > Given this result, may we use std::copy() everywhere since it is > > guaranteed to compile? OK, I am not going to argue with your timing data even though I cannot reproduce them. Let's just end up with a program that compiles and uses std::memmove. OK to commit this patch? Compiling src/Utilities/tests/delete_test1.cpp showed that the vector type `Array_t' was declared to store doubles but actually stored integers. Also, arguments for a call to std::memmove() was modified to permit compilation. 2001 May 24 Jeffrey D. Oldham * delete_test1.cpp (Array_t): s/vector/vector/ (delete_shiftup_test2): Modify memmove operands to permit compilation. Tested on sequential Linux using gcc 3.0 by compiling the program Approved by ???you??? Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: delete_test1.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/tests/delete_test1.cpp,v retrieving revision 1.7 diff -c -p -r1.7 delete_test1.cpp *** delete_test1.cpp 2001/03/21 00:56:09 1.7 --- delete_test1.cpp 2001/05/25 01:28:27 *************** void delete_shiftup_test2(Array_t &data, *** 596,601 **** --- 596,602 ---- const int size = data.size(); const std::vector::iterator data_begin = data.begin(); + const Array_t::pointer data_begin_ptr = &(data[0]); // Now loop through the data and destroy the values *************** void delete_shiftup_test2(Array_t &data, *** 625,632 **** data_begin + copy_end_index, data_begin + insert_index); else ! std::memmove(data_begin + insert_index, ! data_begin + copy_begin_index, sizeof(Array_t::value_type)*length); insert_index += length; --- 626,636 ---- data_begin + copy_end_index, data_begin + insert_index); else ! // Jim Crotinger, in early 2000, measured significant ! // speedup using KCC by using std::memmove rather than ! // std::copy. ! std::memmove(data_begin_ptr + insert_index, ! data_begin_ptr + copy_begin_index, sizeof(Array_t::value_type)*length); insert_index += length; From cummings at cacr.caltech.edu Fri May 25 01:57:06 2001 From: cummings at cacr.caltech.edu (Julian Cummings) Date: Thu, 24 May 2001 18:57:06 -0700 Subject: [pooma-dev] RFA: Vector.h: s/iosfwd/ios/ References: <20010523124111.A17219@codesourcery.com> <20010523172150.A32698@codesourcery.com> Message-ID: <3B0DBBF2.DE28ECE4@cacr.caltech.edu> Maybe I am doing something wrong or just going crazy, but I cannot verify this patch. Every compiler that I have tried so far (SGI CC 7.3.1.1m, KCC 4.0a, gcc 2.95.2) does the same thing when I try to compile CartesianTest1. They all give errors in DomainTraits.int.h, saying that you cannot specialize a class template after its first use. They are pointing to the various specializations of DomainTraits for the C built-in integral types. What I cannot figure out is where the DomainTraits template is used previously that would cause this error. It looks to me like DomainTraits.int.h just includes DomainTraits.h and then defines the specializations. Is anyone else experiencing this problem with any compiler, including the ones I have mentioned? I am working with the head version of r2 from the repository. Help!! Thanks, Julian C. Jeffrey Oldham wrote: > I revise the request to modify Tiny/Vector.h by adding the > same change to Tiny/TinyMatrix.h. > > OK to commit? > > When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, > gcc 3.0 complained about this line from src/Tiny/Vector.h: > > std::ios::fmtflags incomingFormatFlags = out.flags(); > > This is resolved by replacing by . A similar problem in > TinyMatrix.h was demonstrated by > src/Utilities/LINUXgcc/delete_test1.cpp. > > 2001 May 23 Jeffrey D. Oldham > > * TinyMatrix.h: Replace by . > * Vector.h: Likewise. > > Tested on sequential Linux using gcc 3.0 by compiling CartesianTest1.cpp > Approved by ???you??? > > I do not understand why was not the original choice. > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > > -------------------------------------------------------------------------------- > > Tiny.patchName: Tiny.patch > Type: Plain Text (text/plain) -- Dr. Julian C. Cummings E-mail: cummings at cacr.caltech.edu California Institute of Technology Phone: 626-395-2543 1200 E. California Blvd., Mail Code 158-79 Fax: 626-584-5917 Pasadena, CA 91125 From oldham at codesourcery.com Fri May 25 02:01:38 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 24 May 2001 19:01:38 -0700 Subject: [pooma-dev] RFA: Vector.h: s/iosfwd/ios/ In-Reply-To: <3B0DBBF2.DE28ECE4@cacr.caltech.edu>; from cummings@cacr.caltech.edu on Thu, May 24, 2001 at 06:57:06PM -0700 References: <20010523124111.A17219@codesourcery.com> <20010523172150.A32698@codesourcery.com> <3B0DBBF2.DE28ECE4@cacr.caltech.edu> Message-ID: <20010524190138.B2528@codesourcery.com> On Thu, May 24, 2001 at 06:57:06PM -0700, Julian Cummings wrote: > Maybe I am doing something wrong or just going crazy, > but I cannot verify this patch. Every compiler that I have > tried so far (SGI CC 7.3.1.1m, KCC 4.0a, gcc 2.95.2) does > the same thing when I try to compile CartesianTest1. They > all give errors in DomainTraits.int.h, saying that you cannot > specialize a class template after its first use. They are pointing > to the various specializations of DomainTraits for the C > built-in integral types. What I cannot figure out is where the > DomainTraits template is used previously that would cause > this error. It looks to me like DomainTraits.int.h just includes > DomainTraits.h and then defines the specializations. I am working on resolving this problem in a way that Jim Crotinger will accept. Attached is an unacceptable patch that solved the problem for me. > Is anyone else experiencing this problem with any compiler, > including the ones I have mentioned? I am working with the > head version of r2 from the repository. Help!! Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: NewDomain.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/NewDomain.h,v retrieving revision 1.30 diff -c -p -r1.30 NewDomain.h *** NewDomain.h 2001/04/13 02:12:59 1.30 --- NewDomain.h 2001/05/23 22:50:43 *************** *** 60,65 **** --- 60,66 ---- //----------------------------------------------------------------------------- #include "Domain/DomainTraits.h" + #include "Domain/DomainTraits.int.h" #include "Utilities/PAssert.h" //----------------------------------------------------------------------------- From oldham at codesourcery.com Fri May 25 02:31:13 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Thu, 24 May 2001 19:31:13 -0700 Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits Specializ ation In-Reply-To: ; from JimC@proximation.com on Thu, May 24, 2001 at 09:48:07AM -0700 References: Message-ID: <20010524193113.A18776@codesourcery.com> On Thu, May 24, 2001 at 09:48:07AM -0700, James Crotinger wrote: > > Actually, will the problem be fixed if you include DomainTraits.h and > DomainTraits.int.h in Array.h and NewField/Field.h? These look like the > culprits - they define these ViewN structs, which make use of the > DomainTraits template, but the DomainTraits template and its specializations > are never included. Further, these are used to implement the generic > operator(), which is the main place where we need to detect if someone is > passing an int as an argument. > > (The general DomainTraits template is always included implicitly by the > client who uses a particular Domain, but the int specialization is not - I > don't know why this works with other compilers.) No, this does not solve the problem. James Crotinger writes: > Jeffrey D. Oldham writes: > > Do you know of a way to have a compiler list all > > the templates it is instantiating? > > No, but one of the features I really like about KCC is that when it gets an > error while instantiating a template it gives you a full list of what it was > instantiating when the error occurred, which is usually sufficient to figure > these things out. It would be nice for GCC to do something similar instead > of just giving the line number of the error. KCC does not produce any more information than gcc 3.0 does. My experiment below is as precise to the source of the problem as I know how to do. It seems Domain/NewDomain.h includes some code which causes a ripple of template instantiations that cause the difficulty. We do need to ensure that all the Pooma code compiles. Will you please solve the problem? My proposed solution is attached. Thanks, Jeffrey D. Oldham oldham at codesourcery.com > > -----Original Message----- > > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > > Sent: Thursday, May 24, 2001 10:09 AM > > To: JimC at proximation.com > > Cc: pooma-dev at pooma.codesourcery.com > > Subject: Re: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits > > Specialization > > > > > > On Wed, May 23, 2001 at 03:28:34PM -0700, James Crotinger wrote: > > > I don't think that's it either - the question is, who is > > directly causing > > > DomainIterator to be instantiated? > > > > I do not know. Starting with > > CoordinateSystems/tests/CartesianTest1.cpp with an empty main(), I > > repeatedly replaced header files while the problem continued to exist > > until I ended with > > > > #include "Domain/NewDomain.h" // problem in here? > > #include "Domain/DomainTraits.int.h" > > > > int main() > > { > > } > > > > Replacing the first line with the header files it includes makes the > > problem disappear. Thus, I conclude that the use is in > > Domain/NewDomain.h, not in files it includes. Every use of > > DomainTraits<...> uses a template parameter so I do not know what is > > being instantiated. Do you know of a way to have a compiler list all > > the templates it is instantiating? > > > > **************** > > > > How about this? OK to commit? > > > > When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, > > gcc 3.0 complained that a DomainTraits specialization was declared > > after the general DomainTraits. This patch resolve the problem. > > > > 2001 May 23 Jeffrey D. Oldham > > > > * NewDomain.h: Add DomainTraits.int.h inclusion. > > > > Tested on sequential Linux using gcc 3.0 by compiling > > CartesianTest1.cpp > > Approved by ???you??? -------------- next part -------------- Index: NewDomain.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Domain/NewDomain.h,v retrieving revision 1.30 diff -c -p -r1.30 NewDomain.h *** NewDomain.h 2001/04/13 02:12:59 1.30 --- NewDomain.h 2001/05/23 22:50:43 *************** *** 60,65 **** --- 60,66 ---- //----------------------------------------------------------------------------- #include "Domain/DomainTraits.h" + #include "Domain/DomainTraits.int.h" #include "Utilities/PAssert.h" //----------------------------------------------------------------------------- From cummings at cacr.caltech.edu Fri May 25 02:59:46 2001 From: cummings at cacr.caltech.edu (Julian Cummings) Date: Thu, 24 May 2001 19:59:46 -0700 Subject: [pooma-dev] RFA: delete_test1 Modifications References: <20010523173302.B32698@codesourcery.com> Message-ID: <3B0DCAA1.9184F960@cacr.caltech.edu> Jeffrey, This patch seems OK to me. There is a problem with respect to the SGI CC compiler because they do not provide standard new-style C headers to wrap C library stuff in the std namespace. Michael Aivazis and I once looked into the idea of creating replacements for the missing new-style headers. The most straightforward idea is, for example // replacement for file namespace std { #include } This works for everything except , for very arcane reasons. The successful alternative we came up with is // better replacement for file #include namespace std { // declare items from C library in namespace std using ::clock_t; using ::time_t; // etc. etc. } We have these files checked into our Caltech VTF repository. If no one objects, I'd like to bring these over and put them in a new directory src/arch/SGI. Then I can edit the SGIN32CC.conf and SGI64CC.conf files and add a -I flag for this platform-specific set of include files. The gcc and KCC compilers can ignore these new headers, of course. This should allow us to use new-style C headers and the std namespace in the standard way even with the SGI CC compiler. Julian C. Jeffrey Oldham wrote: > OK to commit? > > Compiling src/Utilities/tests/delete_test1.cpp showed that the vector > type `Array_t' was declared to store doubles but actually stored > integers. Also, a call to std::memmove() illegally converted vector > iterators to pointers. The alternative call to std::copy() is instead > used. > > 2001 May 23 Jeffrey D. Oldham > > * delete_test1.cpp (Array_t): s/vector/vector/ > (delete_shiftup_test2): Remove "optimization" call to memmove. > > Tested on sequential Linux using gcc 3.0 by compiling the program > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > > -------------------------------------------------------------------------------- > > delete_test1.cpp.patchName: delete_test1.cpp.patch > Type: Plain Text (text/plain) -- Dr. Julian C. Cummings E-mail: cummings at cacr.caltech.edu California Institute of Technology Phone: 626-395-2543 1200 E. California Blvd., Mail Code 158-79 Fax: 626-584-5917 Pasadena, CA 91125 From scotth at proximation.com Fri May 25 14:31:28 2001 From: scotth at proximation.com (Scott Haney) Date: Fri, 25 May 2001 08:31:28 -0600 Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits Specializ ation In-Reply-To: <20010524193113.A18776@codesourcery.com> Message-ID: Hi everyone, Let's come to a quick and simple, but not necessarily perfect, resolution to this. I would like a quick resolution because it is clear to me that Domains need to be rewritten. The physical design needs work and the code can be dramatically simplified, thereby making these low-level objects less heavyweight and easier for both compilers and people to deal with. Allan, I would like to suggest that you take a whack at this when you are able. As a general rule, I would like to suggest that if people have objections to patches, they work with the person proposing the patch to find an acceptable solution OFFLINE, if a thread involves more than 1 or 2 volleys of messages. Email sometimes isn't conducive to folks understanding the context of objections and this breeds frustration. After a resolution is obtained, someone should summarize the issues to the list. Finally, what would people thing if we started using the issue tracking system to handle requested reviews of patches? I find that I lose track of patches I should be looking at. Scott From scotth at proximation.com Fri May 25 14:40:33 2001 From: scotth at proximation.com (Scott Haney) Date: Fri, 25 May 2001 08:40:33 -0600 Subject: [pooma-dev] Particles and NewField In-Reply-To: Message-ID: Hi Julian, We're working on making the centering cleaner to access. I would like to suggest that making particles work with NewField be your priority after 6/1 so that we can excise the old field. Scott On Monday, May 21, 2001, at 01:35 PM, Julian C. Cummings wrote: > Hi Scott, > > No, I have not tackled that yet. I did study > the issues involved and sent a note around on > this list a few weeks ago about what I thought > was needed. I just need a few solid chunks of > several hours each to sit and do the work. I > should have time for it after June 1st. (If it > is extremely pressing to do this sooner, I can > try, but life will be better after my class and > the Caltech ASCI research review are over.) > > The one thing I could use from the NewFields > (I think I mentioned this in my earlier note) > is a simple interface for determining if a > Field is cell or vert centered along a given > dimension. This is encoded in the offset values, > but a simple query function would be helpful. > > The work to be done is essentially (a) modifying > items used by Particles to eliminate the centering > or geometry template parameter, and (b) rewriting > the particle/field interpolator code to handle > centering at run-time. Most Particles code will > not change at all. > > Julian C. From scotth at proximation.com Fri May 25 14:57:32 2001 From: scotth at proximation.com (Scott Haney) Date: Fri, 25 May 2001 08:57:32 -0600 Subject: [pooma-dev] docbook overview In-Reply-To: Message-ID: Hi Allan, I have a few questions and concerns. Is it clear that HTML with CSS will not work for us? I ask because there are some very nice WYSIWYG HTML editors like Dreamweaver that make things a lot easier than even something like LaTeX, given that we're not doing a lot of equations. Also, the world seems to be moving to XML and good tools are rapidly being developed to support this. I hope that we can focus on content and leave it to tools to figure out how to program a table or a list. I'd also hate for us to invest a lot in SGML just as people are moving away from it. This said, I think your points are quite valid in general and maybe, in practice, DocBook is a little less scary than it sounds from your message. Therefore, I look forward to your report. Scott On Thursday, May 24, 2001, at 05:57 AM, Allan Stokes wrote: > > Hello everyone, > > Back at the Proximation meeting it was suggested that the Pooma > documentation be prepared in DocBook format. Not everyone there was > familiar with DocBook so I'd like to take a few minutes to describe > DocBook > and the authoring process so everyone understands the document format. > > About ten years ago SGML (Generalized Markup Language) became an > official > standard for document markup. This is an extremely rich structure which > does not lend itself to simple applications. For example, in SGML you > can > redeclare the characters which function as markup delimiters. There > isn't > much you take for granted without a full parse. > > HTML is a simplified language which includes a subset of all possible > SGML > documents. The HTML subset was designed to exclude SGML mechanisms > which > complicate parsing so that HTML documents would be simple to read and > process. > > Unfortunately, the markup elements included in HTML conflate structure > with > layout. Tags such as

    and

      express paragraph and list document > elements. But you also find stuff like this (as on the Pooma.com home > page): > > > > >
      > > The table structure and the visual presentation are hopelessly mangled > together. This makes HTML a poor choice for creating portable > documents. > > TeX also suffers from unnatural commingling, which is one of several > reasons > people find TeX unpleasant to use. In the case of TeX, the problem was > partly addressed by creating LaTeX as a document language. LaTeX > allows the > author to describe the structure of the document directly and (mostly) > keeps > the visual mechanics behind the curtains. > > DocBook was invented to solve the same problem with HTML: separating > structure from presentation. The structure DocBook describes is > everything > you might want to put in a book. > > Here is a small scrap which I created while testing my DocBook tools to > give > the flavour of the notation. > > > > > > Allan's First DocBook Book > > Allan > Stokes > > > 2001 > Allan Stokes > > > > Foreward > I survived PSGML. > > > chapters MUST have a title > The location of the PSGML tutorial is www.lysator.liu.se > > And so it goes. > > > > > This is a valid SGML document. The first line declares the document > data > type (DTD) which governs the structure of the rest of the document. > The DTD > formally defines what markup elements are legal, required, optional, > etc. > > If you run this scrap through a formal SGML validator, the validator > will be > able to tell you if your document obeys the rules imposed by the DTD. > This > fragment references the DocBook DTD for DocBook version 4.1. > > With this background I can now define what DocBook is. DocBook is an > SGML > DTD. Presently the DocBook DTD is about 300,000 characters of SGML in > SGML > DTD syntax which defines the vast majority of document elements which > any > technical book might wish to include. O'Reilly has published high > quality > technical books directly from DocBook sources. > > DocBook is also used for electronic documentation. The Linux > Documentation > Project (LDP) has standardized on DocBook, and FreeBSD is in the > process of > converting much of their own online documentation into DocBook format. > The > tools required to work with DocBook are now standard components on many > of > these platforms, so DocBook has become exceptionally portable. > > A common stumbling block in understanding DocBook is that DocBook itself > provides no tools. DocBook is an SGML DTD. The DocBook DTD is > essentially > an SGML document in its own right. (In the SGML world, everything is a > document. When you have a hammer ...) > > The core tool for working with DocBook is the SGML validator. A formal > SGML > validator parses the DTD to determine the rules which govern the > document > instance which follows. The validator will tell you if your DocBook > document is a legal document. In the purest sense, DocBook defines a > subset > of all possible SGML documents as being legal DocBook documents. The > semantics of the markup are defined by the tools used in the > postproduction. > > All DocBook gives us is a structure for composing well-formed > documents. We > need to address the issue of publishing the document separately. > > To do this you need an SGML processor which is capable of converting the > DocBook source document into a backend format. There are many tools out > there which can manipulate SGML so there are many ways to publish a > DocBook > document. In the non-commercial world, DocBook publishing is usually > done > with Jade (a free tool written by James Clark). > > Jade comes with a set of standard stylesheets for a variety of backend > formats. The quality of output is quite acceptable using the default > stylesheets. It is unlikely that we will wish to make any changes to > the > standard stylesheets for publishing the Pooma documentation. You can > typically use Jade without having to deal with much of Jade's > complexity. > But I'll describe Jade anyway. > > There are a variety of standards for specifying stylesheets. Jade > supports > the DSSSL standard. DSSSL stylesheets are written in a Scheme-like > language. DSSSL processing reminds me of Pooma. The DocBook document > is an > SGML tree structure (much like a Pooma template expression), and DSSSL > behaves like an expression template which walks the tree structure and > transforms it (decorates, trims, etc.) into a new tree structure, then > finally you flatten the whole thing for output (e.g. evaluate). > > DSSSL is a functional language which iterates via tail recursion. A > DSSSL > stylesheet, surprise, is itself a valid SGML document. (It is even > possible > to use Jade to transform DSSSL stylesheets into other DSSSL stylesheets. > It's this kind of thing which gives DSSSL a cult reputation. Let go of > your > mouse and back away quietly.) > > The primary backend formats supported by Jade are HTML, RTF, TeX. The > TeX > produced by Jade is suitable for conversion into high quality > Postscript or > PDF. > > Jade is easy enough to use, but configuring Jade involves a couple of > frustrating steps. SGML contains several methods of indirection which > are > used extensively to modularize the implementation of the DocBook DTD > and the > DSSSL stylesheets. Most SGML entities are reference via public > identifiers > (as opposed to host filenames). Most SGML tools resolve the public > identifiers by searching site-local files called catalogs. The catalog > files supply local mappings to names which can be resolved on the local > file > system. Most SGML toolsets expect the catalog configuration to be done > manually before all the SGML magic will work. > > Invoking Jade with the right combinations of stylesheets and backend > formats > is moderately tricky as well. > > The "DocBook Definitive Guide" presents a solution to this problem which > demonstrates typical DSSSL trickery. A DSSSL stylesheet is an SGML > document > whose structure is defined by a DSSSL DTD. What they do is modify the > standard DSSSL DTD to allow annotations to be placed inside the DSSSL > stylesheet which define what combinations of stylesheets and backends > are > appropriate. Then they supply a Perl script which uses Jade to look > inside > the DSSSL stylesheet to find the annotations which govern how the > backend > format specified on the command line should be produced. > > The whole thing is slick when it works, but initially you get a severe > dose > of abstraction shock trying to figure out which bit of syntax functions > at > what level. > > I have most of this stuff working in my own environment. Once I figure > out > how I accomplished this feat I think it would be a good idea to > document my > Jade configuration and publishing process. Perhaps these notes would be > suitable for a web page somewhere on pooma.com. (Is that stuff under > source > control?) > > The final piece of the puzzle is the authoring process. > > Generally, everything I've found on the web about authoring DocBook > applies > to emacs. emacs has a psgml package which defines a major mode for > editing > DocBook documents. psgml defines several menus and many keystrokes for > applying syntax directed markup. When you load your DocBook document, > psgml > parses the DocBook DTD to determine the required markup structure for > your > document. It will prompt you on legal completions when you get lost in > tricky annotations. > > It also has hooks to run external SGML validators to find errors in your > markup. You can also automate the process of publishing your documents > using Jade by commands invoked from within emacs. There are also a > number > of commercial applications which provide the same capabilities (syntax > directed editing of SGML documents). > > psgml is a generic setup. I discovered that I needed to apply a number > of > tweaks to emacs to make the configuration usable. For example, psgml > doesn't necessarily know how you have your catalog files set up when > invoking external tools. > > Maintaining an existing DocBook document manually (e.g. without setting > up > psgml) is not much worse than maintaining HTML manually. However, I > doubt > anyone would want to crank new material without the support of something > like psgml. > > There's another aspect of DocBook which I should mention briefly because > many of the web materials talk about it. So far I've described the SGML > version of DocBook and the tools appropriate for publishing SGML DocBook > (Jade/DSSSL). > > There is also a parallel version of DocBook in XML format. XML is also > an > SGML language, simplified even more than HTML. The SGML version of > DocBook > is slightly more human friendly so most people write in the SGML > dialect. > The interconversion is mechanical. > > Jade and DSSSL are mature tools (with many limitations) which are no > longer > being aggressively developed, in part because DSSSL/Scheme is regarded > as > overkill. > > The ongoing work is mostly in the XML camp now. XML defines several > different stylesheets languages (e.g. CSS) and different transformation > tools (e.g. XSL/XSLT). When browsers fully support HTML/CSS it will be > possible to publish XML DocBook documents directly to the web. The web > browser will do the presentation directly from the style sheet. > > The XML version of DocBook uses an XML syntax for declaring the DocBook > DTD. > If I understand the situation correctly, the XML syntax is slightly less > expressive than the SGML syntax, so the two DocBook DTDs are not > presently > formally equivalent. The next major version of DocBook is supposed to > address this issue. > > The XML tools at this point are mostly experimental. Within the next > few > years it is anticipated that the new XML model will largely supplant the > Jade/DSSSL process. It will be a different way of publishing the same > source documents. > > I hope that gives people a good overview of what DocBook is, where it is > going, and how the process fits together. Once I finish collecting my > installation notes I'll set up my document framework for the Pooma > concepts. > > Allan From oldham at codesourcery.com Fri May 25 17:44:33 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 25 May 2001 10:44:33 -0700 Subject: Patch: Expanding Supported Explicit Instantiations Message-ID: <20010525104433.B30239@codesourcery.com> Dave Nystrom desired to explicitly instantiate this program: #include "Pooma/NewFields.h" #define T1 NoGeometry<(int)3> #define T2 int #define T3 CompressibleBrick #define T4 Interval<(int)3> template View1,T4>::sv; I do not know the correct syntax for explicitly instantiating View1's const static bool `sv' if this is even legal. The attached patch permits instantiating #include "Pooma/NewFields.h" #define T1 NoGeometry<(int)3> #define T2 int #define T3 CompressibleBrick #define T4 Interval<(int)3> template class View1,T4>; It also permits template View0 >; without first explicitly instantiating Array<2,T2,T3>; The main idea is to break mutually recursive class definitions by defining alternative `View' classes that contain all the type definitions of their corresponding `View' classes but omit the member functions. These alternative classes provide the return type for non-templated member functions of Array and Field classes. These member functions' bodies still use the View classes. Since the alternative classes' definitions are the same as for the View classes, this trickery works. If a View class's code changes, the corresponding alternative class's code must also be changed. This might lead to future maintenance problems. Stephen Smith provided the insight for the patch so he deserves all positive credit. Send all criticisms to Jeffrey. 2001-05-25 Jeffrey D. Oldham * Array/Array.h (View0): Modify initial comment to indicate changes should also be made to AltView0. (AltView0): New class to avoid explicit instantiation problems. (ComponentView): Modify initial comment to indicate class should not be explicitly instantiated. (Array::read()): Change return type to AltView0. (Array::operator()()): Likewise. * NewField/Field.h (View1Implementation): Modify initial comment to indicate changes should also be made to AltView1Implementation. (AltView1Implementation): New class to avoid explicit instantiation problems. (View1): Modify initial comment to indicate changes should also be made to AltView1. (AltView1): New class to avoid explicit instantiation problems. (Field::read()): Change return type to AltView1. (Field::readAll()): Likewise. (Field::read(s1)): Likewise. (Field::operator()()): Likewise. (Field::all()): Likewise. (Field::operator()(s1)): Likewise. Tested on sequential Linux using gcc 3.0 Approved by Scott Haney Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: Array/Array.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Array/Array.h,v retrieving revision 1.140 diff -c -p -r1.140 Array.h *** Array/Array.h 2001/05/14 21:11:22 1.140 --- Array/Array.h 2001/05/25 17:37:49 *************** struct View1, D *** 642,647 **** --- 642,649 ---- // an existing engine cannot be any kind of slice domain. // Also, bounds checking would make no sense because it would // reduce to contains(a.domain(), a.domain()); + // + // Any changes to this class should also be made to AltView0. template struct View0 > *************** struct View0 > *** 686,691 **** --- 688,728 ---- } }; + // AltView0 avoids an instantiation problem that arises when two + // classes use each other. This class's definition should be exactly + // the same as View0 except omitting member functions. + // + // Do NOT explicitly instantiate this class. + + template + struct AltView0; + + template + struct AltView0 > + { + // Convenience typedef for the thing we're taking a view of. + + typedef Array Subject_t; + + // Deduce domains for the output type. + // At some point, we need to fix NewDomain1; until then, use + // the temporary version from Array.h. + + typedef typename Subject_t::Engine_t Engine_t; + typedef typename Subject_t::Domain_t Domain_t; + + // Deduce the template parameters for the output type. + + typedef typename NewEngine::Type_t NewEngine_t; + enum { newDim = NewEngine_t::dimensions }; + typedef typename NewEngine_t::Tag_t NewEngineTag_t; + + // The output types. + + typedef Array Type_t; + typedef Type_t ReadType_t; + }; + template struct View1, int> { *************** struct Patch > *** 1278,1283 **** --- 1315,1321 ---- //----------------------------------------------------------------------------- // ComponentView specialization for Array. + // Changes to ComponentView should also be made to AltComponentView. //----------------------------------------------------------------------------- template *************** struct ComponentView --- 1352,1362 ---- }; //----------------------------------------------------------------------------- ! // AltComponentView avoids an instantiation problem that arises when ! // two classes use each other. These classes' definitions should be ! // exactly the same as ComponentView except omitting member functions. ! // ! // Do NOT explicitly instantiate these alternative classes. //----------------------------------------------------------------------------- template *************** public: *** 1785,1791 **** // A zero-argument version of operator(), which takes a view of // array's domain, is also supplied. ! typename View0::ReadType_t read() const { typedef View0 Ret_t; --- 1826,1832 ---- // A zero-argument version of operator(), which takes a view of // array's domain, is also supplied. ! typename AltView0::ReadType_t read() const { typedef View0 Ret_t; *************** public: *** 1855,1861 **** return Ret_t::makeRead(*this, s1, s2, s3, s4, s5, s6, s7); } ! typename View0::Type_t operator()() const { typedef View0 Ret_t; --- 1896,1902 ---- return Ret_t::makeRead(*this, s1, s2, s3, s4, s5, s6, s7); } ! typename AltView0::Type_t operator()() const { typedef View0 Ret_t; Index: NewField/Field.h =================================================================== RCS file: /home/pooma/Repository/r2/src/NewField/Field.h,v retrieving revision 1.13 diff -c -p -r1.13 Field.h *** NewField/Field.h 2001/05/14 21:11:24 1.13 --- NewField/Field.h 2001/05/25 17:37:51 *************** public: *** 187,192 **** --- 187,195 ---- // View1Implementation specialization for indexing a field // with a single domain. There is a single-valued version (SV == true) // and a multi-valued version (SV == false). + // + // Any changes to View1Implementation should also be made to + // AltView1Implementation. //----------------------------------------------------------------------------- // Single-valued version. Handles scalars and Locs. *************** struct View1Implementation + struct AltView1Implementation; + + template + struct AltView1Implementation, Domain, true> + { + // Convenience typedef for the thing we're taking a view of. + + typedef Field Subject_t; + + // The return types are pretty simple here. + + typedef typename Subject_t::Element_t ReadType_t; + typedef typename Subject_t::ElementRef_t Type_t; + }; + + template + struct AltView1Implementation, Domain, false> + { + // Convenience typedef for the thing we're taking a view of. + + typedef Field Subject_t; + + // Deduce domains for the output type. + + typedef typename Subject_t::Engine_t Engine_t; + typedef typename NewEngine::Type_t NewEngine_t; + typedef typename NewEngine_t::Element_t NewT_t; + typedef typename NewEngine_t::Tag_t NewEngineTag_t; + + // Deduce the new GeometryTag. + + typedef typename + NewGeometryTag::Type_t + NewGeometryTag_t; + + // The output types. + + typedef Field ReadType_t; + typedef Field Type_t; + }; + + + //----------------------------------------------------------------------------- // View1 specialization for indexing a field with a single domain. + // + // Any changes to View1 should also be made to AltView1. //----------------------------------------------------------------------------- template *************** struct View1 specialization for indexing a field with an int. + // + // Any changes to View1 should also be made to AltView1. //----------------------------------------------------------------------------- template *************** struct View1 + struct AltView1; + + template + struct AltView1, Sub1> + { + // Convenience typedef for the thing we're taking a view of. + + typedef Field Subject_t; + + // Deduce domains for the output type. + // At some point, we need to fix NewDomain1; until then, use + // the temporary version from NewDomain.h. + + typedef typename Subject_t::Domain_t Domain_t; + typedef TemporaryNewDomain1 NewDomain_t; + typedef typename NewDomain_t::SliceType_t SDomain_t; + + // Deduce appropriate version of implementation to dispatch to. + + static const bool sv = DomainTraits::singleValued; + typedef AltView1Implementation Dispatch_t; + + // The optimized domain combiner. + + typedef CombineDomainOpt Combine_t; + + // The return types. + + typedef typename Dispatch_t::ReadType_t ReadType_t; + typedef typename Dispatch_t::Type_t Type_t; + }; + + + //----------------------------------------------------------------------------- + // AltView1 avoids an instantiation problem that arises when two + // classes use each other. This class's definition should be exactly + // the same as View1 except omitting member functions. + // + // Do NOT explicitly instantiate this class. + //----------------------------------------------------------------------------- + + template + struct AltView1, int> + { + // Convenience typedef for the thing we're taking a view of. + + typedef Field Subject_t; + + // The return types. + + typedef typename Subject_t::Element_t ReadType_t; + typedef typename Subject_t::ElementRef_t Type_t; + + }; + + + //----------------------------------------------------------------------------- + // AltView1 avoids an instantiation problem that arises when two + // classes use each other. This class's definition should be exactly + // the same as View1 except omitting member functions. + // + // Do NOT explicitly instantiate this class. + //----------------------------------------------------------------------------- + + template + struct AltView1; + + template + struct AltView1, Sub1> + { + // Convenience typedef for the thing we're taking a view of. + + typedef Field Subject_t; + + // Deduce domains for the output type. + // At some point, we need to fix NewDomain1; until then, use + // the temporary version from NewDomain.h. + + typedef typename Subject_t::Domain_t Domain_t; + typedef TemporaryNewDomain1 NewDomain_t; + typedef typename NewDomain_t::SliceType_t SDomain_t; + + // Deduce appropriate version of implementation to dispatch to. + + static const bool sv = DomainTraits::singleValued; + typedef View1Implementation Dispatch_t; + + // The optimized domain combiner. + + typedef CombineDomainOpt Combine_t; + + // The return types. + + typedef typename Dispatch_t::ReadType_t ReadType_t; + typedef typename Dispatch_t::Type_t Type_t; + }; + + + //----------------------------------------------------------------------------- + // AltView1 avoids an instantiation problem that arises when two + // classes use each other. This class's definition should be exactly + // the same as View1 except omitting member functions. + // + // Do NOT explicitly instantiate this class. + //----------------------------------------------------------------------------- + + template + struct AltView1, int> + { + // Convenience typedef for the thing we're taking a view of. + + typedef Field Subject_t; + + // The return types. + + typedef typename Subject_t::Element_t ReadType_t; + typedef typename Subject_t::ElementRef_t Type_t; + + }; + + + //----------------------------------------------------------------------------- // View2 specialization for indexing a field with two // domains. //----------------------------------------------------------------------------- *************** public: *** 1010,1023 **** // version returns a view of the physical domain and the 'All'-suffixed // versions return a view of the total domain. ! inline typename View1::ReadType_t read() const { typedef View1 Ret_t; return Ret_t::makeRead(*this, physicalDomain()); } ! inline typename View1::ReadType_t readAll() const { typedef View1 Ret_t; --- 1200,1213 ---- // version returns a view of the physical domain and the 'All'-suffixed // versions return a view of the total domain. ! inline typename AltView1::ReadType_t read() const { typedef View1 Ret_t; return Ret_t::makeRead(*this, physicalDomain()); } ! inline typename AltView1::ReadType_t readAll() const { typedef View1 Ret_t; *************** public: *** 1025,1031 **** } template ! inline typename View1::ReadType_t read(const Sub1 &s1) const { typedef View1 Ret_t; --- 1215,1221 ---- } template ! inline typename AltView1::ReadType_t read(const Sub1 &s1) const { typedef View1 Ret_t; *************** public: *** 1048,1061 **** return Ret_t::makeRead(*this, s1, s2, s3); } ! inline typename View1::Type_t operator()() const { typedef View1 Ret_t; return Ret_t::make(*this, physicalDomain()); } ! inline typename View1::Type_t all() const { typedef View1 Ret_t; --- 1238,1251 ---- return Ret_t::makeRead(*this, s1, s2, s3); } ! inline typename AltView1::Type_t operator()() const { typedef View1 Ret_t; return Ret_t::make(*this, physicalDomain()); } ! inline typename AltView1::Type_t all() const { typedef View1 Ret_t; *************** public: *** 1063,1069 **** } template ! inline typename View1::Type_t operator()(const Sub1 &s1) const { typedef View1 Ret_t; --- 1253,1259 ---- } template ! inline typename AltView1::Type_t operator()(const Sub1 &s1) const { typedef View1 Ret_t; From cummings at mail.linkline.com Fri May 25 17:57:11 2001 From: cummings at mail.linkline.com (Julian C. Cummings ) Date: Fri, 25 May 2001 10:57:11 -0700 Subject: [pooma-cvs] CVS update: pooma Message-ID: <200105251057.AA156500560@mail.linkline.com> Hi All, I just wanted to apologize for jumping in and patching the DomainTraits.h file. I was at Caltech yesterday and had not seen the flurry of e-mails between Jeffrey and Jim regarding this problem and possible ways of fixing it. In any event, I recognized that this issue with the DomainTraits.int.h file possibly not being included early enough was a potential problem when I was working on the Domain sources previously. Since the problem popped up yet again, I figured I should just fix it. I do think my fix is appropriate. DomainTraits.int.h contains specializations of the DomainTraits template. These have to be seen before the template is instantiated. Since it can be terribly complicated to figure out exactly where a template is first being instantiated sometimes, it is easiest to just include the specializations right away. So I just included DomainTraits.int.h at the end of DomainTraits.h (and removed all other includes of DomainTraits.int.h). This solves the problem permanently. I don't think that a major overhaul/rewrite of the Domain sources is a good use of Allan's time or anyone else's at this moment. These sources reach into absolutely all parts of Pooma, and there will inevitably be problems and surprises if we swap out the Domain sources entirely. Although the present source is perhaps overly complex, it does work correctly. I think there's plenty of other stuff that is actually broken or needs to be completed to keep us all happily busy for some time to come. Just my two cents on this issue. I support Scott's suggestions for issue tracking and taking discussions of particular patches offline if they become extended. Just add a note that you are taking a discussion offline, and whoever is interested can continue with it. I have been frustrated by some of the endless discussions about suggested patches. E-mail is usually not an efficient means of resolving these issues. We should probably be picking up the phone a little more often. On the delete_test issue: I will leave it to Jim and Jeffrey to come up with a solution that works and is portable across the various platforms and compilers we support. I had forgotten that I had to comment out the memmove() stuff because it did not work under the Intel VTune compiler (or the gcc compiler as Jeffrey discovered). That's why I commented out the code rather than delete it entirely. If there is a strong reason for maintaining the use of memmove and someone can make it work portably, please do so. Thanks, Julian C. ---------- Original Message ---------------------------------- From: pooma at merlin.codesourcery.com Reply-To: pooma-dev at pooma.codesourcery.com Date: 25 May 2001 02:16:57 -0000 > >Date: Thursday May 24, 2001 @ 20:16 >Author: pooma > >Update of /home/pooma/Repository/r2/src/Domain >In directory merlin.codesourcery.com:/tmp/cvs-serv10429/src/Domain > >Modified Files: > DomainTraits.Grid.h DomainTraits.Interval.h DomainTraits.Loc.h > DomainTraits.Range.h DomainTraits.h >Log Message: >Fixed problem I noted in a recent e-mail with struct template >DomainTraits being instantiated before the specializations for >built-in integral types were seen. This could happen if a file >included DomainTraits.h but not DomainTraits.int.h and then later >on did include DomainTraits.int.h. There's no harm in including >these specializations anyway, so I put a #include DomainTraits.int.h >at the end of DomainTraits.h. I removed #include DomainTraits.int.h >from some of the other DomainTraits header files, since they will >now get it automatically from DomainTraits.h. > > > From mark at codesourcery.com Fri May 25 17:57:20 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 25 May 2001 10:57:20 -0700 Subject: [pooma-dev] docbook overview Message-ID: <20010525105720J.mitchell@codesourcery.com> >>>>> "Scott" == Scott Haney writes: Scott> Hi Allan, Scott> I have a few questions and concerns. Scott> Is it clear that HTML with CSS will not work for us? Just about. I've been there and tried that -- Netscape, for example, basically falls over on all non-trivial instances of CSS. It doesn't just do the wrong thing: it crashes. Scott> This said, I think your points are quite valid in general Scott> and maybe, in practice, DocBook is a little less scary than Scott> it sounds from your message. Therefore, I look forward to Scott> your report. I strongly suggest that we go with DocBook. One of the big advantages is the ease with which you can get printed manuals. For example, O'Reilly now lets you give them source for a book as DocBook -- and they just print it, and you're done. It's not actually as threatening as Allan made it sound :-), and any SGML editor will work fine with it. It's also proven technology: we've been using it for months on some other projects, with good success. Allan, you might want to contact Alex Samuel (samuel at codesourcery.com) to find out exactly how he set up DocBook for the work he's been doing with it. But, as long we have a standard process to get set up, that's the important thing. Thanks, -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From mark at codesourcery.com Fri May 25 17:58:23 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 25 May 2001 10:58:23 -0700 Subject: Patch: Expanding Supported Explicit Instantiations In-Reply-To: <20010525104433.B30239@codesourcery.com> References: <20010525104433.B30239@codesourcery.com> Message-ID: <20010525105823J.mitchell@codesourcery.com> >>>>> "Jeffrey" == Jeffrey Oldham writes: Jeffrey> I do not know the correct syntax for explicitly Jeffrey> instantiating View1's const static bool `sv' if this is For: template { static int x; }; you do like this: template int S::x; -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From cummings at mail.linkline.com Fri May 25 17:59:07 2001 From: cummings at mail.linkline.com (Julian C. Cummings ) Date: Fri, 25 May 2001 10:59:07 -0700 Subject: [pooma-cvs] CVS update: pooma Message-ID: <200105251059.AA27525682@mail.linkline.com> Hi All, I just wanted to apologize for jumping in and patching the DomainTraits.h file. I was at Caltech yesterday and had not seen the flurry of e-mails between Jeffrey and Jim regarding this problem and possible ways of fixing it. In any event, I recognized that this issue with the DomainTraits.int.h file possibly not being included early enough was a potential problem when I was working on the Domain sources previously. Since the problem popped up yet again, I figured I should just fix it. I do think my fix is appropriate. DomainTraits.int.h contains specializations of the DomainTraits template. These have to be seen before the template is instantiated. Since it can be terribly complicated to figure out exactly where a template is first being instantiated sometimes, it is easiest to just include the specializations right away. So I just included DomainTraits.int.h at the end of DomainTraits.h (and removed all other includes of DomainTraits.int.h). This solves the problem permanently. I don't think that a major overhaul/rewrite of the Domain sources is a good use of Allan's time or anyone else's at this moment. These sources reach into absolutely all parts of Pooma, and there will inevitably be problems and surprises if we swap out the Domain sources entirely. Although the present source is perhaps overly complex, it does work correctly. I think there's plenty of other stuff that is actually broken or needs to be completed to keep us all happily busy for some time to come. Just my two cents on this issue. I support Scott's suggestions for issue tracking and taking discussions of particular patches offline if they become extended. Just add a note that you are taking a discussion offline, and whoever is interested can continue with it. I have been frustrated by some of the endless discussions about suggested patches. E-mail is usually not an efficient means of resolving these issues. We should probably be picking up the phone a little more often. On the delete_test issue: I will leave it to Jim and Jeffrey to come up with a solution that works and is portable across the various platforms and compilers we support. I had forgotten that I had to comment out the memmove() stuff because it did not work under the Intel VTune compiler (or the gcc compiler as Jeffrey discovered). That's why I commented out the code rather than delete it entirely. If there is a strong reason for maintaining the use of memmove and someone can make it work portably, please do so. Thanks, Julian C. ---------- Original Message ---------------------------------- From: pooma at merlin.codesourcery.com Reply-To: pooma-dev at pooma.codesourcery.com Date: 25 May 2001 02:16:57 -0000 > >Date: Thursday May 24, 2001 @ 20:16 >Author: pooma > >Update of /home/pooma/Repository/r2/src/Domain >In directory merlin.codesourcery.com:/tmp/cvs-serv10429/src/Domain > >Modified Files: > DomainTraits.Grid.h DomainTraits.Interval.h DomainTraits.Loc.h > DomainTraits.Range.h DomainTraits.h >Log Message: >Fixed problem I noted in a recent e-mail with struct template >DomainTraits being instantiated before the specializations for >built-in integral types were seen. This could happen if a file >included DomainTraits.h but not DomainTraits.int.h and then later >on did include DomainTraits.int.h. There's no harm in including >these specializations anyway, so I put a #include DomainTraits.int.h >at the end of DomainTraits.h. I removed #include DomainTraits.int.h >from some of the other DomainTraits header files, since they will >now get it automatically from DomainTraits.h. > > > From JimC at proximation.com Fri May 25 18:31:08 2001 From: JimC at proximation.com (James Crotinger) Date: Fri, 25 May 2001 11:31:08 -0700 Subject: [pooma-dev] RFA: delete_test1 Modifications Message-ID: That's fine. Like I said, it doesn't matter here as this is just a test. Julian commented out the corresponding code in algorithm.h so we're not using this optimization in real code anyway. Jim > -----Original Message----- > From: Jeffrey Oldham [mailto:oldham at codesourcery.com] > Sent: Thursday, May 24, 2001 7:33 PM > To: James Crotinger > Cc: pooma-dev at pooma.codesourcery.com > Subject: Re: [pooma-dev] RFA: delete_test1 Modifications > > > On Thu, May 24, 2001 at 04:17:54PM -0700, James Crotinger wrote: > > copy doesn't have the same semantics as memmove and so it > is potentially > > faster (it can only copy overlapping regions if the > destination is before > > the source, which is the case in the shift-up copies, which > almost always > > involve overlapping regions). However, I did a lot of > testing with KCC on > > the SGI and found that for larger moves, memmove was > faster. This is why I > > put a test into the delete_shiftup algorithm to use copy > only if the length > > of the copy was less than 100 (a good round number). > Someone (named julianc) > > has since commented out that code without leaving a comment > in the source as > > to the reason. Looking at the log I see that it was due to > VC++ not having a > > proper std::advance. This should have just been coded > around. At any rate, I > > didn't add this complication lightly. Now perhaps KCC has > since written copy > > to use memmove so I don't know if my investigations from > early 2000 are > > still valid. > > > > Jim > > > > > For those skipping intermediary emails, the discussion is whether > > > memmove() is faster than copy(). > > > > > > Attached is a program that constructs a vector, copies > its contents to > > > another vector, and then checks the copy for correctness. On > > > Linux/gcc3.0 and Irix6.5/KCC, I cannot find any significant speed > > > difference between std::copy and std::memmove for vectors > of doubles. > > > Given this result, may we use std::copy() everywhere since it is > > > guaranteed to compile? > > OK, I am not going to argue with your timing data even though I cannot > reproduce them. Let's just end up with a program that compiles and > uses std::memmove. > > OK to commit this patch? > > Compiling src/Utilities/tests/delete_test1.cpp showed that the vector > type `Array_t' was declared to store doubles but actually stored > integers. Also, arguments for a call to std::memmove() was modified > to permit compilation. > > 2001 May 24 Jeffrey D. Oldham > > * delete_test1.cpp (Array_t): s/vector/vector/ > (delete_shiftup_test2): Modify memmove operands to > permit compilation. > > Tested on sequential Linux using gcc 3.0 by compiling > the program > Approved by ???you??? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JimC at proximation.com Fri May 25 18:58:30 2001 From: JimC at proximation.com (James Crotinger) Date: Fri, 25 May 2001 11:58:30 -0700 Subject: [pooma-dev] docbook overview Message-ID: My main concern here is Allan's comment that the main authoring tool is emacs. Don't get me wrong - I'm probably the biggest emacs user here. But I want a WYSIWYG authoring tool for whatever we're doing. I've written tons of LaTeX and done a couple of papers with HTML (without a WYSIWYG tool) and I'm tired of it (unless I need a lot of equations - I still haven't seen a good alternative to LaTeX for this [I'm very picky about formatting]). If there are some decent WYSIWYG tools that can save their documents in DocBook format, then that would be great, especially if there is a planned path toward XML and if the WYSIWYG tools don't make gratuitious changes to the ASCII file so that "cvs diff"'s are small when the changes are small. Jim > -----Original Message----- > From: Mark Mitchell [mailto:mark at codesourcery.com] > Sent: Friday, May 25, 2001 11:57 AM > To: scotth at proximation.com > Cc: pooma-dev at pooma.codesourcery.com > Subject: Re: [pooma-dev] docbook overview > > > >>>>> "Scott" == Scott Haney writes: > > Scott> Hi Allan, > > Scott> I have a few questions and concerns. > > Scott> Is it clear that HTML with CSS will not work for us? > > Just about. I've been there and tried that -- Netscape, for example, > basically falls over on all non-trivial instances of CSS. It doesn't > just do the wrong thing: it crashes. > > Scott> This said, I think your points are quite valid in general > Scott> and maybe, in practice, DocBook is a little less scary than > Scott> it sounds from your message. Therefore, I look forward to > Scott> your report. > > I strongly suggest that we go with DocBook. One of the big advantages > is the ease with which you can get printed manuals. For example, > O'Reilly now lets you give them source for a book as DocBook -- and > they just print it, and you're done. > > It's not actually as threatening as Allan made it sound :-), and any > SGML editor will work fine with it. > > It's also proven technology: we've been using it for months on some > other projects, with good success. Allan, you might want to contact > Alex Samuel (samuel at codesourcery.com) to find out exactly how he set > up DocBook for the work he's been doing with it. But, as long we have > a standard process to get set up, that's the important thing. > > Thanks, > > -- > Mark Mitchell mark at codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JimC at proximation.com Fri May 25 19:13:30 2001 From: JimC at proximation.com (James Crotinger) Date: Fri, 25 May 2001 12:13:30 -0700 Subject: [pooma-dev] Re: [pooma-cvs] CVS update: pooma Message-ID: > -----Original Message----- > From: Julian C. Cummings [mailto:cummings at mail.linkline.com] > Sent: Friday, May 25, 2001 11:59 AM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] Re: [pooma-cvs] CVS update: pooma > > > Hi All, > > I just wanted to apologize for jumping in and patching > the DomainTraits.h file. I don't think anyone has commented on the point that I made yesterday - Array.h and Field.h use DomainTraits but never include DomainTraits.h. Furthermore, their op() functions are designed to treat int args as Domains, so clearly these files should be including DomainTraits.h and DomainTraits.int.h. I don't know if that fix the problem that Jeffrey is specifically looking at, but it should be done anyway since the code, as it stands, is wrong. Regarding including DomainTraits.int.h at the end of DomainTraits.h - the purist in me feels that the user of DomainTraits should make this decision - if he's expecting to treat ints as Domains then he needs to write all the code using DomainTraits; what Geoff Furnish would probably call "Domain-free" code. However, there are a number of places in Pooma where the code is NOT written to be "Domain-free" and which would not compile if a Domain template parameter were an int. I'm sure there are even functions with separate overloads that have different semantics for int args. This code doesn't *need* to see DomainTraits.int.h. On the pragmatic side, I can't see that it would hurt (any code that would compile with this change that had not formerly compiled would treat the int as a Loc<1> and behave just as if a Loc<1> had been passed - I suppose if the user had just made a mistake, this might be hard to find - i.e. this specialization weakens type safety somewhat) and the Domain design is such a mess already that I'm certainly not going to hold up a change like this for purity sake. 8-) Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Fri May 25 19:20:32 2001 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 25 May 2001 12:20:32 -0700 Subject: [pooma-dev] docbook overview In-Reply-To: References: Message-ID: <20010525122032N.mitchell@codesourcery.com> >>>>> "James" == James Crotinger writes: James> the biggest emacs user here. But I want a WYSIWYG authoring James> tool for whatever we're doing. Hmm. There *are* free DocBook WYSIWYG editors but I don't know how well they work. One example is `www.conglomerate.org'. Also `epcEdit' is not WYSIWYG -- but is specially designed to work with SGML. Also, there are commercial DocBook editors that what a lot of the publishing people are using now. For example, Arbortext's `Epic' or Adobe's `FrameMaker'. There's also something called XMetaL. These are all WYSIWYG. These tools are all priced around $750. It would be nice if DocBook tools were two years further along. But, this is the format we want -- it's a good way of producing web docs, print docs, and even man pages, in a reliable way, and just about everyone is using it. If we don't do this, then we'll end up converting two years hence, and that's a complete pain in the neck. In fairness, since Allan has the job of writing most of the documentation, and since he's happy in Emacs, shouldn't we let him use what he likes, especially when it's the forward-looking technology that the industry seems to be standardizing on? -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From oldham at codesourcery.com Fri May 25 19:33:02 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 25 May 2001 12:33:02 -0700 Subject: RFA: Tutorial Documentation Typographical Fix Message-ID: <200105251933.MAA04578@oz.codesourcery.com> Per Scott Haney's suggestion, I filed my latest Pooma source code patch request using Pooma's QMTrack. To access it, 1) point your browser to http://pooma.codesourcery.com:4242/track/ 2) log in using your last name as your username and your password 3) Enter `tutorial_patch' as the Issue ID. 4) Approve my patch. I'll step back as everyone rushes to try out the new tool. :) If you have difficulty, send email to samuel at codesourcery.com, who is building the tools, or to me. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Fri May 25 20:07:47 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 25 May 2001 13:07:47 -0700 Subject: Weekly Report Message-ID: <200105252007.NAA04747@oz.codesourcery.com> This week: Worked with Stephen Smith to resolve Dave Nystrom's explicit instantiation problem. Compiled all test programs, submitting patches as necessary to permit compilation. Committed numerous patches. Next week: Finish implementation of interpolation and restriction operators. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Fri May 25 20:10:39 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 25 May 2001 13:10:39 -0700 Subject: [pooma-dev] RFA: SGI CC Header Files In-Reply-To: <3B0DCAA1.9184F960@cacr.caltech.edu>; from cummings@cacr.caltech.edu on Thu, May 24, 2001 at 07:59:46PM -0700 References: <20010523173302.B32698@codesourcery.com> <3B0DCAA1.9184F960@cacr.caltech.edu> Message-ID: <20010525131039.A4734@codesourcery.com> On Thu, May 24, 2001 at 07:59:46PM -0700, Julian Cummings wrote: > Jeffrey, > > This patch seems OK to me. There is a problem with respect > to the SGI CC compiler because they do not provide standard > new-style C headers to wrap C library stuff in the std namespace. > > Michael Aivazis and I once looked into the idea of creating > replacements for the missing new-style headers. The most > straightforward idea is, for example > > // replacement for file > namespace std { > #include > } > > This works for everything except , for very arcane > reasons. The successful alternative we came up with is > > // better replacement for file > #include > > namespace std { > // declare items from C library in namespace std > using ::clock_t; > using ::time_t; > // etc. etc. > } > > We have these files checked into our Caltech VTF > repository. If no one objects, I'd like to bring these > over and put them in a new directory src/arch/SGI. > Then I can edit the SGIN32CC.conf and SGI64CC.conf > files and add a -I flag for this platform-specific set > of include files. The gcc and KCC compilers can ignore > these new headers, of course. This should allow us to > use new-style C headers and the std namespace in the > standard way even with the SGI CC compiler. It's fine with me. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From oldham at codesourcery.com Fri May 25 20:30:11 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Fri, 25 May 2001 13:30:11 -0700 Subject: Patch: delete_test1.cpp Message-ID: <20010525133011.A4823@codesourcery.com> Compiling src/Utilities/tests/delete_test1.cpp showed that the vector type `Array_t' was declared to store doubles but actually stored integers. Also, a call to std::memmove() illegally converted vector iterators to pointers. The alternative call to std::copy() is instead used. Considerable discussion between Jim Crotinger and Jeffrey D. Oldham on pooma-dev annoyed other people on the list. The issue, also present in some Domain code, is that using std::memmove() requires converting a vector iterator to a pointer. Jeffrey Oldham objects to this violation of the abstraction barrier and was not able to show a significant speedup using std::memmove() rather than std::copy(). Jim Crotinger says he measured significant speed-up using std::memmove() in early 2000. For the record, one way to obtain a pointer to a vector location that the gcc 3.0 compiler accepts is const Array_t::pointer data_begin_ptr = &(data[0]); 2001 May 25 Jeffrey D. Oldham * delete_test1.cpp (Array_t): s/vector/vector/ (delete_shiftup_test2): Remove "optimization" call to memmove. Tested on sequential Linux using gcc 3.0 by compiling the program Approved by Jim Crotinger Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: delete_test1.cpp =================================================================== RCS file: /home/pooma/Repository/r2/src/Utilities/tests/delete_test1.cpp,v retrieving revision 1.7 diff -c -p -r1.7 delete_test1.cpp *** delete_test1.cpp 2001/03/21 00:56:09 1.7 --- delete_test1.cpp 2001/05/25 20:20:55 *************** int main(int argc, char *argv[]) *** 94,100 **** typedef std::vector KillList_t; ! typedef std::vector Array_t; void delete_shiftup_orig (Array_t &data, const KillList_t &killList); void delete_shiftup_test1(Array_t &data, const KillList_t &killList); --- 94,100 ---- typedef std::vector KillList_t; ! typedef std::vector Array_t; void delete_shiftup_orig (Array_t &data, const KillList_t &killList); void delete_shiftup_test1(Array_t &data, const KillList_t &killList); *************** void delete_shiftup_test2(Array_t &data, *** 618,635 **** if (inext < killed) copy_end_index = killList[inext]; ! const int length = copy_end_index - copy_begin_index; ! ! if (length < 100) ! std::copy(data_begin + copy_begin_index, ! data_begin + copy_end_index, ! data_begin + insert_index); ! else ! std::memmove(data_begin + insert_index, ! data_begin + copy_begin_index, ! sizeof(Array_t::value_type)*length); ! ! insert_index += length; } } --- 618,627 ---- if (inext < killed) copy_end_index = killList[inext]; ! std::copy(data_begin + copy_begin_index, ! data_begin + copy_end_index, ! data_begin + insert_index); ! insert_index += copy_end_index - copy_begin_index; } } From cummings at cacr.caltech.edu Fri May 25 21:38:22 2001 From: cummings at cacr.caltech.edu (Julian C. Cummings) Date: Fri, 25 May 2001 14:38:22 -0700 Subject: [pooma-dev] RFA: SGI CC Header Files In-Reply-To: <20010525131039.A4734@codesourcery.com> Message-ID: I have all of the replacement new-style C header files for the SGI compiler set up and ready to be checked in. I tested them by compiling src/Utilities/tests/delete_test1.cpp under SGI CC. In order to do this, I had to add the following two includes to delete_test1.cpp: #include // needed for std::rand() #include // needed for std::memmove() So I would propose that you augment whatever patch you come up with for delete_test1.cpp to also add these two include statements. If I don't hear any objections, I will check in the replacement header files for SGI CC sometime over the weekend. Thanks, Julian C. -----Original Message----- From: Jeffrey Oldham [mailto:oldham at codesourcery.com] Sent: Friday, May 25, 2001 1:11 PM To: Julian Cummings Cc: pooma-dev at pooma.codesourcery.com Subject: Re: [pooma-dev] RFA: SGI CC Header Files On Thu, May 24, 2001 at 07:59:46PM -0700, Julian Cummings wrote: > Jeffrey, > > This patch seems OK to me. There is a problem with respect > to the SGI CC compiler because they do not provide standard > new-style C headers to wrap C library stuff in the std namespace. > > Michael Aivazis and I once looked into the idea of creating > replacements for the missing new-style headers. The most > straightforward idea is, for example > > // replacement for file > namespace std { > #include > } > > This works for everything except , for very arcane > reasons. The successful alternative we came up with is > > // better replacement for file > #include > > namespace std { > // declare items from C library in namespace std > using ::clock_t; > using ::time_t; > // etc. etc. > } > > We have these files checked into our Caltech VTF > repository. If no one objects, I'd like to bring these > over and put them in a new directory src/arch/SGI. > Then I can edit the SGIN32CC.conf and SGI64CC.conf > files and add a -I flag for this platform-specific set > of include files. The gcc and KCC compilers can ignore > these new headers, of course. This should allow us to > use new-style C headers and the std namespace in the > standard way even with the SGI CC compiler. It's fine with me. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From wdn at lanl.gov Fri May 25 22:43:43 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Fri, 25 May 2001 16:43:43 -0600 (MDT) Subject: [pooma-dev] RFA: DomainIterator.h: Add DomainTraits Specializ ation In-Reply-To: <20010524193113.A18776@codesourcery.com> References: <20010524193113.A18776@codesourcery.com> Message-ID: <15118.57023.433804.585628@mutley.lanl.gov> > > Jeffrey D. Oldham writes: > > > Do you know of a way to have a compiler list all > > > the templates it is instantiating? With KCC, you can easily determine all the templates that were instantiated. I do this all the time for doing explicit instantiations:-{. Here is how I accomplish this with KCC - would work for any EDG based compiler. find . -name "*.ii" -exec cat {} \; | edg_decode >& Templates.dat If you want to restrict to a specific arch then use find . -path "*/MY_ARCH/*" -name "*.ii" -exec cat {} \; | edg_decode >& Templates.dat Then you can grep through this file to find certain types of templates such as :-) grep "View1<" Templates.dat >& View1.dat Does this help you or are you looking for something different? -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 From wdn at lanl.gov Fri May 25 23:29:02 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Fri, 25 May 2001 17:29:02 -0600 (MDT) Subject: [pooma-dev] docbook overview In-Reply-To: References: Message-ID: <15118.59879.64802.80127@mutley.lanl.gov> James Crotinger writes: > My main concern here is Allan's comment that the main authoring tool is > emacs. Don't get me wrong - I'm probably the biggest emacs user here. But I > want a WYSIWYG authoring tool for whatever we're doing. I've written tons of > LaTeX and done a couple of papers with HTML (without a WYSIWYG tool) and I'm > tired of it (unless I need a lot of equations - I still haven't seen a good > alternative to LaTeX for this [I'm very picky about formatting]). If you are doing alot of eqations, I've heard that Lyx is pretty good - it purports to be a WYSIWYWant tool. Sits on top of TeX/LaTeX. I used it a little and it seemed pretty good but don't yet have enough experience to say for sure. However, I think Lyx is probably not very relevant to what you want for this project - just thought I'd mention it for the equation minded. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > If there are some decent WYSIWYG tools that can save their documents in > DocBook format, then that would be great, especially if there is a planned > path toward XML and if the WYSIWYG tools don't make gratuitious changes to > the ASCII file so that "cvs diff"'s are small when the changes are small. > > Jim > > > > -----Original Message----- > > From: Mark Mitchell [mailto:mark at codesourcery.com] > > Sent: Friday, May 25, 2001 11:57 AM > > To: scotth at proximation.com > > Cc: pooma-dev at pooma.codesourcery.com > > Subject: Re: [pooma-dev] docbook overview > > > > > > >>>>> "Scott" == Scott Haney writes: > > > > Scott> Hi Allan, > > > > Scott> I have a few questions and concerns. > > > > Scott> Is it clear that HTML with CSS will not work for us? > > > > Just about. I've been there and tried that -- Netscape, for example, > > basically falls over on all non-trivial instances of CSS. It doesn't > > just do the wrong thing: it crashes. > > > > Scott> This said, I think your points are quite valid in general > > Scott> and maybe, in practice, DocBook is a little less scary than > > Scott> it sounds from your message. Therefore, I look forward to > > Scott> your report. > > > > I strongly suggest that we go with DocBook. One of the big advantages > > is the ease with which you can get printed manuals. For example, > > O'Reilly now lets you give them source for a book as DocBook -- and > > they just print it, and you're done. > > > > It's not actually as threatening as Allan made it sound :-), and any > > SGML editor will work fine with it. > > > > It's also proven technology: we've been using it for months on some > > other projects, with good success. Allan, you might want to contact > > Alex Samuel (samuel at codesourcery.com) to find out exactly how he set > > up DocBook for the work he's been doing with it. But, as long we have > > a standard process to get set up, that's the important thing. > > > > Thanks, > > > > -- > > Mark Mitchell mark at codesourcery.com > > CodeSourcery, LLC http://www.codesourcery.com > > > > > > > > RE: [pooma-dev] docbook overview > > > >

      My main concern here is Allan's comment that the main authoring tool is emacs. Don't get me wrong - I'm probably the biggest emacs user here. But I want a WYSIWYG authoring tool for whatever we're doing. I've written tons of LaTeX and done a couple of papers with HTML (without a WYSIWYG tool) and I'm tired of it (unless I need a lot of equations - I still haven't seen a good alternative to LaTeX for this [I'm very picky about formatting]).

      > >

      If there are some decent WYSIWYG tools that can save their documents in DocBook format, then that would be great, especially if there is a planned path toward XML and if the WYSIWYG tools don't make gratuitious changes to the ASCII file so that "cvs diff"'s are small when the changes are small.

      > >

              Jim >

      >
      > >

      > -----Original Message----- >
      > From: Mark Mitchell [mailto:mark at codesourcery.com] >
      > Sent: Friday, May 25, 2001 11:57 AM >
      > To: scotth at proximation.com >
      > Cc: pooma-dev at pooma.codesourcery.com >
      > Subject: Re: [pooma-dev] docbook overview >
      > >
      > >
      > >>>>> "Scott" == Scott Haney <scotth at proximation.com> writes: >
      > >
      >     Scott> Hi Allan, >
      > >
      >     Scott> I have a few questions and concerns. >
      > >
      >     Scott> Is it clear that HTML with CSS will not work for us? >
      > >
      > Just about.  I've been there and tried that -- Netscape, for example, >
      > basically falls over on all non-trivial instances of CSS.  It doesn't >
      > just do the wrong thing: it crashes. >
      > >
      >     Scott> This said, I think your points are quite valid in general >
      >     Scott> and maybe, in practice, DocBook is a little less scary than >
      >     Scott> it sounds from your message. Therefore, I look forward to >
      >     Scott> your report. >
      > >
      > I strongly suggest that we go with DocBook.  One of the big advantages >
      > is the ease with which you can get printed manuals.  For example, >
      > O'Reilly now lets you give them source for a book as DocBook -- and >
      > they just print it, and you're done. >
      > >
      > It's not actually as threatening as Allan made it sound :-), and any >
      > SGML editor will work fine with it. >
      > >
      > It's also proven technology: we've been using it for months on some >
      > other projects, with good success.  Allan, you might want to contact >
      > Alex Samuel (samuel at codesourcery.com) to find out exactly how he set >
      > up DocBook for the work he's been doing with it.  But, as long we have >
      > a standard process to get set up, that's the important thing. >
      > >
      > Thanks, >
      > >
      > -- >
      > Mark Mitchell                   mark at codesourcery.com >
      > CodeSourcery, LLC               http://www.codesourcery.com >
      > >

      > > > From cummings at linkline.com Sat May 26 19:10:09 2001 From: cummings at linkline.com (Julian C. Cummings) Date: Sat, 26 May 2001 12:10:09 -0700 Subject: weekly status report Message-ID: I reviewed some proposed patches from Jeffrey and whipped up some new-style C header file replacements that we can use with the SGI CC compiler to allow standard-compliant coding. Next week, I plan to get a start on modifying Particles to work with the NewFields. I will have more significant chunks of time to devote to this after June 1st. From jhh at caverns.com Sat May 26 22:41:33 2001 From: jhh at caverns.com (John Hall) Date: Sat, 26 May 2001 16:41:33 -0600 Subject: Pooma where and peephole optimization in CW In-Reply-To: <200105251457.f4PEvij27374@mailproxy1.lanl.gov> References: <200105251457.f4PEvij27374@mailproxy1.lanl.gov> Message-ID: Gang: I have been trying to get our code (Tecolote 4.0/Pooma R2) to compile optimized under Metrowerk's Codewarrior off and on for quite some time. The problem always seemed to be in files which contained a Pooma where statement involving a Field. Interestingly, I could compile code using where statements of type Field,ET>. Anyhow, through sheer perseverence I have been able to determine that it is the peephole optimization which is causing the problem (an internal compiler error). When I turn this option off, I can turn every other optimization option on to its highest value and get it to work. Since Metrowerk's pays more attention to you guys than to me, I thought someone might like to code something like: // Make a CompressibleBrick-Engine-based field. Field, double, CompressibleBrick> fc(cell, layout1, origin, spacings); // Test the where statement for a scalar field fc = -1.0; fc = where(fc > 1.0e-16, fc, 0.0); std::cout << fc << std::endl; and turn the peephole optimizer on and see if they get the same problem. Error : internal compiler error: File: 'Operands.c' Line: 814 BasicTest1.cpp line 146 } Thanks, John -- From wdn at lanl.gov Mon May 28 20:46:58 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Mon, 28 May 2001 14:46:58 -0600 (MDT) Subject: Compile Time Problems and Pooma 2 Message-ID: <15122.47231.155261.717836@mutley.lanl.gov> Hi Guys, I wanted to share some results which I have accumulated over the last week or so regarding compile times and Pooma 2. Some of these results I find to be truly stunning in a negative sense. First, I spent most of last week trying to build a couple of versions of my Pooma2Instantiations library on the secure bluemountain b18 machine. I built a debug and an optimized version of the library using KCC-4.0d. I had the source code for Pooma 2 and the Pooma2Instantiations library located on the local scratch disk. I was doing a parallel using 16 processors including 16 processors for the parallel prelink phase. The timing results which I will be reporting were accumulated this last Friday when b18 was virtually idle except for my compiles. The stunning result is that I could build either a debug or optimized version of the library faster on my 2 year old 366 MHz Pentium 2 laptop with 384 MBytes of memory than I could on an idle b18 using 16 processors. I find this result to be truly stunning. The majority of the compile time, at least 90%, on b18 was spent in the backend C compiler. Here are some timings that I did on 5 files that were associated with instantiating the Pooma 2 global assign function on both b18 and my old laptop. The timing results are not totally comparable because the prelinker chooses to assign templates a little differently from one machine to the other because of doing a parallel compile on b18. These compiles were +K0 compiles using KCC-4.0d. Anyway, here they are: b18 results: Irix 6.5, MipsPro 7.3.1.2m --------------------------------------- Filename | # of .ii | # lines of | +K0 Compile | Line | Time | lines | int C code | Time | Ratio | Ratio -------------------------------------------------------------------------- assign_arg7_03.cc | 341 | 566783 | 7070.603 | 5.46 | 24.14 -------------------------------------------------------------------------- assign_arg5_01.cc | 349 | 314395 | 3266.179 | 3.03 | 11.15 -------------------------------------------------------------------------- assign_arg7_09.cc | 144 | 314070 | 2320.959 | 3.02 | 7.92 -------------------------------------------------------------------------- assign_arg7_13.cc | 124 | 209043 | 1142.474 | 2.01 | 3.90 -------------------------------------------------------------------------- assign_arg5_03.cc | 0 | 103832 | 292.872 | 1.00 | 1.00 -------------------------------------------------------------------------- mutley results: RedHat 6.2 -------------------------- Filename | # of .ii | # lines of | +K0 Compile | Line | Time | lines | int C code | Time | Ratio | Ratio -------------------------------------------------------------------------- assign_arg7_03.cc | 0 | 478303 | 467.63 | 3.63 | 2.84 -------------------------------------------------------------------------- assign_arg5_01.cc | 246 | 308959 | 428.92 | 2.28 | 2.61 -------------------------------------------------------------------------- assign_arg7_09.cc | 91 | 272079 | 360.49 | 2.01 | 2.19 -------------------------------------------------------------------------- assign_arg7_13.cc | 178 | 231415 | 254.78 | 1.71 | 1.55 -------------------------------------------------------------------------- assign_arg5_03.cc | 207 | 135366 | 164.39 | 1.00 | 1.00 -------------------------------------------------------------------------- It seems that on my linux laptop, gcc's compile time scales roughly linearly with the number of lines of intermediate C code. That does not seem to be the case for the SGI cc compiler. I computed these results using both the MipsPro 7.2.1 C compiler and the MipsPro 7.3.1.2m C compiler and the results were essentially identical for practical purposes. Another experiment which I did was to take the instantiation request for the assign function which had the longest template argument and put that in a separate file and do some testing on my linux laptop. The longest template argument was 1666 characters in length. Here are the results with and without exceptions enabled. With Exceptions: ---------------- Case | # lines of | Compile | Optimization | # lines of int | Compile | int C code | Time | Level | C code - base | Time - base ------------------------------------------------------------------------- 1 | 28804 | 33.34 | +K0 | 51 | 12.50 ------------------------------------------------------------------------- 2 | 18263 | 35.27 | +K1 | 37 | 12.33 ------------------------------------------------------------------------- 3 | 14451 | 62.21 | +K2 | 18 | 12.35 ------------------------------------------------------------------------- 4 | 15767 | 76.47 | +K3 | 18 | 12.30 ------------------------------------------------------------------------- Without Exceptions: ------------------- Case | # lines of | Compile | Optimization | # lines of int | Compile | int C code | Time | Level | C code - base | Time - base ------------------------------------------------------------------------- 1 | 26975 | 25.01 | +K0 | 41 | 12.47 ------------------------------------------------------------------------- 2 | 16288 | 31.08 | +K1 | 37 | 13.71 ------------------------------------------------------------------------- 3 | 12476 | 49.62 | +K2 | 18 | 12.32 ------------------------------------------------------------------------- 4 | 13037 | 57.00 | +K3 | 18 | 12.33 ------------------------------------------------------------------------- The results recorded in the "base" columns are results obtained when the template instantiation request is commented out and reflects the compile times and lines of intermediate C code for the case where only the included header files are being parsed. Care was taken to record the number of lines of intermediate C code before the prelinker phase. The prelinker phase determines that the explicit instantiation request for this single assign function triggers the need for an additional 292 templates and the lines of intermediate C code for these additional 292 templates nearly doubles the above numbers. It seems amazing that a single assign function would need between 14430 and 28750 lines of intermediate C code to represent it depending on the optimization level and that it would trigger the need for another 292 templates. Also, I don't think we have gotten to the level of complexity in the expressions for our Pooma 2 based code that we have in our Pooma 1 based code. In our Pooma 1 based code, I have seen expressions which generate template parameters over 2800 characters long. Here is another benchmark to compare the Pooma 2 base code and the Pooma 1 based code. In the Pooma 1 based code, my instantiation library explicitly instantiated nearly every Pooma 1 template. The +K1 compilation of this instantiation library generated approximately 3.5 million lines of intermediate C code for the whole library and just under 1 million lines for the instantiation of all the global assign functions. There were about 1196 of these global assign functions that were instantiated. In constrast, the Pooma 2 instantiation library instantiates 1282 global assign functions which generates 4711082 lines of intermediate C code. The complete Pooma 2 instantiation library currently generates 5327932 lines of intermediate C code. However, there are still lots of Pooma 2 templates that are currently being instantiated by the prelinker in our Blanca code that need to be moved to the Pooma 2 instantiation library. So, it appears that there is alot more intermediate C code generated by KCC for our Pooma 2 code than for our Pooma 1 code. I'm not sure what to make of all this since to a certain degree I am comparing apples and oranges. But I think it does provide some indication of how Pooma 1 and Pooma 2 compare in regard to code generation which contributes to long compile times. Also, I tried out Jeffrey's fixes to allow instantiation of the View1 class and have some comments. It appears that I can now instantiate the View1 class but now I find that I have about 1000 AltView1 templates that I am unable to instantiate. Perhaps we need a new AltAltView1 class:-). Well, seriously, this fix is not solving the root problem which I have which is that I need to be able to explicitly instantiate anything that the compiler is able to instantiate so that I don't have to depend on the prelinker recompiling files. Also, I tried the following template instantiation request which did not work. template const bool View1,T4>::sv; KCC using --strict complained that I did not provide an implementation. So, I don't know what the problem is here. I don't know if the syntax is wrong or there is some bug in KCC. But I do know that the prelinker is capable of performing the instantiation of this member of the View1 class. I have this problem with other Pooma 2 classes such as the ElementProperties class. I wish I could get this problem solved because my compile times are at least twice as long as they would be if I were able to instantiate everything that the compiler is instantiating. I would like to know what the Pooma 2 team things about these results. I find them sobering and not something that I want to see publicized. Do you guys have any ideas about how to modify the relevant parts of Pooma 2 so that less intermediate C code gets generated by KCC? Are there tradeoffs here that you are aware of? Is this code generation problem related specifically to the expression template engine or are there other things involved here? I've been wondering lately if Pooma 2 was designed in a way that would make it easy to use some other expression template engine. I've also been wondering whether it would be possible to make expression templates a feature selectable at compile time. Then for debugging or development perhaps a more lightweight version of Pooma 2 could be used that would run like a dog but compile much faster and facilitate an effective and efficient development environment. Then building a high performance runtime version of our code could be banished to a batch script that was done only infrequently or by a very small group of people. Are things like this reasonable to contemplate with Pooma 2? Please let me know if you have any questions about the results I have presented in this email or if I can supply additional information. I plan to also send a copy of the current version of my Pooma 2 instantiation stuff so you guys can do any testing of your own that you want to do. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 From stephens at proximation.com Mon May 28 23:36:28 2001 From: stephens at proximation.com (Stephen Smith) Date: Mon, 28 May 2001 16:36:28 -0700 Subject: [pooma-dev] Compile Time Problems and Pooma 2 Message-ID: I have a few comments/questions. When I looked at compile times on Nirvana, they were generally linearly related to the intermediate c file size (In K, not the number of lines). Do you know what the sizes of the intermediate files are? A lot of the time is related to just writing the file to disk. Compile times are significantly faster if you checkout the repository on a local filesystem. (I used to use /scratch.) You would probably see significantly slower compile time on Linux if you compiled on directories mounted using NFS. I'm not sure why you're instantiating View1 etc. instead of the functions that Blanca uses directly. For arrays, this would be op() and read(). For example: template View1, Interval<2> >::Type_t Array<2, double, Brick>::operator()(const Interval<2> &) const; You can't instantiate the AltView classes because there is a circular dependency between the field and the view class that AltView is used to solve. Finally, what are the compile times for Debug? Probably a set of compile options that don't inline and don't add the bounds checking code would give you much shorter compile times. Adding a non-expression template implementation would be a moderate chunk of work and may or may not improve compile times significantly. Compile times come from making the views, and building the expression. Compiling the expression evaluation is insignificant. Replacing expression templates could save you the compile time related to building the expression, but the cost of making the view objects may still be significant. Stephen -----Original Message----- From: Dave Nystrom [mailto:wdn at lanl.gov] Sent: Monday, May 28, 2001 2:47 PM To: pooma-dev Cc: Arch Robison; KCC Support; Dave Nystrom; John Hall; Jean Marshall; Don Marshall Subject: [pooma-dev] Compile Time Problems and Pooma 2 Hi Guys, I wanted to share some results which I have accumulated over the last week or so regarding compile times and Pooma 2. Some of these results I find to be truly stunning in a negative sense. First, I spent most of last week trying to build a couple of versions of my Pooma2Instantiations library on the secure bluemountain b18 machine. I built a debug and an optimized version of the library using KCC-4.0d. I had the source code for Pooma 2 and the Pooma2Instantiations library located on the local scratch disk. I was doing a parallel using 16 processors including 16 processors for the parallel prelink phase. The timing results which I will be reporting were accumulated this last Friday when b18 was virtually idle except for my compiles. The stunning result is that I could build either a debug or optimized version of the library faster on my 2 year old 366 MHz Pentium 2 laptop with 384 MBytes of memory than I could on an idle b18 using 16 processors. I find this result to be truly stunning. The majority of the compile time, at least 90%, on b18 was spent in the backend C compiler. Here are some timings that I did on 5 files that were associated with instantiating the Pooma 2 global assign function on both b18 and my old laptop. The timing results are not totally comparable because the prelinker chooses to assign templates a little differently from one machine to the other because of doing a parallel compile on b18. These compiles were +K0 compiles using KCC-4.0d. Anyway, here they are: b18 results: Irix 6.5, MipsPro 7.3.1.2m --------------------------------------- Filename | # of .ii | # lines of | +K0 Compile | Line | Time | lines | int C code | Time | Ratio | Ratio -------------------------------------------------------------------------- assign_arg7_03.cc | 341 | 566783 | 7070.603 | 5.46 | 24.14 -------------------------------------------------------------------------- assign_arg5_01.cc | 349 | 314395 | 3266.179 | 3.03 | 11.15 -------------------------------------------------------------------------- assign_arg7_09.cc | 144 | 314070 | 2320.959 | 3.02 | 7.92 -------------------------------------------------------------------------- assign_arg7_13.cc | 124 | 209043 | 1142.474 | 2.01 | 3.90 -------------------------------------------------------------------------- assign_arg5_03.cc | 0 | 103832 | 292.872 | 1.00 | 1.00 -------------------------------------------------------------------------- mutley results: RedHat 6.2 -------------------------- Filename | # of .ii | # lines of | +K0 Compile | Line | Time | lines | int C code | Time | Ratio | Ratio -------------------------------------------------------------------------- assign_arg7_03.cc | 0 | 478303 | 467.63 | 3.63 | 2.84 -------------------------------------------------------------------------- assign_arg5_01.cc | 246 | 308959 | 428.92 | 2.28 | 2.61 -------------------------------------------------------------------------- assign_arg7_09.cc | 91 | 272079 | 360.49 | 2.01 | 2.19 -------------------------------------------------------------------------- assign_arg7_13.cc | 178 | 231415 | 254.78 | 1.71 | 1.55 -------------------------------------------------------------------------- assign_arg5_03.cc | 207 | 135366 | 164.39 | 1.00 | 1.00 -------------------------------------------------------------------------- It seems that on my linux laptop, gcc's compile time scales roughly linearly with the number of lines of intermediate C code. That does not seem to be the case for the SGI cc compiler. I computed these results using both the MipsPro 7.2.1 C compiler and the MipsPro 7.3.1.2m C compiler and the results were essentially identical for practical purposes. Another experiment which I did was to take the instantiation request for the assign function which had the longest template argument and put that in a separate file and do some testing on my linux laptop. The longest template argument was 1666 characters in length. Here are the results with and without exceptions enabled. With Exceptions: ---------------- Case | # lines of | Compile | Optimization | # lines of int | Compile | int C code | Time | Level | C code - base | Time - base ------------------------------------------------------------------------- 1 | 28804 | 33.34 | +K0 | 51 | 12.50 ------------------------------------------------------------------------- 2 | 18263 | 35.27 | +K1 | 37 | 12.33 ------------------------------------------------------------------------- 3 | 14451 | 62.21 | +K2 | 18 | 12.35 ------------------------------------------------------------------------- 4 | 15767 | 76.47 | +K3 | 18 | 12.30 ------------------------------------------------------------------------- Without Exceptions: ------------------- Case | # lines of | Compile | Optimization | # lines of int | Compile | int C code | Time | Level | C code - base | Time - base ------------------------------------------------------------------------- 1 | 26975 | 25.01 | +K0 | 41 | 12.47 ------------------------------------------------------------------------- 2 | 16288 | 31.08 | +K1 | 37 | 13.71 ------------------------------------------------------------------------- 3 | 12476 | 49.62 | +K2 | 18 | 12.32 ------------------------------------------------------------------------- 4 | 13037 | 57.00 | +K3 | 18 | 12.33 ------------------------------------------------------------------------- The results recorded in the "base" columns are results obtained when the template instantiation request is commented out and reflects the compile times and lines of intermediate C code for the case where only the included header files are being parsed. Care was taken to record the number of lines of intermediate C code before the prelinker phase. The prelinker phase determines that the explicit instantiation request for this single assign function triggers the need for an additional 292 templates and the lines of intermediate C code for these additional 292 templates nearly doubles the above numbers. It seems amazing that a single assign function would need between 14430 and 28750 lines of intermediate C code to represent it depending on the optimization level and that it would trigger the need for another 292 templates. Also, I don't think we have gotten to the level of complexity in the expressions for our Pooma 2 based code that we have in our Pooma 1 based code. In our Pooma 1 based code, I have seen expressions which generate template parameters over 2800 characters long. Here is another benchmark to compare the Pooma 2 base code and the Pooma 1 based code. In the Pooma 1 based code, my instantiation library explicitly instantiated nearly every Pooma 1 template. The +K1 compilation of this instantiation library generated approximately 3.5 million lines of intermediate C code for the whole library and just under 1 million lines for the instantiation of all the global assign functions. There were about 1196 of these global assign functions that were instantiated. In constrast, the Pooma 2 instantiation library instantiates 1282 global assign functions which generates 4711082 lines of intermediate C code. The complete Pooma 2 instantiation library currently generates 5327932 lines of intermediate C code. However, there are still lots of Pooma 2 templates that are currently being instantiated by the prelinker in our Blanca code that need to be moved to the Pooma 2 instantiation library. So, it appears that there is alot more intermediate C code generated by KCC for our Pooma 2 code than for our Pooma 1 code. I'm not sure what to make of all this since to a certain degree I am comparing apples and oranges. But I think it does provide some indication of how Pooma 1 and Pooma 2 compare in regard to code generation which contributes to long compile times. Also, I tried out Jeffrey's fixes to allow instantiation of the View1 class and have some comments. It appears that I can now instantiate the View1 class but now I find that I have about 1000 AltView1 templates that I am unable to instantiate. Perhaps we need a new AltAltView1 class:-). Well, seriously, this fix is not solving the root problem which I have which is that I need to be able to explicitly instantiate anything that the compiler is able to instantiate so that I don't have to depend on the prelinker recompiling files. Also, I tried the following template instantiation request which did not work. template const bool View1,T4>::sv; KCC using --strict complained that I did not provide an implementation. So, I don't know what the problem is here. I don't know if the syntax is wrong or there is some bug in KCC. But I do know that the prelinker is capable of performing the instantiation of this member of the View1 class. I have this problem with other Pooma 2 classes such as the ElementProperties class. I wish I could get this problem solved because my compile times are at least twice as long as they would be if I were able to instantiate everything that the compiler is instantiating. I would like to know what the Pooma 2 team things about these results. I find them sobering and not something that I want to see publicized. Do you guys have any ideas about how to modify the relevant parts of Pooma 2 so that less intermediate C code gets generated by KCC? Are there tradeoffs here that you are aware of? Is this code generation problem related specifically to the expression template engine or are there other things involved here? I've been wondering lately if Pooma 2 was designed in a way that would make it easy to use some other expression template engine. I've also been wondering whether it would be possible to make expression templates a feature selectable at compile time. Then for debugging or development perhaps a more lightweight version of Pooma 2 could be used that would run like a dog but compile much faster and facilitate an effective and efficient development environment. Then building a high performance runtime version of our code could be banished to a batch script that was done only infrequently or by a very small group of people. Are things like this reasonable to contemplate with Pooma 2? Please let me know if you have any questions about the results I have presented in this email or if I can supply additional information. I plan to also send a copy of the current version of my Pooma 2 instantiation stuff so you guys can do any testing of your own that you want to do. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnharveyhall at qwest.net Tue May 29 07:12:39 2001 From: johnharveyhall at qwest.net (John Hall) Date: Tue, 29 May 2001 01:12:39 -0600 Subject: Can no longer make new fields Message-ID: Gang: I have updated to the latest POOMA and under CodeWarrior, I can no longer create fields. Obviously, this is a little distressing. Here is a traceback of the exception: TecFramework::MetaClass>::Initialize(TecFramework::Ptr) const TecFramework::IMutate::Initialize(TecFramework ::Ptr) poomalote::PoomaFields::Initialize() poomalote::PoomaFields::Initialize2D() poomalote::PoomaFields::try2D<4Vert>(const Vert&) poomalote::MakeField>>::operator ()(const Vert&,const std::list, std::allocator>>&,const bool&,long) poomalote::TecMeshD<2, UniformRectilinear<2, double, Cartesian<2>>>::ExtractT<4Vert,d>(const Vert&,TecFramework::Ptr) poomalote::TecMeshD<2, UniformRectilinear<2, double, Cartesian<2>>>::getNewCenteredTypeField<4Vert,d>(const Vert&,const double&) FieldEngineBase<2, double, CompressibleBrick>::!(const Vert&,const DomainLayout<2>&) Engine<2, double, CompressibleBrick>::Engine(const DomainLayout<2>&) CompressibleBlock::CompressibleBlockController::CompressibleBl ockController(int) Pooma::neverCompress() Pooma::toss_cookies(const char*,const char*,int,...) I tried to recreate the exception message that was thrown and I got: routine neverCompress pAssert "initialized_s" in file: "Pooma.cmpl.cpp" at line 725. Any help would be appreciated. John Hall From scotth at proximation.com Tue May 29 15:13:07 2001 From: scotth at proximation.com (Scott Haney) Date: Tue, 29 May 2001 09:13:07 -0600 Subject: [pooma-dev] docbook overview In-Reply-To: <20010525122032N.mitchell@codesourcery.com> Message-ID: Hi Mark, If Allan were really going to write all of the documentation, I'd grant your last point. However, I think it is reasonable to suspect that Proximation folks will have a little to contribute in this area. Therefore, our concerns should be considered. We can also debate whether the world is headed to SGML or, as I suspect, XML. However, let's not. We'll give DocBook a try subject to the caveat that we're not going to spend time porting this to MacOS X or Windows, which means that we may be checking in badly-formed files that others will have to debug. Also, if it sucks for us, we'll provide input in other forms and allow the DocBook boosters to convert. Sound fair? Scott On Friday, May 25, 2001, at 01:20 PM, Mark Mitchell wrote: >>>>>> "James" == James Crotinger writes: > > James> the biggest emacs user here. But I want a WYSIWYG authoring > James> tool for whatever we're doing. > > Hmm. There *are* free DocBook WYSIWYG editors but I don't know how > well they work. One example is `www.conglomerate.org'. Also > `epcEdit' is not WYSIWYG -- but is specially designed to work with > SGML. > > Also, there are commercial DocBook editors that what a lot of the > publishing people are using now. For example, Arbortext's `Epic' or > Adobe's `FrameMaker'. There's also something called XMetaL. These > are all WYSIWYG. These tools are all priced around $750. > > It would be nice if DocBook tools were two years further along. But, > this is the format we want -- it's a good way of producing web docs, > print docs, and even man pages, in a reliable way, and just about > everyone is using it. If we don't do this, then we'll end up > converting two years hence, and that's a complete pain in the neck. > > In fairness, since Allan has the job of writing most of the > documentation, and since he's happy in Emacs, shouldn't we let him use > what he likes, especially when it's the forward-looking technology > that the industry seems to be standardizing on? > > -- > Mark Mitchell mark at codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com -- Scott W. Haney Development Manager Proximation LLC 2960 Rodeo Park Drive West Santa Fe, NM 87505 Voice: 505-424-3809 x101 FAX: 505-438-4161 From allan at stokes.ca Tue May 29 17:07:32 2001 From: allan at stokes.ca (Allan Stokes) Date: Tue, 29 May 2001 10:07:32 -0700 Subject: [pooma-dev] docbook overview Message-ID: Hello Scott, I was having one of my foggy days when I wrote my DocBook overview so I tried to keep it descriptive without making too many claims about whether DocBook is a good or a bad thing. The purpose was to describe DocBook and the environment around it so that others would have a chance to raise their concerns. I don't yet have much experience with DocBook. I do have some experience with SGML/XML text manipulation and I generally like that approach. I expect that authoring in DocBook will be as easy as writing raw HTML once I get into it. I know that in the long run the separation of structure from presentation pays off. My biggest concern presently is the equation support. Just because DocBook has an "equation" element doesn't mean it won't be onerous. I will explore this issue in my trial documents. I once toyed with IBM's TechExplorer, which was a plug-in for IE allowing the display of Latex equations. Convenient, but not very portable. Equations can be a big problem. No need for debate on whether the future is SGML or XML. DocBook is neutral on this subject. The difference between a DocBook document formatted in SGML syntax or in XML syntax are on the level of which way out to hang a roll of bathroom tissue. Once XML is further along it will become possible to eliminate the use of Jade/DSSSL in preference for XSL/XSLT when publishing the documents. I ignored XML completely in my description, except to explain that it exists as a parallel stream. I guess the point I was trying to make is that the XML community sees DocBook, someday RSN, as one of its own. I don't have many concerns about getting good typographic quality. Jade is an extremely powerful typesetting tool. James Clark contributed the GNU implementation of groff before he started working on Jade, and Jade is almost certainly a superset in functionality. However, if you want to be really picky, you might end up having to modify DSSSL code, which can be quite a hairball, so I'm hoping we aren't that picky. Because DocBook knows the structure of the source document, I don't expect it to emit much "stupid" typography. I'm picky myself actually. I know the difference between an em and an en and it bugs me when these things aren't handled right. After I've played with Jade for a while, I'll know better what to expect. If you wish to be picky right down to intercharacter whitespace/word-break level, you'd probably use Jade to emit Latex and then tweak the Latex format until it looked perfect. DocBook is a flexible environment where anything is possible. The trick is to figure out which modes are effective in practice. I wish I had more experience to offer. >From my point of view, the primary appeal of DocBook is the separation of structure from presentation. Ultimately this is the only way to go if you wish to use one source format to produce a wide range of back-end formats. I understand the problem with emacs not being wysiwyg. I hate to impose something like psgml on others. However, we need to bear in mind that wysiwyg brings its own problems. wysiwyg is only wysiwyg if you are targetting a single backend format which is specified in advance. I like to take a wider view of technical documentation. wysiwyg can also stand for "what you saw is what you got". You experience this whenever you open up old Office documents with a newer version. I tend to regard wysiwyg as standing for "what you see is what you've got", i.e as a useful visual aid during composition. I'm not amused when people confuse wysiwyg with camera-ready output. I'm certainly willing to do my part to make DocBook tolerable for everyone. Fixing badly-formed DocBook files isn't likely to be much of a chore. The SGML world has great tools for this kind of thing and psgml has more blades than a Swiss army knife. Converting formats is OK if that makes life easier for others. As long as we pick formats which are reasonably equivalent with the understanding that DocBook provides its own presentation backend and that our decisions about how much control to take over that process need to be made cautiously. I looked at many options before I identified DocBook as solving the largest number of problems. If it creates problems I'm happy to consider alternatives. Allan -----Original Message----- From: Scott Haney [mailto:scotth at proximation.com] Sent: Tuesday 29 May 2001 08:13 To: pooma-dev at pooma.codesourcery.com Subject: Re: [pooma-dev] docbook overview Hi Mark, If Allan were really going to write all of the documentation, I'd grant your last point. However, I think it is reasonable to suspect that Proximation folks will have a little to contribute in this area. Therefore, our concerns should be considered. We can also debate whether the world is headed to SGML or, as I suspect, XML. However, let's not. We'll give DocBook a try subject to the caveat that we're not going to spend time porting this to MacOS X or Windows, which means that we may be checking in badly-formed files that others will have to debug. Also, if it sucks for us, we'll provide input in other forms and allow the DocBook boosters to convert. Sound fair? Scott From scotth at proximation.com Tue May 29 17:17:13 2001 From: scotth at proximation.com (Scott Haney) Date: Tue, 29 May 2001 11:17:13 -0600 Subject: [pooma-dev] RFA: Tutorial Documentation Typographical Fix In-Reply-To: <200105251933.MAA04578@oz.codesourcery.com> Message-ID: On Friday, May 25, 2001, at 01:33 PM, Jeffrey Oldham wrote: > > Per Scott Haney's suggestion, I filed my latest Pooma source code > patch request using Pooma's QMTrack. To access it, > > 1) point your browser to http://pooma.codesourcery.com:4242/track/ > > 2) log in using your last name as your username and your password > > 3) Enter `tutorial_patch' as the Issue ID. > > 4) Approve my patch. > > I'll step back as everyone rushes to try out the new tool. :) If you > have difficulty, send email to samuel at codesourcery.com, who is > building the tools, or to me. > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com I went to the page and was able to find the patch. However, this would be a lot more useful if I could browse issues rather than having to know the ID. Alternatively, can one use wildcards in searches? Also, I couldn't read the attachment when I downloaded it. I think the problem is that its MIME type was set as application/octet-stream. Also, IE downloaded the file as "download attachment" it would be nice if it could get the name right. Scott From scotth at proximation.com Tue May 29 17:40:39 2001 From: scotth at proximation.com (Scott Haney) Date: Tue, 29 May 2001 11:40:39 -0600 Subject: [pooma-dev] Can no longer make new fields In-Reply-To: Message-ID: Hi John, I just fixed a typo in Field.h. I haven't been able to reproduce your problem though. I can make Fields with and without CompressibleBricks and I call Pooma::neverCompress(). The variable initialized_s is set in Pooma::initialize(). Are you sure you're calling this? Scott On Tuesday, May 29, 2001, at 01:12 AM, John Hall wrote: > Gang: > I have updated to the latest POOMA and under CodeWarrior, I can no > longer create fields. Obviously, this is a little distressing. Here is > a traceback of the exception: > > TecFramework::MetaClass elds, > poomalote::PoomaFields>>::Initialize(TecFramework::Ptr nyType>) const > TecFramework::IMutate::Initialize(TecFramework > ::Ptr) > poomalote::PoomaFields::Initialize() > poomalote::PoomaFields::Initialize2D() > poomalote::PoomaFields::try2D<4Vert>(const Vert&) > poomalote::MakeField Cartesian<2>>>::operator ()(const Vert&,const > std::list, > std::allocator>>&,const > bool&,long) > poomalote::TecMeshD<2, UniformRectilinear<2, double, > Cartesian<2>>>::ExtractT<4Vert,d>(const > Vert&,TecFramework::Ptr) > poomalote::TecMeshD<2, UniformRectilinear<2, double, > Cartesian<2>>>::getNewCenteredTypeField<4Vert,d>(const Vert&,const > double&) > FieldEngineBase<2, double, CompressibleBrick>::!(const > Vert&,const DomainLayout<2>&) > Engine<2, double, CompressibleBrick>::Engine(const DomainLayout<2>&) > CompressibleBlock::CompressibleBlockController::CompressibleBl > ockController(int) > Pooma::neverCompress() > Pooma::toss_cookies(const char*,const char*,int,...) > > I tried to recreate the exception message that was thrown and I got: > routine neverCompress pAssert "initialized_s" in file: "Pooma.cmpl.cpp" > at line 725. > > Any help would be appreciated. > John Hall From wdn at lanl.gov Tue May 29 17:53:16 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Tue, 29 May 2001 11:53:16 -0600 (MDT) Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: References: Message-ID: <15123.51609.122947.372321@mutley.lanl.gov> Hi Stephen, Thanks for your reply. Stephen Smith writes: > I have a few comments/questions. > > When I looked at compile times on Nirvana, they were > generally linearly related to the intermediate c file > size (In K, not the number of lines). Do you know what > the sizes of the intermediate files are? A lot of the time Here are the b18 results with the extra info you requested. I decided to record the size of the .int.c files in MBytes for obvious reasons:-). b18 results: Irix 6.5, MipsPro 7.3.1.2m --------------------------------------- Filename | # of .ii | # lines of | +K0 Compile | Line | Time | Size In | lines | int C code | Time | Ratio | Ratio | MBytes ------------------------------------------------------------------------------------ assign_arg7_03.cc | 341 | 566783 | 7070.603 | 5.46 | 24.14 | 61.73 ------------------------------------------------------------------------------------ assign_arg5_01.cc | 349 | 314395 | 3266.179 | 3.03 | 11.15 | 32.59 ------------------------------------------------------------------------------------ assign_arg7_09.cc | 144 | 314070 | 2320.959 | 3.02 | 7.92 | 33.55 ------------------------------------------------------------------------------------ assign_arg7_13.cc | 124 | 209043 | 1142.474 | 2.01 | 3.90 | 22.54 ------------------------------------------------------------------------------------ assign_arg5_03.cc | 0 | 103832 | 292.872 | 1.00 | 1.00 | 10.66 ------------------------------------------------------------------------------------ > is related to just writing the file to disk. Compile times > are significantly faster if you checkout the repository > on a local filesystem. (I used to use /scratch.) You would > probably see significantly slower compile time on Linux if > you compiled on directories mounted using NFS. I read your later email so I know you picked up on the fact that I am using /scratch on b18. Also, b18 was essentially idle so that I had a pretty dedicated compile platform. The only stuff I was grabbing from an NFS disk was the KCC headers and the system headers. I have actually installed KCC on the scratch disk in the past and noticed about a 10% reduction in compile time by having the KCC headers local. I've never copied the system headers over to scratch but I thought about it once. Should not be hard but I figured the performance increase would be comparable to making KCC local i.e. about 10%. On our secure Pooma 1 code when I moved Pooma 1 and our Blanca source code from NFS to the scratch disk, I reduced compile times by a factor of 3. That was after we already had /tmp on scratch and all our build products going to scratch. > I'm not sure why you're instantiating View1 etc. instead of > the functions that Blanca uses directly. For arrays, this would > be op() and read(). For example: > > template View1, Interval<2> >::Type_t > Array<2, double, Brick>::operator()(const Interval<2> &) const; I am trying to make a custom Blanca instantiation library for Pooma 2 templates and to also explicitly instantiate all the templates that Blanca uses, including STL templates and Blanca templates. The fundamental reason for this tedious exercise is to significantly reduce the overall compile time required to build Blanca software. There are two ways to get compile time reductions. One is to instantiate Pooma 2 templates that we are using in a separate Pooma2Instantiations library that only gets recompiled when we update or change Pooma 2. Then, all of the Pooma 2 templates that would have normally been assigned to Blanca translation units are now in this instantiation library that only needs to be rebuilt on an infrequent basis i.e. when we update Pooma 2. So, a tremendous amount of compilation work has been pushed to a lower level. The second way to significantly reduce compile times is to eliminate recompiles that the prelinker performs. But the way this works is that you start reducing the number of templates that get assigned to a translation unit by the prelinker but until you make that number go to 0, you will still be recompiling the file. One problem with relying on the prelinker is that you can't very easily control which translation units it chooses to assign templates to and it tends to be pretty democratic and assign some to all. Maybe we need a republican prelinker that would assign all the templates to just a few:-). Anyway, the bottom line is that I need to be able to explicitly instantiate any template that the compiler can instantiate which when using EDG based compilers is via the prelinker. The absolute only reason that I want to instantiate the View1<...>::sv template is because when I analyse the .ii files for our Blanca compiles I find that the compiler has found references to 1800+ of these templates that if feels obliged to instantiate. I need to be able to instantiate them myself so the prelinker does not put some in nearly every translation unit and then feel obliged to recompile that translation unit. > You can't instantiate the AltView classes because there is a > circular dependency between the field and the view class that > AltView is used to solve. I realize this. I'm just pointing out in my previous email that Jeffrey's fix unfortunately did not really solve the fundamental problem that I am trying to solve. I can now instantiate the View1 class but now I have just as many AltView1 templates that I cannot instantiate and the prelinker is going to be very democratic about where it assigns them as well. > Finally, what are the compile times for Debug? Probably a set of The times that I reported were Debug compile times i.e. +K0 - at least for the b18 stuff. The second experiment that I did was aimed at studying how many lines of C code would be generated for different compile optimization levels for just one of these global assign functions i.e. the one with the longest template argument which would presumably be associated with the most complex assignment expression that we were using or at least pretty close to the most complex. So in the second experiment, I did +K0, +K1, +K2 and +K3 builds. For optimization levels of +K1 and higher, I included these options as well. These were what my optimized builds of the Pooma 2 library were adding on. -DNOCHEETAHCTAssert -DNOCHEETAHRTAssert -DNOPAssert -DNOCTAssert \ --restrict --inline_keyword_space_time=10000.0 > compile options that don't inline and don't add the bounds checking > code would give you much shorter compile times. Adding a non-expression > template implementation would be a moderate chunk of work and may or may > not improve compile times significantly. Compile times come from making > the views, and building the expression. Compiling the expression evaluation > is insignificant. Replacing expression templates could save you the > compile time related to building the expression, but the cost of making > the view objects may still be significant. Hmmmmmmmmm. Well, I don't really understand what drives the compile times for Pooma 2 based code very well. At the lowest level there seems a strong correlation with the amount of intermediate C code that is generated whether measured in lines or bytes. Also, when it comes to optimizing functions, I am under the impression that the optimization process generally scales quadratically or perhaps worse with the size of the function body. But I have no idea why the intermediate C code to evaluate a single complex expression should be measured in tens of thousands of lines of code even though it is evaluating this expression in a parallel environment, etc. This somehow does not seem reasonable to me but I claim ignorance and am perhaps being naive. I would imagine that reductions could be made but I don't know if this would involve trade offs and if so, what they would be. From my position of ignorance about the details of Pooma 2, I worry that 1). the design is not properly factored so that alot of the code for one global assign function looks the same as that for another global assign function, only the template parameters are a little different and 2). that functions are being inlined that do not really need to be inlined for runtime performance reasons. But again, I must emphasize my position of ignorance because I just have not had time to study the details of Pooma 2 - spending too much time trying to get manageable compile times. Hope others will chime in with their evaluation of all this stuff. Thanks again, Stephen, for your response. Let me know if I can provide additional information. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > Stephen > > -----Original Message----- > From: Dave Nystrom [mailto:wdn at lanl.gov] > Sent: Monday, May 28, 2001 2:47 PM > To: pooma-dev > Cc: Arch Robison; KCC Support; Dave Nystrom; John Hall; Jean Marshall; > Don Marshall > Subject: [pooma-dev] Compile Time Problems and Pooma 2 > > > Hi Guys, > > I wanted to share some results which I have accumulated over the last week > or > so regarding compile times and Pooma 2. Some of these results I find to be > truly stunning in a negative sense. First, I spent most of last week trying > to build a couple of versions of my Pooma2Instantiations library on the > secure bluemountain b18 machine. I built a debug and an optimized version > of > the library using KCC-4.0d. I had the source code for Pooma 2 and the > Pooma2Instantiations library located on the local scratch disk. I was doing > a parallel using 16 processors including 16 processors for the parallel > prelink phase. The timing results which I will be reporting were > accumulated > this last Friday when b18 was virtually idle except for my compiles. The > stunning result is that I could build either a debug or optimized version of > the library faster on my 2 year old 366 MHz Pentium 2 laptop with 384 MBytes > of memory than I could on an idle b18 using 16 processors. I find this > result to be truly stunning. The majority of the compile time, at least > 90%, > on b18 was spent in the backend C compiler. Here are some timings that I > did > on 5 files that were associated with instantiating the Pooma 2 global assign > function on both b18 and my old laptop. The timing results are not totally > comparable because the prelinker chooses to assign templates a little > differently from one machine to the other because of doing a parallel > compile > on b18. These compiles were +K0 compiles using KCC-4.0d. Anyway, here they > are: > > b18 results: Irix 6.5, MipsPro 7.3.1.2m > --------------------------------------- > > Filename | # of .ii | # lines of | +K0 Compile | Line | Time > | lines | int C code | Time | Ratio | Ratio > -------------------------------------------------------------------------- > assign_arg7_03.cc | 341 | 566783 | 7070.603 | 5.46 | 24.14 > -------------------------------------------------------------------------- > assign_arg5_01.cc | 349 | 314395 | 3266.179 | 3.03 | 11.15 > -------------------------------------------------------------------------- > assign_arg7_09.cc | 144 | 314070 | 2320.959 | 3.02 | 7.92 > -------------------------------------------------------------------------- > assign_arg7_13.cc | 124 | 209043 | 1142.474 | 2.01 | 3.90 > -------------------------------------------------------------------------- > assign_arg5_03.cc | 0 | 103832 | 292.872 | 1.00 | 1.00 > -------------------------------------------------------------------------- > > > mutley results: RedHat 6.2 > -------------------------- > > Filename | # of .ii | # lines of | +K0 Compile | Line | Time > | lines | int C code | Time | Ratio | Ratio > -------------------------------------------------------------------------- > assign_arg7_03.cc | 0 | 478303 | 467.63 | 3.63 | 2.84 > -------------------------------------------------------------------------- > assign_arg5_01.cc | 246 | 308959 | 428.92 | 2.28 | 2.61 > -------------------------------------------------------------------------- > assign_arg7_09.cc | 91 | 272079 | 360.49 | 2.01 | 2.19 > -------------------------------------------------------------------------- > assign_arg7_13.cc | 178 | 231415 | 254.78 | 1.71 | 1.55 > -------------------------------------------------------------------------- > assign_arg5_03.cc | 207 | 135366 | 164.39 | 1.00 | 1.00 > -------------------------------------------------------------------------- > > It seems that on my linux laptop, gcc's compile time scales roughly linearly > with the number of lines of intermediate C code. That does not seem to be > the case for the SGI cc compiler. I computed these results using both the > MipsPro 7.2.1 C compiler and the MipsPro 7.3.1.2m C compiler and the results > were essentially identical for practical purposes. > > Another experiment which I did was to take the instantiation request for the > assign function which had the longest template argument and put that in a > separate file and do some testing on my linux laptop. The longest template > argument was 1666 characters in length. Here are the results with and > without exceptions enabled. > > With Exceptions: > ---------------- > > Case | # lines of | Compile | Optimization | # lines of int | Compile > | int C code | Time | Level | C code - base | Time - base > ------------------------------------------------------------------------- > 1 | 28804 | 33.34 | +K0 | 51 | 12.50 > ------------------------------------------------------------------------- > 2 | 18263 | 35.27 | +K1 | 37 | 12.33 > ------------------------------------------------------------------------- > 3 | 14451 | 62.21 | +K2 | 18 | 12.35 > ------------------------------------------------------------------------- > 4 | 15767 | 76.47 | +K3 | 18 | 12.30 > ------------------------------------------------------------------------- > > Without Exceptions: > ------------------- > > Case | # lines of | Compile | Optimization | # lines of int | Compile > | int C code | Time | Level | C code - base | Time - base > ------------------------------------------------------------------------- > 1 | 26975 | 25.01 | +K0 | 41 | 12.47 > ------------------------------------------------------------------------- > 2 | 16288 | 31.08 | +K1 | 37 | 13.71 > ------------------------------------------------------------------------- > 3 | 12476 | 49.62 | +K2 | 18 | 12.32 > ------------------------------------------------------------------------- > 4 | 13037 | 57.00 | +K3 | 18 | 12.33 > ------------------------------------------------------------------------- > > The results recorded in the "base" columns are results obtained when the > template instantiation request is commented out and reflects the compile > times and lines of intermediate C code for the case where only the included > header files are being parsed. Care was taken to record the number of lines > of intermediate C code before the prelinker phase. The prelinker phase > determines that the explicit instantiation request for this single assign > function triggers the need for an additional 292 templates and the lines of > intermediate C code for these additional 292 templates nearly doubles the > above numbers. It seems amazing that a single assign function would need > between 14430 and 28750 lines of intermediate C code to represent it > depending on the optimization level and that it would trigger the need for > another 292 templates. Also, I don't think we have gotten to the level of > complexity in the expressions for our Pooma 2 based code that we have in our > Pooma 1 based code. In our Pooma 1 based code, I have seen expressions > which > generate template parameters over 2800 characters long. > > Here is another benchmark to compare the Pooma 2 base code and the Pooma 1 > based code. In the Pooma 1 based code, my instantiation library explicitly > instantiated nearly every Pooma 1 template. The +K1 compilation of this > instantiation library generated approximately 3.5 million lines of > intermediate C code for the whole library and just under 1 million lines for > the instantiation of all the global assign functions. There were about 1196 > of these global assign functions that were instantiated. In constrast, the > Pooma 2 instantiation library instantiates 1282 global assign functions > which > generates 4711082 lines of intermediate C code. The complete Pooma 2 > instantiation library currently generates 5327932 lines of intermediate C > code. However, there are still lots of Pooma 2 templates that are currently > being instantiated by the prelinker in our Blanca code that need to be moved > to the Pooma 2 instantiation library. So, it appears that there is alot > more > intermediate C code generated by KCC for our Pooma 2 code than for our Pooma > 1 code. I'm not sure what to make of all this since to a certain degree I > am > comparing apples and oranges. But I think it does provide some indication > of > how Pooma 1 and Pooma 2 compare in regard to code generation which > contributes to long compile times. > > Also, I tried out Jeffrey's fixes to allow instantiation of the View1 class > and have some comments. It appears that I can now instantiate the View1 > class but now I find that I have about 1000 AltView1 templates that I am > unable to instantiate. Perhaps we need a new AltAltView1 class:-). Well, > seriously, this fix is not solving the root problem which I have which is > that I need to be able to explicitly instantiate anything that the compiler > is able to instantiate so that I don't have to depend on the prelinker > recompiling files. Also, I tried the following template instantiation > request which did not work. > > template const bool View1,T4>::sv; > > KCC using --strict complained that I did not provide an implementation. So, > I don't know what the problem is here. I don't know if the syntax is wrong > or there is some bug in KCC. But I do know that the prelinker is capable of > performing the instantiation of this member of the View1 class. I have this > problem with other Pooma 2 classes such as the ElementProperties class. I > wish I could get this problem solved because my compile times are at least > twice as long as they would be if I were able to instantiate everything that > the compiler is instantiating. > > I would like to know what the Pooma 2 team things about these results. I > find them sobering and not something that I want to see publicized. Do you > guys have any ideas about how to modify the relevant parts of Pooma 2 so > that > less intermediate C code gets generated by KCC? Are there tradeoffs here > that you are aware of? Is this code generation problem related specifically > to the expression template engine or are there other things involved here? > I've been wondering lately if Pooma 2 was designed in a way that would make > it easy to use some other expression template engine. I've also been > wondering whether it would be possible to make expression templates a > feature > selectable at compile time. Then for debugging or development perhaps a > more > lightweight version of Pooma 2 could be used that would run like a dog but > compile much faster and facilitate an effective and efficient development > environment. Then building a high performance runtime version of our code > could be banished to a batch script that was done only infrequently or by a > very small group of people. Are things like this reasonable to contemplate > with Pooma 2? > > Please let me know if you have any questions about the results I have > presented in this email or if I can supply additional information. I plan > to > also send a copy of the current version of my Pooma 2 instantiation stuff so > you guys can do any testing of your own that you want to do. > > -- > Dave Nystrom email: wdn at lanl.gov > LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > > > > > > RE: [pooma-dev] Compile Time Problems and Pooma 2 > > > >

      I have a few comments/questions. >

      > >

      When I looked at compile times on Nirvana, they were >
      generally linearly related to the intermediate c file >
      size (In K, not the number of lines).  Do you know what >
      the sizes of the intermediate files are?  A lot of the time >
      is related to just writing the file to disk.  Compile times >
      are significantly faster if you checkout the repository >
      on a local filesystem. (I used to use /scratch.)  You would >
      probably see significantly slower compile time on Linux if >
      you compiled on directories mounted using NFS. >

      > >

      I'm not sure why you're instantiating View1 etc. instead of >
      the functions that Blanca uses directly.  For arrays, this would >
      be op() and read().  For example: >

      > >

      template View1<Array<2, double, Brick>, Interval<2> >::Type_t >
      Array<2, double, Brick>::operator()(const Interval<2> &) const; >

      > >

      You can't instantiate the AltView classes because there is a >
      circular dependency between the field and the view class that >
      AltView is used to solve. >

      > >

      Finally, what are the compile times for Debug?  Probably a set of >
      compile options that don't inline and don't add the bounds checking >
      code would give you much shorter compile times.  Adding a non-expression >
      template implementation would be a moderate chunk of work and may or may >
      not improve compile times significantly.  Compile times come from making >
      the views, and building the expression.  Compiling the expression evaluation >
      is insignificant.  Replacing expression templates could save you the >
      compile time related to building the expression, but the cost of making >
      the view objects may still be significant. >

      > >

          Stephen >

      > >

      -----Original Message----- >
      From: Dave Nystrom [mailto:wdn at lanl.gov] >
      Sent: Monday, May 28, 2001 2:47 PM >
      To: pooma-dev >
      Cc: Arch Robison; KCC Support; Dave Nystrom; John Hall; Jean Marshall; >
      Don Marshall >
      Subject: [pooma-dev] Compile Time Problems and Pooma 2 >

      >
      > >

      Hi Guys, >

      > >

      I wanted to share some results which I have accumulated over the last week or >
      so regarding compile times and Pooma 2.  Some of these results I find to be >
      truly stunning in a negative sense.  First, I spent most of last week trying >
      to build a couple of versions of my Pooma2Instantiations library on the >
      secure bluemountain b18 machine.  I built a debug and an optimized version of >
      the library using KCC-4.0d.  I had the source code for Pooma 2 and the >
      Pooma2Instantiations library located on the local scratch disk.  I was doing >
      a parallel using 16 processors including 16 processors for the parallel >
      prelink phase.  The timing results which I will be reporting were accumulated >
      this last Friday when b18 was virtually idle except for my compiles.  The >
      stunning result is that I could build either a debug or optimized version of >
      the library faster on my 2 year old 366 MHz Pentium 2 laptop with 384 MBytes >
      of memory than I could on an idle b18 using 16 processors.  I find this >
      result to be truly stunning.  The majority of the compile time, at least 90%, >
      on b18 was spent in the backend C compiler.  Here are some timings that I did >
      on 5 files that were associated with instantiating the Pooma 2 global assign >
      function on both b18 and my old laptop.  The timing results are not totally >
      comparable because the prelinker chooses to assign templates a little >
      differently from one machine to the other because of doing a parallel compile >
      on b18.  These compiles were +K0 compiles using KCC-4.0d.  Anyway, here they >
      are: >

      > >

      b18 results: Irix 6.5, MipsPro 7.3.1.2m >
      --------------------------------------- >

      > >

      Filename           | # of .ii | # lines of | +K0 Compile | Line  | Time >
                         |  lines   | int C code |    Time     | Ratio | Ratio >
      -------------------------------------------------------------------------- >
      assign_arg7_03.cc  |   341    |   566783   |  7070.603   |  5.46 |  24.14 >
      -------------------------------------------------------------------------- >
      assign_arg5_01.cc  |   349    |   314395   |  3266.179   |  3.03 |  11.15 >
      -------------------------------------------------------------------------- >
      assign_arg7_09.cc  |   144    |   314070   |  2320.959   |  3.02 |   7.92 >
      -------------------------------------------------------------------------- >
      assign_arg7_13.cc  |   124    |   209043   |  1142.474   |  2.01 |   3.90 >
      -------------------------------------------------------------------------- >
      assign_arg5_03.cc  |     0    |   103832   |   292.872   |  1.00 |   1.00 >
      -------------------------------------------------------------------------- >

      >
      > >

      mutley results: RedHat 6.2 >
      -------------------------- >

      > >

      Filename           | # of .ii | # lines of | +K0 Compile | Line  | Time >
                         |  lines   | int C code |    Time     | Ratio | Ratio >
      -------------------------------------------------------------------------- >
      assign_arg7_03.cc  |     0    |   478303   |   467.63    |  3.63 |  2.84 >
      -------------------------------------------------------------------------- >
      assign_arg5_01.cc  |   246    |   308959   |   428.92    |  2.28 |  2.61 >
      -------------------------------------------------------------------------- >
      assign_arg7_09.cc  |    91    |   272079   |   360.49    |  2.01 |  2.19 >
      -------------------------------------------------------------------------- >
      assign_arg7_13.cc  |   178    |   231415   |   254.78    |  1.71 |  1.55 >
      -------------------------------------------------------------------------- >
      assign_arg5_03.cc  |   207    |   135366   |   164.39    |  1.00 |  1.00 >
      -------------------------------------------------------------------------- >

      > >

      It seems that on my linux laptop, gcc's compile time scales roughly linearly >
      with the number of lines of intermediate C code.  That does not seem to be >
      the case for the SGI cc compiler.  I computed these results using both the >
      MipsPro 7.2.1 C compiler and the MipsPro 7.3.1.2m C compiler and the results >
      were essentially identical for practical purposes. >

      > >

      Another experiment which I did was to take the instantiation request for the >
      assign function which had the longest template argument and put that in a >
      separate file and do some testing on my linux laptop.  The longest template >
      argument was 1666 characters in length.  Here are the results with and >
      without exceptions enabled. >

      > >

      With Exceptions: >
      ---------------- >

      > >

      Case | # lines of | Compile | Optimization | # lines of int | Compile >
           | int C code |  Time   |    Level     | C code - base  | Time - base >
      ------------------------------------------------------------------------- >
        1  |   28804    |  33.34  |     +K0      |       51       |  12.50 >
      ------------------------------------------------------------------------- >
        2  |   18263    |  35.27  |     +K1      |       37       |  12.33 >
      ------------------------------------------------------------------------- >
        3  |   14451    |  62.21  |     +K2      |       18       |  12.35 >
      ------------------------------------------------------------------------- >
        4  |   15767    |  76.47  |     +K3      |       18       |  12.30 >
      ------------------------------------------------------------------------- >

      > >

      Without Exceptions: >
      ------------------- >

      > >

      Case | # lines of | Compile | Optimization | # lines of int | Compile >
           | int C code |  Time   |    Level     | C code - base  | Time - base >
      ------------------------------------------------------------------------- >
        1  |   26975    |  25.01  |     +K0      |       41       |  12.47 >
      ------------------------------------------------------------------------- >
        2  |   16288    |  31.08  |     +K1      |       37       |  13.71 >
      ------------------------------------------------------------------------- >
        3  |   12476    |  49.62  |     +K2      |       18       |  12.32 >
      ------------------------------------------------------------------------- >
        4  |   13037    |  57.00  |     +K3      |       18       |  12.33 >
      ------------------------------------------------------------------------- >

      > >

      The results recorded in the "base" columns are results obtained when the >
      template instantiation request is commented out and reflects the compile >
      times and lines of intermediate C code for the case where only the included >
      header files are being parsed.  Care was taken to record the number of lines >
      of intermediate C code before the prelinker phase.  The prelinker phase >
      determines that the explicit instantiation request for this single assign >
      function triggers the need for an additional 292 templates and the lines of >
      intermediate C code for these additional 292 templates nearly doubles the >
      above numbers.  It seems amazing that a single assign function would need >
      between 14430 and 28750 lines of intermediate C code to represent it >
      depending on the optimization level and that it would trigger the need for >
      another 292 templates.  Also, I don't think we have gotten to the level of >
      complexity in the expressions for our Pooma 2 based code that we have in our >
      Pooma 1 based code.  In our Pooma 1 based code, I have seen expressions which >
      generate template parameters over 2800 characters long. >

      > >

      Here is another benchmark to compare the Pooma 2 base code and the Pooma 1 >
      based code.  In the Pooma 1 based code, my instantiation library explicitly >
      instantiated nearly every Pooma 1 template.  The +K1 compilation of this >
      instantiation library generated approximately 3.5 million lines of >
      intermediate C code for the whole library and just under 1 million lines for >
      the instantiation of all the global assign functions.  There were about 1196 >
      of these global assign functions that were instantiated.  In constrast, the >
      Pooma 2 instantiation library instantiates 1282 global assign functions which >
      generates 4711082 lines of intermediate C code.  The complete Pooma 2 >
      instantiation library currently generates 5327932 lines of intermediate C >
      code.  However, there are still lots of Pooma 2 templates that are currently >
      being instantiated by the prelinker in our Blanca code that need to be moved >
      to the Pooma 2 instantiation library.  So, it appears that there is alot more >
      intermediate C code generated by KCC for our Pooma 2 code than for our Pooma >
      1 code.  I'm not sure what to make of all this since to a certain degree I am >
      comparing apples and oranges.  But I think it does provide some indication of >
      how Pooma 1 and Pooma 2 compare in regard to code generation which >
      contributes to long compile times. >

      > >

      Also, I tried out Jeffrey's fixes to allow instantiation of the View1 class >
      and have some comments.  It appears that I can now instantiate the View1 >
      class but now I find that I have about 1000 AltView1 templates that I am >
      unable to instantiate.  Perhaps we need a new AltAltView1 class:-).  Well, >
      seriously, this fix is not solving the root problem which I have which is >
      that I need to be able to explicitly instantiate anything that the compiler >
      is able to instantiate so that I don't have to depend on the prelinker >
      recompiling files.  Also, I tried the following template instantiation >
      request which did not work. >

      > >

              template const bool View1<Field<T1,T2,T3>,T4>::sv; >

      > >

      KCC using --strict complained that I did not provide an implementation.  So, >
      I don't know what the problem is here.  I don't know if the syntax is wrong >
      or there is some bug in KCC.  But I do know that the prelinker is capable of >
      performing the instantiation of this member of the View1 class.  I have this >
      problem with other Pooma 2 classes such as the ElementProperties class.  I >
      wish I could get this problem solved because my compile times are at least >
      twice as long as they would be if I were able to instantiate everything that >
      the compiler is instantiating. >

      > >

      I would like to know what the Pooma 2 team things about these results.  I >
      find them sobering and not something that I want to see publicized.  Do you >
      guys have any ideas about how to modify the relevant parts of Pooma 2 so that >
      less intermediate C code gets generated by KCC?  Are there tradeoffs here >
      that you are aware of?  Is this code generation problem related specifically >
      to the expression template engine or are there other things involved here? >
      I've been wondering lately if Pooma 2 was designed in a way that would make >
      it easy to use some other expression template engine.  I've also been >
      wondering whether it would be possible to make expression templates a feature >
      selectable at compile time.  Then for debugging or development perhaps a more >
      lightweight version of Pooma 2 could be used that would run like a dog but >
      compile much faster and facilitate an effective and efficient development >
      environment.  Then building a high performance runtime version of our code >
      could be banished to a batch script that was done only infrequently or by a >
      very small group of people.  Are things like this reasonable to contemplate >
      with Pooma 2? >

      > >

      Please let me know if you have any questions about the results I have >
      presented in this email or if I can supply additional information.  I plan to >
      also send a copy of the current version of my Pooma 2 instantiation stuff so >
      you guys can do any testing of your own that you want to do. >

      > >

      -- >
      Dave Nystrom                    email: wdn at lanl.gov >
      LANL X-3                        phone: 505-667-7913     fax: 505-665-3046 >

      > > > From oldham at codesourcery.com Tue May 29 18:19:15 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 29 May 2001 11:19:15 -0700 Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <15122.47231.155261.717836@mutley.lanl.gov>; from wdn@lanl.gov on Mon, May 28, 2001 at 02:46:58PM -0600 References: <15122.47231.155261.717836@mutley.lanl.gov> Message-ID: <20010529111915.A15347@codesourcery.com> On Mon, May 28, 2001 at 02:46:58PM -0600, Dave Nystrom wrote: > this last Friday when b18 was virtually idle except for my compiles. The > stunning result is that I could build either a debug or optimized version of > the library faster on my 2 year old 366 MHz Pentium 2 laptop with 384 MBytes > of memory than I could on an idle b18 using 16 processors. I find this > result to be truly stunning. The majority of the compile time, at least 90%, > on b18 was spent in the backend C compiler. I am not surprised that a Pentium is faster than b18. When building gcc, my sequential Linux/Pentium i686 computer runs faster than Nirvana using ten processors. Starting a new process under Irix seems to be very slow and also the processors are slower. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From samuel at codesourcery.com Tue May 29 18:23:37 2001 From: samuel at codesourcery.com (Alex Samuel) Date: Tue, 29 May 2001 11:23:37 -0700 (PDT) Subject: [pooma-dev] RFA: Tutorial Documentation Typographical Fix In-Reply-To: <200105291719.KAA13823@watercress.indetermi.net> References: <200105251933.MAA04578@oz.codesourcery.com> <200105291719.KAA13823@watercress.indetermi.net> Message-ID: <15123.59689.384149.743709@watercress.indetermi.net> Scott Haney writes: Scott> However, this would be a lot more useful if I could browse Scott> issues rather than having to know the ID. Alternatively, can Scott> one use wildcards in searches? How to do this is, admittedly, not clear. It'll be more obvious in the next version. Simply run a query with the query expression "1" (always true, in Python). In fact, an empty query string is treated as the same thing. Scott> Also, IE downloaded the file as "download attachment" it would Scott> be nice if it could get the name right. Hmm... different browsers handle this differently. I'll see if I can figure out how IE does it. Thanks for the feedback! Regards Alex From scotth at proximation.com Tue May 29 18:23:44 2001 From: scotth at proximation.com (Scott Haney) Date: Tue, 29 May 2001 12:23:44 -0600 Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <15123.51609.122947.372321@mutley.lanl.gov> Message-ID: Hi Dave, The root problem is that you want to blindly take the output from KCC and use that to guide pre-instantiation. This is certainly the easiest thing from your perspective, but it presents an almost insurmountable problem from our perspective in that we have to guarantee that every template can be instantiated in any possible order. I don't think we can do this in all cases. This means that your tool needs to get slightly smarter to handle the small set of exceptions where order does matter. For the case you're describing, you need to pre-instantiate some stuff from Field before you hit AltView1, etc. I expect that the number of exceptions is quite small and could easily be added to your scripts. Scott On Tuesday, May 29, 2001, at 11:53 AM, Dave Nystrom wrote: >> Also, I tried out Jeffrey's fixes to allow instantiation of the View1 >> class >> and have some comments. It appears that I can now instantiate the >> View1 >> class but now I find that I have about 1000 AltView1 templates that I >> am >> unable to instantiate. Perhaps we need a new AltAltView1 class:-). >> Well, >> seriously, this fix is not solving the root problem which I have which >> is >> that I need to be able to explicitly instantiate anything that the >> compiler >> is able to instantiate so that I don't have to depend on the prelinker >> recompiling files. Also, I tried the following template instantiation >> request which did not work. From wdn at lanl.gov Tue May 29 18:43:22 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Tue, 29 May 2001 12:43:22 -0600 (MDT) Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <20010529111915.A15347@codesourcery.com> References: <15122.47231.155261.717836@mutley.lanl.gov> <20010529111915.A15347@codesourcery.com> Message-ID: <15123.60634.487824.331682@mutley.lanl.gov> Jeffrey Oldham writes: > On Mon, May 28, 2001 at 02:46:58PM -0600, Dave Nystrom wrote: > > this last Friday when b18 was virtually idle except for my compiles. The > > stunning result is that I could build either a debug or optimized version of > > the library faster on my 2 year old 366 MHz Pentium 2 laptop with 384 MBytes > > of memory than I could on an idle b18 using 16 processors. I find this > > result to be truly stunning. The majority of the compile time, at least 90%, > > on b18 was spent in the backend C compiler. > > I am not surprised that a Pentium is faster than b18. When building > gcc, my sequential Linux/Pentium i686 computer runs faster than > Nirvana using ten processors. Starting a new process under Irix seems > to be very slow and also the processors are slower. Oh well, I confess to still being stunned. When compiling the secure version of our code which sits on top of Pooma 1, I've been able to beat the time that I get using my 4 processor Linux box from VALinux which has 500 MHz processors and 10000 rpm disks and 2 GBytes of ram. Of course, it was 16 processors versus 4 and b18 did not beat my quad by much. > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com > -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 From oldham at codesourcery.com Tue May 29 18:51:59 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 29 May 2001 11:51:59 -0700 Subject: Patch: Tutorial Documentation Typographical Fixes Message-ID: <20010529115159.A23577@codesourcery.com> Committed patch information: 2001 May 29 Jeffrey D. Oldham * tut-07.html: Fix typographical error. * tut-08.html: Likewise. Tested on Netscape 4.77 Linux Approved by Julian Cummings. Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: tut-07.html =================================================================== RCS file: /home/pooma/Repository/r2/docs/tut-07.html,v retrieving revision 1.2 diff -c -p -r1.2 tut-07.html *** tut-07.html 2001/03/26 23:49:59 1.2 --- tut-07.html 2001/05/25 19:00:36 *************** specified by the constructor's origi *** 208,214 **** parameter. UniformRectilinearMesh then takes another point, spacings, whose values specify the spacings along each axis. !

      The inter-element spacings for a RectilinerMesh, on the other hand, are specified using a Vector of one-dimensional Arrays. Such a structure can be defined and filled using code like the following: --- 208,214 ---- parameter. UniformRectilinearMesh then takes another point, spacings, whose values specify the spacings along each axis. !

      The inter-element spacings for a RectilinearMesh, on the other hand, are specified using a Vector of one-dimensional Arrays. Such a structure can be defined and filled using code like the following: Index: tut-08.html =================================================================== RCS file: /home/pooma/Repository/r2/docs/tut-08.html,v retrieving revision 1.2 diff -c -p -r1.2 tut-08.html *** tut-08.html 2001/03/26 23:49:59 1.2 --- tut-08.html 2001/05/25 19:00:37 *************** typedef Div<Cell, DiscreteGeometry< *** 992,998 **** FieldStencil<Div_t> divVV2SC(); // Divergence, Vector/Vert-->Scalar/Cell ! sc = divV2SC(fv);

      Programmers may also find it convenient to create wrappers by --- 992,998 ---- FieldStencil<Div_t> divVV2SC(); // Divergence, Vector/Vert-->Scalar/Cell ! sc = divV2SC(vv);

      Programmers may also find it convenient to create wrappers by From johnharveyhall at qwest.net Tue May 29 19:15:57 2001 From: johnharveyhall at qwest.net (John Hall) Date: Tue, 29 May 2001 13:15:57 -0600 Subject: [pooma-dev] Can no longer make new fields In-Reply-To: <200105291740.f4THenj28908@mailproxy1.lanl.gov> References: <200105291740.f4THenj28908@mailproxy1.lanl.gov> Message-ID: Scott: Ooops. A bad compiler option caused the pooma init code to get stripped out. I had forgotten I had been playing with the compiler options. Its all better now, regression tests are working again, etc. Thanks for showing me where to look. John >Hi John, > >I just fixed a typo in Field.h. I haven't been able to reproduce >your problem though. I can make Fields with and without >CompressibleBricks and I call Pooma::neverCompress(). The variable >initialized_s is set in Pooma::initialize(). Are you sure you're >calling this? > >Scott > >On Tuesday, May 29, 2001, at 01:12 AM, John Hall wrote: > >>Gang: >>I have updated to the latest POOMA and under CodeWarrior, I can no >>longer create fields. Obviously, this is a little distressing. Here >>is a traceback of the exception: >> >>TecFramework::MetaClass>Fi elds, >>poomalote::PoomaFields>>::Initialize(TecFramework::Ptr>nyType>) const >>TecFramework::IMutate::Initialize(TecFramewo >>rk ::Ptr) >>poomalote::PoomaFields::Initialize() >>poomalote::PoomaFields::Initialize2D() >>poomalote::PoomaFields::try2D<4Vert>(const Vert&) >>poomalote::MakeField>double, Cartesian<2>>>::operator ()(const Vert&,const >>std::list, >>std::allocator>>&,const >>bool&,long) >>poomalote::TecMeshD<2, UniformRectilinear<2, double, >>Cartesian<2>>>::ExtractT<4Vert,d>(const >>Vert&,TecFramework::Ptr) >>poomalote::TecMeshD<2, UniformRectilinear<2, double, >>Cartesian<2>>>::getNewCenteredTypeField<4Vert,d>(const Vert&,const >>double&) >>FieldEngineBase<2, double, CompressibleBrick>::!(const >>Vert&,const DomainLayout<2>&) >>Engine<2, double, CompressibleBrick>::Engine(const DomainLayout<2>&) >>CompressibleBlock::CompressibleBlockController::Compressible >>Bl ockController(int) >>Pooma::neverCompress() >>Pooma::toss_cookies(const char*,const char*,int,...) >> >>I tried to recreate the exception message that was thrown and I got: >>routine neverCompress pAssert "initialized_s" in file: >>"Pooma.cmpl.cpp" at line 725. >> >>Any help would be appreciated. >>John Hall From wdn at lanl.gov Tue May 29 20:12:32 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Tue, 29 May 2001 14:12:32 -0600 (MDT) Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <200105291823.f4TINtj05857@mailproxy1.lanl.gov> References: <15123.51609.122947.372321@mutley.lanl.gov> <200105291823.f4TINtj05857@mailproxy1.lanl.gov> Message-ID: <15123.61004.444220.371042@mutley.lanl.gov> Scott Haney writes: Hi Scott, Thanks for your response. I think I have many problems as my last few emails have indicated. But I guess you are addressing the explicit instantiation problem. One point that needs to be clarified is that I have no scripts to do the explicit instantiations that I am performing. Instead, I am taking the output of the KCC prelinker and massaging that using XEmacs keyboard macros to generate my explicit instantiation requests. I think that at some point when things stabilize it would be good to write some scripts that could facilitate this process. I'm not sure I'm the best person to do this - Lee Ankeny comes to mind as someone who is much more fluent with Perl than I am and who could do this job faster. I'd be willing to do this someday if I can't get someone else to volunteer though. However, my experience so far using the XEmacs keyboard macro approach is that it may not be very easy to write a robust script to take care of all the explicit instantiation stuff. I often run into details in this process which require decisions to be made that might be difficult to code into a script and cover all the possible cases. So, I don't think it is worth the time to invest in scripts right now. So, now it should be clear that I don't have a tool that I can make smarter. What I hear you saying is that you don't think you can guarantee that Pooma 2 can be written in a way that guarantees no circular dependencies. Is that really true? I've read books that claim that circular dependencies are bad and indicate deficiencies in the software design. And I confess that I tend to believe them. But I am not sufficiently proficient at C++ software design to make any kind of absolute statements on this topic and as I have indicated I do not know enough about the details of Pooma 2 to really know what you guys are up against when it comes to trying to meet your design goals for Pooma 2. But, I thought that you solved a similar type of problem with the Array class. Did Jeffrey take the same approach that you did with the Array class or is his solution somewhat different? I did not follow his solution very closely - I was just hoping that you guys would know how to fix the problem and I could then update my Pooma 2 and continue on with the explicit instantiation stuff. You suggest that I should be able to accomplish what I want by making sure that I first instantiate some stuff from Field before instantiating the AltView1 stuff. This did occur to me a few days ago but I have not thought seriously about it. First let me say that I don't really think the AltView1 stuff fixes anything from my perspective and that if I have do deal with this order dependent instantiation because of circular dependencies, I'd rather just deal with it for View1 and get rid of AltView1. Here is where I see a potential complication in your suggested solution. If I want to instantiate View1,T4> you are suggesting I do this as follows: template class Field; template class View1,T4>; or at least something similar. For this to work, I would need to collect all the cases where T4 is different but T1, T2 and T3 are the same and group them all together because I can't have multiple instantiation requests for Field in the same translation unit and really don't want to across different translation units because of multiple symbol definition linker warnings. I think that greatly complicates my task - in fact I'm not sure it would be very feasible at all using XEmacs and keyboard macros. I'd probably be forced to write a script and I really don't have time to do that now and I don't think it would be a simple script. I think it is unmanageble to do this sort of custom processing with XEmacs because of the huge number of View1 templates - over 1800 last time I counted. So, what do you propose? I had not really thought it unreasonable for me to be able to explicitly instantiate anything that the compiler could instantiate - it seemed to work with Pooma 1. But maybe I just don't understand what you guys are up against. I view the View1 template instantiation problem as somewhat of a special case because of the huge number of templates involved. I would certainly be willing to jump through some special hoops like you suggest in order to deal with a much smaller number of templates. But I am reluctant to believe this is feasible or a good plan when we are already talking about 1800+ templates and the prospect of this number growing much larger as our team contiues to add more source code. Well, I'm not sure what the solution is. Maybe we can come to some sort of solution if we continue to think about this. Hope this helps clarify things some from my perspective. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > The root problem is that you want to blindly take the output from KCC > and use that to guide pre-instantiation. This is certainly the easiest > thing from your perspective, but it presents an almost insurmountable > problem from our perspective in that we have to guarantee that every > template can be instantiated in any possible order. I don't think we can > do this in all cases. This means that your tool needs to get slightly > smarter to handle the small set of exceptions where order does matter. > For the case you're describing, you need to pre-instantiate some stuff > from Field before you hit AltView1, etc. I expect that the number of > exceptions is quite small and could easily be added to your scripts. > > Scott > > > On Tuesday, May 29, 2001, at 11:53 AM, Dave Nystrom wrote: > > >> Also, I tried out Jeffrey's fixes to allow instantiation of the View1 > >> class > >> and have some comments. It appears that I can now instantiate the > >> View1 > >> class but now I find that I have about 1000 AltView1 templates that I > >> am > >> unable to instantiate. Perhaps we need a new AltAltView1 class:-). > >> Well, > >> seriously, this fix is not solving the root problem which I have which > >> is > >> that I need to be able to explicitly instantiate anything that the > >> compiler > >> is able to instantiate so that I don't have to depend on the prelinker > >> recompiling files. Also, I tried the following template instantiation > >> request which did not work. > From oldham at codesourcery.com Tue May 29 20:24:32 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 29 May 2001 13:24:32 -0700 Subject: Patch: Vector.h: s/iosfwd/ios/g Message-ID: <20010529132432.A31096@codesourcery.com> When trying to compile src/CoordinateSystems/tests/CartesianTest1.cpp, gcc 3.0 complained about this line from src/Tiny/Vector.h: std::ios::fmtflags incomingFormatFlags = out.flags(); This is resolved by replacing by . 2001 May 29 Jeffrey D. Oldham * TinyMatrix.h: Replace by . * Vector.h: Likewise. Tested on sequential Linux using gcc 3.0 by compiling CartesianTest1.cpp Approved by Julian Cummings Thanks, Jeffrey D. Oldham oldham at codesourcery.com -------------- next part -------------- Index: TinyMatrix.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Tiny/TinyMatrix.h,v retrieving revision 1.11 diff -c -p -r1.11 TinyMatrix.h *** TinyMatrix.h 2001/04/05 09:34:47 1.11 --- TinyMatrix.h 2001/05/24 00:18:15 *************** class Full; *** 56,62 **** #include "Tiny/TinyMatrixEngine.h" #include "Tiny/TinyMatrixElements.h" #include "Tiny/TinyMatrixOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: --- 56,62 ---- #include "Tiny/TinyMatrixEngine.h" #include "Tiny/TinyMatrixElements.h" #include "Tiny/TinyMatrixOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: Index: Vector.h =================================================================== RCS file: /home/pooma/Repository/r2/src/Tiny/Vector.h,v retrieving revision 1.25 diff -c -p -r1.25 Vector.h *** Vector.h 2000/04/28 00:04:02 1.25 --- Vector.h 2001/05/24 00:18:15 *************** class Full; *** 56,62 **** #include "Tiny/VectorEngine.h" #include "Tiny/VectorElements.h" #include "Tiny/VectorOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: --- 56,62 ---- #include "Tiny/VectorEngine.h" #include "Tiny/VectorElements.h" #include "Tiny/VectorOperators.h" ! #include //----------------------------------------------------------------------------- // Forward Declarations: From scotth at proximation.com Tue May 29 20:38:55 2001 From: scotth at proximation.com (Scott Haney) Date: Tue, 29 May 2001 14:38:55 -0600 Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <15123.61004.444220.371042@mutley.lanl.gov> Message-ID: On Tuesday, May 29, 2001, at 02:12 PM, Dave Nystrom wrote: > > What I hear you saying is that you don't think you can guarantee that > Pooma 2 > can be written in a way that guarantees no circular dependencies. Is > that > really true? I've read books that claim that circular dependencies are > bad > and indicate deficiencies in the software design. And I confess that I > tend > to believe them. But I am not sufficiently proficient at C++ software > design > to make any kind of absolute statements on this topic and as I have > indicated > I do not know enough about the details of Pooma 2 to really know what > you > guys are up against when it comes to trying to meet your design goals > for > Pooma 2. But, I thought that you solved a similar type of problem with > the > Array class. Did Jeffrey take the same approach that you did with the > Array > class or is his solution somewhat different? I did not follow his > solution > very closely - I was just hoping that you guys would know how to fix the > problem and I could then update my Pooma 2 and continue on with the > explicit > instantiation stuff. > Dave, As a general principle, we can agree that circular dependencies are bad. Field is using auxiliary templates that need information from Field. This problem can be worked around nicely in non-templated C++ code, but it is difficult to work through with templates. However, maybe, by re-factoring, this can be fixed. In particular, AltView1 doesn't use that much of Field. I will give this a shot. Scott From allan at stokes.ca Tue May 29 22:12:18 2001 From: allan at stokes.ca (Allan Stokes) Date: Tue, 29 May 2001 15:12:18 -0700 Subject: status report Message-ID: Last week I configured the DocBook environment and toolchain under w2k and unix. I familiarized myself with DocBook authoring in the psgml environment and the document features required by the Pooma documentation. I began setting up a Redhat 7.1 environment to run the most recent KAI release. This week I will complete the configuration of my Redhat environment. Following Mark's advice I will set up my primary Pooma checkout on the Redhat machine and access it indirectly from NT via Samba. This will eliminate some issues keeping my experimental changes consistent between my two working environments. In the past I've used CVS locally for this purpose, which is not viable here. I will author a trial document exploring features of DocBook, such as equations, where Pooma has special needs. I will solicit further discussion of Pooma's documentation requirements. From oldham at codesourcery.com Tue May 29 22:34:08 2001 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 29 May 2001 15:34:08 -0700 Subject: RFA: Reorder Member Initializers Patch Message-ID: <20010529153408.A32233@codesourcery.com> Per Scott Haney's suggestion, I filed my latest Pooma source code patch request using Pooma's QMTrack. To access it, 1) point your browser to http://pooma.codesourcery.com:4242/track/ 2) log in using your last name as your username and your password 3) Enter `reorder_patch' as the Issue ID. 4) Approve my patch. If you have difficulty, send email to samuel at codesourcery.com, who is building the tools, or to me. Thanks, Jeffrey D. Oldham oldham at codesourcery.com From wdn at lanl.gov Tue May 29 23:24:23 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Tue, 29 May 2001 17:24:23 -0600 (MDT) Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <200105292039.f4TKd7j02486@mailproxy1.lanl.gov> References: <15123.61004.444220.371042@mutley.lanl.gov> <200105292039.f4TKd7j02486@mailproxy1.lanl.gov> Message-ID: <15124.11471.450823.218891@mutley.lanl.gov> Scott Haney writes: > As a general principle, we can agree that circular dependencies are bad. > Field is using auxiliary templates that need information from Field. > This problem can be worked around nicely in non-templated C++ code, but > it is difficult to work through with templates. However, maybe, by > re-factoring, this can be fixed. In particular, AltView1 doesn't use > that much of Field. I will give this a shot. Well, good luck. Sounds like I've opened up a real can of worms. Do you have any comments on the rest of my original email from Sunday or my response to Stephen. I'm particularly interested in whether you think there is much to be gained in terms of reducing the amount of code generated and improving compile times by revisiting the logical design. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 From scotth at proximation.com Wed May 30 13:56:43 2001 From: scotth at proximation.com (Scott Haney) Date: Wed, 30 May 2001 07:56:43 -0600 Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <15124.11471.450823.218891@mutley.lanl.gov> Message-ID: On Tuesday, May 29, 2001, at 05:24 PM, Dave Nystrom wrote: > Scott Haney writes: >> As a general principle, we can agree that circular dependencies are >> bad. >> Field is using auxiliary templates that need information from Field. >> This problem can be worked around nicely in non-templated C++ code, but >> it is difficult to work through with templates. However, maybe, by >> re-factoring, this can be fixed. In particular, AltView1 doesn't use >> that much of Field. I will give this a shot. > > Well, good luck. Sounds like I've opened up a real can of worms. Do > you > have any comments on the rest of my original email from Sunday or my > response > to Stephen. I'm particularly interested in whether you think there is > much > to be gained in terms of reducing the amount of code generated and > improving > compile times by revisiting the logical design. > > -- > Dave Nystrom email: wdn at lanl.gov > LANL X-3 phone: 505-667-7913 fax: 505-665-3046 Hi Dave, I have no doubt that we can improve compile times. However, I'm not sure what to make of your numbers. They imply that something strange is happening on the SGI, but that's not really our target platform, so I don't believe that we should spend much time looking into this right now. Our priorities are, as I understand it, to (1) provide core capabilities in order to allow you guys to meet your October deadline and (2) to optimize performance and scalability. I'd put compile time performance in (2), but the contract clearly implies we should focus on run time first. That said, it is worth a little more time to investigate this View preinstantiation issue because it can elucidate some design principles that can be used to reduce the number of template instantiations as we go forward. In the long term, I believe that we may need to provide a tool of some sort to support pre-instantiation, but that is not a job for now. Scott From wdn at lanl.gov Wed May 30 15:58:58 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Wed, 30 May 2001 09:58:58 -0600 (MDT) Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <200105301356.f4UDuqj27963@mailproxy1.lanl.gov> References: <15124.11471.450823.218891@mutley.lanl.gov> <200105301356.f4UDuqj27963@mailproxy1.lanl.gov> Message-ID: <15125.3602.528183.51677@mutley.lanl.gov> Scott Haney writes: > > On Tuesday, May 29, 2001, at 05:24 PM, Dave Nystrom wrote: > > > Scott Haney writes: > >> As a general principle, we can agree that circular dependencies are > >> bad. > >> Field is using auxiliary templates that need information from Field. > >> This problem can be worked around nicely in non-templated C++ code, but > >> it is difficult to work through with templates. However, maybe, by > >> re-factoring, this can be fixed. In particular, AltView1 doesn't use > >> that much of Field. I will give this a shot. > > > > Well, good luck. Sounds like I've opened up a real can of worms. Do > > you > > have any comments on the rest of my original email from Sunday or my > > response > > to Stephen. I'm particularly interested in whether you think there is > > much > > to be gained in terms of reducing the amount of code generated and > > improving > > compile times by revisiting the logical design. > > > > -- > > Dave Nystrom email: wdn at lanl.gov > > LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > > I have no doubt that we can improve compile times. However, I'm not sure > what to make of your numbers. They imply that something strange is > happening on the SGI, but that's not really our target platform, so I > don't believe that we should spend much time looking into this right I agree that the numbers I reported imply something strange going on with our SGI machine/compilers. I thought it was strange enough that it should be reported to pooma-dev in case you guys had some insight into the problem that I was missing. I'm not really looking for a platform specific solution from you guys. Actually, my data indicates a temporary work around for the SGI is to just break up my files into much smaller files since the SGI C compiler seems to scale more like quadratic with the size of the .int.c files. Of course I already have what I thought might be reasonable granularity there. The instantiation requests for the Pooma 2 assign functions are currently spread over 20 files. I probably need to talk to someone from SGI about this data and see if they know what is going on as well. I think that the SGI platform will be an important platform for our October 1 deadline. To my knowledge, Lee Ankeny has not been successful yet getting any of our Pooma 1 based code compiling on the Compaq machines. Perhaps that will change with the recent release of KCC-4.0e for Tru64 Unix 5.0. BTW, do you guys have accounts on the chi machine - an open Compaq machine? I was under the impression that you were supposed to have accounts there now. I'm worried about what compile times are going to be like on the Compaq as well. I don't know enough about the machine yet but I wonder if our parallel builds will be limited to 4 processors. > now. Our priorities are, as I understand it, to (1) provide core > capabilities in order to allow you guys to meet your October deadline > and (2) to optimize performance and scalability. I'd put compile time > performance in (2), but the contract clearly implies we should focus on > run time first. That said, it is worth a little more time to investigate I don't disagree with these priorities at all. And I don't have any authority to change them either. You guys just need to be aware that compile times are starting to affect the productivity of our work - including John, Jean and Don. A few months back I saw John compile all of our source code base in 9 minutes. I recently heard that it now takes 1.5 hours for them to compile all our source code base - and that is using MetroWerks. If there is any low hanging fruit to be picked from the compile time tree that will make a difference then we could really use it. If I can explicitly instantiate all of the templates that the compiler is currently instantiating, I can probably reduce our whole system compile times by a factor of at least 2 and for developers who don't have to compile the Pooma2Instantiations library it will probably be a much larger factor. But, I don't think you can afford to spend huge amounts of time on this right now. I think we would agree on that. > this View preinstantiation issue because it can elucidate some design > principles that can be used to reduce the number of template > instantiations as we go forward. In the long term, I believe that we may > need to provide a tool of some sort to support pre-instantiation, but > that is not a job for now. Well again, good luck. When I reported this problem 2-3 weeks ago, I thought it would be a simple fix. I did not realize that it would be as involved as it has turned out to be. I hope you can come up with a simple and elegant fix without spending much of your time on it. BTW, I seem to be spending an awful lot of time responding to emails which may or may not be productive. But I'm still happy to provide anymore data or discuss this with anyone that wants to. I just don't want to beat a dead horse or spam everyone's InBox. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 From wdn at lanl.gov Wed May 30 16:24:23 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Wed, 30 May 2001 10:24:23 -0600 (MDT) Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <200105301356.f4UDuqj27963@mailproxy1.lanl.gov> References: <15124.11471.450823.218891@mutley.lanl.gov> <200105301356.f4UDuqj27963@mailproxy1.lanl.gov> Message-ID: <15125.6746.792373.107226@mutley.lanl.gov> Attached is a gzipped tar file of the .cc files in my Pooma2Instantiations library which I promised to send. If you look in the include.mk file, you will see a list of the translation units that are currently part of the library. Also, the file assign_arg7_17.cc is the file I used for generating the data for part of my original email. It contains a single template instantiation request for a Pooma 2 assign function with 7 template arguments. It is the one that has the longest template parameter i.e. 1666 characters in length. These files all depend explicitly only on Pooma 2 header files. If anyone has any inclination to play around with them, I'd be interested in any results you come up with. In particular, I'd be interested to know how gcc does at handling them. -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: General.tar.gz URL: From cummings at mail.linkline.com Wed May 30 22:25:36 2001 From: cummings at mail.linkline.com (Julian C. Cummings ) Date: Wed, 30 May 2001 15:25:36 -0700 Subject: [pooma-dev] Compile Time Problems and Pooma 2 Message-ID: <200105301525.AA1268121944@mail.linkline.com> Dave, I don't have an account on chi, but I do have an account on the Compaq TeraScale machine at Pittsburgh Supercomputing Center. It has the same Compaq Tru64 operating system, but I don't think they have KCC installed. I should probably have a look at building Pooma 2 there using the Compaq compiler. I might be able to help Lee with Pooma 1 issues, but it would make more sense to get an account on your chi machine first. Julian C. ---------- Original Message ---------------------------------- From: Dave Nystrom Date: Wed, 30 May 2001 09:58:58 -0600 (MDT) > >I agree that the numbers I reported imply something strange going on with our >SGI machine/compilers. I thought it was strange enough that it should be >reported to pooma-dev in case you guys had some insight into the problem that >I was missing. I'm not really looking for a platform specific solution from >you guys. Actually, my data indicates a temporary work around for the SGI is >to just break up my files into much smaller files since the SGI C compiler >seems to scale more like quadratic with the size of the .int.c files. Of >course I already have what I thought might be reasonable granularity there. >The instantiation requests for the Pooma 2 assign functions are currently >spread over 20 files. I probably need to talk to someone from SGI about this >data and see if they know what is going on as well. > >I think that the SGI platform will be an important platform for our October 1 >deadline. To my knowledge, Lee Ankeny has not been successful yet getting >any of our Pooma 1 based code compiling on the Compaq machines. Perhaps that >will change with the recent release of KCC-4.0e for Tru64 Unix 5.0. BTW, do >you guys have accounts on the chi machine - an open Compaq machine? I was >under the impression that you were supposed to have accounts there now. I'm >worried about what compile times are going to be like on the Compaq as well. >I don't know enough about the machine yet but I wonder if our parallel builds >will be limited to 4 processors. > >-- >Dave Nystrom email: wdn at lanl.gov >LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > From wdn at lanl.gov Wed May 30 22:48:26 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Wed, 30 May 2001 16:48:26 -0600 (MDT) Subject: [pooma-dev] Compile Time Problems and Pooma 2 In-Reply-To: <200105301525.AA1268121944@mail.linkline.com> References: <200105301525.AA1268121944@mail.linkline.com> Message-ID: <15125.30822.877193.556685@mutley.lanl.gov> I just learned this afternoon that the chi machine has version 5.1 of Tru64 Unix installed. KCC is currently available for 5.0 and they are trying to get access to a machine with 5.1 to do the port of KCC to 5.1. Dave Julian C. Cummings writes: > Dave, > > I don't have an account on chi, but I do have an account > on the Compaq TeraScale machine at Pittsburgh Supercomputing > Center. It has the same Compaq Tru64 operating system, but > I don't think they have KCC installed. I should probably > have a look at building Pooma 2 there using the Compaq compiler. > I might be able to help Lee with Pooma 1 issues, but it would > make more sense to get an account on your chi machine first. > > Julian C. > > > > > > ---------- Original Message ---------------------------------- > From: Dave Nystrom > Date: Wed, 30 May 2001 09:58:58 -0600 (MDT) > > > > >I agree that the numbers I reported imply something strange going on with our > >SGI machine/compilers. I thought it was strange enough that it should be > >reported to pooma-dev in case you guys had some insight into the problem that > >I was missing. I'm not really looking for a platform specific solution from > >you guys. Actually, my data indicates a temporary work around for the SGI is > >to just break up my files into much smaller files since the SGI C compiler > >seems to scale more like quadratic with the size of the .int.c files. Of > >course I already have what I thought might be reasonable granularity there. > >The instantiation requests for the Pooma 2 assign functions are currently > >spread over 20 files. I probably need to talk to someone from SGI about this > >data and see if they know what is going on as well. > > > >I think that the SGI platform will be an important platform for our October 1 > >deadline. To my knowledge, Lee Ankeny has not been successful yet getting > >any of our Pooma 1 based code compiling on the Compaq machines. Perhaps that > >will change with the recent release of KCC-4.0e for Tru64 Unix 5.0. BTW, do > >you guys have accounts on the chi machine - an open Compaq machine? I was > >under the impression that you were supposed to have accounts there now. I'm > >worried about what compile times are going to be like on the Compaq as well. > >I don't know enough about the machine yet but I wonder if our parallel builds > >will be limited to 4 processors. > > > >-- > >Dave Nystrom email: wdn at lanl.gov > >LANL X-3 phone: 505-667-7913 fax: 505-665-3046 > > > From wdn at lanl.gov Thu May 31 19:01:42 2001 From: wdn at lanl.gov (Dave Nystrom) Date: Thu, 31 May 2001 13:01:42 -0600 (MDT) Subject: GCC Message-ID: <15126.37944.920480.240946@mutley.lanl.gov> I'd like to try building our blanca code on my new laptop using GCC. I'm running RH 7.1 and the version of GCC is I believe 2.96. I assume that is not good enough and that I should use a beta or pre-release version of GCC. What version of GCC should I use? Where can I get it? Does it come in rpm format for a RH 7.1 version? Any other tips in trying it out? Thanks, -- Dave Nystrom email: wdn at lanl.gov LANL X-3 phone: 505-667-7913 fax: 505-665-3046 From oldham at oz.codesourcery.com Thu May 31 19:13:28 2001 From: oldham at oz.codesourcery.com (Jeffrey Oldham) Date: Thu, 31 May 2001 12:13:28 -0700 Subject: [pooma-dev] GCC In-Reply-To: <15126.37944.920480.240946@mutley.lanl.gov>; from wdn@lanl.gov on Thu, May 31, 2001 at 01:01:42PM -0600 References: <15126.37944.920480.240946@mutley.lanl.gov> Message-ID: <20010531121328.A5340@oz.codesourcery.com> On Thu, May 31, 2001 at 01:01:42PM -0600, Dave Nystrom wrote: > I'd like to try building our blanca code on my new laptop using GCC. I'm > running RH 7.1 and the version of GCC is I believe 2.96. I assume that is > not good enough and that I should use a beta or pre-release version of GCC. > > What version of GCC should I use? Where can I get it? Does it come in rpm > format for a RH 7.1 version? Any other tips in trying it out? I have been using gcc 3.0, which will be released 15Jun. RPMS for i386's are available at http://www.codesourcery.com/gcc-snapshots/. Thanks, Jeffrey D. Oldham oldham at codesourcery.com