From yye00 at cct.lsu.edu  Fri Dec  1 10:21:05 2006
From: yye00 at cct.lsu.edu (Yaakoub Y El Khamra)
Date: Fri, 01 Dec 2006 10:21:05 -0600
Subject: [Developers] Tim Tautges, CCT Colloquia MOAB
Message-ID: <45705671.6040009@cct.lsu.edu>


Greetings
As the CFDToolkit is making more use of MOAB every day, we asked Tim 
Tautges currently of Sandia and soon to be of Argonne National Labs to 
give a talk about MOAB. This talk will be broadcast over the access grid 
and is scheduled with NCSA as CCT Colloquia, the NCSA venue is Cosmic 
Voyage. We will also have a recording of the talk ready for download in 
about 2 hours.



Cheers
Yaakoub

From yye00 at cct.lsu.edu  Mon Dec  4 17:16:01 2006
From: yye00 at cct.lsu.edu (Yaakoub Y El Khamra)
Date: Mon, 04 Dec 2006 17:16:01 -0600
Subject: [Developers] Plone spamming issues
Message-ID: <4574AC31.90605@cct.lsu.edu>


Greetings
Having just finished the weekly CactusCode.org website checks it has 
come to my attention that we attracted at least a dozen spam accounts 
that were subsequently deleted and had their data removed. If by any 
chance we accidentally deleted a valid user account we apologize and ask 
you to kindly re-register yourself with the CactusCode.org website.

Regards
Yaakoub

From szilagyi at aei.mpg.de  Tue Dec  5 05:34:22 2006
From: szilagyi at aei.mpg.de (Bela Szilagyi)
Date: Tue, 5 Dec 2006 12:34:22 +0100
Subject: [Developers] exit strategies
Message-ID: <200612051234.22866.szilagyi@aei.mpg.de>

As I understand, currently Cactus does "nice" exits, i.e., it calls exit() 
even if the user thorn is desperate enough to call CCTK_Warn(0, ...);

While there is a value to niceness, it would be nice to allow (with an extra 
parameter) for abort() - style exits, such that a core-dump is requested from 
the system.

If CCTK_Abort() also calls exit() rather than abort(), perhaps the new 
aborting parameter could apply to this function.


-- 
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  Wed Dec  6 07:44:04 2006
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 6 Dec 2006 14:44:04 +0100
Subject: [Developers] PATCH: Add new schedule bins for mesh refinement
References: <200612061341.kB6DfUSW012930@cactus.cct.lsu.edu>
Message-ID: <65ED9048-CC98-433C-B2C4-40A681C44D39@cct.lsu.edu>

Begin forwarded message:

> From: schnetter at cct.lsu.edu
> Date: December 6, 2006 2:41:30 PM GMT+01:00
> To: goodale at cct.lsu.edu, gnats-admin at cactuscode.org,  
> cactusmaint at cactuscode.org
> Subject: [CactusMaint] Cactus/2074: PATCH: Add new schedule bins  
> for mesh refinement
> Reply-To: bugs at cactuscode.org, CactusMaint  
> <cactusmaint at cactuscode.org>

> I suggest to add three new schedule bins
>
> PREREGRIDINITIAL
> POSTREGRIDINITIAL
>
> POSTRESTRICTINITIAL
>
> These bins are necessary so that thorns can distinguish between the  
> corresponding operations during evolution and during initial data  
> setup.  That is, for example, operations that need to be performed  
> after restricting during time evolution may differ from operations  
> that need to be performed after restricting while initial data are  
> set up.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>

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/20061206/cb139890/attachment.bin 

From steve.white at aei.mpg.de  Wed Dec  6 13:29:17 2006
From: steve.white at aei.mpg.de (Steve White)
Date: Wed, 6 Dec 2006 20:29:17 +0100
Subject: [Developers] exit strategies
In-Reply-To: <200612051234.22866.szilagyi@aei.mpg.de>
References: <200612051234.22866.szilagyi@aei.mpg.de>
Message-ID: <20061206192912.GA31926@sshserv.aei.mpg.de>

Bela,

This was one of those "things I was going to do something about".

Some time earlier this year we were disappointed by this behaviour, so I
investigated it somewhat, seeing how exit() and abort() were used in 
Cactus and thorns.  I don't recall if I posted my report, but here it is:

Use of exit() and abort() in Cactus

exit() is used by several thorns in a raw form sometimes with arbitrary
values, sometimes without even printing an error message.  (note that if a
message is printed by a not-root process, the message won't be seen in the
main stdio)

Only two meaningful, standard values are defined for the argument of exit():
	EXIT_SUCCESS, EXIT_FAILURE. 
These are sometimes used but usually not.  And there are cases of arbitrary
nonsense values being passed.

