From maria at einstein.phyast.pitt.edu Tue May 15 13:08:59 2007 From: maria at einstein.phyast.pitt.edu (Maria Cristina Babiuc) Date: Tue, 15 May 2007 14:08:59 -0400 Subject: [Users] running Cactus on bigben Message-ID: <200705151408.59826.maria@einstein.phyast.pitt.edu> Hello, Could somebody please help me in running Cactus successfully on the PSC Cray XT3 machine bigben? The wavetoy runs OK, but with my arrangemnt I got the error: ----- DEBUG: PCB, CONTEXT, STACK TRACE --------------------- PROCESSOR [ 0] log_nid = 0 phys_nid = 0xe host_id = 2560 host_pid = 7607 group_id = 59479 num_procs = 4 rank = 0 local_pid = 2 base_node_index = 0 last_node_index = 1 text_base = 0x00000000200000 text_len = 0x00000001800000 data_base = 0x00000001a00000 data_len = 0x00000000a00000 stack_base = 0x0000007ec00000 stack_len = 0x00000001000000 heap_base = 0x00000002600000 heap_len = 0x00000039e00000 ss = 0x000000000000001f fs = 000000000000000000 gs = 0x0000000000000017 rip = 0x0000000001604e9e rdi = 0x000000007fbf8b1c rsi = 0x000000007fbf9598 rbp = 0x0000000021f9c130 rsp = 0x000000007fbf87a0 rbx = 0x000000007fbf8840 rdx = 0x0000000001c3c45c rcx = 0x0000000021f4aca0 rax = 0x0000000000000030 cs = 0x000000000000001f R8 = 0x000000007fbf8b18 R9 = 0x0000000001c3c460 R10 = 0x0000000021fed6d8 R11 = 0x0000000001604e9e R12 = 0x0000000021f60a00 R13 = 0x0000000000000028 R14 = 0x0000000000003348 R15 = 0x0000000000003348 rflg = 0x0000000000010202 prev_sp = 0x000000007fbf87a0 error_code = 6 SIGNAL #[11][Segmentation fault] fault_address = 0x0000000000000030 0x21f9c0b0 0x402aec1e8c8eb652 0x402c5f89b0f180f9 0x402dc5bda23734fa 0x402f1c85 040d0174 0x21f9c0d0 0x403030e1691e5f4f 0x4030c9badb49a4d9 0x403157dd998b6dd4 0x4031da69 4dc74767 0x21f9c0f0 0x4032508fecd49282 0x4032b996fbb2aeb9 0x403314d8b5dca4c4 0x403361c5 12ebc6b7 0x21f9c110 0x40339fe2a9ec52dc 0x4033cecf70fd4cf2 0x4033ee41580d1b29 0x4033fe06 bdbeacd5 0x21f9c130 0x3f7f942415330b74 0x3fb1bea7f2e4e25e 0x3fc8984781598471 0x3fd80755 84eb49c5 0x21f9c150 0x3fe3c75da2872962 0x3fed64e9446b6712 0x3ff4669044d5148b 0x3ffaf701 32b6d7c8 0x21f9c170 0x40012cb591c5c4c9 0x4005411333a490fb 0x4009b22925b2d905 0x400e78f4 b70d05c4 0x21f9c190 0x4011c6f5f7e5fcff 0x40147484bb919634 0x401740ec9e1cfdf0 0x401a27c2 e6e29375 0x21f9c1b0 0x401d247325a8b819 0x40201923368f7e0f 0x4021a63561e53b88 0x402336fd 5fd15b38 0x21f9c1d0 0x4024c902a02ea4ce 0x402659ca9e1ac486 0x4027e6dcc97081ed 0x40296dc6 6d2ba3f6 0x21f9c1f0 0x402aec1e8c8eb641 0x402c5f89b0f18106 0x402dc5bda2373504 0x402f1c85 040d0183 0x21f9c210 0x403030e1691e5f44 0x4030c9badb49a4e8 0x403157dd998b6ddf 0x4031da69 4dc74763 0x21f9c230 0x4032508fecd49285 0x4032b996fbb2aebf 0x403314d8b5dca4c7 0x403361c5 12ebc6b4 0x21f9c250 0x40339fe2a9ec52da 0x4033cecf70fd4cfd 0x4033ee41580d1b1f 0x4033fe06 bdbeaccb 0x21f9c270 0x 640 0x 21f99060 0x 0 0x 0 Stack Trace: ------------------------------ #0 0x0000000001604e9e in cctk_reduce_() #1 0x3fb1bea7f2e4e25e in cctk_reduce_() I would appreciate your help, Maria From schnetter at cct.lsu.edu Tue May 15 13:18:26 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 15 May 2007 13:18:26 -0500 Subject: [Users] running Cactus on bigben In-Reply-To: <200705151408.59826.maria@einstein.phyast.pitt.edu> References: <200705151408.59826.maria@einstein.phyast.pitt.edu> Message-ID: <03BBA387-AF8A-42D0-BDE7-FC5CD4866294@cct.lsu.edu> On May 15, 2007, at 13:08:59, Maria Cristina Babiuc wrote: > Could somebody please help me in running Cactus successfully on the > PSC Cray > XT3 machine bigben? > The wavetoy runs OK, but with my arrangemnt I got the error: > ----- DEBUG: PCB, CONTEXT, STACK TRACE --------------------- > SIGNAL #[11][Segmentation fault] fault_address = 0x0000000000000030 Not being an expert on Big Ben, I nevertheless wager a guess. A segmentation fault can be caused either by an error in your code, or by your simulation running out of memory. Try to estimate how much memory you need on every processor, and compare that to the available memory on each node. It may be necessary to use more processors in order to reduce the per-processor memory requirement. If you use PUGH, then the option PUGH::storage_verbose = yes can help you. If you use Carpet, then the option CarpetLib::print_memstats_every = 1 may help. -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/users/attachments/20070515/cd71deb8/attachment.bin From maria at einstein.phyast.pitt.edu Tue May 15 14:15:40 2007 From: maria at einstein.phyast.pitt.edu (Maria Cristina Babiuc) Date: Tue, 15 May 2007 15:15:40 -0400 Subject: [Users] running Cactus on bigben In-Reply-To: <03BBA387-AF8A-42D0-BDE7-FC5CD4866294@cct.lsu.edu> References: <200705151408.59826.maria@einstein.phyast.pitt.edu> <03BBA387-AF8A-42D0-BDE7-FC5CD4866294@cct.lsu.edu> Message-ID: <200705151515.40423.maria@einstein.phyast.pitt.edu> Hello, Erik, thank you for your input. The arrangement runs fine on my desktop computer, so I'm surprised it could run out of memory on a supercomputer. I'm using 4 processors, on two nodes, and each compute node has 2 Gbytes of memory. I tried the option PUGH::storage_verbose = yes, but I need some help in how to interpret the output. I am getting a very long list in which the message is: INFO (PUGH): Switched memory off for variable 'variable_name' [GV TLs: -11782 Total Size: 430.99 MB] Thanks, Maria On Tuesday 15 May 2007 14:18, Erik Schnetter wrote: > On May 15, 2007, at 13:08:59, Maria Cristina Babiuc wrote: > > Could somebody please help me in running Cactus successfully on the > > PSC Cray > > XT3 machine bigben? > > The wavetoy runs OK, but with my arrangemnt I got the error: > > ----- DEBUG: PCB, CONTEXT, STACK TRACE --------------------- > > > > SIGNAL #[11][Segmentation fault] fault_address = 0x0000000000000030 > > Not being an expert on Big Ben, I nevertheless wager a guess. A > segmentation fault can be caused either by an error in your code, or > by your simulation running out of memory. Try to estimate how much > memory you need on every processor, and compare that to the available > memory on each node. It may be necessary to use more processors in > order to reduce the per-processor memory requirement. > > If you use PUGH, then the option PUGH::storage_verbose = yes can help > you. If you use Carpet, then the option > CarpetLib::print_memstats_every = 1 may help. > > -erik From schnetter at cct.lsu.edu Tue May 15 14:39:34 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 15 May 2007 14:39:34 -0500 Subject: [Users] running Cactus on bigben In-Reply-To: <200705151515.40423.maria@einstein.phyast.pitt.edu> References: <200705151408.59826.maria@einstein.phyast.pitt.edu> <03BBA387-AF8A-42D0-BDE7-FC5CD4866294@cct.lsu.edu> <200705151515.40423.maria@einstein.phyast.pitt.edu> Message-ID: <9A7957A6-72FE-448D-8BC7-71B5CEFA7593@cct.lsu.edu> On May 15, 2007, at 14:15:40, Maria Cristina Babiuc wrote: > Hello, > > Erik, thank you for your input. > The arrangement runs fine on my desktop computer, so I'm surprised > it could > run out of memory on a supercomputer. I'm using 4 processors, on > two nodes, > and each compute node has 2 Gbytes of memory. Some modern workstations have more memory than you have per processor on a supercomputer. > I tried the option PUGH::storage_verbose = yes, but I need some > help in how to > interpret the output. I am getting a very long list in which the > message is: > INFO (PUGH): Switched memory off for variable 'variable_name' [GV > TLs: -11782 > Total Size: 430.99 MB] This message means (a) there is an error in PUGH, because it thinks that the number of active time levels in negative, and (b) that this particular processor (probably processor 0) has 430 MB allocated, which would fit onto the node. I assume that the number 430.99 is the last number that appears before the segmentation fault? I just see the following lines in your output: > Stack Trace: ------------------------------ > #0 0x0000000001604e9e in cctk_reduce_() > #1 0x3fb1bea7f2e4e25e in cctk_reduce_() Can you should rebuild your application without optimisation and with debug information included? This would give you more information from the stack backtrace you sent. -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: reduce1.c Type: application/octet-stream Size: 1553 bytes Desc: not available Url : http://www.cactuscode.org/pipermail/users/attachments/20070515/446e62c4/attachment-0001.obj -------------- 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/users/attachments/20070515/446e62c4/attachment-0001.bin From tradke at aei.mpg.de Wed May 16 03:41:18 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Wed, 16 May 2007 10:41:18 +0200 Subject: [Users] running Cactus on bigben In-Reply-To: <9A7957A6-72FE-448D-8BC7-71B5CEFA7593@cct.lsu.edu> References: <200705151408.59826.maria@einstein.phyast.pitt.edu> <03BBA387-AF8A-42D0-BDE7-FC5CD4866294@cct.lsu.edu> <200705151515.40423.maria@einstein.phyast.pitt.edu> <9A7957A6-72FE-448D-8BC7-71B5CEFA7593@cct.lsu.edu> Message-ID: <464AC3AE.20909@aei.mpg.de> Erik Schnetter wrote: > Can you should rebuild your application without optimisation and with > debug information included? This would give you more information from > the stack backtrace you sent. Did you try a PUGH build without MPI, does it run on a single processor ? -- Cheers, Thomas. From schnetter at cct.lsu.edu Wed May 16 15:31:31 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Wed, 16 May 2007 15:31:31 -0500 Subject: [Users] Porting problem on IBM ppc In-Reply-To: References: <5D481E3E-A547-4ACB-B1E0-A8638FAC7D91@cct.lsu.edu> <71C472F3-605E-4BC9-9717-BC67CAA4AC91@cct.lsu.edu> <937A25CB-55A2-4F83-9BC0-A0B0AC1AA0FA@cct.lsu.edu> Message-ID: <8D44A7A8-6E96-470A-9E4C-1D8C2AC92F71@cct.lsu.edu> Hee Il, your file contains preprocessed C source code. It should instead contain makefile statements declaring dependencies between source files. This is probably caused by an error when you configured Cactus; either the automatic configuration failed, or you passed wrong options. Can you send me the options that you pass while configuring, as well as tell me which compiler you use? (I'm sorry if I asked the same earlier, but it's been a while.) -erik On Mar 14, 2007, at 00:40:56, Hee Il Kim wrote: > Thanks. I attached the file. > > Hee Il > > 2007/3/14, Erik Schnetter : On Mar 14, 2007, > at 00:22:15, Hee Il Kim wrote: > > > Sorry Erik, > > > > I didn't know that option should be given in comand line. I > > attached the log files at configuration and building stages. > > I see. Yes, the option SILENT=no has no effect when you specify it > when you configure. That's arguably confusing in Cactus. > > I think the auto-generated file Domain.c.d is not correct. Can you > send that file? It should be just a few lines long, and it should > contain makefile rules. > > -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. > > > > > _______________________________________________ > Users mailing list > Users at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > Users at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/users -- 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/users/attachments/20070516/dd4e0dde/attachment.bin From tradke at aei.mpg.de Thu May 17 10:06:29 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Thu, 17 May 2007 17:06:29 +0200 Subject: [Users] release of portal version 1.1 Message-ID: <464C6F75.70609@aei.mpg.de> Hi, today I have upgraded both the Cactus User Portal and the NumRel portal https://portal.cactuscode.org https://portal.aei.mpg.de to version 1.1. Two improvements should be pointed out: * Metadata queries in the Cactus integration test results have been optimised so that the response time is now in the order of a few seconds. * The amount of integration test results stored is not limited anymore to the most recent 30 days per machine. All integration test results from December 2006 on can now be searched. As you can see in the testsuites summary for each integration test, the ratio of passed/failed testsuites has quite improved over time: while it was 50/50 back in December, it is now more like 70/30 for the 'PublicThorns' configuration. Let's keep working in this direction ! -- Cheers, Thomas. From schnetter at cct.lsu.edu Wed May 30 20:58:46 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Wed, 30 May 2007 21:58:46 -0400 Subject: [Users] ADMConstraints Message-ID: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> While calculating the constraints with ADMConstraints in the presence of mesh refinement works fine, there was a problem with calculating norms of the constraints, which may require time interpolation. In order to do this correctly, it is necessary to keep several time levels of the constraints, and to re-calculate the constraints after changing the grid hierarchy. If this is not done, then the values of the constraints at each output grid point are correct, but norms of the constraints may not be. I updated ADMConstraints so that it supports this behaviour. In order to remain backward compatible, this behaviour cannot be the default. Obtaining correct norms for the constraints requires setting the parameters ADMConstraints::constraints_persist = yes ADMConstraints::constraints_timelevels = 3 where the number 3 depend on the time interpolation order; for linear time interpolation, you only need 2 time levels. On the other hand, if you want to save space and time, and if you do not need the norms of the constraints, then you should set the parameter ADMConstraints::constraints_prolongation_type = "none" -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/users/attachments/20070530/1e0181ed/attachment.bin From baiotti at aei.mpg.de Thu May 31 03:40:48 2007 From: baiotti at aei.mpg.de (Luca Baiotti) Date: Thu, 31 May 2007 10:40:48 +0200 (CEST) Subject: [Users] ADMConstraints In-Reply-To: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> References: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> Message-ID: <1624890.1180600848490.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de> Hi Erik, thanks for the update. Have you also thought of adding the flag chackpoint='no' to the ADMConstraints variables? Is there any counter-indication? Luca On May 31, 2007 03:58 AM, Erik Schnetter wrote: > While calculating the constraints with ADMConstraints in the presence > of mesh refinement works fine, there was a problem with calculating > norms of the constraints, which may require time interpolation. In > order to do this correctly, it is necessary to keep several time > levels of the constraints, and to re-calculate the constraints after > changing the grid hierarchy. If this is not done, then the values of > the constraints at each output grid point are correct, but norms of > the constraints may not be. > > I updated ADMConstraints so that it supports this behaviour. In > order to remain backward compatible, this behaviour cannot be the > default. Obtaining correct norms for the constraints requires > setting the parameters > > ADMConstraints::constraints_persist = yes > ADMConstraints::constraints_timelevels = 3 > > where the number 3 depend on the time interpolation order; for linear > time interpolation, you only need 2 time levels. > > On the other hand, if you want to save space and time, and if you do > not need the norms of the constraints, then you should set the > parameter > > ADMConstraints::constraints_prolongation_type = "none" > > -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. > > > From frank.loeffler at aei.mpg.de Thu May 31 03:46:28 2007 From: frank.loeffler at aei.mpg.de (Frank =?utf-8?Q?L=C3=B6ffler?=) Date: Thu, 31 May 2007 10:46:28 +0200 Subject: [Users] ADMConstraints In-Reply-To: <1624890.1180600848490.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de> References: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> <1624890.1180600848490.SLOX.WebMail.wwwrun@mailserv.aei.mpg.de> Message-ID: <20070531084628.GF12100@peterpan.ap.op.sissa.it> On Thu, May 31, 2007 at 10:40:48AM +0200, Luca Baiotti wrote: > thanks for the update. Have you also thought of adding the flag > chackpoint='no' to the ADMConstraints variables? Is there any > counter-indication? I think that the problem with this is that in the case when you want to have correct constraint norms you need the constraints on all time levels. When you recover, however I think only the current time level would be recalculated and you would end up with incorrect constraints. If you however do not need the correct norms and just one time level is enough, I would not see a problem with this, as they could easily be recomputed. Frank From szilagyi at aei.mpg.de Thu May 31 07:56:00 2007 From: szilagyi at aei.mpg.de (Bela Szilagyi) Date: Thu, 31 May 2007 14:56:00 +0200 Subject: [Users] ADMConstraints In-Reply-To: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> References: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> Message-ID: <200705311456.00561.szilagyi@aei.mpg.de> Should there be a similar patch applied to ADMAnalysis as well? On Thursday 31 May 2007 03:58:46 Erik Schnetter wrote: > While calculating the constraints with ADMConstraints in the presence > of mesh refinement works fine, there was a problem with calculating > norms of the constraints, which may require time interpolation. In > order to do this correctly, it is necessary to keep several time > levels of the constraints, and to re-calculate the constraints after > changing the grid hierarchy. If this is not done, then the values of > the constraints at each output grid point are correct, but norms of > the constraints may not be. > > I updated ADMConstraints so that it supports this behaviour. In > order to remain backward compatible, this behaviour cannot be the > default. Obtaining correct norms for the constraints requires > setting the parameters > > ADMConstraints::constraints_persist = yes > ADMConstraints::constraints_timelevels = 3 > > where the number 3 depend on the time interpolation order; for linear > time interpolation, you only need 2 time levels. > > On the other hand, if you want to save space and time, and if you do > not need the norms of the constraints, then you should set the parameter > > ADMConstraints::constraints_prolongation_type = "none" > > -erik Bela Szilagyi ---------------------------------------------------- Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut Tel: +49 331 567 7189 Fax: +49 331 567 7252 ---------------------------------------------------- From szilagyi at aei.mpg.de Thu May 31 09:45:31 2007 From: szilagyi at aei.mpg.de (Bela Szilagyi) Date: Thu, 31 May 2007 16:45:31 +0200 Subject: [Users] ADMConstraints In-Reply-To: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> References: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> Message-ID: <200705311645.31755.szilagyi@aei.mpg.de> As I see it in the current schedule.ccl, if ADMConstraints::constraints_persist == yes then the group ADMConstraintsGroup is scheduled at CCTK_EVOL. This leaves the constraints uninitialized. Can we, in addition, schedule the same group at CCTK_POSTINITIAL as well (for the case of persistent constraints)? we also schedule On Thursday 31 May 2007 03:58:46 Erik Schnetter wrote: > While calculating the constraints with ADMConstraints in the presence > of mesh refinement works fine, there was a problem with calculating > norms of the constraints, which may require time interpolation. In > order to do this correctly, it is necessary to keep several time > levels of the constraints, and to re-calculate the constraints after > changing the grid hierarchy. If this is not done, then the values of > the constraints at each output grid point are correct, but norms of > the constraints may not be. > > I updated ADMConstraints so that it supports this behaviour. In > order to remain backward compatible, this behaviour cannot be the > default. Obtaining correct norms for the constraints requires > setting the parameters > > ADMConstraints::constraints_persist = yes > ADMConstraints::constraints_timelevels = 3 > > where the number 3 depend on the time interpolation order; for linear > time interpolation, you only need 2 time levels. > > On the other hand, if you want to save space and time, and if you do > not need the norms of the constraints, then you should set the parameter > > ADMConstraints::constraints_prolongation_type = "none" > > -erik Bela Szilagyi ---------------------------------------------------- Max-Planck-Institut f?r Gravitationsphysik Albert-Einstein-Institut Tel: +49 331 567 7189 Fax: +49 331 567 7252 ---------------------------------------------------- From schnetter at cct.lsu.edu Thu May 31 10:36:28 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Thu, 31 May 2007 11:36:28 -0400 Subject: [Users] ADMConstraints In-Reply-To: <200705311456.00561.szilagyi@aei.mpg.de> References: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> <200705311456.00561.szilagyi@aei.mpg.de> Message-ID: Very likely yes. I wanted to wait for some feedback first to see whether the change to ADMConstraints satisfies people's needs. -erik On May 31, 2007, at 08:56:00, Bela Szilagyi wrote: > Should there be a similar patch applied to ADMAnalysis as well? > > > On Thursday 31 May 2007 03:58:46 Erik Schnetter wrote: >> While calculating the constraints with ADMConstraints in the presence >> of mesh refinement works fine, there was a problem with calculating >> norms of the constraints, which may require time interpolation. In >> order to do this correctly, it is necessary to keep several time >> levels of the constraints, and to re-calculate the constraints after >> changing the grid hierarchy. If this is not done, then the values of >> the constraints at each output grid point are correct, but norms of >> the constraints may not be. >> >> I updated ADMConstraints so that it supports this behaviour. In >> order to remain backward compatible, this behaviour cannot be the >> default. Obtaining correct norms for the constraints requires >> setting the parameters >> >> ADMConstraints::constraints_persist = yes >> ADMConstraints::constraints_timelevels = 3 >> >> where the number 3 depend on the time interpolation order; for linear >> time interpolation, you only need 2 time levels. >> >> On the other hand, if you want to save space and time, and if you do >> not need the norms of the constraints, then you should set the >> parameter >> >> ADMConstraints::constraints_prolongation_type = "none" >> >> -erik > > > > > > Bela Szilagyi > ---------------------------------------------------- > Max-Planck-Institut f?r Gravitationsphysik > Albert-Einstein-Institut > Tel: +49 331 567 7189 > Fax: +49 331 567 7252 > ---------------------------------------------------- > > > _______________________________________________ > Users mailing list > Users at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/users > -- 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/users/attachments/20070531/c3224708/attachment-0001.bin From schnetter at cct.lsu.edu Thu May 31 10:38:39 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Thu, 31 May 2007 11:38:39 -0400 Subject: [Users] ADMConstraints In-Reply-To: <200705311645.31755.szilagyi@aei.mpg.de> References: <5AFF5575-C165-45D8-82D5-B0B77A7DB2F1@cct.lsu.edu> <200705311645.31755.szilagyi@aei.mpg.de> Message-ID: <48E681AD-01E1-43CC-9F2B-0D3FE5B695A4@cct.lsu.edu> Yes, you are right. Thank you for the pointer. -erik On May 31, 2007, at 10:45:31, Bela Szilagyi wrote: > As I see it in the current schedule.ccl, if > > ADMConstraints::constraints_persist == yes > > then the group ADMConstraintsGroup is scheduled at CCTK_EVOL. > > This leaves the constraints uninitialized. Can we, in addition, > schedule the > same group at CCTK_POSTINITIAL as well (for the case of persistent > constraints)? > > > > we also schedule > > On Thursday 31 May 2007 03:58:46 Erik Schnetter wrote: >> While calculating the constraints with ADMConstraints in the presence >> of mesh refinement works fine, there was a problem with calculating >> norms of the constraints, which may require time interpolation. In >> order to do this correctly, it is necessary to keep several time >> levels of the constraints, and to re-calculate the constraints after >> changing the grid hierarchy. If this is not done, then the values of >> the constraints at each output grid point are correct, but norms of >> the constraints may not be. >> >> I updated ADMConstraints so that it supports this behaviour. In >> order to remain backward compatible, this behaviour cannot be the >> default. Obtaining correct norms for the constraints requires >> setting the parameters >> >> ADMConstraints::constraints_persist = yes >> ADMConstraints::constraints_timelevels = 3 >> >> where the number 3 depend on the time interpolation order; for linear >> time interpolation, you only need 2 time levels. >> >> On the other hand, if you want to save space and time, and if you do >> not need the norms of the constraints, then you should set the >> parameter >> >> ADMConstraints::constraints_prolongation_type = "none" >> >> -erik > > > > > > Bela Szilagyi > ---------------------------------------------------- > Max-Planck-Institut f?r Gravitationsphysik > Albert-Einstein-Institut > Tel: +49 331 567 7189 > Fax: +49 331 567 7252 > ---------------------------------------------------- > > > _______________________________________________ > Users mailing list > Users at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/users > -- 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/users/attachments/20070531/8a270e05/attachment.bin