From dprideout at gmail.com Fri Jan 9 12:52:00 2009 From: dprideout at gmail.com (David Rideout) Date: Fri, 9 Jan 2009 13:52:00 -0500 Subject: [Developers] checking for variable storage in another thorn Message-ID: <1ce81abb0901091052n2faaa14cj579b1b6ce7be49a7@mail.gmail.com> I would like to check if a variable has storage, in a context where that variable may not even exist. (It is declared in another thorn, unrelated to the checking thorn.) This works fine except that I get a level one warning each time, from PUGH_ArrayGroupSize(). Shall we make this a level 2 or 3 warning? Given that a level 1 warning implies that the code is going to give wrong answers (correct?), this seems to be a bug. It may be possible to first check if it exists, and then check if it has storage, but this seems excessive and unnecessary. Thanks, David From schnetter at cct.lsu.edu Fri Jan 9 13:15:19 2009 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Fri, 9 Jan 2009 13:15:19 -0600 Subject: [Developers] checking for variable storage in another thorn In-Reply-To: <1ce81abb0901091052n2faaa14cj579b1b6ce7be49a7@mail.gmail.com> References: <1ce81abb0901091052n2faaa14cj579b1b6ce7be49a7@mail.gmail.com> Message-ID: On Jan 9, 2009, at 12:52:00, David Rideout wrote: > I would like to check if a variable has storage, in a context where > that variable may not even exist. (It is declared in another thorn, > unrelated to the checking thorn.) This works fine except that I get a > level one warning each time, from PUGH_ArrayGroupSize(). Shall we > make this a level 2 or 3 warning? Given that a level 1 warning > implies that the code is going to give wrong answers (correct?), this > seems to be a bug. It may be possible to first check if it exists, > and then check if it has storage, but this seems excessive and > unnecessary. The most efficient way to check for storage multiple times is the following: 1. Obtain the group index for the variable, and store it in a static variable. 2. Use the group index to check for storage repeatedly. In this way you would also avoid the level 1 warning. What function do you call to find out whether the group has storage? I don't see why ArrayGroupSize should be called for this, as it returns the size of the array, independent of whether it has storage. I would prefer to leave this a level one warning. I assume that the most common cause for this error is a misspelled variable name, and this should be critical error. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from . -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20090109/9534c46c/attachment.bin From dprideout at gmail.com Fri Jan 9 13:36:14 2009 From: dprideout at gmail.com (David Rideout) Date: Fri, 9 Jan 2009 14:36:14 -0500 Subject: [Developers] checking for variable storage in another thorn In-Reply-To: References: <1ce81abb0901091052n2faaa14cj579b1b6ce7be49a7@mail.gmail.com> Message-ID: <1ce81abb0901091136q24f10483n230bcd58a26eb06e@mail.gmail.com> Here is my code, if (CCTK_QueryGroupStorage(GH, "TranPercZn::phi") > 0) phi = CCTK_VarDataPtr(GH, 0, "TranPercZn::phi"); which generates a level 1 warning WARNING[L1,P0] (PUGH): PUGH_ArrayGroupSize: Invalid group name 'TranPercZn::phi' when TranPercZn::phi does not exist. Upon your advice I've changed it to: i = CCTK_GroupIndex("TranPercZn::phi"); if (i>=0 && CCTK_QueryGroupStorageI(GH, i) > 0) phi = CCTK_VarDataPtr(GH, 0, "TranPercZn::phi"); which removes the level 1 warning. It is a bit more convoluted but I can live with it. Perhaps a better solution is to fix PUGH's QueryGroupStorage()? Thanks, David On Fri, Jan 9, 2009 at 2:15 PM, Erik Schnetter wrote: > On Jan 9, 2009, at 12:52:00, David Rideout wrote: > >> I would like to check if a variable has storage, in a context where >> that variable may not even exist. (It is declared in another thorn, >> unrelated to the checking thorn.) This works fine except that I get a >> level one warning each time, from PUGH_ArrayGroupSize(). Shall we >> make this a level 2 or 3 warning? Given that a level 1 warning >> implies that the code is going to give wrong answers (correct?), this >> seems to be a bug. It may be possible to first check if it exists, >> and then check if it has storage, but this seems excessive and >> unnecessary. > > > The most efficient way to check for storage multiple times is the following: > > 1. Obtain the group index for the variable, and store it in a static > variable. > 2. Use the group index to check for storage repeatedly. > > In this way you would also avoid the level 1 warning. > > What function do you call to find out whether the group has storage? I > don't see why ArrayGroupSize should be called for this, as it returns the > size of the array, independent of whether it has storage. > > > > I would prefer to leave this a level one warning. I assume that the most > common cause for this error is a misspelled variable name, and this should > be critical error. > > -erik > > -- > Erik Schnetter http://www.cct.lsu.edu/~eschnett/ > > My email is as private as my paper mail. I therefore support encrypting > and signing email messages. Get my PGP key from . > > > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers > > From schnetter at cct.lsu.edu Fri Jan 9 13:43:44 2009 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Fri, 9 Jan 2009 13:43:44 -0600 Subject: [Developers] checking for variable storage in another thorn In-Reply-To: <1ce81abb0901091136q24f10483n230bcd58a26eb06e@mail.gmail.com> References: <1ce81abb0901091052n2faaa14cj579b1b6ce7be49a7@mail.gmail.com> <1ce81abb0901091136q24f10483n230bcd58a26eb06e@mail.gmail.com> Message-ID: <326F8418-5147-42AA-A9FF-1F2B2FE472C3@cct.lsu.edu> I just see that PUGH_QueryGroupStorage has an error in its error message (!), claiming to be PUGH_ArrayGroupSize. The code itself seems correct and efficient. -erik On Jan 9, 2009, at 13:36:14, David Rideout wrote: > Here is my code, > > if (CCTK_QueryGroupStorage(GH, "TranPercZn::phi") > 0) > phi = CCTK_VarDataPtr(GH, 0, "TranPercZn::phi"); > > which generates a level 1 warning > > WARNING[L1,P0] (PUGH): PUGH_ArrayGroupSize: Invalid group name > 'TranPercZn::phi' > > when TranPercZn::phi does not exist. > > Upon your advice I've changed it to: > > i = CCTK_GroupIndex("TranPercZn::phi"); > if (i>=0 && CCTK_QueryGroupStorageI(GH, i) > 0) > phi = CCTK_VarDataPtr(GH, 0, "TranPercZn::phi"); > > which removes the level 1 warning. It is a bit more convoluted but I > can live with it. Perhaps a better solution is to fix PUGH's > QueryGroupStorage()? > > Thanks, > David > > On Fri, Jan 9, 2009 at 2:15 PM, Erik Schnetter > wrote: >> On Jan 9, 2009, at 12:52:00, David Rideout wrote: >> >>> I would like to check if a variable has storage, in a context where >>> that variable may not even exist. (It is declared in another thorn, >>> unrelated to the checking thorn.) This works fine except that I >>> get a >>> level one warning each time, from PUGH_ArrayGroupSize(). Shall we >>> make this a level 2 or 3 warning? Given that a level 1 warning >>> implies that the code is going to give wrong answers (correct?), >>> this >>> seems to be a bug. It may be possible to first check if it exists, >>> and then check if it has storage, but this seems excessive and >>> unnecessary. >> >> >> The most efficient way to check for storage multiple times is the >> following: >> >> 1. Obtain the group index for the variable, and store it in a static >> variable. >> 2. Use the group index to check for storage repeatedly. >> >> In this way you would also avoid the level 1 warning. >> >> What function do you call to find out whether the group has >> storage? I >> don't see why ArrayGroupSize should be called for this, as it >> returns the >> size of the array, independent of whether it has storage. >> >> >> >> I would prefer to leave this a level one warning. I assume that >> the most >> common cause for this error is a misspelled variable name, and this >> should >> be critical error. >> >> -erik >> >> -- >> Erik Schnetter http://www.cct.lsu.edu/~eschnett/ >> >> My email is as private as my paper mail. I therefore support >> encrypting >> and signing email messages. Get my PGP key from > pgp.mit.edu>. >> >> >> _______________________________________________ >> Developers mailing list >> Developers at cactuscode.org >> http://www.cactuscode.org/mailman/listinfo/developers >> >> > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from . -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20090109/55b929ba/attachment.bin From schnetter at cct.lsu.edu Mon Jan 12 10:17:58 2009 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Mon, 12 Jan 2009 10:17:58 -0600 Subject: [Developers] Outputting a combined timer report from a single processor Message-ID: <97B91EA6-E65D-4419-A9D7-63325E733DA3@cct.lsu.edu> The enclosed patch to CactusUtils/TimerReport adds a new parameter output_all_timers_together, which outputs the timer report into a single file instead of writing one file per processor. It only outputs minimum, maximum, and average time reduced over all processors. Ian Hinder, could you especially have a look at this patch since this patch is based on your recent modification? -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from . --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) application/octet-stream --- From tradke at aei.mpg.de Thu Jan 15 05:46:00 2009 From: tradke at aei.mpg.de (Thomas Radke) Date: Thu, 15 Jan 2009 12:46:00 +0100 Subject: [Developers] Outputting a combined timer report from a single processor In-Reply-To: <97B91EA6-E65D-4419-A9D7-63325E733DA3@cct.lsu.edu> References: <97B91EA6-E65D-4419-A9D7-63325E733DA3@cct.lsu.edu> Message-ID: <496F21F8.2040701@aei.mpg.de> Erik Schnetter wrote: > The enclosed patch to CactusUtils/TimerReport adds a new parameter > output_all_timers_together, which outputs the timer report into a > single file instead of writing one file per processor. It only > outputs minimum, maximum, and average time reduced over all processors. > > Ian Hinder, could you especially have a look at this patch since this > patch is based on your recent modification? Hi Erik, the patch looks good to me (I haven't tested it though). Just a comment regarding the implementation: since you're using C99 syntax already I'd suggest to rename the source file into into C++ proper. -- Cheers, Thomas. From knarf at cct.lsu.edu Thu Jan 15 09:19:00 2009 From: knarf at cct.lsu.edu (Frank Loeffler) Date: Thu, 15 Jan 2009 09:19:00 -0600 Subject: [Developers] Outputting a combined timer report from a single processor In-Reply-To: <496F21F8.2040701@aei.mpg.de> References: <97B91EA6-E65D-4419-A9D7-63325E733DA3@cct.lsu.edu> <496F21F8.2040701@aei.mpg.de> Message-ID: <20090115151900.GA5149@topf.wg> Hi, On Thu, Jan 15, 2009 at 12:46:00PM +0100, Thomas Radke wrote: > Just a comment regarding the implementation: since you're using C99 > syntax already I'd suggest to rename the source file into into C++ proper. I am not the author and I only had a short look at the patch, but it seems to be simple C to me, not C++. I would suggest to either change the patch to use C89 syntax or, at some point, require C99 for Cactus C code. Frank From ian.hinder at aei.mpg.de Fri Jan 16 09:31:46 2009 From: ian.hinder at aei.mpg.de (Ian Hinder) Date: Fri, 16 Jan 2009 16:31:46 +0100 Subject: [Developers] Outputting a combined timer report from a single processor In-Reply-To: <20090115151900.GA5149@topf.wg> References: <97B91EA6-E65D-4419-A9D7-63325E733DA3@cct.lsu.edu> <496F21F8.2040701@aei.mpg.de> <20090115151900.GA5149@topf.wg> Message-ID: <4970A862.8080807@aei.mpg.de> Frank Loeffler wrote: > > Hi, > > > > On Thu, Jan 15, 2009 at 12:46:00PM +0100, Thomas Radke wrote: >> >> Just a comment regarding the implementation: since you're using C99 >> >> syntax already I'd suggest to rename the source file into into C++ proper. > > > > I am not the author and I only had a short look at the patch, but it > > seems to be simple C to me, not C++. I would suggest to either change > > the patch to use C89 syntax or, at some point, require C99 for Cactus C > > code. I vote against making it C++; changing the code to be C89 looks to be straightforward. However, C99 gives quite a few conveniences. What is the policy on inclusion of C99 code in Cactus? Since some compilers (gcc I think) need to be explicitly told to accept C99, it makes it a bit of a mess. I believe the current situation is "if you need to use gcc, and you have thorns which use C99, then you'd better include the c99 flag in your config file". We could either 1. Ban C99 code from Cactus, ensuring that gcc is able to compile everything without additional flags. 2. Allow C99 flags in Cactus, and change the default Cactus flags for gcc to include C99. Is it possible this would break existing code? Are all valid C89 programs valid C99 programs? Do we need to support compilers which do not support C99? 3. Allow each thorn (file?) to state whether they need C99 or not. This is similar to the situation we currently have with C(89), C++ and Fortran. I would have thought the simplest solution was (2), unless it breaks something. -- Ian Hinder ian.hinder at aei.mpg.de From tradke at aei.mpg.de Mon Jan 19 05:16:53 2009 From: tradke at aei.mpg.de (Thomas Radke) Date: Mon, 19 Jan 2009 12:16:53 +0100 Subject: [Developers] Outputting a combined timer report from a single processor In-Reply-To: <4970A862.8080807@aei.mpg.de> References: <97B91EA6-E65D-4419-A9D7-63325E733DA3@cct.lsu.edu> <496F21F8.2040701@aei.mpg.de> <20090115151900.GA5149@topf.wg> <4970A862.8080807@aei.mpg.de> Message-ID: <49746125.3010105@aei.mpg.de> Ian Hinder wrote: > Frank Loeffler wrote: >>> Hi, >>> >>> On Thu, Jan 15, 2009 at 12:46:00PM +0100, Thomas Radke wrote: >>>>> Just a comment regarding the implementation: since you're using C99 >>>>> syntax already I'd suggest to rename the source file into into C++ > proper. >>> I am not the author and I only had a short look at the patch, but it >>> seems to be simple C to me, not C++. I would suggest to either change >>> the patch to use C89 syntax or, at some point, require C99 for Cactus C >>> code. > > I vote against making it C++; changing the code to be C89 looks to be > straightforward. However, C99 gives quite a few conveniences. Which all come with C++ anyway. Why do Frank and you balk at making good use of it, and rather rely on C compilers to support an extension of the C standard ? > What is the policy on inclusion of C99 code in Cactus? Since some > compilers (gcc I think) need to be explicitly told to accept C99, it > makes it a bit of a mess. I believe the current situation is "if you > need to use gcc, and you have thorns which use C99, then you'd better > include the c99 flag in your config file". We could either > > 1. Ban C99 code from Cactus, ensuring that gcc is able to compile > everything without additional flags. > > 2. Allow C99 flags in Cactus, and change the default Cactus flags for > gcc to include C99. Is it possible this would break existing code? Are > all valid C89 programs valid C99 programs? Do we need to support > compilers which do not support C99? > > 3. Allow each thorn (file?) to state whether they need C99 or not. This > is similar to the situation we currently have with C(89), C++ and Fortran. > > I would have thought the simplest solution was (2), unless it breaks > something. (1) would be too strict, I guess. There are C thorns out there, provided by the community, which make use of C99 extensions. (2) is possible, and we do that already for some compilers - not for all though. This option is also safe to implement because C99 is just an extension of C98/C95. (3) wouldn't solve the actual problem, would it ? So I agree with you that option (2) is the way to go. I believe it's implemented already on all architectures where people are doing production runs nowadays. If we come across a less common platform where C99 support is not yet turned on then let's hope it's just a flag to be added to the default C compiler flags. The question remains though whether new code which uses extensions to the C89 standard should be written in C99 or C++. Here I'd vote for the latter. -- Cheers, Thomas. From knarf at cct.lsu.edu Mon Jan 19 22:35:51 2009 From: knarf at cct.lsu.edu (Frank Loeffler) Date: Mon, 19 Jan 2009 22:35:51 -0600 Subject: [Developers] Outputting a combined timer report from a single processor In-Reply-To: <49746125.3010105@aei.mpg.de> References: <97B91EA6-E65D-4419-A9D7-63325E733DA3@cct.lsu.edu> <496F21F8.2040701@aei.mpg.de> <20090115151900.GA5149@topf.wg> <4970A862.8080807@aei.mpg.de> <49746125.3010105@aei.mpg.de> Message-ID: <20090120043551.GB4714@topf.wg> Hi, On Mon, Jan 19, 2009 at 12:16:53PM +0100, Thomas Radke wrote: > Why do Frank and you balk at making good > use of it, and rather rely on C compilers to support an extension of the > C standard ? C99 ist not an extension. It is the new standard for now already ten years or so. I do not like to C++ "solution" because of two reasons: - I would personally like to see C99 to be required by Cactus if at all possible. This would mean that I could actually use it without big warning signs in README files of several thorns. - If this will not be possible, and I could imagine there could be good reasons for it, I would rather like to see clean C than C99 "sold as" C++ (even if it is valid C++). This should not be difficult to do in this case. > > What is the policy on inclusion of C99 code in Cactus? Since some > > compilers (gcc I think) need to be explicitly told to accept C99, it > > makes it a bit of a mess. We have configuration files with compiler flags already. I usually compile Cactus with C99 and did so for some years already without problems. I like to use some of the C99 features, so I do in several of my thorns. I believe the current policy is that Cactus itself should only contain C89, but of course every other arrangement can handle that differently. > >I believe the current situation is "if you > > need to use gcc, and you have thorns which use C99, then you'd better > > include the c99 flag in your config file". We could either Yes, I think this is correct, except that this is not a "gcc problem". The standard of the intel compiler (without -std= option) is also C89 (gnu89). It might be less strict though. It might also be interesting to know that the Cactus configuration for Linux and Intel Compilers already sets the standard to C99. Even more (I did not know that up to now): it also sets that for gcc and the pathscale compiler. > > 1. Ban C99 code from Cactus, ensuring that gcc is able to compile > > everything without additional flags. I believe that this is current policy. In my opinion it would be nice if this could be changes. However, this requires that we should evaluate how much C99 is supported wherever Cactus is used. I also do not think that the flags are the problem here. The real problem would be a production machine without a compiler capable of handling C99. > > 2. Allow C99 flags in Cactus, and change the default Cactus flags for > > gcc to include C99. The required C standard version should be changed regardless of the compiler. Otherwise parts of Cactus could not be compiled anymore with certain compilers which do not understand C99. > > Is it possible this would break existing code? Are > > all valid C89 programs valid C99 programs? Theoretically: Yes. No. However, practically I would expect only minor problems, if any at all. > > Do we need to support > > compilers which do not support C99? That is the question. I am quite sure that all the compilers for the usual clusters can handle C99. If someone knows a machine / an architecture where this is not true and where Cactus is activly used, it would be nice to speak up now. > > 3. Allow each thorn (file?) to state whether they need C99 or not. This > > is similar to the situation we currently have with C(89), C++ and Fortran. We could do that. However given that C99 and C89 are much closer together than F77 and F90, I would find it nicer to only support one of both, even if this would be C89. > (1) would be too strict, I guess. There are C thorns out there, provided > by the community, which make use of C99 extensions. Yes, but they are not really "part of Cactus" in the sense that the Cactus team does not have any control over those thorns, their policy and which compiler flags people use. > (3) wouldn't solve the actual problem, would it ? It would solve the current problem, but at a price which I think is way too high. > The question remains though whether new code which uses extensions to > the C89 standard should be written in C99 or C++. Here I'd vote for the > latter. I would like to leave that to the author. If all I need to solve a given task is a simple C program and I e.g. like to use "//" comments and "for (int i=0;" statements, then I would certainly not use C++ just for that. But that is a matter of taste I guess. Mine might even change in the future, but others might not. Frank From schnetter at cct.lsu.edu Tue Jan 20 09:13:49 2009 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 20 Jan 2009 09:13:49 -0600 Subject: [Developers] Outputting a combined timer report from a single processor In-Reply-To: <4970A862.8080807@aei.mpg.de> References: <97B91EA6-E65D-4419-A9D7-63325E733DA3@cct.lsu.edu> <496F21F8.2040701@aei.mpg.de> <20090115151900.GA5149@topf.wg> <4970A862.8080807@aei.mpg.de> Message-ID: <3BEEBEBC-5A86-413E-AD18-CF3691CA7CED@cct.lsu.edu> On Jan 16, 2009, at 09:31:46, Ian Hinder wrote: > 2. Allow C99 flags in Cactus, and change the default Cactus flags for > gcc to include C99. Is it possible this would break existing code? > Are > all valid C89 programs valid C99 programs? Do we need to support > compilers which do not support C99? I am regularly building Cactus on a variety of production systems (currently 22) with different operating systems using a set of different compilers. C89, C99, C++ (several "versions" of the standard), F77, F90, F95 (with more or less official extensions) are all supported there. The largest problem is handling compiler bugs. If there is an important system where there is essentially only one compiler available, and this compiler does e.g. not call C++ constructors correctly with static local variables (a current problem on some systems), then we either have to ensure that another correct C++ compiler is available on this system, or have to call constructors explicitly e.g. by turning the static variable into a pointer. (I'm currently favouring the latter.) However, I don't see any problem with C99 style variable declarations; this is solidly supported by all compilers. The only question is to supply the corresponding compiler options either automatically (in the known_architectures directory) or via the "standard" options that we suggest on the Cactus web site. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from . -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20090120/13d764eb/attachment.bin From knarf at cct.lsu.edu Thu Jan 22 14:36:48 2009 From: knarf at cct.lsu.edu (Frank Loeffler) Date: Thu, 22 Jan 2009 14:36:48 -0600 Subject: [Developers] GetCactus: too restrict svn check Message-ID: <20090122203648.GB5811@numrel07.cct.lsu.edu> Hi, this patch fixes a check for svn which is too strict. Please apply. Frank Index: GetCactus =================================================================== RCS file: /cactus/Utilities/Scripts/GetCactus,v retrieving revision 1.61 diff -u -r1.61 GetCactus --- GetCactus 22 Oct 2008 13:45:43 -0000 1.61 +++ GetCactus 22 Jan 2009 20:34:11 -0000 @@ -1122,11 +1122,6 @@ { $client = "cvs"; } - if ($svn eq 0) - { - DIE("Did not find Subversion binary 'svn', but Subversion repository ". - "checkout/update was requested."); - } $th =~ /(.*?)\//; my $cur_arrangement = $1; --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) text/plain (text body -- kept) --- From tradke at aei.mpg.de Fri Jan 23 03:45:59 2009 From: tradke at aei.mpg.de (Thomas Radke) Date: Fri, 23 Jan 2009 10:45:59 +0100 Subject: [Developers] GetCactus: too restrict svn check In-Reply-To: <20090122203648.GB5811@numrel07.cct.lsu.edu> References: <20090122203648.GB5811@numrel07.cct.lsu.edu> Message-ID: <497991D7.3030700@aei.mpg.de> Frank Loeffler wrote: > Hi, > > this patch fixes a check for svn which is too strict. Please apply. Done. -- Cheers, Thomas. From schnetter at cct.lsu.edu Tue Jan 27 16:20:11 2009 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 27 Jan 2009 16:20:11 -0600 Subject: [Developers] Patch for PUGH topologies Message-ID: <6134E1B6-89BE-4D37-968D-ABBA50B79F48@cct.lsu.edu> The enclosed patch for PUGH's topology selection prevents setting up topologies for lower-dimensional grid functions if these are not allowed. This prevents problems if such topologies do not exist, e.g. on small grids. Please comment. -erik Index: SetupPGH.c =================================================================== RCS file: /cactusdevcvs/CactusPUGH/PUGH/src/SetupPGH.c,v retrieving revision 1.86 diff -u -r1.86 SetupPGH.c --- SetupPGH.c 26 Sep 2005 03:06:25 -0000 1.86 +++ SetupPGH.c 27 Jan 2009 22:19:22 -0000 @@ -128,32 +128,59 @@ /* Set up connectivity and extras for each dimension */ for (idim = 1; idim <= dim; idim++) { - nprocs = malloc (idim * sizeof (int)); - - PUGH_SetupDefaultTopology (idim, nprocs); + int type; + const void * const allow_mixeddim_gfs_ptr = + CCTK_ParameterGet ("allow_mixeddim_gfs", "Cactus", &type); + const CCTK_INT allow_mixeddim_gfs = + *(const CCTK_INT*)allow_mixeddim_gfs_ptr; + if (type != PARAMETER_BOOLEAN) + { + CCTK_WARN (CCTK_WARN_ABORT, "internal error -- flesh parameter Cactus::allow_mixeddim_gfs has wrong type"); + } - /* Check that there are enough grid points in this dimension - * to make parallelising it worthwhile - */ - for (i = 0; i < idim; i++) + /* Do not set up topologies for lower-dimensional grid functions + if these are not allowed. This prevents problems if such + topologies do not exist, e.g. on small grids. */ + if (allow_mixeddim_gfs || idim == dim) { - if ((! nprocs[i]) && (abs (nsize[i]) <= 2 * nghostzones[i] + 1)) + CCTK_VInfo (CCTK_THORNSTRING, + "Setting up a topology for %d dimensions", idim); + nprocs = malloc (idim * sizeof (int)); + + PUGH_SetupDefaultTopology (idim, nprocs); + + /* Check that there are enough grid points in this dimension + * to make parallelising it worthwhile + */ + for (i = 0; i < idim; i++) { - nprocs[i] = 1; + if ((! nprocs[i]) && (abs (nsize[i]) <= 2 * nghostzones[i] + 1)) + { + nprocs[i] = 1; + } } - } - pughGH->Connectivity[idim-1] = PUGH_SetupConnectivity (idim, pughGH->nprocs, - nsize, nghostzones, - nprocs, perme); - free(nprocs); - - pughGH->GFExtras[idim-1] = PUGH_SetupPGExtras (1, idim, perme, staggertype, - nsize, nghostzones, - pughGH->nprocs, - pughGH- >Connectivity[idim-1]->nprocs, - pughGH- >Connectivity[idim-1]->neighbours, - pughGH->myproc); + pughGH->Connectivity[idim-1] = + PUGH_SetupConnectivity (idim, pughGH->nprocs, + nsize, nghostzones, + nprocs, perme); + free(nprocs); + + pughGH->GFExtras[idim-1] = + PUGH_SetupPGExtras (1, idim, perme, staggertype, + nsize, nghostzones, + pughGH->nprocs, + pughGH->Connectivity[idim-1]->nprocs, + pughGH->Connectivity[idim-1]->neighbours, + pughGH->myproc); + } + else + { + CCTK_VInfo (CCTK_THORNSTRING, + "Not setting up a topology for %d dimensions", idim); + pughGH->Connectivity[idim-1] = NULL; + pughGH->GFExtras[idim-1] = NULL; + } } /* create the timer for communication time */ -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from . -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20090127/70ea1592/attachment.bin From schnetter at cct.lsu.edu Tue Jan 27 23:42:23 2009 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 27 Jan 2009 23:42:23 -0600 Subject: [Developers] Preparing for a new Cactus release Message-ID: <56614614-83CD-482A-AB82-E752A79ED04C@cct.lsu.edu> Fellow Cactus Developers We are currently preparing for a new beta release (aka "stable version") of Cactus, which will be Cactus 4.0 beta 16. This release will include the flesh, associated basic thorns, and corresponding documentation, and will (as usual) start out as copy of the current development version. At the moment we are testing Cactus, including certain publicly available thorns, on various machines and architectures, ensuring that our configuration options work and that (most of) the test suites pass. To ensure consistent results we will make only emergency changes to Cactus until the release. It would help us if you could hold off changes to your publicly available thorns (selected thorns from the arrangements AEIThorns, AstroGrid, BetaThorns, Carpet, Excision, LSUThorns, PerturbedBH, and TAT) in the next few days as well. We expect this release to be ready some time late this week. We will announce the release on the mailing lists in the usual way. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from . -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20090127/8046ccae/attachment.bin From tradke at aei.mpg.de Wed Jan 28 04:12:18 2009 From: tradke at aei.mpg.de (Thomas Radke) Date: Wed, 28 Jan 2009 11:12:18 +0100 Subject: [Developers] Patch for PUGH topologies In-Reply-To: <6134E1B6-89BE-4D37-968D-ABBA50B79F48@cct.lsu.edu> References: <6134E1B6-89BE-4D37-968D-ABBA50B79F48@cct.lsu.edu> Message-ID: <49802F82.7060006@aei.mpg.de> Erik Schnetter wrote: > The enclosed patch for PUGH's topology selection prevents setting up > topologies for lower-dimensional grid functions if these are not > allowed. This prevents problems if such topologies do not exist, e.g. > on small grids. > > Please comment. Hi Erik, the patch looks fine to me, and fixes eg. the broken BenchADM testsuite (when run on more than one processor). Just a minor thing: the Cactus::allow_mixeddim_gfs parameter query should be moved outside the outermost loop, and - apart from the parameter type checking - one could also test the pointer value against NULL, or dereference it only after the type check. -- Cheers, Thomas. From tradke at aei.mpg.de Fri Jan 30 05:30:57 2009 From: tradke at aei.mpg.de (Thomas Radke) Date: Fri, 30 Jan 2009 12:30:57 +0100 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting Message-ID: <4982E4F1.2040108@aei.mpg.de> This patch fixes the GetCactus script so that it does not prompt for a password when checking out SVN modules as user 'cvs_anon'. In this case, the default password 'anon' is assumed and added automatically to the SVN command line options, as well as the '--no-auth-cache' option to prevent SVN from caching the anonymous user authentication information (which may overwrite any previously stored user auth info). -- Cheers, Thomas. --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) text/x-patch --- From knarf at cct.lsu.edu Fri Jan 30 07:00:06 2009 From: knarf at cct.lsu.edu (Frank Loeffler) Date: Fri, 30 Jan 2009 07:00:06 -0600 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <4982E4F1.2040108@aei.mpg.de> References: <4982E4F1.2040108@aei.mpg.de> Message-ID: <20090130130006.GV4125@numrel07.cct.lsu.edu> On Fri, Jan 30, 2009 at 12:30:57PM +0100, Thomas Radke wrote: > This patch fixes the GetCactus script so that it does not prompt for a > password when checking out SVN modules as user 'cvs_anon'. In this case, Thanks > the default password 'anon' is assumed and added automatically to the > SVN command line options, as well as the '--no-auth-cache' option to > prevent SVN from caching the anonymous user authentication information > (which may overwrite any previously stored user auth info). For Subversion I am not sure if we should do this. Subversion allows checkout without a password. Such a public user/username like with cvs is not necessary. IMHO this should be fixed on the Subversion server. Frank From schnetter at cct.lsu.edu Fri Jan 30 07:54:03 2009 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Fri, 30 Jan 2009 07:54:03 -0600 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <20090130130006.GV4125@numrel07.cct.lsu.edu> References: <4982E4F1.2040108@aei.mpg.de> <20090130130006.GV4125@numrel07.cct.lsu.edu> Message-ID: <7BBEB205-725C-449B-914F-642601A739F3@cct.lsu.edu> On Jan 30, 2009, at 07:00:06, Frank Loeffler wrote: > On Fri, Jan 30, 2009 at 12:30:57PM +0100, Thomas Radke wrote: >> This patch fixes the GetCactus script so that it does not prompt >> for a >> password when checking out SVN modules as user 'cvs_anon'. In this >> case, > > Thanks > >> the default password 'anon' is assumed and added automatically to the >> SVN command line options, as well as the '--no-auth-cache' option to >> prevent SVN from caching the anonymous user authentication >> information >> (which may overwrite any previously stored user auth info). > > For Subversion I am not sure if we should do this. Subversion allows > checkout without a password. Such a public user/username like with cvs > is not necessary. IMHO this should be fixed on the Subversion server. At the moment, several publicly available thorns require the user to use "anon" as password, and this makes the checkout process hang. I think we should update the GetCactus script, and at the same time work on changing the server configuration which may take some time. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from . -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20090130/85815e13/attachment.bin From knarf at cct.lsu.edu Fri Jan 30 08:42:44 2009 From: knarf at cct.lsu.edu (Frank Loeffler) Date: Fri, 30 Jan 2009 08:42:44 -0600 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <7BBEB205-725C-449B-914F-642601A739F3@cct.lsu.edu> References: <4982E4F1.2040108@aei.mpg.de> <20090130130006.GV4125@numrel07.cct.lsu.edu> <7BBEB205-725C-449B-914F-642601A739F3@cct.lsu.edu> Message-ID: <20090130144244.GY4125@numrel07.cct.lsu.edu> Hi, On Fri, Jan 30, 2009 at 07:54:03AM -0600, Erik Schnetter wrote: > At the moment, several publicly available thorns require the user to use > "anon" as password, and this makes the checkout process hang. That is true. I wrote David Link about it (the administrator of the subversion repositories at AEI). > I think we > should update the GetCactus script, and at the same time work on changing > the server configuration which may take some time. Ok, granted. So, let's hardcode 'cvs_anon' and 'anon' for the moment in the script. Frank From tradke at aei.mpg.de Fri Jan 30 09:17:33 2009 From: tradke at aei.mpg.de (Thomas Radke) Date: Fri, 30 Jan 2009 16:17:33 +0100 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <20090130144244.GY4125@numrel07.cct.lsu.edu> References: <4982E4F1.2040108@aei.mpg.de> <20090130130006.GV4125@numrel07.cct.lsu.edu> <7BBEB205-725C-449B-914F-642601A739F3@cct.lsu.edu> <20090130144244.GY4125@numrel07.cct.lsu.edu> Message-ID: <49831A0D.5010406@aei.mpg.de> Frank Loeffler wrote: > Hi, > > On Fri, Jan 30, 2009 at 07:54:03AM -0600, Erik Schnetter wrote: >> At the moment, several publicly available thorns require the user to use >> "anon" as password, and this makes the checkout process hang. > > That is true. I wrote David Link about it (the administrator of the > subversion repositories at AEI). > >> I think we >> should update the GetCactus script, and at the same time work on changing >> the server configuration which may take some time. > > Ok, granted. So, let's hardcode 'cvs_anon' and 'anon' for the moment in > the script. Note that only the password for user 'cvs_anon' is hardcoded. The username can be set via the #REPOSITORY_USER pragma. We could introduce a #REPOSITORY_PASSWORD pragma as well. I have committed the patch. -- Cheers, Thomas. From schnetter at cct.lsu.edu Fri Jan 30 09:17:37 2009 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Fri, 30 Jan 2009 09:17:37 -0600 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <20090130144244.GY4125@numrel07.cct.lsu.edu> References: <4982E4F1.2040108@aei.mpg.de> <20090130130006.GV4125@numrel07.cct.lsu.edu> <7BBEB205-725C-449B-914F-642601A739F3@cct.lsu.edu> <20090130144244.GY4125@numrel07.cct.lsu.edu> Message-ID: <6397E30F-B091-440C-B9DF-E512C548E6CD@cct.lsu.edu> On Jan 30, 2009, at 08:42:44, Frank Loeffler wrote: > Hi, > > On Fri, Jan 30, 2009 at 07:54:03AM -0600, Erik Schnetter wrote: >> At the moment, several publicly available thorns require the user >> to use >> "anon" as password, and this makes the checkout process hang. > > That is true. I wrote David Link about it (the administrator of the > subversion repositories at AEI). > >> I think we >> should update the GetCactus script, and at the same time work on >> changing >> the server configuration which may take some time. > > Ok, granted. So, let's hardcode 'cvs_anon' and 'anon' for the moment > in > the script. If you commit this change, please run a full checkout and build of Cactus from scratch on one of the large machines (e.g. Eric or Ranger) to ensure things work correctly. We can also postpone the change until after the beta release. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from . -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20090130/a8ef8f98/attachment.bin From knarf at cct.lsu.edu Fri Jan 30 09:38:08 2009 From: knarf at cct.lsu.edu (Frank Loeffler) Date: Fri, 30 Jan 2009 09:38:08 -0600 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <49831A0D.5010406@aei.mpg.de> References: <4982E4F1.2040108@aei.mpg.de> <20090130130006.GV4125@numrel07.cct.lsu.edu> <7BBEB205-725C-449B-914F-642601A739F3@cct.lsu.edu> <20090130144244.GY4125@numrel07.cct.lsu.edu> <49831A0D.5010406@aei.mpg.de> Message-ID: <20090130153804.GB4125@numrel07.cct.lsu.edu> Hi, On Fri, Jan 30, 2009 at 04:17:33PM +0100, Thomas Radke wrote: > We could introduce a #REPOSITORY_PASSWORD pragma as well. I would rather not like it. I fear that people would then tend to use it for other accounts than cvs_anon. > I have committed the patch. Thanks. Can you please try it with some big thornlist file on, e.g. damiana? thanks, Frank From knarf at cct.lsu.edu Fri Jan 30 09:50:18 2009 From: knarf at cct.lsu.edu (Frank Loeffler) Date: Fri, 30 Jan 2009 09:50:18 -0600 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <4982E4F1.2040108@aei.mpg.de> References: <4982E4F1.2040108@aei.mpg.de> Message-ID: <20090130155018.GD4125@numrel07.cct.lsu.edu> Hi, On Fri, Jan 30, 2009 at 12:30:57PM +0100, Thomas Radke wrote: > This patch fixes the GetCactus script so that it does not prompt for a > password when checking out SVN modules as user 'cvs_anon'. While testing the new version I also found that the current mechanism for CVS does not work as well. The problem is that for cvs this is done by editing the ~/.cvspass file and adding lines like :pserver:cvs_anon at cvs.cactuscode.org:/cactusdevcvs Ay=0= However, that does not catch all repositories where cvs_anon may be used, e.g. not :pserver:cvs_anon at cvs.cct.lsu.edu:2401/numrel Ay=0= However, I would say we leave it like it is until after the release. Frank From tradke at aei.mpg.de Fri Jan 30 09:59:06 2009 From: tradke at aei.mpg.de (Thomas Radke) Date: Fri, 30 Jan 2009 16:59:06 +0100 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <20090130153804.GB4125@numrel07.cct.lsu.edu> References: <4982E4F1.2040108@aei.mpg.de> <20090130130006.GV4125@numrel07.cct.lsu.edu> <7BBEB205-725C-449B-914F-642601A739F3@cct.lsu.edu> <20090130144244.GY4125@numrel07.cct.lsu.edu> <49831A0D.5010406@aei.mpg.de> <20090130153804.GB4125@numrel07.cct.lsu.edu> Message-ID: <498323CA.9030408@aei.mpg.de> Frank Loeffler wrote: > Hi, > > On Fri, Jan 30, 2009 at 04:17:33PM +0100, Thomas Radke wrote: >> We could introduce a #REPOSITORY_PASSWORD pragma as well. > > I would rather not like it. I fear that people would then tend to use it > for other accounts than cvs_anon. > >> I have committed the patch. > > Thanks. Can you please try it with some big thornlist file on, e.g. > damiana? I did, with the Utilities/ThornListsExternal/TestedBeta16.th thornlist, and had no problems checking it out with the GetCactus script. -- Cheers, Thomas. From knarf at cct.lsu.edu Fri Jan 30 10:04:01 2009 From: knarf at cct.lsu.edu (Frank Loeffler) Date: Fri, 30 Jan 2009 10:04:01 -0600 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <498323CA.9030408@aei.mpg.de> References: <4982E4F1.2040108@aei.mpg.de> <20090130130006.GV4125@numrel07.cct.lsu.edu> <7BBEB205-725C-449B-914F-642601A739F3@cct.lsu.edu> <20090130144244.GY4125@numrel07.cct.lsu.edu> <49831A0D.5010406@aei.mpg.de> <20090130153804.GB4125@numrel07.cct.lsu.edu> <498323CA.9030408@aei.mpg.de> Message-ID: <20090130160401.GE4125@numrel07.cct.lsu.edu> Hi, On Fri, Jan 30, 2009 at 04:59:06PM +0100, Thomas Radke wrote: > I did, with the Utilities/ThornListsExternal/TestedBeta16.th thornlist, > and had no problems checking it out with the GetCactus script. I used the same thornlist. Did you clear ~/.cvspass before? Frank From tradke at aei.mpg.de Fri Jan 30 10:18:29 2009 From: tradke at aei.mpg.de (Thomas Radke) Date: Fri, 30 Jan 2009 17:18:29 +0100 Subject: [Developers] GetCactus: anonymous checkout of SVN modules without password prompting In-Reply-To: <20090130160401.GE4125@numrel07.cct.lsu.edu> References: <4982E4F1.2040108@aei.mpg.de> <20090130130006.GV4125@numrel07.cct.lsu.edu> <7BBEB205-725C-449B-914F-642601A739F3@cct.lsu.edu> <20090130144244.GY4125@numrel07.cct.lsu.edu> <49831A0D.5010406@aei.mpg.de> <20090130153804.GB4125@numrel07.cct.lsu.edu> <498323CA.9030408@aei.mpg.de> <20090130160401.GE4125@numrel07.cct.lsu.edu> Message-ID: <49832855.4060001@aei.mpg.de> Frank Loeffler wrote: > Hi, > > On Fri, Jan 30, 2009 at 04:59:06PM +0100, Thomas Radke wrote: >> I did, with the Utilities/ThornListsExternal/TestedBeta16.th thornlist, >> and had no problems checking it out with the GetCactus script. > > I used the same thornlist. Did you clear ~/.cvspass before? No, I haven't touched anything regarding CVS. I verified though that my cached personal SVN user account authorisation information in ~/.subversion/auth/svn.simple/ is not overwritten anymore. -- Cheers, Thomas.