However, exit() does not trigger a core dump or print an informational
message, and sometimes that is what one really needs.

The most evil thing is a raw call to exit() (with a magic number argument)
which prints no explanatory message.  This necessitates debugging to find
where the code exited.

Likewise, CCTK_VWarn should be preferred to direct calls to CCTK_Exit
or CCTK_Abort.

Let's discuss these possibilites

	1) a parameter that makes any call to CCTK_Exit() with value other
	   than EXIT_SUCCESS to call abort().

	2) To make CCTK_Abort print a message and call abort().

	3) To clean up raw calls to exit() in thorns.

	4) make CCTK_VWarn to pass EXIT_FAILURE to CCTK_Abort if
	   level <= error_level (do in Flesh, PUGH and Carpet)


-?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - 

arrangements/AEIDevelopment/TwoPunctures/src/TP_utilities.c:  exit (1);
arrangements/AEIDevelopment/Unfish/src/unfish.c:           exit(1);
arrangements/AEIThorns/BAM_Elliptic/src/Cactus4_utils.c:#define STOP  exit(0);
arrangements/AEIThorns/BAM_Elliptic/src/Cactus4_utils.c:#define ABORT exit(1);
arrangements/AEIThorns/BAM_Elliptic/src/Cactus4_utils.c:#define CORE  exit(2);
arrangements/CactusExternal/FlexIO/src/ffio.c:    exit (1);
arrangements/CactusExternal/FlexIO/src/ffio.c:          exit (1);
arrangements/CactusExternal/FlexIO/src/ffio.c:                  exit (1);
arrangements/CactusExternal/FlexIO/src/ffio.c:                          exit (1);
arrangements/CactusExternal/jpeg6b/src/ansi2knr.c:                      exit(1);
arrangements/CactusExternal/jpeg6b/src/ansi2knr.c:              exit(0);
arrangements/CactusExternal/jpeg6b/src/ansi2knr.c:                      exit(1);
arrangements/CactusExternal/jpeg6b/src/ansi2knr.c:              exit(1);
arrangements/CactusPUGH/PUGH/src/SetupPGH.c:  exit (retval);
arrangements/CactusPUGH/PUGH/src/SetupPGH.c:               exit
arrangements/CactusPUGH/PUGH/src/SetupPGH.c:  exit (retval);arrangements/EUHydro/Whisky_RNSID/src/equil.c:       exit(0);
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: fprintf(stderr,"...now exiting to system...\n");
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: exit(1);
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: void exit();
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: fprintf(stderr,"...now exiting to system...\n");
arrangements/EUHydro/Whisky_RNSID/src/nrutil.c: exit(1);
arrangements/EUHydro/Whisky_RNSID/src/rnsid.c:               exit(0);

-?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - 

src/main/ScheduleInterface.c:    exit(2);
src/comm/CactusDefaultComm.c:  exit (retval);
src/util/ParseFile.c
	:CheckBuf has the useless
	    assert(0);
	    exit(1);

-?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - 

Drivers overload CCTK_Exit and CCTK_Abort
	Defines Exit and Abort, which just call exit with arbitrary values
arrangements/Carpet/Carpet/src/helpers.cc
arrangements/CactusPUGH/PUGH/src/SetupPGH.c


But it's only called a few places:
-?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - -?- - - 

src/comm/OverloadComm.c:  *ierror = CCTK_Exit (*GH, *retval);
src/main/CommandLine.c:  CCTK_Exit (NULL, retval);
src/main/CommandLine.c:              CCTK_Exit (NULL, 2);
src/main/CommandLine.c:  CCTK_Exit (NULL, 0);
src/main/CommandLine.c:  CCTK_Exit (NULL, retcode);
src/main/CommandLine.c:  CCTK_Exit (NULL, 1);
src/main/CommandLine.c:  CCTK_Exit (NULL, 1);
src/main/CommandLine.c:  CCTK_Exit (NULL, 1);
src/main/CommandLine.c:  CCTK_Exit (NULL, 1);
	/* this is how CCTK_VWarn exits -- note it always reports normal exit*/
src/main/WarnLevel.c:    CCTK_Abort (NULL, 0);
	/* this is particularly wierd--in CCTKi_FinaliseParamWarn */
src/main/WarnLevel.c:      CCTK_Abort (NULL, 99);	
src/util/Malloc.c:    /*$CCTK_Abort(NULL);$*/
src/util/Malloc.c:      /*$CCTK_Abort(NULL);$*/
src/util/Malloc.c:    CCTK_Abort(NULL,0);

