From baiotti at aei.mpg.de Thu Nov 2 11:11:11 2006 From: baiotti at aei.mpg.de (Luca Baiotti) Date: Thu, 02 Nov 2006 18:11:11 +0100 Subject: [Developers] Recover SaveAndRestore variables with PUGH In-Reply-To: <453742C6.4070903@aei.mpg.de> References: <4535DF7A.60605@aei.mpg.de> <1161245758.2332.8.camel@multiplicity> <453742C6.4070903@aei.mpg.de> Message-ID: <454A26AF.6040904@aei.mpg.de> Thomas Radke wrote: > Ian Hawke wrote: > >>On Wed, 2006-10-18 at 19:43 -0500, Erik Schnetter wrote: >> >> >>>On Oct 18, 2006, at 03:02:02, Luca Baiotti wrote: >> >> >>>I think the root of the problem is that evolution_method="none" does >>>not do anything to time levels. It should instead copy the previous >>>time level into the current time level in the prestep bin. The >>>current mechanism was implemented when people would use only a single >>>time level with stationary spacetimes; only with Carpet do people >>>want multiple time levels in that case, which breaks things. >>> >>>Ian, do you think that this would also solve the problem? >> >> >>It would work, and is rather more satisfactory than modifying MoL (as >>SaveAndRestore variables just mean "these might be evolved by some other >>thorn"). >> >>I still believe that the only guaranteed way of ensuring consistency >>after recovery is to checkpoint all timelevels, even with PUGH, because >>you never know what somebody's going to try and do. > > > If you don't want to solve the problem by modifying PUGH or MoL it's a > small thing for me to implement a new boolean parameter > IO::checkpoint_all_timelevels (defaulting to "no"?). > > Just let me know. This discussion has been quiet for a while; so I would assume that the last suggestion is supported by everyone. If this is the case, Thomas please implement your suggestion (it is not so urgent, anyway). Thanks, Luca. From schnetter at cct.lsu.edu Thu Nov 2 11:22:26 2006 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Thu, 2 Nov 2006 18:22:26 +0100 Subject: [Developers] Recover SaveAndRestore variables with PUGH In-Reply-To: <454A26AF.6040904@aei.mpg.de> References: <4535DF7A.60605@aei.mpg.de> <1161245758.2332.8.camel@multiplicity> <453742C6.4070903@aei.mpg.de> <454A26AF.6040904@aei.mpg.de> Message-ID: <23991E8B-1920-49D3-A5BB-73703E03BF72@cct.lsu.edu> On Nov 2, 2006, at 18:11:11, Luca Baiotti wrote: > Thomas Radke wrote: >> Ian Hawke wrote: >> >>> On Wed, 2006-10-18 at 19:43 -0500, Erik Schnetter wrote: >>> >>> >>>> On Oct 18, 2006, at 03:02:02, Luca Baiotti wrote: >>> >>> >>>> I think the root of the problem is that evolution_method="none" >>>> does >>>> not do anything to time levels. It should instead copy the >>>> previous >>>> time level into the current time level in the prestep bin. The >>>> current mechanism was implemented when people would use only a >>>> single >>>> time level with stationary spacetimes; only with Carpet do people >>>> want multiple time levels in that case, which breaks things. >>>> >>>> Ian, do you think that this would also solve the problem? >>> >>> >>> It would work, and is rather more satisfactory than modifying MoL >>> (as >>> SaveAndRestore variables just mean "these might be evolved by >>> some other >>> thorn"). >>> >>> I still believe that the only guaranteed way of ensuring consistency >>> after recovery is to checkpoint all timelevels, even with PUGH, >>> because >>> you never know what somebody's going to try and do. >> >> >> If you don't want to solve the problem by modifying PUGH or MoL >> it's a >> small thing for me to implement a new boolean parameter >> IO::checkpoint_all_timelevels (defaulting to "no"?). >> >> Just let me know. > > This discussion has been quiet for a while; so I would assume that the > last suggestion is supported by everyone. > > If this is the case, Thomas please implement your suggestion (it is > not > so urgent, anyway). I don't really; I think making the evolution method "none" work correctly (by not assuming that the new time level is taken from the pre-previous one) is superior. I have placed a correspondingly modified copy of ADMBase onto Peyote in ~eschnett/ADMBase.tar.gz. Couldyou test it? It has some other, unrelated changes as well; if it solves your problem, we can clean it up. -erik -- Erik Schnetter My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20061102/3bcc9357/attachment.bin From bgiacoma at aei.mpg.de Sun Nov 5 04:09:04 2006 From: bgiacoma at aei.mpg.de (bgiacoma) Date: Sun, 5 Nov 2006 11:09:04 +0100 (CET) Subject: [Developers] Recover SaveAndRestore variables with PUGH In-Reply-To: <23991E8B-1920-49D3-A5BB-73703E03BF72@cct.lsu.edu> References: <4535DF7A.60605@aei.mpg.de> <1161245758.2332.8.camel@multiplicity> <453742C6.4070903@aei.mpg.de> <454A26AF.6040904@aei.mpg.de> <23991E8B-1920-49D3-A5BB-73703E03BF72@cct.lsu.edu> Message-ID: Hi, On Thu, 2 Nov 2006, Erik Schnetter wrote: > I have placed a correspondingly modified copy of ADMBase onto Peyote in > ~eschnett/ADMBase.tar.gz. Couldyou test it? It has some other, unrelated > changes as well; if it solves your problem, we can clean it up. I tested it with the parameter file I sent some time ago and now it seems to work. In the attached file test.tar you can find the stdout and stderr of whisky+ADMBase (original version) and Whisky+ADMBase (erik version). They are respectively named as tov_test_adm_part* and tov_test_adm_erik_part* As you can see the info about the maximum of the density is correctly computed in tov_test_adm_erik_part2 (compare with tov_test_adm_erik_part1) which started from a checkpoint generated at iteration 5 and which used the ADMBase version by Erik. In the original version this does not happen as you can see from the same info between file tov_test_adm_part1 and tov_test_adm_part2 (the latter having been started from a checkpoint saved at iteration 5). Good job! Cheers, Bruno -- Dr. Bruno Giacomazzo Max Planck Institute for Gravitational Physics Albert Einstein Institute Am M??hlenberg 1 D-14476 Potsdam Germany Tel. : +49 331 567 7643 Fax : +49 331 567 7649 email : bgiacoma at aei.mpg.de ------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: test.tar Type: application/x-tar Size: 40960 bytes Desc: Url : http://www.cactuscode.org/pipermail/developers/attachments/20061105/9fce3e4b/attachment-0001.tar From szilagyi at aei.mpg.de Tue Nov 7 13:21:06 2006 From: szilagyi at aei.mpg.de (Bela Szilagyi) Date: Tue, 7 Nov 2006 20:21:06 +0100 Subject: [Developers] parameter data type check? Message-ID: <200611072021.06422.szilagyi@aei.mpg.de> I just caught myself having had in one of my param.ccl files the declaration CCCTK_INT index_of_AH[3] "....." { 0 :: "...." # ..... } 0 where the three "C"-s from CCCTK_INT are indeed there in the parameter declaration file. Compilation seems to have gone through with no trouble. The question is -- what kind of variable is this "index_of_AH" in my C routine? More generically -- is there any check/enforcement that the user declarations are consistent with the set of defined cactus data types? -- Bela Szilagyi Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut Tel: +49 331 567 7632 Fax: +49 331 567 7649 From schnetter at cct.lsu.edu Tue Nov 7 14:04:47 2006 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 7 Nov 2006 14:04:47 -0600 Subject: [Developers] parameter data type check? In-Reply-To: <200611072021.06422.szilagyi@aei.mpg.de> References: <200611072021.06422.szilagyi@aei.mpg.de> Message-ID: On Nov 7, 2006, at 13:21:06, Bela Szilagyi wrote: > I just caught myself having had in one of my param.ccl files the > declaration > > CCCTK_INT index_of_AH[3] "....." > { > 0 :: "...." > # ..... > } 0 > > where the three "C"-s from CCCTK_INT are indeed there in the parameter > declaration file. > > Compilation seems to have gone through with no trouble. The > question is -- > what kind of variable is this "index_of_AH" in my C routine? > > More generically -- is there any check/enforcement that the user > declarations > are consistent with the set of defined cactus data types? Don't worry, there are lots of checks there; all automatically produced C code is produced via rules that ensure that only legal C code is created. Having said that, there can of course be errors or omissions in Cactus, but there are no big holes. You have found an interesting bug. The parser for parameter files is supposed to accept two syntaxes, "INT" and "CCTK_INT", for the same data type. However, the parser accidentally also allows arbitrary characters on the same line in front of the data type. That is, the first "C" is ignored as garbage, the remainder is then parsed as expected. The source of the bug is a missing "^" (caret) character in line 151 of the file lib/sbin/parameter_parser.pl, which forbids leading additional characters. -erik -- Erik Schnetter My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20061107/e6847b2c/attachment.bin From dprideout at gmail.com Fri Nov 10 12:26:28 2006 From: dprideout at gmail.com (David Rideout) Date: Fri, 10 Nov 2006 18:26:28 +0000 Subject: [Developers] Fwd: Cactus_dev compilation with Intel Mac + gcc In-Reply-To: <455332BA.8040509@milkyway.gsfc.nasa.gov> References: <455332BA.8040509@milkyway.gsfc.nasa.gov> Message-ID: <1ce81abb0611101026t19def01eh7199d5da825e6b71@mail.gmail.com> Hi Bernard, I hope you don't mind my forwarding this to the developers list, but it should be of general interest... I get the same exact errors when trying to compile Cactus on a powerpc Mac. Some recent commit must have broken Cactus on a Mac? (Also maybe it was Erik which started this thread you speak of? I don't think it was me.) Cheers, David ---------- Forwarded message ---------- From: Bernard Kelly Date: Nov 9, 2006 1:52 PM Subject: Cactus_dev compilation with Intel Mac + gcc To: dprideout at gmail.com Hi David. I found the tail-end of a Cactus + Mac discussion that you initiated on the cactus "Users" mailing list a few weeks ago. Does this mean you're happily compiling Cactus on your Mac? I checked out cactusdev recently, and totally failed to compile on my Mac (both with gcc-4.0 or gcc-3.3). The errors set in early (after config), with messages like the following appearing when working on CactusBase/Boundary/ScalarBoundary ---------------------------------------------------------------------------------------- Users/kelly/Work/Cactus_Dev/src/include/cGH.h:43: error: parse error before "CCTK_REAL8" /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:43: warning: no semicolon at end of struct or union /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:44: warning: data definition has no type or storage class /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:47: error: parse error before '*' token /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:47: warning: data definition has no type or storage class /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:73: error: parse error before "cctk_time" /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:73: warning: data definition has no type or storage class /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:89: error: parse error before '}' token [ and so on ...] ---------------------------------------------------------------------------------------- this seems to be something fundamental, and doesn't arise when compiling the stable version of Cactus. I could go to the Users mailing list with this, but thought you might have some quick explanation of what's happening. Any input -- including whom else I should bother -- is appreciated. Thanks, Bernard From schnetter at cct.lsu.edu Fri Nov 10 13:02:40 2006 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Fri, 10 Nov 2006 13:02:40 -0600 Subject: [Developers] Fwd: Cactus_dev compilation with Intel Mac + gcc In-Reply-To: <1ce81abb0611101026t19def01eh7199d5da825e6b71@mail.gmail.com> References: <455332BA.8040509@milkyway.gsfc.nasa.gov> <1ce81abb0611101026t19def01eh7199d5da825e6b71@mail.gmail.com> Message-ID: <9A195794-6736-4B5E-9360-2A78E62577E7@cct.lsu.edu> Hi, I'm using Cactus on a Mac, happily. I have a local change to the configuration scripts for Macs which I have unfortunately not yet committed. (I did not know that things actually broke for others until recently.) I'll do that later today; sorry about the delay. -erik On Nov 10, 2006, at 12:26:28, David Rideout wrote: > Hi Bernard, > > I hope you don't mind my forwarding this to the developers list, but > it should be of general interest... I get the same exact errors when > trying to compile Cactus on a powerpc Mac. Some recent commit must > have broken Cactus on a Mac? > > (Also maybe it was Erik which started this thread you speak of? I > don't think it was me.) > > Cheers, > David > > ---------- Forwarded message ---------- > From: Bernard Kelly > Date: Nov 9, 2006 1:52 PM > Subject: Cactus_dev compilation with Intel Mac + gcc > To: dprideout at gmail.com > > > Hi David. > > I found the tail-end of a Cactus + Mac discussion that you > initiated on > the cactus "Users" mailing list a few weeks ago. Does this mean you're > happily compiling Cactus on your Mac? > > I checked out cactusdev recently, and totally failed to compile on my > Mac (both with gcc-4.0 or gcc-3.3). The errors set in early (after > config), with messages like the following appearing when working on > CactusBase/Boundary/ScalarBoundary > > ---------------------------------------------------------------------- > ------------------ > Users/kelly/Work/Cactus_Dev/src/include/cGH.h:43: error: parse error > before "CCTK_REAL8" > /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:43: warning: no > semicolon > at end of struct or union > /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:44: warning: data > definition has no type or storage class > /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:47: error: parse error > before '*' token > /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:47: warning: data > definition has no type or storage class > /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:73: error: parse error > before "cctk_time" > /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:73: warning: data > definition has no type or storage class > /Users/kelly/Work/Cactus_Dev/src/include/cGH.h:89: error: parse error > before '}' token > [ and so on ...] > ---------------------------------------------------------------------- > ------------------ > > > this seems to be something fundamental, and doesn't arise when > compiling > the stable version of Cactus. > > I could go to the Users mailing list with this, but thought you might > have some quick explanation of what's happening. Any input -- > including > whom else I should bother -- is appreciated. > > Thanks, > > Bernard > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers > -- Erik Schnetter My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20061110/cbf37232/attachment.bin From baiotti at aei.mpg.de Sat Nov 11 07:05:33 2006 From: baiotti at aei.mpg.de (Luca Baiotti) Date: Sat, 11 Nov 2006 14:05:33 +0100 Subject: [Developers] Recover SaveAndRestore variables with PUGH In-Reply-To: References: <4535DF7A.60605@aei.mpg.de> <1161245758.2332.8.camel@multiplicity> <453742C6.4070903@aei.mpg.de> <454A26AF.6040904@aei.mpg.de> <23991E8B-1920-49D3-A5BB-73703E03BF72@cct.lsu.edu> Message-ID: <4555CA9D.7030701@aei.mpg.de> Hi, it works, like Bruno said. Should it be committed? Ciao, Luca. bgiacoma wrote: > Hi, > > On Thu, 2 Nov 2006, Erik Schnetter wrote: > >> I have placed a correspondingly modified copy of ADMBase onto Peyote >> in ~eschnett/ADMBase.tar.gz. Couldyou test it? It has some other, >> unrelated changes as well; if it solves your problem, we can clean it up. > > > I tested it with the parameter file I sent some time ago and now it > seems to work. In the attached file test.tar you can find the stdout and > stderr of whisky+ADMBase (original version) and Whisky+ADMBase (erik > version). They are respectively named as tov_test_adm_part* and > tov_test_adm_erik_part* > > As you can see the info about the maximum of the density is correctly > computed in tov_test_adm_erik_part2 (compare with > tov_test_adm_erik_part1) which started from a checkpoint generated at > iteration 5 and which used the ADMBase version by Erik. In the original > version this does not happen as you can see from the same info between > file tov_test_adm_part1 and tov_test_adm_part2 (the latter having been > started from a checkpoint saved at iteration 5). > > Good job! > > Cheers, > Bruno From steve.white at aei.mpg.de Sun Nov 12 11:09:44 2006 From: steve.white at aei.mpg.de (Steve White) Date: Sun, 12 Nov 2006 18:09:44 +0100 Subject: [Developers] Valgrind warnings Message-ID: <20061112170943.GA31716@sshserv.aei.mpg.de> Hi, I'm trying to debug a strange problem in this JobChaining project. I'll describe the problem and history. Perhaps you could provide some advice, or try to run valgrind on your favourite code, or relate an experience. I get a reproducible effect when running a big par file of Luca's. The processes just run into the weeds, usually appearing to hang in library routines. Forced core dumps don't show a complete backtrace. It's stack damage. So I ran the thing in Valgrind. I see great numbers of warnings about uninitialized memory being used, which at least seem to start in the Parameters.c file. Now, that code is generally objectionable, and features many potential bugs, but all attempts to locate the source of this warning have so far failed. My best lead on the problem at hand is this warning. Beside this, I have tried many dozens of kinds of expreriments, but haven't been able to make a lot of sense of what I'm seeing. Now, a curiosity: A build of a JobChain WaveToy with Carpet, with the same Cactus configuration, showed no such errors when run under Valgrind. However, I had not updated my arrangements generally in some time, only Carpet-dev and JobChaining were quite up-to-date; the others were some month or two old. When I then updated everything, the Valgrind errors appeared in my Wavetoy *too*. The first reports appear when Carpet is creating certain parameters (example attached). Note that the Valgrind complaints may reflect problems in the C libraries. Unfortunately, I failed to anticipate this and did not record the state of my arrangements etc before I did the update. I was not using Formaline. Yesterday, I attempted to recreate my build free from warnings by regressing my checkouts of arrangements and the Flesh. I had no luck. I don't understand. I have asked our sysadmin to retrieve backups of the directories involved. Now, in LAM runs, I have always seen uninitialized memory warnings from the LAM library. Also, even in a very simple PUGH WaveToy, I get some use of uninitialized memory in the evolution loop... But I'm very suspicious about these Parameter.c warnings right at the beginning of Carpet runs. Thanks for your time. -- Steve White : Programmer Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut Am M?hlenberg 1, D-14476 Golm, Germany +49-331-567-7625 -------------- next part -------------- ==11345== Conditional jump or move depends on uninitialised value(s) ==11345== at 0x1BEDD90D: re_compile_internal (in /lib/libc-2.3.6.so) ==11345== by 0x1BEDECA5: regcomp (in /lib/libc-2.3.6.so) ==11345== by 0x805C921: CCTK_RegexMatch (Misc.c:1162) ==11345== by 0x8050125: ParameterSetString (Parameters.c:2092) ==11345== by 0x804FDB7: ParameterSetSimple (Parameters.c:1998) ==11345== by 0x804E027: CCTKi_ParameterCreate (Parameters.c:351) ==11345== by 0x8075BEB: CCTKi_BindingsCreateCarpetParameters (Carpet_Parameters.c:172) ==11345== by 0x8074D6D: CCTKi_BindingsParametersInitialise (BindingsParameters.c:39) ==11345== by 0x8055399: CCTKi_InitialiseSubsystemDefaults (Subsystems.c:51) ==11345== by 0x804D961: CCTKi_InitialiseCactus (InitialiseCactus.c:91) ==11345== by 0x804D89C: main (flesh.cc:64) From yye00 at cct.lsu.edu Mon Nov 13 14:43:20 2006 From: yye00 at cct.lsu.edu (Yaakoub Y El Khamra) Date: Mon, 13 Nov 2006 14:43:20 -0600 Subject: [Developers] Cactus website Message-ID: <4558D8E8.9040202@cct.lsu.edu> Greetings The cactus website is down for maintenance. We have removed 600 accounts that belonged to various spammers from the plone website and are in the process of removing some of the files they uploaded as portraits. If we have accidentally removed your account we apologize for the inconvenience and kindly request that you register yourself again. Regards Yaakoub El Khamra From yye00 at cct.lsu.edu Mon Nov 13 15:59:07 2006 From: yye00 at cct.lsu.edu (Yaakoub Y El Khamra) Date: Mon, 13 Nov 2006 15:59:07 -0600 Subject: [Developers] Cactus Website Message-ID: <4558EAAB.1040006@cct.lsu.edu> The Cactus Code website is now back online. While we are still working on the website's internal operation we expect no disruption to the service. Thank you for your patience and understanding. Regards Yaakoub Y El Khamra From schnetter at cct.lsu.edu Mon Nov 13 20:35:33 2006 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Mon, 13 Nov 2006 21:35:33 -0500 Subject: [Developers] Recover SaveAndRestore variables with PUGH In-Reply-To: <4555CA9D.7030701@aei.mpg.de> References: <4535DF7A.60605@aei.mpg.de> <1161245758.2332.8.camel@multiplicity> <453742C6.4070903@aei.mpg.de> <454A26AF.6040904@aei.mpg.de> <23991E8B-1920-49D3-A5BB-73703E03BF72@cct.lsu.edu> <4555CA9D.7030701@aei.mpg.de> Message-ID: <3A48C795-7FDA-4B8A-A1F8-DC2DD1C7FA54@cct.lsu.edu> I think it should. The patch needs to be cleaned up, so that there are no unrelated changed, and a test case should be added. After that, it needs to be posted officially so that others can have a look at it before it is committed. If you have time to clean up the patch and add a test case, then this would speed up things. Otherwise it'll probably happen not before next month. -erik On Nov 11, 2006, at 08:05:33, Luca Baiotti wrote: > Hi, > > it works, like Bruno said. Should it be committed? > > > Ciao, > > Luca. > > > bgiacoma wrote: >> Hi, >> >> On Thu, 2 Nov 2006, Erik Schnetter wrote: >> >>> I have placed a correspondingly modified copy of ADMBase onto Peyote >>> in ~eschnett/ADMBase.tar.gz. Couldyou test it? It has some other, >>> unrelated changes as well; if it solves your problem, we can >>> clean it up. >> >> >> I tested it with the parameter file I sent some time ago and >> now it >> seems to work. In the attached file test.tar you can find the >> stdout and >> stderr of whisky+ADMBase (original version) and Whisky+ADMBase (erik >> version). They are respectively named as tov_test_adm_part* and >> tov_test_adm_erik_part* >> >> As you can see the info about the maximum of the density is correctly >> computed in tov_test_adm_erik_part2 (compare with >> tov_test_adm_erik_part1) which started from a checkpoint generated at >> iteration 5 and which used the ADMBase version by Erik. In the >> original >> version this does not happen as you can see from the same info >> between >> file tov_test_adm_part1 and tov_test_adm_part2 (the latter having >> been >> started from a checkpoint saved at iteration 5). >> >> Good job! >> >> Cheers, >> Bruno > > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers > -- Erik Schnetter My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20061113/c78c37e7/attachment-0001.bin From steve.white at aei.mpg.de Tue Nov 14 07:32:48 2006 From: steve.white at aei.mpg.de (Steve White) Date: Tue, 14 Nov 2006 14:32:48 +0100 Subject: [Developers] Valgrind warnings In-Reply-To: <20061112170943.GA31716@sshserv.aei.mpg.de> References: <20061112170943.GA31716@sshserv.aei.mpg.de> Message-ID: <20061114133247.GC5943@sshserv.aei.mpg.de> Hi again, I spoke with Erik yesterday concerning Valgrind in Cactus. He commented that Valgrind didn't understand some compiler optimizations. As obvious as that is, I don't remember it having occurred to me. But it doesn't seem to be the case here that an optimization is triggering the Valgrind warnings. First, I have a small test program (attached) that calls system routines similar to those in Cactus about which Valgrind is complaining. By commenting out a line, you can trigger a similar complaint. Valgrind produces the same results regardless of whether the program is compiled with the Intel flags -O3 -ip Also, I have been compiling all these Cactus runs with OPTIMISE=no. So I don't think that optimization is triggering the Valgrind errors. Cheers! On 12.11.06, Steve White wrote: > Hi, > > I'm trying to debug a strange problem in this JobChaining project. I'll > describe the problem and history. Perhaps you could provide some advice, > or try to run valgrind on your favourite code, or relate an experience. > > I get a reproducible effect when running a big par file of Luca's. > The processes just run into the weeds, usually appearing to hang in > library routines. Forced core dumps don't show a complete backtrace. > It's stack damage. > > So I ran the thing in Valgrind. I see great numbers of warnings about > uninitialized memory being used, which at least seem to start in the > Parameters.c file. Now, that code is generally objectionable, and features > many potential bugs, but all attempts to locate the source of this > warning have so far failed. > > My best lead on the problem at hand is this warning. > > Beside this, I have tried many dozens of kinds of expreriments, but haven't > been able to make a lot of sense of what I'm seeing. > > Now, a curiosity: A build of a JobChain WaveToy with Carpet, with the same > Cactus configuration, showed no such errors when run under Valgrind. > > However, I had not updated my arrangements generally in some time, only > Carpet-dev and JobChaining were quite up-to-date; the others were some > month or two old. When I then updated everything, the Valgrind errors > appeared in my Wavetoy *too*. The first reports appear when Carpet is > creating certain parameters (example attached). > > Note that the Valgrind complaints may reflect problems in the C > libraries. > > Unfortunately, I failed to anticipate this and did not record the state > of my arrangements etc before I did the update. I was not using > Formaline. Yesterday, I attempted to recreate my build free from warnings > by regressing my checkouts of arrangements and the Flesh. I had no luck. > I don't understand. I have asked our sysadmin to retrieve backups of the > directories involved. > > Now, in LAM runs, I have always seen uninitialized memory warnings from > the LAM library. Also, even in a very simple PUGH WaveToy, I get some use of > uninitialized memory in the evolution loop... > > But I'm very suspicious about these Parameter.c warnings right at the > beginning of Carpet runs. > > Thanks for your time. > > -- > Steve White : Programmer > Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut > Am M?hlenberg 1, D-14476 Golm, Germany +49-331-567-7625 > ==11345== Conditional jump or move depends on uninitialised value(s) > ==11345== at 0x1BEDD90D: re_compile_internal (in /lib/libc-2.3.6.so) > ==11345== by 0x1BEDECA5: regcomp (in /lib/libc-2.3.6.so) > ==11345== by 0x805C921: CCTK_RegexMatch (Misc.c:1162) > ==11345== by 0x8050125: ParameterSetString (Parameters.c:2092) > ==11345== by 0x804FDB7: ParameterSetSimple (Parameters.c:1998) > ==11345== by 0x804E027: CCTKi_ParameterCreate (Parameters.c:351) > ==11345== by 0x8075BEB: CCTKi_BindingsCreateCarpetParameters (Carpet_Parameters.c:172) > ==11345== by 0x8074D6D: CCTKi_BindingsParametersInitialise (BindingsParameters.c:39) > ==11345== by 0x8055399: CCTKi_InitialiseSubsystemDefaults (Subsystems.c:51) > ==11345== by 0x804D961: CCTKi_InitialiseCactus (InitialiseCactus.c:91) > ==11345== by 0x804D89C: main (flesh.cc:64) > -- Steve White : Programmer Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut Am M?hlenberg 1, D-14476 Golm, Germany +49-331-567-7625 -------------- next part -------------- #include #include #include int CCTK_RegexMatch(const char *string, const char *pattern, const int nmatch, regmatch_t *pmatch) { int status = 0; regex_t re; if (regcomp(&re, pattern, REG_EXTENDED) == 0) { printf( "%s, '%s'\n", "doing regexec", string ); status = regexec(&re, string, (size_t)nmatch, pmatch, 0); regfree(&re); } else return 1; return status; } int Util_IntInRange( int inval, const char * range) { regmatch_t pmatch[6]; return CCTK_RegexMatch(range, "(\\[|\\()?([^]):]*):?([^]):]*)?:?([^]):]*)?(\\]|\\))?", 6, pmatch) != 0; } int main() { char fakerange[10]; fakerange[0] = '0'; fakerange[1] = ':'; fakerange[2] = '5'; fakerange[3] = '\0'; /* delete this to cause memory error*/ fakerange[4] = '\0'; if( Util_IntInRange( 5, fakerange) ) printf( "%s", "yes!\n" ); else printf( "%s", "no.\n" ); return 0; } From hinder at gravity.psu.edu Tue Nov 14 10:05:30 2006 From: hinder at gravity.psu.edu (Ian Hinder) Date: Tue, 14 Nov 2006 11:05:30 -0500 Subject: [Developers] Valgrind warnings In-Reply-To: <20061114133247.GC5943@sshserv.aei.mpg.de> References: <20061112170943.GA31716@sshserv.aei.mpg.de> <20061114133247.GC5943@sshserv.aei.mpg.de> Message-ID: <4559E94A.8020500@gravity.psu.edu> Steve White wrote: > Hi again, > > I spoke with Erik yesterday concerning Valgrind in Cactus. He commented > that Valgrind didn't understand some compiler optimizations. As > obvious as that is, I don't remember it having occurred to me. > > But it doesn't seem to be the case here that an optimization is > triggering the Valgrind warnings. > > First, I have a small test program (attached) that calls system routines > similar to those in Cactus about which Valgrind is complaining. By > commenting out a line, you can trigger a similar complaint. > > Valgrind produces the same results regardless of whether the program > is compiled with the Intel flags > -O3 -ip > > Also, I have been compiling all these Cactus runs with OPTIMISE=no. I have a vague memory that saying OPTIMISE=no just does not add any optimization options to the command line, meaning that the default optimization (usually -O2) is used. Is that correct, or am I misremembering? > > So I don't think that optimization is triggering the Valgrind errors. > > Cheers! > > > On 12.11.06, Steve White wrote: >> Hi, >> >> I'm trying to debug a strange problem in this JobChaining project. I'll >> describe the problem and history. Perhaps you could provide some advice, >> or try to run valgrind on your favourite code, or relate an experience. >> >> I get a reproducible effect when running a big par file of Luca's. >> The processes just run into the weeds, usually appearing to hang in >> library routines. Forced core dumps don't show a complete backtrace. >> It's stack damage. >> >> So I ran the thing in Valgrind. I see great numbers of warnings about >> uninitialized memory being used, which at least seem to start in the >> Parameters.c file. Now, that code is generally objectionable, and features >> many potential bugs, but all attempts to locate the source of this >> warning have so far failed. >> >> My best lead on the problem at hand is this warning. >> >> Beside this, I have tried many dozens of kinds of expreriments, but haven't >> been able to make a lot of sense of what I'm seeing. >> >> Now, a curiosity: A build of a JobChain WaveToy with Carpet, with the same >> Cactus configuration, showed no such errors when run under Valgrind. >> >> However, I had not updated my arrangements generally in some time, only >> Carpet-dev and JobChaining were quite up-to-date; the others were some >> month or two old. When I then updated everything, the Valgrind errors >> appeared in my Wavetoy *too*. The first reports appear when Carpet is >> creating certain parameters (example attached). >> >> Note that the Valgrind complaints may reflect problems in the C >> libraries. >> >> Unfortunately, I failed to anticipate this and did not record the state >> of my arrangements etc before I did the update. I was not using >> Formaline. Yesterday, I attempted to recreate my build free from warnings >> by regressing my checkouts of arrangements and the Flesh. I had no luck. >> I don't understand. I have asked our sysadmin to retrieve backups of the >> directories involved. >> >> Now, in LAM runs, I have always seen uninitialized memory warnings from >> the LAM library. Also, even in a very simple PUGH WaveToy, I get some use of >> uninitialized memory in the evolution loop... >> >> But I'm very suspicious about these Parameter.c warnings right at the >> beginning of Carpet runs. >> >> Thanks for your time. >> >> -- >> Steve White : Programmer >> Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut >> Am M?hlenberg 1, D-14476 Golm, Germany +49-331-567-7625 > >> ==11345== Conditional jump or move depends on uninitialised value(s) >> ==11345== at 0x1BEDD90D: re_compile_internal (in /lib/libc-2.3.6.so) >> ==11345== by 0x1BEDECA5: regcomp (in /lib/libc-2.3.6.so) >> ==11345== by 0x805C921: CCTK_RegexMatch (Misc.c:1162) >> ==11345== by 0x8050125: ParameterSetString (Parameters.c:2092) >> ==11345== by 0x804FDB7: ParameterSetSimple (Parameters.c:1998) >> ==11345== by 0x804E027: CCTKi_ParameterCreate (Parameters.c:351) >> ==11345== by 0x8075BEB: CCTKi_BindingsCreateCarpetParameters (Carpet_Parameters.c:172) >> ==11345== by 0x8074D6D: CCTKi_BindingsParametersInitialise (BindingsParameters.c:39) >> ==11345== by 0x8055399: CCTKi_InitialiseSubsystemDefaults (Subsystems.c:51) >> ==11345== by 0x804D961: CCTKi_InitialiseCactus (InitialiseCactus.c:91) >> ==11345== by 0x804D89C: main (flesh.cc:64) >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers -- Ian Hinder hinder at gravity.psu.edu http://www.gravity.psu.edu/~hinder From goodale at cct.lsu.edu Tue Nov 14 10:12:36 2006 From: goodale at cct.lsu.edu (Tom Goodale) Date: Tue, 14 Nov 2006 16:12:36 +0000 (GMT) Subject: [Developers] Valgrind warnings In-Reply-To: <4559E94A.8020500@gravity.psu.edu> References: <20061112170943.GA31716@sshserv.aei.mpg.de> <20061114133247.GC5943@sshserv.aei.mpg.de> <4559E94A.8020500@gravity.psu.edu> Message-ID: On Tue, 14 Nov 2006, Ian Hinder wrote: > Steve White wrote: >> Valgrind produces the same results regardless of whether the program >> is compiled with the Intel flags >> -O3 -ip >> >> Also, I have been compiling all these Cactus runs with OPTIMISE=no. > > I have a vague memory that saying OPTIMISE=no just does not add any > optimization options to the command line, meaning that the default > optimization (usually -O2) is used. Is that correct, or am I > misremembering? That certainly used to be the case, but has been changed for several architectures, although not all yet. For linux -O0 is added. Cheers, Tom From steve.white at aei.mpg.de Tue Nov 14 11:29:52 2006 From: steve.white at aei.mpg.de (Steve White) Date: Tue, 14 Nov 2006 18:29:52 +0100 Subject: [Developers] Valgrind warnings In-Reply-To: <4559E94A.8020500@gravity.psu.edu> References: <20061112170943.GA31716@sshserv.aei.mpg.de> <20061114133247.GC5943@sshserv.aei.mpg.de> <4559E94A.8020500@gravity.psu.edu> Message-ID: <20061114172952.GB6846@sshserv.aei.mpg.de> Ian, On 14.11.06, Ian Hinder wrote: > Steve White wrote: > > Hi again, > > > > I spoke with Erik yesterday concerning Valgrind in Cactus. He commented > > that Valgrind didn't understand some compiler optimizations. As > > obvious as that is, I don't remember it having occurred to me. > > > > But it doesn't seem to be the case here that an optimization is > > triggering the Valgrind warnings. > > > > First, I have a small test program (attached) that calls system routines > > similar to those in Cactus about which Valgrind is complaining. By > > commenting out a line, you can trigger a similar complaint. > > > > Valgrind produces the same results regardless of whether the program > > is compiled with the Intel flags > > -O3 -ip > > > > Also, I have been compiling all these Cactus runs with OPTIMISE=no. > > I have a vague memory that saying OPTIMISE=no just does not add any > optimization options to the command line, meaning that the default > optimization (usually -O2) is used. Is that correct, or am I > misremembering? > You're right. (This has been brought up before, and called a bug, but nobody has done anything about it.) I suppose it makes sense to try compiling it with optimizations explicitly turned off, but based on the results of my small example, this is unlikely to change the outcome. Thanks! > > > > > So I don't think that optimization is triggering the Valgrind errors. > > > > Cheers! > > > > > > On 12.11.06, Steve White wrote: > >> Hi, > >> > >> I'm trying to debug a strange problem in this JobChaining project. I'll > >> describe the problem and history. Perhaps you could provide some advice, > >> or try to run valgrind on your favourite code, or relate an experience. > >> > >> I get a reproducible effect when running a big par file of Luca's. > >> The processes just run into the weeds, usually appearing to hang in > >> library routines. Forced core dumps don't show a complete backtrace. > >> It's stack damage. > >> > >> So I ran the thing in Valgrind. I see great numbers of warnings about > >> uninitialized memory being used, which at least seem to start in the > >> Parameters.c file. Now, that code is generally objectionable, and features > >> many potential bugs, but all attempts to locate the source of this > >> warning have so far failed. > >> > >> My best lead on the problem at hand is this warning. > >> > >> Beside this, I have tried many dozens of kinds of expreriments, but haven't > >> been able to make a lot of sense of what I'm seeing. > >> > >> Now, a curiosity: A build of a JobChain WaveToy with Carpet, with the same > >> Cactus configuration, showed no such errors when run under Valgrind. > >> > >> However, I had not updated my arrangements generally in some time, only > >> Carpet-dev and JobChaining were quite up-to-date; the others were some > >> month or two old. When I then updated everything, the Valgrind errors > >> appeared in my Wavetoy *too*. The first reports appear when Carpet is > >> creating certain parameters (example attached). > >> > >> Note that the Valgrind complaints may reflect problems in the C > >> libraries. > >> > >> Unfortunately, I failed to anticipate this and did not record the state > >> of my arrangements etc before I did the update. I was not using > >> Formaline. Yesterday, I attempted to recreate my build free from warnings > >> by regressing my checkouts of arrangements and the Flesh. I had no luck. > >> I don't understand. I have asked our sysadmin to retrieve backups of the > >> directories involved. > >> > >> Now, in LAM runs, I have always seen uninitialized memory warnings from > >> the LAM library. Also, even in a very simple PUGH WaveToy, I get some use of > >> uninitialized memory in the evolution loop... > >> > >> But I'm very suspicious about these Parameter.c warnings right at the > >> beginning of Carpet runs. > >> > >> Thanks for your time. > >> > >> -- > >> Steve White : Programmer > >> Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut > >> Am M?hlenberg 1, D-14476 Golm, Germany +49-331-567-7625 > > > >> ==11345== Conditional jump or move depends on uninitialised value(s) > >> ==11345== at 0x1BEDD90D: re_compile_internal (in /lib/libc-2.3.6.so) > >> ==11345== by 0x1BEDECA5: regcomp (in /lib/libc-2.3.6.so) > >> ==11345== by 0x805C921: CCTK_RegexMatch (Misc.c:1162) > >> ==11345== by 0x8050125: ParameterSetString (Parameters.c:2092) > >> ==11345== by 0x804FDB7: ParameterSetSimple (Parameters.c:1998) > >> ==11345== by 0x804E027: CCTKi_ParameterCreate (Parameters.c:351) > >> ==11345== by 0x8075BEB: CCTKi_BindingsCreateCarpetParameters (Carpet_Parameters.c:172) > >> ==11345== by 0x8074D6D: CCTKi_BindingsParametersInitialise (BindingsParameters.c:39) > >> ==11345== by 0x8055399: CCTKi_InitialiseSubsystemDefaults (Subsystems.c:51) > >> ==11345== by 0x804D961: CCTKi_InitialiseCactus (InitialiseCactus.c:91) > >> ==11345== by 0x804D89C: main (flesh.cc:64) > >> > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Developers mailing list > > Developers at cactuscode.org > > http://www.cactuscode.org/mailman/listinfo/developers > > > -- > Ian Hinder > hinder at gravity.psu.edu > http://www.gravity.psu.edu/~hinder > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers > -- Steve White : Programmer Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut Am M?hlenberg 1, D-14476 Golm, Germany +49-331-567-7625 From bgiacoma at aei.mpg.de Tue Nov 14 11:36:45 2006 From: bgiacoma at aei.mpg.de (Bruno Giacomazzo) Date: Tue, 14 Nov 2006 18:36:45 +0100 (CET) Subject: [Developers] Recover SaveAndRestore variables with PUGH In-Reply-To: <3A48C795-7FDA-4B8A-A1F8-DC2DD1C7FA54@cct.lsu.edu> References: <4535DF7A.60605@aei.mpg.de> <1161245758.2332.8.camel@multiplicity> <453742C6.4070903@aei.mpg.de> <454A26AF.6040904@aei.mpg.de> <23991E8B-1920-49D3-A5BB-73703E03BF72@cct.lsu.edu> <4555CA9D.7030701@aei.mpg.de> <3A48C795-7FDA-4B8A-A1F8-DC2DD1C7FA54@cct.lsu.edu> Message-ID: Erik, On Mon, 13 Nov 2006, Erik Schnetter wrote: > If you have time to clean up the patch and add a test case, then this would > speed up things. Otherwise it'll probably happen not before next month. I can have a look at that. For the test case I think we can use the par file I sent when I reported the problem. Cheers, Bruno > On Nov 11, 2006, at 08:05:33, Luca Baiotti wrote: > >> Hi, >> >> it works, like Bruno said. Should it be committed? >> >> >> Ciao, >> >> Luca. >> >> >> bgiacoma wrote: >>> Hi, >>> >>> On Thu, 2 Nov 2006, Erik Schnetter wrote: >>> >>>> I have placed a correspondingly modified copy of ADMBase onto Peyote >>>> in ~eschnett/ADMBase.tar.gz. Couldyou test it? It has some other, >>>> unrelated changes as well; if it solves your problem, we can clean it >>>> up. >>> >>> >>> I tested it with the parameter file I sent some time ago and now it >>> seems to work. In the attached file test.tar you can find the stdout and >>> stderr of whisky+ADMBase (original version) and Whisky+ADMBase (erik >>> version). They are respectively named as tov_test_adm_part* and >>> tov_test_adm_erik_part* >>> >>> As you can see the info about the maximum of the density is correctly >>> computed in tov_test_adm_erik_part2 (compare with >>> tov_test_adm_erik_part1) which started from a checkpoint generated at >>> iteration 5 and which used the ADMBase version by Erik. In the original >>> version this does not happen as you can see from the same info between >>> file tov_test_adm_part1 and tov_test_adm_part2 (the latter having been >>> started from a checkpoint saved at iteration 5). >>> >>> Good job! >>> >>> Cheers, >>> Bruno >> >> _______________________________________________ >> Developers mailing list >> Developers at cactuscode.org >> http://www.cactuscode.org/mailman/listinfo/developers >> > > > -- Dr. Bruno Giacomazzo Max Planck Institute for Gravitational Physics Albert Einstein Institute Am M??hlenberg 1 D-14476 Potsdam Germany Tel. : +49 331 567 7643 Fax : +49 331 567 7649 email : bgiacoma at aei.mpg.de ------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ------------------------------------------------- From steve.white at aei.mpg.de Tue Nov 14 11:40:19 2006 From: steve.white at aei.mpg.de (Steve White) Date: Tue, 14 Nov 2006 18:40:19 +0100 Subject: [Developers] Valgrind warnings In-Reply-To: References: <20061112170943.GA31716@sshserv.aei.mpg.de> <20061114133247.GC5943@sshserv.aei.mpg.de> <4559E94A.8020500@gravity.psu.edu> Message-ID: <20061114174018.GC6846@sshserv.aei.mpg.de> Tom, Using the Intel 9.1 compilers on Peyote with a recent checkout with a config file containing WARN =yes DEBUG =yes OPTIMISE =no I see only the -M flag appearing on the compile lines (no -O flags at all). Cheers! On 14.11.06, Tom Goodale wrote: > > On Tue, 14 Nov 2006, Ian Hinder wrote: > > > Steve White wrote: > > >> Valgrind produces the same results regardless of whether the program > >> is compiled with the Intel flags > >> -O3 -ip > >> > >> Also, I have been compiling all these Cactus runs with OPTIMISE=no. > > > > I have a vague memory that saying OPTIMISE=no just does not add any > > optimization options to the command line, meaning that the default > > optimization (usually -O2) is used. Is that correct, or am I > > misremembering? > > That certainly used to be the case, but has been changed for several > architectures, although not all yet. For linux -O0 is added. > > Cheers, > > Tom > -- Steve White : Programmer Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut Am M?hlenberg 1, D-14476 Golm, Germany +49-331-567-7625 From schnetter at cct.lsu.edu Tue Nov 14 14:34:29 2006 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 14 Nov 2006 15:34:29 -0500 Subject: [Developers] Recover SaveAndRestore variables with PUGH In-Reply-To: References: <4535DF7A.60605@aei.mpg.de> <1161245758.2332.8.camel@multiplicity> <453742C6.4070903@aei.mpg.de> <454A26AF.6040904@aei.mpg.de> <23991E8B-1920-49D3-A5BB-73703E03BF72@cct.lsu.edu> <4555CA9D.7030701@aei.mpg.de> <3A48C795-7FDA-4B8A-A1F8-DC2DD1C7FA54@cct.lsu.edu> Message-ID: On Nov 14, 2006, at 12:36:45, Bruno Giacomazzo wrote: > Erik, > > On Mon, 13 Nov 2006, Erik Schnetter wrote: >> If you have time to clean up the patch and add a test case, then >> this would speed up things. Otherwise it'll probably happen not >> before next month. > > I can have a look at that. For the test case I think we can use > the par file I sent when I reported the problem. Bruno, I just updated the chapter on test suites in the users' guide. I have added a section about best practices for test suites. Have a look there before you prepare the test case. -erik -- Erik Schnetter My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20061114/bc250cdd/attachment.bin From jthorn at aei.mpg.de Wed Nov 15 02:04:48 2006 From: jthorn at aei.mpg.de (Jonathan Thornburg) Date: Wed, 15 Nov 2006 09:04:48 +0100 (CET) Subject: [Developers] [Flesh-cvs] DEVELOPMENT CVS "Cactus/doc/UsersGuide ThornWriters.tex" In-Reply-To: <20061114203423.2BEE68196@asylum.cct.lsu.edu> References: <20061114203423.2BEE68196@asylum.cct.lsu.edu> Message-ID: On Tue, 14 Nov 2006, Erik Schnetter wrote: > Update of /cactusdevcvs/Cactus/doc/UsersGuide > In directory asylum.cct.lsu.edu:/tmp/cvs-serv8750 > > Modified Files: > ThornWriters.tex > Log Message: > Describe best practices for writing test suites. Erik, thank you for documenting this. Documented "Best practices" are a ++good thing. ciao, -- -- Jonathan Thornburg Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, "Old Europe" http://www.aei.mpg.de/~jthorn/home.html "Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral." -- quote by Freire / poster by Oxfam From sebastiano.bernuzzi at gmail.com Thu Nov 16 05:47:54 2006 From: sebastiano.bernuzzi at gmail.com (sebastiano bernuzzi) Date: Thu, 16 Nov 2006 12:47:54 +0100 Subject: [Developers] carpet2 : recombine 1d, 2d data files In-Reply-To: <793f07c70611160345v4e8b9decr6d795cca025a5835@mail.gmail.com> References: <793f07c70611160345v4e8b9decr6d795cca025a5835@mail.gmail.com> Message-ID: <793f07c70611160347u27e2f657v862a879ef2705e35@mail.gmail.com> Hi I had data from a long carpet ( carpet 2 ) simulation with various checkpoints How can I put together 1d and 2d data files ? thanks -- Sebastiano Bernuzzi SKYPE: sebastiano.bernuzzi ------------------------------------------------------ www.fis.unipr.it/~bernuzzi www.mojoshouse.net ------------------------------------------------------ -- Sebastiano Bernuzzi SKYPE: sebastiano.bernuzzi ------------------------------------------------------ www.fis.unipr.it/~bernuzzi www.mojoshouse.net ------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.cactuscode.org/pipermail/developers/attachments/20061116/3d3881de/attachment.html From cott at aei.mpg.de Thu Nov 16 05:55:23 2006 From: cott at aei.mpg.de (Christian David Ott) Date: Thu, 16 Nov 2006 12:55:23 +0100 (CET) Subject: [Developers] carpet2 : recombine 1d, 2d data files In-Reply-To: <793f07c70611160347u27e2f657v862a879ef2705e35@mail.gmail.com> References: <793f07c70611160345v4e8b9decr6d795cca025a5835@mail.gmail.com> <793f07c70611160347u27e2f657v862a879ef2705e35@mail.gmail.com> Message-ID: Hi, On Thu, 16 Nov 2006, sebastiano bernuzzi wrote: > I had data from a long carpet ( carpet 2 ) simulation with various > checkpoints > How can I put together 1d and 2d data files ? since this is a question related to CarpetIOASCII, I suggest that we move this discussion to developers at lists.carpetcode.org. To answer your question: Since 1D and 2D files are currently just ASCII files, you can use 'cat file1 file2 > file3' to concatenate the files. - Christian From baiotti at aei.mpg.de Thu Nov 16 06:12:25 2006 From: baiotti at aei.mpg.de (Luca Baiotti) Date: Thu, 16 Nov 2006 13:12:25 +0100 Subject: [Developers] carpet2 : recombine 1d, 2d data files In-Reply-To: References: <793f07c70611160345v4e8b9decr6d795cca025a5835@mail.gmail.com> <793f07c70611160347u27e2f657v862a879ef2705e35@mail.gmail.com> Message-ID: <455C55A9.8030704@aei.mpg.de> Hi, Christian David Ott wrote: > Hi, > > On Thu, 16 Nov 2006, sebastiano bernuzzi wrote: > > >>I had data from a long carpet ( carpet 2 ) simulation with various >>checkpoints >>How can I put together 1d and 2d data files ? > > > since this is a question related to CarpetIOASCII, I suggest > that we move this discussion to developers at lists.carpetcode.org. > > To answer your question: Since 1D and 2D files are currently just > ASCII files, you can use 'cat file1 file2 > file3' to concatenate > the files. Thomas Radke has written very useful scripts that merge different ASCII files from the same simulation, also avoiding duplicate data. They are in CarpetIOASCII/src/util/mergeCarpetIOASCII.pl and CarpetIOScalar/src/util/mergeCarpetIOScalar.pl starting from the stable 3 version. Ciao, Luca. From tradke at aei.mpg.de Fri Nov 24 12:26:56 2006 From: tradke at aei.mpg.de (Thomas Radke) Date: Fri, 24 Nov 2006 19:26:56 +0100 Subject: [Developers] problem with PUGH's default topology setup ? Message-ID: <45673970.6000507@aei.mpg.de> Hi, I noticed when running the two CactusEinstein/AHFinder testsuites, runs on more than a single processor abort with the error message > WARNING level 0 in thorn PUGH processor 0 host peyoteb.aei.mpg.de > (line 158 of /tmp/peyoteb-2006-11-24_20-03-44/Cactus/configs/PublicThorns/build/PUGH/Topology.c): > ->WARNING level 0 in thorn PUGH processor 1 host peyoteb.aei.mpg.de > (line 158 of /tmp/peyoteb-2006-11-24_20-03-44/Cactus/configs/PublicThorns/build/PUGH/Topology.c): > -> Inconsistent PUGH topology In the parfiles no topology parameters are set, so PUGH should calculate a processor decomposition scheme using the default topology setup. Somehow this algorithm seems to fail. Has anyone else seen similar problems ? -- Cheers, Thomas. From hughwang at cct.lsu.edu Tue Nov 28 09:00:49 2006 From: hughwang at cct.lsu.edu (hughwang at cct.lsu.edu) Date: Tue, 28 Nov 2006 09:00:49 -0600 Subject: [Developers] failed taskfarm compilation Message-ID: <20061128090049.i67qdryh8ookscog@webmail.cct.lsu.edu> Hi, all, I am thinking to use taskfarm for some bioinformatic software. The compilation of taskfarm aborted with this message: " Running any thorn-privided configuration scripts... Checking consistency... TaskFarmInfoProvider SHARES from implementation ASCA - no such implementation Creating Thorn-Flesh bindings... Creating implementation bindings... Creating parameter bindings... CST error 2: -> Unknown parameter type '' for parameter 'tfmid' CST error 3: -> Unknown parameter type '' for parameter 'generation' Creating variable bindings... Creating schedule bindings... Creating function bindings... ------------------------------------------------------ There were 3 errors during execution of the CST These must be corrected before compilation can proceed ------------------------------------------------------ ------------------------------------------------------ Warnings were generated during execution of the CST ------------------------------------------------------ CST error 2: -> Unknown parameter type '' for parameter 'tfmid' CST error 3: -> Unknown parameter type '' for parameter 'generation' ------------------------------------------------------ gmake[1]: *** [/home/hughwang/cactustaskfarm/Cactus/configs/taskfarm/config-data /make.thornlist] Error 1 gmake: *** [taskfarm] Error 2 " Regards, Hugh From hughwang at cct.lsu.edu Tue Nov 28 09:06:33 2006 From: hughwang at cct.lsu.edu (hughwang at cct.lsu.edu) Date: Tue, 28 Nov 2006 09:06:33 -0600 Subject: [Developers] failed taskfarm compilation In-Reply-To: <20061128090049.i67qdryh8ookscog@webmail.cct.lsu.edu> References: <20061128090049.i67qdryh8ookscog@webmail.cct.lsu.edu> Message-ID: <20061128090633.ts076qkeocok04o0@webmail.cct.lsu.edu> Yes, I have tried both gmake and make. Hugh Quoting hughwang at cct.lsu.edu: > Hi, all, > I am thinking to use taskfarm for some bioinformatic software. > The compilation of taskfarm aborted with this message: > > > " > Running any thorn-privided configuration scripts... > Checking consistency... > TaskFarmInfoProvider SHARES from implementation ASCA - no such implementation > Creating Thorn-Flesh bindings... > Creating implementation bindings... > Creating parameter bindings... > > CST error 2: > -> Unknown parameter type '' for parameter 'tfmid' > CST error 3: > -> Unknown parameter type '' for parameter 'generation' > > Creating variable bindings... > Creating schedule bindings... > Creating function bindings... > ------------------------------------------------------ > There were 3 errors during execution of the CST > These must be corrected before compilation can proceed > ------------------------------------------------------ > ------------------------------------------------------ > Warnings were generated during execution of the CST > ------------------------------------------------------ > CST error 2: > -> Unknown parameter type '' for parameter 'tfmid' > CST error 3: > -> Unknown parameter type '' for parameter 'generation' > ------------------------------------------------------ > > gmake[1]: *** > [/home/hughwang/cactustaskfarm/Cactus/configs/taskfarm/config-data > /make.thornlist] Error 1 > gmake: *** [taskfarm] Error 2 > " > > > Regards, > > Hugh > > > > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers > > From goodale at cct.lsu.edu Tue Nov 28 09:13:17 2006 From: goodale at cct.lsu.edu (Tom Goodale) Date: Tue, 28 Nov 2006 15:13:17 +0000 (GMT) Subject: [Developers] failed taskfarm compilation In-Reply-To: <20061128090633.ts076qkeocok04o0@webmail.cct.lsu.edu> References: <20061128090049.i67qdryh8ookscog@webmail.cct.lsu.edu> <20061128090633.ts076qkeocok04o0@webmail.cct.lsu.edu> Message-ID: Hi Hugh, can you tell me which repository you got the taskfarm thorns from, and what thornlist you are using ? Cheers, Tom On Tue, 28 Nov 2006, hughwang at cct.lsu.edu wrote: > Yes, > I have tried both gmake and make. > > Hugh > > > Quoting hughwang at cct.lsu.edu: > >> Hi, all, >> I am thinking to use taskfarm for some bioinformatic software. >> The compilation of taskfarm aborted with this message: >> >> >> " >> Running any thorn-privided configuration scripts... >> Checking consistency... >> TaskFarmInfoProvider SHARES from implementation ASCA - no such implementation >> Creating Thorn-Flesh bindings... >> Creating implementation bindings... >> Creating parameter bindings... >> >> CST error 2: >> -> Unknown parameter type '' for parameter 'tfmid' >> CST error 3: >> -> Unknown parameter type '' for parameter 'generation' >> >> Creating variable bindings... >> Creating schedule bindings... >> Creating function bindings... >> ------------------------------------------------------ >> There were 3 errors during execution of the CST >> These must be corrected before compilation can proceed >> ------------------------------------------------------ >> ------------------------------------------------------ >> Warnings were generated during execution of the CST >> ------------------------------------------------------ >> CST error 2: >> -> Unknown parameter type '' for parameter 'tfmid' >> CST error 3: >> -> Unknown parameter type '' for parameter 'generation' >> ------------------------------------------------------ >> >> gmake[1]: *** >> [/home/hughwang/cactustaskfarm/Cactus/configs/taskfarm/config-data >> /make.thornlist] Error 1 >> gmake: *** [taskfarm] Error 2 >> " >> >> >> Regards, >> >> Hugh >> >> >> >> _______________________________________________ >> 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 > From yye00 at cct.lsu.edu Thu Nov 30 13:19:22 2006 From: yye00 at cct.lsu.edu (Yaakoub El Khamra) Date: Thu, 30 Nov 2006 13:19:22 -0600 Subject: [Developers] SPRNG Message-ID: <456F2EBA.3020600@cct.lsu.edu> Greetings As some of you are aware, we have a thorn in CCTDevelopment called SPRNG which provides a very basic interface to the SPRNG: Scalable Parallel Random Number Generator library. Yesterday we had the good fortune of having one of the developers here at CCT. Since this is a subject that interests a lot of users and developers, we have now have the SPRNG seminar up online at: http://www.cct.lsu.edu/~deilands/11-29-2006.zip To view this file you will need to obtain the AGVCR tool (Access Grid Video Cassette Recorder) available here: http://iri.informatics.indiana.edu/~dcpiper/agvcr/index.php Cheers Yaakoub