From tradke at aei.mpg.de Mon Oct 1 11:05:11 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Mon, 01 Oct 2007 18:05:11 +0200 Subject: [Developers] Subversion support for 'make update' In-Reply-To: <20070928232615.GK7408@peterpan.ap.op.sissa.it> References: <20070928232615.GK7408@peterpan.ap.op.sissa.it> Message-ID: <47011AB7.4030804@aei.mpg.de> Frank Loeffler wrote: > Hi, > > this patch adds Subversion support for the Makefile in the following > way: > > make cvsupdate > will continue to do what it did in the past: updating Cactus > and thorns which are in CVS > > new: > make svnupdate > will update thorns which are in Subversion > > make update > will update thorns that are either in CVS or Subversion Hi Frank, I suggest to have only one command to update a given Cactus flesh checkout and accompanying arrangements, regardless of which repositories an arrangement originates from. The command should just do what's appropriate, eg. do a 'cvs/svn update' when a CVS/.svn subdirectory is found in the directory to be updated. I would then mark the old command 'cvsupdate' as depricated and redirect to 'update'. -- Cheers, Thomas. From tradke at aei.mpg.de Mon Oct 1 11:29:38 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Mon, 01 Oct 2007 18:29:38 +0200 Subject: [Developers] Subversion support for GetCactus In-Reply-To: <20070928214456.GJ7408@peterpan.ap.op.sissa.it> References: <20070928214456.GJ7408@peterpan.ap.op.sissa.it> Message-ID: <47012072.6090303@aei.mpg.de> Frank Loeffler wrote: > Hi, > > this patch adds Subversion support for GetCactus. I tried this for some > thorns using https as transport method, but it should work for anything > that Subversion can handle. > > I tried not to change anything related to CVS and to keep the structure > of the file as it was as much as possible. However, in this patch I > also fix a obvious typo ($foundit instead of elsewhere unused $foundif) > in the CVS code and I added a comment to what I think is another mistake > in the CVS code, but I did not change the actual code (search for > 'mistake' and feel free to fix it, which would be trivial). Hi Frank, I've looked through your patch, it looks fine to me. [I haven't tried it though.] I believe this other line that you've found to be mistaken in the current script but didn't fix is also a bug - the '!' negation seems wrong to me too. -- Cheers, Thomas. From tradke at aei.mpg.de Mon Oct 1 11:39:21 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Mon, 01 Oct 2007 18:39:21 +0200 Subject: [Developers] when to schedule steering methods Message-ID: <470122B9.60605@aei.mpg.de> Hi, Erik and I recently discussed the question of when would be the best time in the schedule tree to call a methods which allows users to interactively steer parameters (as are implemented in Cactus's webserver thorns CactusConnect/HTTPS and AstroGrid/HTTPS). Currently the webserver's worker routine is scheduled at POSTSTEP which means that a parameter value may change after the evolution but before the analysis. Erik argues that this is somewhat inconsistent; a parameter change should become active only after an iteration has finished completely. I "countered" by saying that users might want to change I/O parameters before analysis so that they can turn on/off certain analysis routines if they'd want to. What's other people's opinion on that ? Iff we decide to schedule steering methods at the very end of an iteration, we'd need to introduce a new schedule bin, such as STEER. -- Cheers, Thomas. From szilagyi at aei.mpg.de Mon Oct 1 12:54:00 2007 From: szilagyi at aei.mpg.de (Bela Szilagyi) Date: Mon, 1 Oct 2007 19:54:00 +0200 Subject: [Developers] when to schedule steering methods In-Reply-To: <470122B9.60605@aei.mpg.de> References: <470122B9.60605@aei.mpg.de> Message-ID: <200710011954.01037.szilagyi@aei.mpg.de> On Monday 01 October 2007 18:39:21 Thomas Radke wrote: > Iff we decide to schedule steering methods at the very end of an > iteration, we'd need to introduce a new schedule bin, such as STEER. I am in favor of the new bin. From jtao at cct.lsu.edu Mon Oct 1 13:39:26 2007 From: jtao at cct.lsu.edu (Jian Tao) Date: Mon, 01 Oct 2007 13:39:26 -0500 Subject: [Developers] when to schedule steering methods In-Reply-To: <470122B9.60605@aei.mpg.de> References: <470122B9.60605@aei.mpg.de> Message-ID: <47013EDE.2090900@cct.lsu.edu> Hi Thomas, I think re-parsing the parameter file after each iteration totally finishes is better. The parameters to turn on/off certain analysis routines will be effective in the next iteration, won't they ? However, if some analysis parameters are changed at POSTSTEP, the output will be inconsistent. Regards, Jian Thomas Radke wrote: > Hi, > > Erik and I recently discussed the question of when would be the best > time in the schedule tree to call a methods which allows users to > interactively steer parameters (as are implemented in Cactus's webserver > thorns CactusConnect/HTTPS and AstroGrid/HTTPS). > Currently the webserver's worker routine is scheduled at POSTSTEP which > means that a parameter value may change after the evolution but before > the analysis. Erik argues that this is somewhat inconsistent; a > parameter change should become active only after an iteration has > finished completely. I "countered" by saying that users might want to > change I/O parameters before analysis so that they can turn on/off > certain analysis routines if they'd want to. > > What's other people's opinion on that ? > > Iff we decide to schedule steering methods at the very end of an > iteration, we'd need to introduce a new schedule bin, such as STEER. > From frank.loeffler at aei.mpg.de Tue Oct 2 02:23:03 2007 From: frank.loeffler at aei.mpg.de (Frank Loeffler) Date: Tue, 2 Oct 2007 09:23:03 +0200 Subject: [Developers] when to schedule steering methods In-Reply-To: <470122B9.60605@aei.mpg.de> References: <470122B9.60605@aei.mpg.de> Message-ID: <20071002072303.GJ7408@peterpan.ap.op.sissa.it> On Mon, Oct 01, 2007 at 06:39:21PM +0200, Thomas Radke wrote: > What's other people's opinion on that ? I favour Eriks suggestion. Otherwise the ouput might be inconsistent. If this requires a new bin, well, why not. Frank From frank.loeffler at aei.mpg.de Tue Oct 2 02:25:20 2007 From: frank.loeffler at aei.mpg.de (Frank Loeffler) Date: Tue, 2 Oct 2007 09:25:20 +0200 Subject: [Developers] Subversion support for 'make update' In-Reply-To: <47011AB7.4030804@aei.mpg.de> References: <20070928232615.GK7408@peterpan.ap.op.sissa.it> <47011AB7.4030804@aei.mpg.de> Message-ID: <20071002072520.GK7408@peterpan.ap.op.sissa.it> On Mon, Oct 01, 2007 at 06:05:11PM +0200, Thomas Radke wrote: > I suggest to have only one command to update a given Cactus flesh > checkout and accompanying arrangements, regardless of which repositories > an arrangement originates from. The command should just do what's > appropriate, eg. do a 'cvs/svn update' when a CVS/.svn subdirectory is > found in the directory to be updated. If that is fine for everybody, I will prepare a patch for that. Frank From schnetter at cct.lsu.edu Tue Oct 2 09:27:40 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 2 Oct 2007 09:27:40 -0500 Subject: [Developers] when to schedule steering methods In-Reply-To: <470122B9.60605@aei.mpg.de> References: <470122B9.60605@aei.mpg.de> Message-ID: On Oct 1, 2007, at 11:39:21, Thomas Radke wrote: > Hi, > > Erik and I recently discussed the question of when would be the best > time in the schedule tree to call a methods which allows users to > interactively steer parameters (as are implemented in Cactus's > webserver > thorns CactusConnect/HTTPS and AstroGrid/HTTPS). > Currently the webserver's worker routine is scheduled at POSTSTEP > which > means that a parameter value may change after the evolution but before > the analysis. Erik argues that this is somewhat inconsistent; a > parameter change should become active only after an iteration has > finished completely. I "countered" by saying that users might want to > change I/O parameters before analysis so that they can turn on/off > certain analysis routines if they'd want to. > > What's other people's opinion on that ? > > Iff we decide to schedule steering methods at the very end of an > iteration, we'd need to introduce a new schedule bin, such as STEER. I introduced a registration mechanism for Carpet, where thorns can register functions which should be called before or after any of the scheduled functions. This will allow certain actions to be taken at a more fine-grained level, e.g. allowing to single-step through the RHS calculation instead of only through iterations. -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/20071002/9fd6904e/attachment.bin From schnetter at cct.lsu.edu Tue Oct 2 09:29:00 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 2 Oct 2007 09:29:00 -0500 Subject: [Developers] Subversion support for 'make update' In-Reply-To: <47011AB7.4030804@aei.mpg.de> References: <20070928232615.GK7408@peterpan.ap.op.sissa.it> <47011AB7.4030804@aei.mpg.de> Message-ID: <67A8F9CC-22D1-4385-9E59-D5EB8F34B7E1@cct.lsu.edu> On Oct 1, 2007, at 11:05:11, Thomas Radke wrote: > Frank Loeffler wrote: >> Hi, >> >> this patch adds Subversion support for the Makefile in the following >> way: >> >> make cvsupdate >> will continue to do what it did in the past: updating Cactus >> and thorns which are in CVS >> >> new: >> make svnupdate >> will update thorns which are in Subversion >> >> make update >> will update thorns that are either in CVS or Subversion > > Hi Frank, > > I suggest to have only one command to update a given Cactus flesh > checkout and accompanying arrangements, regardless of which > repositories > an arrangement originates from. The command should just do what's > appropriate, eg. do a 'cvs/svn update' when a CVS/.svn subdirectory is > found in the directory to be updated. > I would then mark the old command 'cvsupdate' as depricated and > redirect > to 'update'. I second this suggestion. Is there anybody who wants to implement that for darcs? I.e., call "darcs pull" if a directory _darcs is found. -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/20071002/15e1e1e5/attachment-0001.bin From schnetter at cct.lsu.edu Tue Oct 2 10:43:36 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 2 Oct 2007 10:43:36 -0500 Subject: [Developers] MPI_Finalize Message-ID: Currently, the flesh calls MPI_Init, but the driver is supposed to call MPI_Finalize. This happens presumably in the terminate bin as Driver_Terminate. According to the MPI standard, no externally visible operations may be performed after that, so that the driver may as well call exit at the same time. If not, strange errors can happen, as reported today elsewhere by Luca Baiotti. I propose to have the flesh call MPI_Finalize, to make things symmetric to MPI_Init. It would do so very late in CCTKi_ShutdownCactus after printing "Done.". This means that thorns could continue to schedule actions in the terminate bin after Driver_Terminate, and in the shutdown bin. I attach a diff. Of course, PUGH and Carpet would also need to be changed, so that they don't call MPI_Finalize any more. -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: shutdown.diff Type: application/octet-stream Size: 4209 bytes Desc: not available Url : http://www.cactuscode.org/pipermail/developers/attachments/20071002/57d584a8/attachment.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/developers/attachments/20071002/57d584a8/attachment.bin From werner at cct.lsu.edu Tue Oct 2 11:07:34 2007 From: werner at cct.lsu.edu (Werner Benger) Date: Tue, 02 Oct 2007 11:07:34 -0500 Subject: [Developers] when to schedule steering methods In-Reply-To: References: <470122B9.60605@aei.mpg.de> Message-ID: I tried to reply earlier, but that mail apparently got lost. Wanted to throw in here the memories of the prototype implementation of CactusNet/http , where the http service was separated into two scheduling parts: - one to accept the request and possibly switch on parameters, e.g. for activating an analysis routine - this section is running before the ANALYSIS routines are invoked - a second one to send back the results, which is similar to an output routine, but globally, I think that one was at POSTSTEP, similar to what the current CactusConnect/HTTPS is doing. The reason for this splitup was to enable temporary analysis routines, for instance one analysis per HTTP client request, instead of having this one permanently being invoked even if no one is watching the output. cheers, Werner On Tue, 02 Oct 2007 09:27:40 -0500, Erik Schnetter wrote: > On Oct 1, 2007, at 11:39:21, Thomas Radke wrote: > >> Hi, >> >> Erik and I recently discussed the question of when would be the best >> time in the schedule tree to call a methods which allows users to >> interactively steer parameters (as are implemented in Cactus's >> webserver >> thorns CactusConnect/HTTPS and AstroGrid/HTTPS). >> Currently the webserver's worker routine is scheduled at POSTSTEP >> which >> means that a parameter value may change after the evolution but before >> the analysis. Erik argues that this is somewhat inconsistent; a >> parameter change should become active only after an iteration has >> finished completely. I "countered" by saying that users might want to >> change I/O parameters before analysis so that they can turn on/off >> certain analysis routines if they'd want to. >> >> What's other people's opinion on that ? >> >> Iff we decide to schedule steering methods at the very end of an >> iteration, we'd need to introduce a new schedule bin, such as STEER. > > I introduced a registration mechanism for Carpet, where thorns can > register functions which should be called before or after any of the > scheduled functions. This will allow certain actions to be taken at > a more fine-grained level, e.g. allowing to single-step through the > RHS calculation instead of only through iterations. > > -erik > -- ___________________________________________________________________________ Dr. Werner Benger Visualization Research Laboratory for Creative Arts and Technology (LCAT) Center for Computation & Technology at Louisiana State University (CCT/LSU) 239 Johnston Hall, Baton Rouge, Louisiana 70803 Tel.: +1 225 578 4809 Fax.: +1 225 578-5362 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Here we have to deal with three dimensions, although we can only see two of them: height, direction and velocity." (Kiefer Sutherland as flight attendance in 'Collision Course: Panic in the Tower') From jtao at cct.lsu.edu Tue Oct 2 12:09:32 2007 From: jtao at cct.lsu.edu (Jian Tao) Date: Tue, 02 Oct 2007 12:09:32 -0500 Subject: [Developers] MPI_Finalize In-Reply-To: References: Message-ID: <47027B4C.9000009@cct.lsu.edu> Just curious, could MPI_Init be pushed in the driver instead ? Regards, Jian Erik Schnetter wrote: > Currently, the flesh calls MPI_Init, but the driver is supposed to call > MPI_Finalize. This happens presumably in the terminate bin as > Driver_Terminate. According to the MPI standard, no externally visible > operations may be performed after that, so that the driver may as well > call exit at the same time. If not, strange errors can happen, as > reported today elsewhere by Luca Baiotti. > > I propose to have the flesh call MPI_Finalize, to make things symmetric > to MPI_Init. It would do so very late in CCTKi_ShutdownCactus after > printing "Done.". This means that thorns could continue to schedule > actions in the terminate bin after Driver_Terminate, and in the shutdown > bin. > > I attach a diff. Of course, PUGH and Carpet would also need to be > changed, so that they don't call MPI_Finalize any more. > > -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. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers From schnetter at cct.lsu.edu Tue Oct 2 12:32:01 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 2 Oct 2007 12:32:01 -0500 Subject: [Developers] MPI_Finalize In-Reply-To: <47027B4C.9000009@cct.lsu.edu> References: <47027B4C.9000009@cct.lsu.edu> Message-ID: No, that's not possible. MPI_Init has to be called before command line arguments are passed, which has to happen before the parameter file is read, which has to happen before the driver is known. -erik On Oct 2, 2007, at 12:09:32, Jian Tao wrote: > Just curious, could MPI_Init be pushed in the driver instead ? > > Regards, > Jian > > Erik Schnetter wrote: >> Currently, the flesh calls MPI_Init, but the driver is supposed to >> call >> MPI_Finalize. This happens presumably in the terminate bin as >> Driver_Terminate. According to the MPI standard, no externally >> visible >> operations may be performed after that, so that the driver may as >> well >> call exit at the same time. If not, strange errors can happen, as >> reported today elsewhere by Luca Baiotti. >> >> I propose to have the flesh call MPI_Finalize, to make things >> symmetric >> to MPI_Init. It would do so very late in CCTKi_ShutdownCactus after >> printing "Done.". This means that thorns could continue to schedule >> actions in the terminate bin after Driver_Terminate, and in the >> shutdown >> bin. >> >> I attach a diff. Of course, PUGH and Carpet would also need to be >> changed, so that they don't call MPI_Finalize any more. >> >> -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. >> >> >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> 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 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/20071002/1be29e08/attachment.bin From jtao at cct.lsu.edu Tue Oct 2 13:42:15 2007 From: jtao at cct.lsu.edu (Jian Tao) Date: Tue, 02 Oct 2007 13:42:15 -0500 Subject: [Developers] MPI_Finalize In-Reply-To: References: <47027B4C.9000009@cct.lsu.edu> Message-ID: <47029107.3070900@cct.lsu.edu> Erik Schnetter wrote: > No, that's not possible. MPI_Init has to be called before command line > arguments are passed, which has to happen before the parameter file is > read, which has to happen before the driver is known. Well, the flesh is written in C++, and it is possible to pass null to MPI_Init in MPI_2 thanks to an alternative binding in C++. However, it is not the case for MPI_1. Regards, Jian > -erik > > On Oct 2, 2007, at 12:09:32, Jian Tao wrote: > >> Just curious, could MPI_Init be pushed in the driver instead ? >> >> Regards, >> Jian >> >> Erik Schnetter wrote: >>> Currently, the flesh calls MPI_Init, but the driver is supposed to call >>> MPI_Finalize. This happens presumably in the terminate bin as >>> Driver_Terminate. According to the MPI standard, no externally visible >>> operations may be performed after that, so that the driver may as well >>> call exit at the same time. If not, strange errors can happen, as >>> reported today elsewhere by Luca Baiotti. >>> >>> I propose to have the flesh call MPI_Finalize, to make things symmetric >>> to MPI_Init. It would do so very late in CCTKi_ShutdownCactus after >>> printing "Done.". This means that thorns could continue to schedule >>> actions in the terminate bin after Driver_Terminate, and in the shutdown >>> bin. >>> >>> I attach a diff. Of course, PUGH and Carpet would also need to be >>> changed, so that they don't call MPI_Finalize any more. >>> >>> -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. >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 > > 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 tradke at aei.mpg.de Wed Oct 3 07:58:37 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Wed, 03 Oct 2007 14:58:37 +0200 Subject: [Developers] MPI_Finalize In-Reply-To: References: Message-ID: <470391FD.9030309@aei.mpg.de> Erik Schnetter wrote: > Currently, the flesh calls MPI_Init, but the driver is supposed to call > MPI_Finalize. This happens presumably in the terminate bin as > Driver_Terminate. According to the MPI standard, no externally visible > operations may be performed after that, so that the driver may as well > call exit at the same time. If not, strange errors can happen, as > reported today elsewhere by Luca Baiotti. > > I propose to have the flesh call MPI_Finalize, to make things symmetric > to MPI_Init. It would do so very late in CCTKi_ShutdownCactus after > printing "Done.". This means that thorns could continue to schedule > actions in the terminate bin after Driver_Terminate, and in the > shutdown bin. > > I attach a diff. Of course, PUGH and Carpet would also need to be > changed, so that they don't call MPI_Finalize any more. Hi Erik, is the Cactus::process_termination parameter logic necessary ? When would one want Cactus to terminate non-regularly ? -- Cheers, Thomas. From schnetter at cct.lsu.edu Wed Oct 3 08:26:26 2007 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Wed, 3 Oct 2007 08:26:26 -0500 Subject: [Developers] MPI_Finalize In-Reply-To: <470391FD.9030309@aei.mpg.de> References: <470391FD.9030309@aei.mpg.de> Message-ID: On Oct 3, 2007, at 07:58:37, Thomas Radke wrote: > Erik Schnetter wrote: >> Currently, the flesh calls MPI_Init, but the driver is supposed >> to call >> MPI_Finalize. This happens presumably in the terminate bin as >> Driver_Terminate. According to the MPI standard, no externally >> visible >> operations may be performed after that, so that the driver may as >> well >> call exit at the same time. If not, strange errors can happen, as >> reported today elsewhere by Luca Baiotti. >> >> I propose to have the flesh call MPI_Finalize, to make things >> symmetric >> to MPI_Init. It would do so very late in CCTKi_ShutdownCactus after >> printing "Done.". This means that thorns could continue to schedule >> actions in the terminate bin after Driver_Terminate, and in the >> shutdown bin. >> >> I attach a diff. Of course, PUGH and Carpet would also need to be >> changed, so that they don't call MPI_Finalize any more. > > Hi Erik, > > is the Cactus::process_termination parameter logic necessary ? When > would one want Cactus to terminate non-regularly ? This logic is not necessary in order to move MPI_Finalize to the flesh. It is mostly for debugging. I've had cases where calling MPI_Finalize would take a long time, whereas just exiting makes the queuing system reclaim the nodes much faster. I assume that this was due to an error in the MPI installation. I don't remember what machine this was. -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/20071003/0fd4e594/attachment-0001.bin From tradke at aei.mpg.de Thu Oct 4 03:16:00 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Thu, 04 Oct 2007 10:16:00 +0200 Subject: [Developers] Infrastructure for initial data setup In-Reply-To: <468E6451.5050805@aei.mpg.de> References: <106FBFC4-A024-40F5-8BF8-C0B70083FCD3@cct.lsu.edu> <468E6451.5050805@aei.mpg.de> Message-ID: <4704A140.50407@aei.mpg.de> Hi Erik, I also support your suggestion to add such an ID infrastructure thorn. Looking through the attached source code, I have two comments (only about minor things): 1) The possible values for the keyword parameter InitBase::initial_data_setup_method don't need the word 'init' again. I also suggest to use spaces rather than underscores as a delimiter (ie. "some levels" instead of "some_levels"). 2) Remove the empty thorn subdirectories 'par/' and 'test/'. -- Cheers, Thomas. Luca Baiotti wrote: > Hi, > > your proposal seems a good idea to me. > > Luca. > > > Erik Schnetter wrote: > >>There is currently no infrastructure in Cactus which helps decide how to >>set up initial data. With mesh refinement, there are several >>incompatible ways in which initial data thorns can set up initial data. >>Depending on this, evolution thorns may have to adapt, or mesh >>refinement drivers may schedule evolution differently. >> >>This lack of infrastructure leads to problems, since initial data >>thorns, evolution methods, and the Carpet mesh refinement driver are not >>well coordinated. The user who writes parameter files has to know the >>behaviour of each of these, and then choose parameters so that these >>pieces work together correctly. There is no entity in Cactus which >>knows how initial data should be set up, and which could provide error >>checking. This leads to inconsistencies which are difficult to detect. >> >>I suggest to create a new thorn CactusBase/InitBase. It would contain >>the following README: >> >>---------------------------------------- >>Specify how initial data are to be set up. There are three >>possibilities: >> >>1. The initial data thorn sets up data on one time level, while other >> time levels are scratch space. The time evolution method must >> start up from a single time level. (This is the default.) >> >>2. The initial data thorn sets up data on exactly one time level, and >> is called once for each active time level. (This means that the >> initial data thorn can only access the current time level.) >> >>3. The initial data thorn sets up data on all active time levels. >> (This makes it necessary that the initial data thorn checks the >> number of active time levels.) >>---------------------------------------- >> >>Apart from this README, thorn InitBase would contain one restricted >>parameter "initial_data_setup_method" which allows users to choose the >>desired behaviour in the parameter file. All initial data thorns, >>evolution methods, and drivers then have to check the value of this >>parameter, and either adapt their behaviour or signal an error. >> >>-erik > > > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers > > From tradke at aei.mpg.de Wed Oct 3 15:04:37 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Wed, 03 Oct 2007 22:04:37 +0200 Subject: [Developers] when to schedule steering methods In-Reply-To: References: <470122B9.60605@aei.mpg.de> Message-ID: <4703F5D5.6040300@aei.mpg.de> Werner Benger wrote: > I tried to reply earlier, but that mail apparently got lost. Wanted to throw in here > the memories of the prototype implementation of CactusNet/http , where the > http service was separated into two scheduling parts: > > - one to accept the request and possibly switch on parameters, e.g. for > activating an analysis routine - this section is running before the ANALYSIS > routines are invoked > > - a second one to send back the results, which is similar to an output routine, > but globally, I think that one was at POSTSTEP, similar to what the current > CactusConnect/HTTPS is doing. > > The reason for this splitup was to enable temporary analysis routines, for > instance one analysis per HTTP client request, instead of having this one > permanently being invoked even if no one is watching the output. Hi Werner, the steering mechanisms in CactusConnect/HTTPD and AstroGrid/HTTPS let you pause a simulation, then single-step to the next iteration, continue or terminate the run. I guess what you had in mind can be easily achieved by temporarily turning on/off output for an analysis quantity in single-step mode ? -- Cheers, Thomas. From tradke at aei.mpg.de Thu Oct 4 05:00:29 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Thu, 04 Oct 2007 12:00:29 +0200 Subject: [Developers] when to schedule steering methods In-Reply-To: References: <470122B9.60605@aei.mpg.de> Message-ID: <4704B9BD.90805@aei.mpg.de> Erik Schnetter wrote: > On Oct 1, 2007, at 11:39:21, Thomas Radke wrote: > >> Hi, >> >> Erik and I recently discussed the question of when would be the best >> time in the schedule tree to call a methods which allows users to >> interactively steer parameters (as are implemented in Cactus's webserver >> thorns CactusConnect/HTTPS and AstroGrid/HTTPS). >> Currently the webserver's worker routine is scheduled at POSTSTEP which >> means that a parameter value may change after the evolution but before >> the analysis. Erik argues that this is somewhat inconsistent; a >> parameter change should become active only after an iteration has >> finished completely. I "countered" by saying that users might want to >> change I/O parameters before analysis so that they can turn on/off >> certain analysis routines if they'd want to. >> >> What's other people's opinion on that ? >> >> Iff we decide to schedule steering methods at the very end of an >> iteration, we'd need to introduce a new schedule bin, such as STEER. > > > I introduced a registration mechanism for Carpet, where thorns can > register functions which should be called before or after any of the > scheduled functions. This will allow certain actions to be taken at a > more fine-grained level, e.g. allowing to single-step through the RHS > calculation instead of only through iterations. Okay, there seems to be an agreement that runtime parameter steering should be moved from POSTSTEP to the very end of an iteration. How do we go about implementing it ? Shall we use Erik's registration mechanism (which at least for now is specific Carpet), or should I prepare a flesh/drivers patch to add another schedule bin ? -- Cheers, Thomas. From goodale at cct.lsu.edu Thu Oct 4 05:03:35 2007 From: goodale at cct.lsu.edu (Tom Goodale) Date: Thu, 4 Oct 2007 11:03:35 +0100 (BST) Subject: [Developers] when to schedule steering methods In-Reply-To: <4704B9BD.90805@aei.mpg.de> References: <470122B9.60605@aei.mpg.de> <4704B9BD.90805@aei.mpg.de> Message-ID: On Thu, 4 Oct 2007, Thomas Radke wrote: > Okay, there seems to be an agreement that runtime parameter steering > should be moved from POSTSTEP to the very end of an iteration. > How do we go about implementing it ? Shall we use Erik's registration > mechanism (which at least for now is specific Carpet), or should I > prepare a flesh/drivers patch to add another schedule bin ? Go ahead and introducing a STEER bin. Cheers, Tom From werner at cct.lsu.edu Thu Oct 4 10:32:15 2007 From: werner at cct.lsu.edu (Werner Benger) Date: Thu, 04 Oct 2007 10:32:15 -0500 Subject: [Developers] when to schedule steering methods In-Reply-To: <4703F5D5.6040300@aei.mpg.de> References: <470122B9.60605@aei.mpg.de> <4703F5D5.6040300@aei.mpg.de> Message-ID: On Wed, 03 Oct 2007 15:04:37 -0500, Thomas Radke wrote: > Werner Benger wrote: >> I tried to reply earlier, but that mail apparently got lost. Wanted to throw in here >> the memories of the prototype implementation of CactusNet/http , where the >> http service was separated into two scheduling parts: >> >> - one to accept the request and possibly switch on parameters, e.g. for >> activating an analysis routine - this section is running before the ANALYSIS >> routines are invoked >> >> - a second one to send back the results, which is similar to an output routine, >> but globally, I think that one was at POSTSTEP, similar to what the current >> CactusConnect/HTTPS is doing. >> >> The reason for this splitup was to enable temporary analysis routines, for >> instance one analysis per HTTP client request, instead of having this one >> permanently being invoked even if no one is watching the output. > > Hi Werner, > > the steering mechanisms in CactusConnect/HTTPD and AstroGrid/HTTPS let > you pause a simulation, then single-step to the next iteration, continue > or terminate the run. > > I guess what you had in mind can be easily achieved by temporarily > turning on/off output for an analysis quantity in single-step mode ? > Hm, depends if pausing the simulation and going into single step mode is an option. That requires synchroneous connectivity (the simulation waiting for user input) and if the connection drops inbetween, your simulation will be stalled then, right? My approach was more something like: "I want to see Psi4", even if its not activated as output in the parameter file, and "I want to see it only on the web pages when I look at it", i.e.without interfering with the simulation itself and/or pausing it. But, that's a question to what behaviour users would like to have. Werner -- ___________________________________________________________________________ Dr. Werner Benger Visualization Research Laboratory for Creative Arts and Technology (LCAT) Center for Computation & Technology at Louisiana State University (CCT/LSU) 239 Johnston Hall, Baton Rouge, Louisiana 70803 Tel.: +1 225 578 4809 Fax.: +1 225 578-5362 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Here we have to deal with three dimensions, although we can only see two of them: height, direction and velocity." (Kiefer Sutherland as flight attendance in 'Collision Course: Panic in the Tower') From tradke at aei.mpg.de Thu Oct 11 09:49:45 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Thu, 11 Oct 2007 16:49:45 +0200 Subject: [Developers] PATCH: add new schedule bin CCTK_EVOL_CONTROL Message-ID: <470E3809.7090409@aei.mpg.de> Hi, following up the thread "when to schedule steering methods" on the developers mailing list (http://www.cactuscode.org/old/pipermail/developers/2007-October/005439.html), here is the according patch (for the flesh and PUGH) to add a new schedule bin at the very end of an evolution step. As the documentation says, it should be used for routines which potentially alter the status of the simulation, eg. by interaction with users to steer runtime parameters. Note that I changed the name of the new bin from STEER to EVOL_CONTROL which I thought would be more appropriate. But I'm open for better suggestions. -- Cheers, Thomas. --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) text/x-patch --- From tradke at aei.mpg.de Thu Oct 18 07:13:07 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Thu, 18 Oct 2007 14:13:07 +0200 Subject: [Developers] checkpointing MoL variables Message-ID: <47174DD3.7070204@aei.mpg.de> Hi Ian, in http://www.cactuscode.org/pipermail/developers/2006-May/004731.html you said you have tagged all variables except the ErrorScalars with Checkpoint="no". Did you accidentally forget ScratchSpace[] and SandRScratchSpace[] ? -- Cheers, Thomas. From i.hawke at soton.ac.uk Thu Oct 18 07:47:59 2007 From: i.hawke at soton.ac.uk (I.Hawke) Date: Thu, 18 Oct 2007 13:47:59 +0100 Subject: [Developers] checkpointing MoL variables In-Reply-To: <47174DD3.7070204@aei.mpg.de> References: <47174DD3.7070204@aei.mpg.de> Message-ID: <471755FF.1010404@soton.ac.uk> Thomas Radke wrote: > Hi Ian, > > in http://www.cactuscode.org/pipermail/developers/2006-May/004731.html > you said you have tagged all variables except the ErrorScalars with > Checkpoint="no". Did you accidentally forget ScratchSpace[] and > SandRScratchSpace[] ? > > Hmm. The log says the author of that patch was a certain tradke... but it's quite possible that I wrote it in the first place. From memory it should be possible to not checkpoint those variables - the array scratch space was not checkpointed when it existed. Ian From tradke at aei.mpg.de Thu Oct 18 08:01:16 2007 From: tradke at aei.mpg.de (Thomas Radke) Date: Thu, 18 Oct 2007 15:01:16 +0200 Subject: [Developers] checkpointing MoL variables In-Reply-To: <471755FF.1010404@soton.ac.uk> References: <47174DD3.7070204@aei.mpg.de> <471755FF.1010404@soton.ac.uk> Message-ID: <4717591C.9060105@aei.mpg.de> I.Hawke wrote: > Thomas Radke wrote: > >>Hi Ian, >> >>in http://www.cactuscode.org/pipermail/developers/2006-May/004731.html >>you said you have tagged all variables except the ErrorScalars with >>Checkpoint="no". Did you accidentally forget ScratchSpace[] and >>SandRScratchSpace[] ? >> >> > > Hmm. The log says the author of that patch was a certain tradke... but > it's quite possible that I wrote it in the first place. From memory it > should be possible to not checkpoint those variables - the array scratch > space was not checkpointed when it existed. Oops, my oversight, sorry ! I will tag these variables now and commit the change. -- Cheers, Thomas.