arrangements/CactusConnect/HTTPD/src/Startup.c:    CCTK_Exit(cctkGH,99);
arrangements/AEIThorns/Nice/src/nice.c:        CCTK_Abort(cctkGH, 1);
arrangements/AEIThorns/Nice/src/nice.c:        CCTK_Abort(cctkGH, 1);
arrangements/AEIThorns/Nice/src/nice.c:        CCTK_Abort(cctkGH, 1);
arrangements/CactusConnect/HTTPD/src/Sockets.c:    CCTK_Abort(cctkGH, EXIT_FAILURE);
arrangements/CactusConnect/HTTPD/src/Sockets.c:          CCTK_Abort(NULL, EXIT_FAILURE);
arrangements/CactusPUGHIO/IsoSurfacer/src/Sockets.c:          CCTK_Abort(NULL, EXIT_FAILURE);
arrangements/CactusPUGHIO/IsoSurfacer/src/Sockets.c:    CCTK_Abort(NULL, EXIT_FAILURE);
arrangements/CactusPUGHIO/IsoSurfacer/src/Sockets.c:    CCTK_Abort(NULL,EXIT_FAILURE);
arrangements/CactusUtils/NaNChecker/src/NaNCheck.c:    CCTK_Abort (cctkGH, 0);
arrangements/CactusUtils/NaNChecker/src/NaNCheck.c:      CCTK_Abort (NULL, 0);



On  5.12.06, Bela Szilagyi wrote:
> As I understand, currently Cactus does "nice" exits, i.e., it calls exit() 
> even if the user thorn is desperate enough to call CCTK_Warn(0, ...);
> 
> While there is a value to niceness, it would be nice to allow (with an extra 
> parameter) for abort() - style exits, such that a core-dump is requested from 
> the system.
> 
> If CCTK_Abort() also calls exit() rather than abort(), perhaps the new 
> aborting parameter could apply to this function.
> 

-- 
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 Dec 12 08:00:05 2006
From: schnetter at cct.lsu.edu (schnetter at cct.lsu.edu)
Date: Tue, 12 Dec 2006 08:00:05 -0600
Subject: [Developers] Documentation/2075: Describe how to run Cactus
	executables
Message-ID: <200612121400.kBCE05nb002593@cactus.cct.lsu.edu>

>Number:         2075
>Notify-List:    developers at cactuscode.org
>Category:       Documentation
>Synopsis:       Describe how to run Cactus executables
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    goodale
>State:          open
>Class:          doc-bug
>Submitter-Id:   user
>Arrival-Date:   Tue Dec 12 08:00:04 -0600 2006
>Originator:     Erik Schnetter
>Release:        Cactus 4.0.b16
>Organization:
>Environment:
>Description:
A user on the mailing list was confused how to run the executable that the Cactus build system produced.  We should explain that the result is (typically) a straightforward MPI application, give a simple example how to use mpirun, and point to MPI documentation for more details.
>How-To-Repeat:
>Fix:
Unknown
>Unformatted:

From schnetter at cct.lsu.edu  Sat Dec 30 07:57:47 2006
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 30 Dec 2006 14:57:47 +0100
Subject: [Developers] exit strategies
In-Reply-To: <20061206192912.GA31926@sshserv.aei.mpg.de>
References: <200612051234.22866.szilagyi@aei.mpg.de>
	<20061206192912.GA31926@sshserv.aei.mpg.de>
Message-ID: <4317979F-8AE5-44F1-90FF-A49081D196E5@cct.lsu.edu>

On Dec 6, 2006, at 20:29:17, Steve White wrote:

> Let's discuss these possibilites
>
> 	1) a parameter that makes any call to CCTK_Exit() with value other
> 	   than EXIT_SUCCESS to call abort().
>
> 	2) To make CCTK_Abort print a message and call abort().
>
> 	3) To clean up raw calls to exit() in thorns.
>
> 	4) make CCTK_VWarn to pass EXIT_FAILURE to CCTK_Abort if
> 	   level <= error_level (do in Flesh, PUGH and Carpet)

We discussed 2) before.  There is a problem when running in parallel,  
since calling exit() or abort() may have problems terminating other  
MPI processes.  It is much preferred to call MPI_Abort() instead.   
However, MPI_Abort() does not call abort(), it calls exit().

Hence there are are two different behaviours:

- Call MPI_Abort(), reliably causing all MPI processes to exit cleanly
- Call abort(), ending up in a debugger or obtaining a core dump, and  
possibly leaving the other MPI processes in an undefined state

Both behaviours have their uses in times.  I suggest to add a command  
line option to distinguish between these two behaviours.  I think it  
should be a command line option and not a parameter because this  
behaviour does not influence any physics output of a simulation, it  
only changes how the job interacts with its environment, similar to  
choosing line buffering or redirecting I/O to files.  A command line  
option also makes it easier to change this behaviour quickly when  
debugging.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>

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/20061230/121efaa8/attachment.bin