From goodale at cct.lsu.edu  Sun Apr  1 03:43:25 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Sun, 1 Apr 2007 09:43:25 +0100 (BST)
Subject: [Developers] 'Cactus' to be renamed
Message-ID: <Pine.LNX.4.64.0704010936000.19199@fandango.dyndns.org>

Hi,

in order to be more botanically correct with the term 'thorn' we are 
renaming 'Cactus' to 'Rose'.  The changes will be made over the next few 
weeks, with CCTK_ functions being replace by RCTK_, the repositories 
moving to cvs.rosecode.org, etc.

As some of you will appreciate this might cause confusion and licensing 
issues with the 'Rational Rose' UML authoring software.  In order to avoid 
these problems IBM have kindly donated the Rose trademarks and copyrights 
to us and 'Rational Rose' will now be renamed 'Contemplative Cactus'.

We, the Cactus - Rose from this date - authors, are sure that you will be 
much happier with the new, botanically correct, nomenclature.

Cheers,

Tom

From jabadi2 at gmail.com  Sun Apr  1 04:04:02 2007
From: jabadi2 at gmail.com (Josh Abadie)
Date: Sun, 1 Apr 2007 04:04:02 -0500
Subject: [Developers] 'Cactus' to be renamed
In-Reply-To: <Pine.LNX.4.64.0704010936000.19199@fandango.dyndns.org>
References: <Pine.LNX.4.64.0704010936000.19199@fandango.dyndns.org>
Message-ID: <fa9006080704010204o5be7a428xa7b1d2fb6699154d@mail.gmail.com>

Thanks for that.  It made me laugh.

On 4/1/07, Tom Goodale <goodale at cct.lsu.edu> wrote:
>
> Hi,
>
> in order to be more botanically correct with the term 'thorn' we are
> renaming 'Cactus' to 'Rose'.  The changes will be made over the next few
> weeks, with CCTK_ functions being replace by RCTK_, the repositories
> moving to cvs.rosecode.org, etc.
>
> As some of you will appreciate this might cause confusion and licensing
> issues with the 'Rational Rose' UML authoring software.  In order to avoid
> these problems IBM have kindly donated the Rose trademarks and copyrights
> to us and 'Rational Rose' will now be renamed 'Contemplative Cactus'.
>
> We, the Cactus - Rose from this date - authors, are sure that you will be
> much happier with the new, botanically correct, nomenclature.
>
> Cheers,
>
> Tom
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>



-- 
/*
###################################################
#Josh Abadie
#System Administrator
#High Performance Computing @ LSU
#work:225-578-8425
#cell:225-202-5633
#email: jabadi2 at lsu.edu
#email:jabadi2 at gmail.com
###################################################
*/

"Because the world is not beautiful, it is." -Kino no Tabi

End Of Line
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/developers/attachments/20070401/2ec14024/attachment.html 

From yye00 at cct.lsu.edu  Sun Apr  1 07:33:04 2007
From: yye00 at cct.lsu.edu (Yaakoub El Khamra)
Date: Sun, 01 Apr 2007 07:33:04 -0500
Subject: [Developers] 'Cactus' to be renamed
In-Reply-To: <Pine.LNX.4.64.0704010936000.19199@fandango.dyndns.org>
References: <Pine.LNX.4.64.0704010936000.19199@fandango.dyndns.org>
Message-ID: <460FA680.3030409@cct.lsu.edu>


lol made my day Tom :)

Cheers
Yaakoub

Tom Goodale wrote:
> Hi,
>
> in order to be more botanically correct with the term 'thorn' we are 
> renaming 'Cactus' to 'Rose'.  The changes will be made over the next few 
> weeks, with CCTK_ functions being replace by RCTK_, the repositories 
> moving to cvs.rosecode.org, etc.
>
> As some of you will appreciate this might cause confusion and licensing 
> issues with the 'Rational Rose' UML authoring software.  In order to avoid 
> these problems IBM have kindly donated the Rose trademarks and copyrights 
> to us and 'Rational Rose' will now be renamed 'Contemplative Cactus'.
>
> We, the Cactus - Rose from this date - authors, are sure that you will be 
> much happier with the new, botanically correct, nomenclature.
>
> Cheers,
>
> Tom
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
>   


From JShalf at lbl.gov  Tue Apr  3 12:51:05 2007
From: JShalf at lbl.gov (John Shalf)
Date: Tue, 3 Apr 2007 10:51:05 -0700
Subject: [Developers] know-architectures file for XT4?
Message-ID: <47FC8B37-3B00-4EE0-98C3-07BEAD7D64A4@lbl.gov>

There doesn't appear to be a known-architectures file for the Cray  
XT3 or XT4 (catamount).  Should I create one?  If one already exists,  
will someone check it in to cactusdevcvs so I don't duplicate work.

Thanks!

-john

From yye00 at cct.lsu.edu  Tue Apr  3 12:54:13 2007
From: yye00 at cct.lsu.edu (Yaakoub Y El Khamra)
Date: Tue, 03 Apr 2007 12:54:13 -0500
Subject: [Developers] know-architectures file for XT4?
In-Reply-To: <47FC8B37-3B00-4EE0-98C3-07BEAD7D64A4@lbl.gov>
References: <47FC8B37-3B00-4EE0-98C3-07BEAD7D64A4@lbl.gov>
Message-ID: <461294C5.6010107@cct.lsu.edu>


Hi John
Tom had one ready for the XT3 but we lost access to the machine before 
we could retrieve it. If you can create one for the XT3 and another for 
the XT4 and check them in I think it would be great.

Cheers
Yaakoub

John Shalf wrote:
> There doesn't appear to be a known-architectures file for the Cray  
> XT3 or XT4 (catamount).  Should I create one?  If one already exists,  
> will someone check it in to cactusdevcvs so I don't duplicate work.
>
> Thanks!
>
> -john
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
>   


From goodale at cct.lsu.edu  Tue Apr  3 12:56:09 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Tue, 3 Apr 2007 18:56:09 +0100 (BST)
Subject: [Developers] know-architectures file for XT4?
In-Reply-To: <47FC8B37-3B00-4EE0-98C3-07BEAD7D64A4@lbl.gov>
References: <47FC8B37-3B00-4EE0-98C3-07BEAD7D64A4@lbl.gov>
Message-ID: <Pine.LNX.4.64.0704031854270.19199@fandango.dyndns.org>

Here's one I created on bigben, but as I no longer had allocation to run 
anything I can't say for certain if the resulting executable works.

If you get a chance to check it it would be great to check it in.

Cheers,

Tom

On Tue, 3 Apr 2007, John Shalf wrote:

> There doesn't appear to be a known-architectures file for the Cray
> XT3 or XT4 (catamount).  Should I create one?  If one already exists,
> will someone check it in to cactusdevcvs so I don't duplicate work.
>
> Thanks!
>
> -john
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
-------------- next part --------------
#! /bin/sh
#  /*@@
#    @file      catamount
#    @date      Wed Oct 6 15:35:45 2005
#    @author    Tom Goodale
#    @desc
#               Known-architectures file for Cray XT3 system
#    @enddesc
#    @version   $Header: /cactusdevcvs/Cactus/lib/make/known-architectures/bgl,v 1.1 2005/10/06 17:54:46 goodale Exp $
#  @@*/

if test "$CCTK_CONFIG_STAGE" = 'preferred-compilers' ; then

  if test -z "$CC"; then
    CC=cc
    echo Setting C compiler to $CC
  fi

  if test -z "$CXX"; then
    CXX=CC
    echo Setting C++ compiler to $CXX
  fi

  if test -z "$F77"; then
    F77=ftn
    echo Setting F77 compiler to $F77
  fi

  if test -z "$F90"; then
    F90=ftn
    echo Setting F90 compiler to $F90
  fi

  if test -z "$FPP" ; then
    FPP='/usr/bin/cpp'
    FPPFLAGS='-traditional'
    echo "Setting FPP to $FPP"
    echo "Setting FPPFLAGS to $FPPFLAGS"
  fi

  if test -z "$CPP" ; then
    CPP='/usr/bin/cpp'
    echo "Setting CPP to $CPP"
  fi

else

  cross_compiling=yes
  # Fortran compilers
  : ${F90FLAGS=""}
  : ${F77FLAGS=""}
  : ${F90_OPTIMISE_FLAGS='-O3 -fastsse -Mnontemporal -Mprefetch=distance:8,nta'}
  : ${F77_OPTIMISE_FLAGS='-O3 -fastsse -Mnontemporal -Mprefetch=distance:8,nta'}
  : ${F90_DEBUG_FLAGS='-g'}
  : ${F77_DEBUG_FLAGS='-g'}

  : ${LIBS='pgf90 pgf90rtl pgftnrtl pgf90_rpm1 pghpf2 pgc m'}

  # C/C++ compilers
  case "$CC" in
    cc)
     : ${CFLAGS=""}
     : ${C_OPTIMISE_FLAGS='-O3 -fastsse -Mnontemporal -Mprefetch=distance:8,nta'}
     ;;
    *)
     ;;
  esac

  case "$CXX" in
    CC)
     : ${CXXFLAGS=""}
     : ${CXX_OPTIMISE_FLAGS='-O3 -fastsse -Mnontemporal -Mprefetch=distance:8,nta'}
     ;;
    *)
     ;;
  esac

  if test "x$cross_compiling" = 'xyes' ; then
    ENDIAN=little
    SIZEOF_LONG_LONG=8
    SIZEOF_LONG_INT=8
    SIZEOF_INT=4
    SIZEOF_SHORT_INT=2

    SIZEOF_LONG_DOUBLE=8
    SIZEOF_DOUBLE=8
    SIZEOF_FLOAT=4

    SIZEOF_POINTER=8

    NULL_DEVICE='/dev/null'
  fi

  # MPI stuff
  if test -n "$MPI" ; then
    NATIVE_MPI_LIBS=' '
    NATIVE_MPI_LIB_DIRS=' '
    NATIVE_MPI_INC_DIRS=' '
  fi

fi

From JShalf at lbl.gov  Tue Apr  3 12:57:37 2007
From: JShalf at lbl.gov (John Shalf)
Date: Tue, 3 Apr 2007 10:57:37 -0700
Subject: [Developers] know-architectures file for XT4?
In-Reply-To: <Pine.LNX.4.64.0704031854270.19199@fandango.dyndns.org>
References: <47FC8B37-3B00-4EE0-98C3-07BEAD7D64A4@lbl.gov>
	<Pine.LNX.4.64.0704031854270.19199@fandango.dyndns.org>
Message-ID: <272064E6-154B-41B1-BD12-D350329090EC@lbl.gov>

I'll put it on our XT4 and give it a spin.
If it works I'll check it in.
If it doesn't, I'll sync it up with the one I've been hacking on for  
our own XT4.

Thanks!

-john

On Apr 3, 2007, at 10:56 AM, Tom Goodale wrote:
> Here's one I created on bigben, but as I no longer had allocation  
> to run anything I can't say for certain if the resulting executable  
> works.
>
> If you get a chance to check it it would be great to check it in.
>
> Cheers,
>
> Tom
>
> On Tue, 3 Apr 2007, John Shalf wrote:
>
>> There doesn't appear to be a known-architectures file for the Cray
>> XT3 or XT4 (catamount).  Should I create one?  If one already exists,
>> will someone check it in to cactusdevcvs so I don't duplicate work.
>>
>> Thanks!
>>
>> -john
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/developers
>> <catamount>

From goodale at cct.lsu.edu  Tue Apr  3 12:59:21 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Tue, 3 Apr 2007 18:59:21 +0100 (BST)
Subject: [Developers] know-architectures file for XT4?
In-Reply-To: <Pine.LNX.4.64.0704031854270.19199@fandango.dyndns.org>
References: <47FC8B37-3B00-4EE0-98C3-07BEAD7D64A4@lbl.gov>
	<Pine.LNX.4.64.0704031854270.19199@fandango.dyndns.org>
Message-ID: <Pine.LNX.4.64.0704031858070.19199@fandango.dyndns.org>


Looking at it I have set it up as 'cross-compilation' so would have needed 
to HOST=catamount on the configure line and may have modified the 
config.guess and config.sub to accept this.

Cheers.

Tom

On Tue, 3 Apr 2007, Tom Goodale wrote:

> Here's one I created on bigben, but as I no longer had allocation to run 
> anything I can't say for certain if the resulting executable works.
>
> If you get a chance to check it it would be great to check it in.
>
> Cheers,
>
> Tom
>
> On Tue, 3 Apr 2007, John Shalf wrote:
>
>> There doesn't appear to be a known-architectures file for the Cray
>> XT3 or XT4 (catamount).  Should I create one?  If one already exists,
>> will someone check it in to cactusdevcvs so I don't duplicate work.
>> 
>> Thanks!
>> 
>> -john
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/developers
>

From jshalf at lbl.gov  Tue Apr  3 13:10:06 2007
From: jshalf at lbl.gov (John Shalf)
Date: Tue, 3 Apr 2007 11:10:06 -0700
Subject: [Developers] know-architectures file for XT4?
In-Reply-To: <Pine.LNX.4.64.0704031858070.19199@fandango.dyndns.org>
References: <47FC8B37-3B00-4EE0-98C3-07BEAD7D64A4@lbl.gov>
	<Pine.LNX.4.64.0704031854270.19199@fandango.dyndns.org>
	<Pine.LNX.4.64.0704031858070.19199@fandango.dyndns.org>
Message-ID: <88CC5034-C544-47BF-A5B8-80DAB5499BD3@lbl.gov>


I get confused on this sometimes Tom,
do I want
	HOST=catamount
or
	MACHINE_ARCH=catamount
I'm using the latter.  Is HOST= equivalent or will it change the  
behavior?

I've hacked config.guess and config.sub accordingly.

-john

On Apr 3, 2007, at 10:59 AM, Tom Goodale wrote:
> Looking at it I have set it up as 'cross-compilation' so would have  
> needed
> to HOST=catamount on the configure line and may have modified the
> config.guess and config.sub to accept this.
>
> Cheers.
>
> Tom
>
> On Tue, 3 Apr 2007, Tom Goodale wrote:
>
>> Here's one I created on bigben, but as I no longer had allocation  
>> to run
>> anything I can't say for certain if the resulting executable works.
>>
>> If you get a chance to check it it would be great to check it in.
>>
>> Cheers,
>>
>> Tom
>>
>> On Tue, 3 Apr 2007, John Shalf wrote:
>>
>>> There doesn't appear to be a known-architectures file for the Cray
>>> XT3 or XT4 (catamount).  Should I create one?  If one already  
>>> exists,
>>> will someone check it in to cactusdevcvs so I don't duplicate work.
>>>
>>> Thanks!
>>>
>>> -john
>>> _______________________________________________
>>> 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 schnetter at cct.lsu.edu  Wed Apr  4 10:19:59 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 4 Apr 2007 17:19:59 +0200
Subject: [Developers] [Flesh-cvs] DEVELOPMENT CVS "Cactus/lib/make
	config.guess config.sub"
In-Reply-To: <20070404010934.32917817D@asylum.cct.lsu.edu>
References: <20070404010934.32917817D@asylum.cct.lsu.edu>
Message-ID: <137ABB7C-F6C2-4A51-871D-E70041CE1877@cct.lsu.edu>

On Apr 4, 2007, at 03:09:34, John Shalf (jshalf) wrote:

> Update of /cactusdevcvs/Cactus/lib/make
> In directory asylum.cct.lsu.edu:/tmp/cvs-serv21797
>
> Modified Files:
> 	config.guess config.sub
> Log Message:
>
> Fixed config.guess and config.sub for Cray xt3 and xt4 targets.

Did you just update them to a more current version, or did you make  
local changes?  If there are local changes, then we'll have to be  
careful when we update from upstream.

-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/20070404/ba681c42/attachment-0001.bin 

From jshalf at lbl.gov  Wed Apr  4 11:13:25 2007
From: jshalf at lbl.gov (John Shalf)
Date: Wed, 4 Apr 2007 09:13:25 -0700
Subject: [Developers] [Flesh-cvs] DEVELOPMENT CVS
	"Cactus/lib/make	config.guess config.sub"
In-Reply-To: <137ABB7C-F6C2-4A51-871D-E70041CE1877@cct.lsu.edu>
References: <20070404010934.32917817D@asylum.cct.lsu.edu>
	<137ABB7C-F6C2-4A51-871D-E70041CE1877@cct.lsu.edu>
Message-ID: <881C8602-E7FC-4D11-BFBA-97D2B8F72C74@lbl.gov>


On Apr 4, 2007, at 8:19 AM, Erik Schnetter wrote:

> On Apr 4, 2007, at 03:09:34, John Shalf (jshalf) wrote:
>
>> Update of /cactusdevcvs/Cactus/lib/make
>> In directory asylum.cct.lsu.edu:/tmp/cvs-serv21797
>>
>> Modified Files:
>> 	config.guess config.sub
>> Log Message:
>>
>> Fixed config.guess and config.sub for Cray xt3 and xt4 targets.
>
> Did you just update them to a more current version, or did you make  
> local changes?

Local changes unfortunately.  config.guess doesn't like  
crosscompilers for microkernels (BG/L CNK has been out for years, but  
never has appeared in config.guess or config.sub).

-john

>   If there are local changes, then we'll have to be careful when we  
> update from upstream.
>
> -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.
>
>
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers

From goodale at cct.lsu.edu  Wed Apr  4 11:15:39 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Wed, 4 Apr 2007 17:15:39 +0100 (BST)
Subject: [Developers] [Flesh-cvs] DEVELOPMENT CVS "Cactus/lib/make
 config.guess config.sub"
In-Reply-To: <137ABB7C-F6C2-4A51-871D-E70041CE1877@cct.lsu.edu>
References: <20070404010934.32917817D@asylum.cct.lsu.edu>
	<137ABB7C-F6C2-4A51-871D-E70041CE1877@cct.lsu.edu>
Message-ID: <Pine.LNX.4.64.0704041714100.15233@fandango.dyndns.org>

On Wed, 4 Apr 2007, Erik Schnetter wrote:

> On Apr 4, 2007, at 03:09:34, John Shalf (jshalf) wrote:
>
>> Update of /cactusdevcvs/Cactus/lib/make
>> In directory asylum.cct.lsu.edu:/tmp/cvs-serv21797
>> 
>> Modified Files:
>> 	config.guess config.sub
>> Log Message:
>> 
>> Fixed config.guess and config.sub for Cray xt3 and xt4 targets.
>
> Did you just update them to a more current version, or did you make local 
> changes?  If there are local changes, then we'll have to be careful when we 
> update from upstream.

That's why updates from upstream are rare.  In a few weeks I'll send the 
latest ones out again for everyone to test on their systems and try to 
integrate them.  Worst case normally is the need to rename or link some 
known-architecture files.

Cheers,

Tom

From sebastiano.bernuzzi at gmail.com  Thu Apr  5 07:57:22 2007
From: sebastiano.bernuzzi at gmail.com (sebastiano bernuzzi)
Date: Thu, 5 Apr 2007 14:57:22 +0200
Subject: [Developers] to cvs.rosecode.org
Message-ID: <793f07c70704050557w752243b9m6f5b67fda53f905@mail.gmail.com>

Hi Rose team

I have some errors compiling my favourite cactus ...opps Rose ,
configuration,
It seems the compilers does not recognize the new sintax RCTK_ ...
can you help me?
( I may be useful another detail:
before exiting some fish appear on the screen )

Cheers

--- --- --- --- --- --- --- --- ---
Hi,

in order to be more botanically correct with the term 'thorn' we are
renaming 'Cactus' to 'Rose'.  The changes will be made over the next few
weeks, with CCTK_ functions being replace by RCTK_, the repositories
moving to cvs.rosecode.org, etc.

As some of you will appreciate this might cause confusion and licensing
issues with the 'Rational Rose' UML authoring software.  In order to avoid
these problems IBM have kindly donated the Rose trademarks and copyrights
to us and 'Rational Rose' will now be renamed 'Contemplative Cactus'.

We, the Cactus - Rose from this date - authors, are sure that you will be
much happier with the new, botanically correct, nomenclature.

Cheers,

Tom


-- 
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/20070405/e828f55f/attachment.html 

From rideout at aei.mpg.de  Fri Apr  6 08:36:25 2007
From: rideout at aei.mpg.de (David Rideout)
Date: Fri, 6 Apr 2007 15:36:25 +0200 (CEST)
Subject: [Developers] fix to integer overflow bug in PUGH
Message-ID: <Pine.LNX.4.60.0704061529460.21970@sshserv2.aei.mpg.de>

The malloc calls in PUGH compute the size to allocate from an int expression. 
This patch casts such expressions to size_t.  This fixes PR 2088.

Patch also includes a check that malloc returns a non-NULL result...

Thanks to Erik Schnetter for pointing me to the solution.

-David
SW5kZXg6IFN0b3JhZ2UuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNT
IGZpbGU6IC9jYWN0dXNkZXZjdnMvQ2FjdHVzUFVHSC9QVUdIL3NyYy9TdG9y
YWdlLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjUyDQpkaWZmIC1jIC1y
MS41MiBTdG9yYWdlLmMNCioqKiBTdG9yYWdlLmMJMTUgSnVuIDIwMDYgMTY6
MTU6MTkgLTAwMDAJMS41Mg0KLS0tIFN0b3JhZ2UuYwk2IEFwciAyMDA3IDEz
OjM5OjE2IC0wMDAwDQoqKioqKioqKioqKioqKioNCioqKiA2MTMsNjE5ICoq
KioNCiAgICAgICAgICBHQS0+cGFkZGRhdGEgPSBOVUxMOw0KICAgICAgICB9
DQogIA0KISAgICAgICBpZiAoR0EtPmV4dHJhcy0+bnBvaW50cyAqIEdBLT52
YXJzaXplICogR0EtPnZlY3Rvcl9zaXplIDw9IDApDQogICAgICAgIHsNCiAg
ICAgICAgICAvKiBvbmx5IHdhcm4gaWYgdGhlIGdsb2JhbCBhcnJheSBzaXpl
IGlzIGFsc28gemVybyAqLw0KICAgICAgICAgIGZvciAoaSA9IDAsIGdsb2Jh
bF9zaXplID0gMTsgaSA8IEdBLT5leHRyYXMtPmRpbTsgaSsrKQ0KLS0tIDYx
Myw2MTkgLS0tLQ0KICAgICAgICAgIEdBLT5wYWRkZGF0YSA9IE5VTEw7DQog
ICAgICAgIH0NCiAgDQohICAgICAgIGlmICgoc2l6ZV90KSBHQS0+ZXh0cmFz
LT5ucG9pbnRzICogR0EtPnZhcnNpemUgKiBHQS0+dmVjdG9yX3NpemUgPD0g
MCkNCiAgICAgICAgew0KICAgICAgICAgIC8qIG9ubHkgd2FybiBpZiB0aGUg
Z2xvYmFsIGFycmF5IHNpemUgaXMgYWxzbyB6ZXJvICovDQogICAgICAgICAg
Zm9yIChpID0gMCwgZ2xvYmFsX3NpemUgPSAxOyBpIDwgR0EtPmV4dHJhcy0+
ZGltOyBpKyspDQoqKioqKioqKioqKioqKioNCioqKiA2MzEsNjQ2ICoqKioN
CiAgICAgICAgZWxzZSBpZiAoISBteV9wYWRkaW5nX2FjdGl2ZSkNCiAgICAg
ICAgew0KICAgICAgICAgIC8qIEVhc3kgY2FzZS4gKi8NCiEgICAgICAgICBH
QS0+ZGF0YSA9IG1hbGxvYyAoR0EtPmV4dHJhcy0+bnBvaW50cyAqIEdBLT52
YXJzaXplICogR0EtPnZlY3Rvcl9zaXplKTsNCiAgICAgICAgICBHQS0+cGFk
ZGRhdGEgPSBHQS0+ZGF0YTsNCiAgICAgICAgfQ0KICAgICAgICBlbHNlDQog
ICAgICAgIHsNCiAgICAgICAgICAvKiBVc2UgdGhlIENhY3R1cyBDYWNoZSBh
bGlnbm1lbnQgZnVuY3Rpb24gKi8NCiAgICAgICAgICBHQS0+ZGF0YSA9IFV0
aWxfQ2FjaGVNYWxsb2MgKEdBLT5hcnJheWlkLA0KISAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgR0EtPmV4dHJhcy0+bnBvaW50cyAq
IEdBLT52YXJzaXplICogR0EtPnZlY3Rvcl9zaXplLA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgJkdBLT5wYWRkZGF0YSk7DQog
ICAgICAgIH0NCiAgICAgICAgR0EtPm5wb2ludHMgPSBHQS0+ZXh0cmFzLT5u
cG9pbnRzOw0KICAjaWZkZWYgREVCVUdfUFVHSA0KICAgICAgICBwcmludGYg
KCIgUFVHSF9FbmFibGVHQXJyYXlEYXRhU3RvcmFnZTogbmV3IHBvaW50ZXIg
aXMgJXAgKCVwKVxuIiwNCi0tLSA2MzEsNjUxIC0tLS0NCiAgICAgICAgZWxz
ZSBpZiAoISBteV9wYWRkaW5nX2FjdGl2ZSkNCiAgICAgICAgew0KICAgICAg
ICAgIC8qIEVhc3kgY2FzZS4gKi8NCiEgICAgICAgICBHQS0+ZGF0YSA9IG1h
bGxvYyAoKHNpemVfdCkgR0EtPmV4dHJhcy0+bnBvaW50cyAqIEdBLT52YXJz
aXplICogR0EtPnZlY3Rvcl9zaXplKTsNCiAgICAgICAgICBHQS0+cGFkZGRh
dGEgPSBHQS0+ZGF0YTsNCiAgICAgICAgfQ0KICAgICAgICBlbHNlDQogICAg
ICAgIHsNCiAgICAgICAgICAvKiBVc2UgdGhlIENhY3R1cyBDYWNoZSBhbGln
bm1lbnQgZnVuY3Rpb24gKi8NCiAgICAgICAgICBHQS0+ZGF0YSA9IFV0aWxf
Q2FjaGVNYWxsb2MgKEdBLT5hcnJheWlkLA0KISAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgKHNpemVfdCkgR0EtPmV4dHJhcy0+bnBv
aW50cyAqIEdBLT52YXJzaXplICogR0EtPnZlY3Rvcl9zaXplLA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJkdBLT5wYWRkZGF0
YSk7DQogICAgICAgIH0NCisgICAgICAgaWYgKCFHQS0+ZGF0YSkNCisgICAg
ICAgew0KKyAJQ0NUS19WV2FybigwLCBfX0xJTkVfXywgX19GSUxFX18sIEND
VEtfVEhPUk5TVFJJTkcsICJFcnJvciBhbGxvY2F0aW5nIG1lbW9yeSBibG9j
ayBvZiBzaXplICINCisgCQkgICAiJWx1IiwgKHNpemVfdCkgR0EtPmV4dHJh
cy0+bnBvaW50cyAqIEdBLT52YXJzaXplICogR0EtPnZlY3Rvcl9zaXplKTsN
CisgICAgICAgfQ0KICAgICAgICBHQS0+bnBvaW50cyA9IEdBLT5leHRyYXMt
Pm5wb2ludHM7DQogICNpZmRlZiBERUJVR19QVUdIDQogICAgICAgIHByaW50
ZiAoIiBQVUdIX0VuYWJsZUdBcnJheURhdGFTdG9yYWdlOiBuZXcgcG9pbnRl
ciBpcyAlcCAoJXApXG4iLA0K


--- StripMime Report -- processed MIME parts ---
multipart/mixed
  text/plain (text body -- kept)
  text/plain (text body -- kept)
---

From schnetter at cct.lsu.edu  Fri Apr  6 17:21:51 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 7 Apr 2007 00:21:51 +0200
Subject: [Developers] [Patches] fix to integer overflow bug in PUGH
In-Reply-To: <Pine.LNX.4.60.0704061529460.21970@sshserv2.aei.mpg.de>
References: <Pine.LNX.4.60.0704061529460.21970@sshserv2.aei.mpg.de>
Message-ID: <6DA304AC-506A-4EE3-9824-78F358E67E37@cct.lsu.edu>

On Apr 6, 2007, at 15:36:25, David Rideout wrote:

> The malloc calls in PUGH compute the size to allocate from an int  
> expression. This patch casts such expressions to size_t.  This  
> fixes PR 2088.
>
> Patch also includes a check that malloc returns a non-NULL result...

The patch looks fine with one exception.  You cannot print a value of  
type size_t with %lu.  I suggest to convert the value to double and  
to print it with %f instead.

-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/20070407/f545a343/attachment.bin 

From d.rideout at imperial.ac.uk  Fri Apr  6 17:33:23 2007
From: d.rideout at imperial.ac.uk (Rideout, David P)
Date: Fri, 6 Apr 2007 23:33:23 +0100
Subject: [Developers] [Patches] fix to integer overflow bug in PUGH
References: <Pine.LNX.4.60.0704061529460.21970@sshserv2.aei.mpg.de>
	<6DA304AC-506A-4EE3-9824-78F358E67E37@cct.lsu.edu>
Message-ID: <32DB9F7418A0734089B73B858EA20FEB87FA@icex6.ic.ac.uk>

How about casting it to an unsigned long instead?  (Just because in principle one may be interested in the exact value.)

-David


-----Original Message-----
From: developers-bounces at cactuscode.org on behalf of Erik Schnetter
Sent: Fri 06-Apr-07 11:21 PM
To: developers at cactuscode.org
Subject: Re: [Developers] [Patches] fix to integer overflow bug in PUGH
 
On Apr 6, 2007, at 15:36:25, David Rideout wrote:

> The malloc calls in PUGH compute the size to allocate from an int  
> expression. This patch casts such expressions to size_t.  This  
> fixes PR 2088.
>
> Patch also includes a check that malloc returns a non-NULL result...

The patch looks fine with one exception.  You cannot print a value of  
type size_t with %lu.  I suggest to convert the value to double and  
to print it with %f instead.

-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: not available
Type: application/ms-tnef
Size: 3283 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070406/fd730364/attachment.bin 

From schnetter at cct.lsu.edu  Fri Apr  6 18:13:55 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 7 Apr 2007 01:13:55 +0200
Subject: [Developers] [Patches] fix to integer overflow bug in PUGH
In-Reply-To: <32DB9F7418A0734089B73B858EA20FEB87FA@icex6.ic.ac.uk>
References: <Pine.LNX.4.60.0704061529460.21970@sshserv2.aei.mpg.de>
	<6DA304AC-506A-4EE3-9824-78F358E67E37@cct.lsu.edu>
	<32DB9F7418A0734089B73B858EA20FEB87FA@icex6.ic.ac.uk>
Message-ID: <E63AECEC-D46E-4456-A750-E628A87E20E7@cct.lsu.edu>

That works only when you can guarantee that a size_t fits into an  
unsigned long.  This may not be true in general.  You could use  
unsigned long long instead, but this type does not exist on all  
platforms.

If the value fits into a double, i.e., if you have less than about  
10^15, then a double is exact.

-erik

On Apr 7, 2007, at 00:33:23, Rideout, David P wrote:

> How about casting it to an unsigned long instead?  (Just because in  
> principle one may be interested in the exact value.)
>
> -David
>
>
> -----Original Message-----
> From: developers-bounces at cactuscode.org on behalf of Erik Schnetter
> Sent: Fri 06-Apr-07 11:21 PM
> To: developers at cactuscode.org
> Subject: Re: [Developers] [Patches] fix to integer overflow bug in  
> PUGH
>
> On Apr 6, 2007, at 15:36:25, David Rideout wrote:
>
>> The malloc calls in PUGH compute the size to allocate from an int
>> expression. This patch casts such expressions to size_t.  This
>> fixes PR 2088.
>>
>> Patch also includes a check that malloc returns a non-NULL result...
>
> The patch looks fine with one exception.  You cannot print a value of
> type size_t with %lu.  I suggest to convert the value to double and
> to print it with %f instead.
>
> -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.
>
>
>
>
>
> <winmail.dat>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers


-- 
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/20070407/7222ec21/attachment-0001.bin 

From jthorn at aei.mpg.de  Sat Apr  7 02:09:45 2007
From: jthorn at aei.mpg.de (Jonathan Thornburg)
Date: Sat, 7 Apr 2007 09:09:45 +0200 (CEST)
Subject: [Developers] [Patches] fix to integer overflow bug in PUGH
In-Reply-To: <E63AECEC-D46E-4456-A750-E628A87E20E7@cct.lsu.edu>
References: <Pine.LNX.4.60.0704061529460.21970@sshserv2.aei.mpg.de>
	<6DA304AC-506A-4EE3-9824-78F358E67E37@cct.lsu.edu>
	<32DB9F7418A0734089B73B858EA20FEB87FA@icex6.ic.ac.uk>
	<E63AECEC-D46E-4456-A750-E628A87E20E7@cct.lsu.edu>
Message-ID: <Pine.LNX.4.63.0704070854280.23086@xeon44.aei.mpg.de>

[[how to print a size_t]]
David Rideout suggested:
> How about casting it to an unsigned long instead?  (Just because in
> principle one may be interested in the exact value.)

On Sat, 7 Apr 2007, Erik Schnetter wrote:
> That works only when you can guarantee that a size_t fits into an unsigned
> long.  This may not be true in general.  You could use unsigned long long
> instead, but this type does not exist on all platforms.
> 
> If the value fits into a double, i.e., if you have less than about 10^15, then
> a double is exact.

C99 <stdint.h> defines the types   intmax_t  and  uintmax_t  for just
this purpose (they're guaranteed to be big enough to hold any
integer/unsigned-integer type in the language standard), with
corresponding C99 printf formats   '%jd   or   %ju   .

What I'm not clear on, however, is whether  intmax_t  is guaranteed
to be big enough to hold a  long long  .

On the other hand, C99 also guarantees that 'long long' and
'unsigned long long' exist (i.e. they're not syntax errors).  On some
lame system they might not be any bigger than 'long' and 'unsigned long'
respectively, though.

Overall, I like Erik's proposal of converting to a  double .
An IEEE double  will hold any integer up to 53 bits exactly
and I strongly suspect that if there are any computers in the world
with 2^53 bytes of addressable memory, they're reserved for spooks
designing H-bombs or pattern-matching every {E-mail,fax,phone call}
in the world, and not available for Cactus.

ciao,

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>      
   School of Mathematics, U of Southampton, England
   "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 schnetter at cct.lsu.edu  Sat Apr  7 04:18:37 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 7 Apr 2007 11:18:37 +0200
Subject: [Developers] [Patches] fix to integer overflow bug in PUGH
In-Reply-To: <Pine.LNX.4.63.0704070854280.23086@xeon44.aei.mpg.de>
References: <Pine.LNX.4.60.0704061529460.21970@sshserv2.aei.mpg.de>
	<6DA304AC-506A-4EE3-9824-78F358E67E37@cct.lsu.edu>
	<32DB9F7418A0734089B73B858EA20FEB87FA@icex6.ic.ac.uk>
	<E63AECEC-D46E-4456-A750-E628A87E20E7@cct.lsu.edu>
	<Pine.LNX.4.63.0704070854280.23086@xeon44.aei.mpg.de>
Message-ID: <9D4E5AFB-1E53-415D-9B30-079F0CDA250D@cct.lsu.edu>

On Apr 7, 2007, at 09:09:45, Jonathan Thornburg wrote:

> [[how to print a size_t]]
> David Rideout suggested:
>> How about casting it to an unsigned long instead?  (Just because in
>> principle one may be interested in the exact value.)
>
> On Sat, 7 Apr 2007, Erik Schnetter wrote:
>> That works only when you can guarantee that a size_t fits into an  
>> unsigned
>> long.  This may not be true in general.  You could use unsigned  
>> long long
>> instead, but this type does not exist on all platforms.
>>
>> If the value fits into a double, i.e., if you have less than about  
>> 10^15, then
>> a double is exact.
>
> C99 <stdint.h> defines the types   intmax_t  and  uintmax_t  for just
> this purpose (they're guaranteed to be big enough to hold any
> integer/unsigned-integer type in the language standard), with
> corresponding C99 printf formats   '%jd   or   %ju   .

Cactus doesn't yet require a C99 compiler.  While I tend to use C99  
features in my own thorns, I don't know whether we should do that in  
PUGH if there is an easy work-around.

> What I'm not clear on, however, is whether  intmax_t  is guaranteed
> to be big enough to hold a  long long  .

intmax_t is by definition large enough to hold a long long; you mean  
size_t.  I believe it is large enough for a size_t as well.  (It may  
not be large enough to hold a void *, but this is irrelevant here.)

> On the other hand, C99 also guarantees that 'long long' and
> 'unsigned long long' exist (i.e. they're not syntax errors).  On some
> lame system they might not be any bigger than 'long' and 'unsigned  
> long'
> respectively, though.
>
> Overall, I like Erik's proposal of converting to a  double .
> An IEEE double  will hold any integer up to 53 bits exactly
> and I strongly suspect that if there are any computers in the world
> with 2^53 bytes of addressable memory, they're reserved for spooks
> designing H-bombs or pattern-matching every {E-mail,fax,phone call}
> in the world, and not available for Cactus.

I've just installed Cactus on a system (www.lite3d.com) which has  
2^42 bytes of addressable memory.  In words these are four Terabytes.  
This is a visualisation machine called "Beast" in Lafayette, Louisiana.

-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/20070407/ecd32c23/attachment.bin 

From schnetter at cct.lsu.edu  Sat Apr  7 05:40:46 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 7 Apr 2007 12:40:46 +0200
Subject: [Developers] Changing the output directory at run time
Message-ID: <55DBE778-CD2B-4F4B-8B01-05012D4EDC7D@cct.lsu.edu>

I notice that IO::out_dir is marked "STEERABLE=recover".  Could this  
be changed to "STEERABLE=always"?  This would make it possible to  
change the output directory while a job is running.  This could be  
used to divert output from an almost-full to a less full file system.

-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/20070407/5b439327/attachment.bin 

From szilagyi at aei.mpg.de  Sat Apr  7 07:10:27 2007
From: szilagyi at aei.mpg.de (Bela Szilagyi)
Date: Sat, 7 Apr 2007 14:10:27 +0200
Subject: [Developers] Changing the output directory at run time
In-Reply-To: <55DBE778-CD2B-4F4B-8B01-05012D4EDC7D@cct.lsu.edu>
References: <55DBE778-CD2B-4F4B-8B01-05012D4EDC7D@cct.lsu.edu>
Message-ID: <200704071410.27072.szilagyi@aei.mpg.de>

I am always in favor of steerability.

Question: would non-ASCII output files be closed in case the output file path 
changes between two IO iterations?  If not, adding this feature could be 
useful.


On Saturday 07 April 2007 12:40, Erik Schnetter wrote:
> I notice that IO::out_dir is marked "STEERABLE=recover".  Could this
> be changed to "STEERABLE=always"?  This would make it possible to
> change the output directory while a job is running.  This could be
> used to divert output from an almost-full to a less full file system.
>
> -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  Tue Apr 10 08:34:01 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 10 Apr 2007 15:34:01 +0200
Subject: [Developers] Thorns with names ending in "dummy"
Message-ID: <D1E8394B-17C5-48F2-BE0F-874FCF58BB3D@cct.lsu.edu>

Is it not possible to have a thorn with a name ending in "dummy"?  I  
tried, and while the CST stage seems to succeed, a

	make *-build BUILDLIST="name_dummy"

fails with

	nothing known about "name_dummy"

-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/20070410/18fc2a07/attachment.bin 

From kellerma at aei.mpg.de  Thu Apr 12 11:05:26 2007
From: kellerma at aei.mpg.de (Thorsten Kellermann)
Date: Thu, 12 Apr 2007 18:05:26 +0200
Subject: [Developers] Problems with reduced Output
Message-ID: <461E58C6.8000508@aei.mpg.de>

Hi Guys

Have a look to the following part of a rho.maximum.asc file:
If you look at the first or the second column you see that the out  is
total rubish, but I don't have an Idea, what's the reason for this.

Thorsten

# WHISKY::rho (rho)
# 1:iteration 2:time 3:data
0 0 0.00127974142134457
20 0.75 0.00127937109137844
320 12 0.00127917455918501
20 0.75 0.00127937109137844
330 12.375 0.00127917350377079
340 12.75 0.00127917253626571
3760 141 0.0012740948753517
350 13.125 0.00127917162597406
360 13.5 0.00127917069301417
30 1.125 0.00127935252494914
10 0.375 0.00127950263865231
30 1.125 0.00127935252494914
370 13.875 0.00127916966952999
380 14.25 0.00127916853757339
3770 141.375 0.00127409381515449
390 14.625 0.00127916731856458
400 15 0.00127916603472211
40 1.5 0.00127934649344432
20 0.75 0.00127937109137844
40 1.5 0.00127934649344432
410 15.375 0.00127916469003562
420 15.75 0.00127916327599524
3780 141.75 0.00127409317919424
430 16.125 0.00127916177534616
440 16.5 0.0012791601697696
50 1.875 0.00127930788919816
30 1.125 0.00127935252494914
450 16.875 0.00127915845740504
50 1.875 0.00127930788919816
460 17.25 0.00127915666640605
3790 142.125 0.00127409282371877
470 17.625 0.00127915493279127
480 18 0.00127915384966087
60 2.25 0.00127927160873322
490 18.375 0.00127915555639189
40 1.5 0.00127934649344432
60 2.25 0.00127927160873322
500 18.75 0.00127916409586219
510 19.125 0.0012791751900817


From schnetter at cct.lsu.edu  Thu Apr 12 11:22:07 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Thu, 12 Apr 2007 11:22:07 -0500
Subject: [Developers] Problems with reduced Output
In-Reply-To: <461E58C6.8000508@aei.mpg.de>
References: <461E58C6.8000508@aei.mpg.de>
Message-ID: <F1E512E2-A89B-44DE-B0D3-51B19EDFB69C@cct.lsu.edu>

On Apr 12, 2007, at 11:05:26, Thorsten Kellermann wrote:

> Hi Guys
>
> Have a look to the following part of a rho.maximum.asc file:
> If you look at the first or the second column you see that the out  is
> total rubish, but I don't have an Idea, what's the reason for this.

You have probably two simulations writing to the same file at the  
same time.

If you are running on Peyote: This machine has currently problems  
stopping jobs.  If a job has vanished from the queue, it may continue  
to run (and slow down other jobs).  One remedy is to never re-use old  
output directories; always choose new directories with new names.

-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/20070412/1a74c11c/attachment.bin 

From jtao at cct.lsu.edu  Fri Apr 13 13:36:55 2007
From: jtao at cct.lsu.edu (jtao at cct.lsu.edu)
Date: Fri, 13 Apr 2007 13:36:55 -0500
Subject: [Developers] question about Cactus scheduler
Message-ID: <20070413133655.3h06tsg2z48wwkkw@webmail.cct.lsu.edu>

I noticed that MoL_DecrementCounter is scheduled
"IN MoL_Step AFTER MoL_Step". I am just curious if that
is a legal statement in Cactus. If it is, what does that mean ?

schedule MoL_DecrementCounter IN MoL_Step AFTER MoL_Step BEFORE MoL_PostStep
{
   LANG: C
   OPTIONS: LEVEL
} "Decrement the counter number"

Regards,
Jian


From jtao at cct.lsu.edu  Sat Apr 14 06:15:01 2007
From: jtao at cct.lsu.edu (jtao at cct.lsu.edu)
Date: Sat, 14 Apr 2007 06:15:01 -0500
Subject: [Developers] How about changing avoid_origin* restricted ?
Message-ID: <20070414061501.u03gcrjw9wgkoc0s@webmail.cct.lsu.edu>

It is sometime necessary to check if the grid contains origin.
If avoid_origin parameters can be accessed directly,
one doesn't have to do explicit checking. Is it ok to change
those avoid_origin parameters restricted ?

Regards,
Jian


From schnetter at cct.lsu.edu  Sat Apr 14 07:26:56 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 14 Apr 2007 08:26:56 -0400
Subject: [Developers] question about Cactus scheduler
In-Reply-To: <20070413133655.3h06tsg2z48wwkkw@webmail.cct.lsu.edu>
References: <20070413133655.3h06tsg2z48wwkkw@webmail.cct.lsu.edu>
Message-ID: <D0240961-0D02-4A9E-BF56-012F6B03322E@cct.lsu.edu>

On Apr 13, 2007, at 14:36:55, jtao at cct.lsu.edu wrote:

> I noticed that MoL_DecrementCounter is scheduled
> "IN MoL_Step AFTER MoL_Step". I am just curious if that
> is a legal statement in Cactus. If it is, what does that mean ?
>
> schedule MoL_DecrementCounter IN MoL_Step AFTER MoL_Step BEFORE  
> MoL_PostStep
> {
>    LANG: C
>    OPTIONS: LEVEL
> } "Decrement the counter number"

Yes, this is legal, although the AFTER statement is meaningless in  
this case.  If a schedule item mentioned in a BEFORE or AFTER clause  
is not present, then this clause is ignored.  This is necessary to  
handle the case where a thorn may or may not be active, and the  
schedule must be restricted only if the thorn is active.

-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/20070414/5050cde9/attachment-0001.bin 

From schnetter at cct.lsu.edu  Sat Apr 14 09:09:52 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 14 Apr 2007 10:09:52 -0400
Subject: [Developers] How about changing avoid_origin* restricted ?
In-Reply-To: <20070414061501.u03gcrjw9wgkoc0s@webmail.cct.lsu.edu>
References: <20070414061501.u03gcrjw9wgkoc0s@webmail.cct.lsu.edu>
Message-ID: <C1A07C0E-9EB1-45B3-9807-8D7C0D6FC82E@cct.lsu.edu>

On Apr 14, 2007, at 07:15:01, jtao at cct.lsu.edu wrote:

> It is sometime necessary to check if the grid contains origin.
> If avoid_origin parameters can be accessed directly,
> one doesn't have to do explicit checking. Is it ok to change
> those avoid_origin parameters restricted ?

I'm afraid that this would not work in the general case.  Even  
CartGrid3D ignores the avoid_origin parameter under certain  
circumstances.  CoordBase does not take them into account.  With mesh  
refinement, avoid_origin describes only the coarsest grid, and finer  
grids can have different behaviour.  avoid_origin is meant for a  
human being to give instructions to CartGrid3D.  It is not a good  
idea to use it to draw conclusions about how the grid is laid out in  
the end.

Instead, you can calculate the quantity

CCTK_REAL nx0 = (0.0 - CCTK_ORIGIN_SPACE(0)) / CCTK_DELTA_SPACE(0)

and test whether it is integer or not:

if (fabs (nx0 - floor(nx0)) < 0.01) /* grid point at origin */

else if (fabs (nx0 - floor(nx0) + 0.5) < 0.01) /* staggered about  
origin */

else /* no definite relation */

-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/20070414/54370910/attachment.bin 

From tradke at aei.mpg.de  Mon Apr 16 05:30:55 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Mon, 16 Apr 2007 12:30:55 +0200
Subject: [Developers] Changing the output directory at run time
In-Reply-To: <200704071410.27072.szilagyi@aei.mpg.de>
References: <55DBE778-CD2B-4F4B-8B01-05012D4EDC7D@cct.lsu.edu>
	<200704071410.27072.szilagyi@aei.mpg.de>
Message-ID: <4623505F.2060600@aei.mpg.de>

Bela Szilagyi wrote:
> I am always in favor of steerability.
> 
> Question: would non-ASCII output files be closed in case the output file path 
> changes between two IO iterations?  If not, adding this feature could be 
> useful.

Making IO::out_dir fully steerable is certainly doable but - for 
consistency - requires changes in all I/O thorns which share this I/O 
parameter. I'd rather limit necessary changes to individual thorns for 
now, making their own output/checkpoint directory parameters steerable. 
One could start with CarpetIOHDF5 and CarpetIOASCII.

Before implementing anything we should clearly define what should happen 
when switching to a different output directory. HDF5 files will surely 
be created anew. What about existing ASCII output files, should they 
also be split or appended in the old outdir ? Would it suffice to make 
the checkpoint directory steerable ?

-- 
Cheers, Thomas.


> On Saturday 07 April 2007 12:40, Erik Schnetter wrote:
> 
>>I notice that IO::out_dir is marked "STEERABLE=recover".  Could this
>>be changed to "STEERABLE=always"?  This would make it possible to
>>change the output directory while a job is running.  This could be
>>used to divert output from an almost-full to a less full file system.
>>
>>-erik
> 
> 

From schnetter at cct.lsu.edu  Mon Apr 16 06:47:26 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 16 Apr 2007 07:47:26 -0400
Subject: [Developers] Changing the output directory at run time
In-Reply-To: <4623505F.2060600@aei.mpg.de>
References: <55DBE778-CD2B-4F4B-8B01-05012D4EDC7D@cct.lsu.edu>
	<200704071410.27072.szilagyi@aei.mpg.de>
	<4623505F.2060600@aei.mpg.de>
Message-ID: <DF8B103A-A475-4E60-97A5-34584E1CE0A6@cct.lsu.edu>

On Apr 16, 2007, at 06:30:55, Thomas Radke wrote:

> Bela Szilagyi wrote:
>> I am always in favor of steerability.
>>
>> Question: would non-ASCII output files be closed in case the  
>> output file path
>> changes between two IO iterations?  If not, adding this feature  
>> could be
>> useful.
>
> Making IO::out_dir fully steerable is certainly doable but - for
> consistency - requires changes in all I/O thorns which share this I/O
> parameter. I'd rather limit necessary changes to individual thorns for
> now, making their own output/checkpoint directory parameters  
> steerable.
> One could start with CarpetIOHDF5 and CarpetIOASCII.
>
> Before implementing anything we should clearly define what should  
> happen
> when switching to a different output directory. HDF5 files will surely
> be created anew. What about existing ASCII output files, should they
> also be split or appended in the old outdir ? Would it suffice to make
> the checkpoint directory steerable ?

I think ASCII files should be created anew.  That is, the old part of  
the output will remain in the old output directory, and the new  
output will be in the new output directory.

The checkpoint directory is not that important, because checkpointing  
requires only a constant amount of space, since old checkpoint files  
are deleted.  As some ASCII output files are large, all output files  
should go into the new directory.  For consistency, all output should  
stay together.

-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/20070416/2ad89c68/attachment.bin 

From yye00 at cct.lsu.edu  Tue Apr 17 20:25:19 2007
From: yye00 at cct.lsu.edu (Yaakoub Y El Khamra)
Date: Tue, 17 Apr 2007 20:25:19 -0500
Subject: [Developers] new reduction patches
Message-ID: <4625737F.9010404@cct.lsu.edu>


Greetings
Please find attached early patches to the new GridArray and LocalArray 
reduction interfaces through PUGHReduce. Please keep in mind that lots 
of files got cleaned up and functions were put in logical order 
(separated new and old interfaces). To follow the same logical scheme, 
some files got renamed: ReduceGA.c and ReduceArraysGlobally.c.
The patches for other thorns will follow shortly.

Cheers
Yaakoub
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cctk_Reduction.h_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070417/ea477288/attachment-0004.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Reduction.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070417/ea477288/attachment-0005.pl 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReduceGridArrays.c
Type: text/x-csrc
Size: 106190 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070417/ea477288/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReduceLocalArrays.c
Type: text/x-csrc
Size: 105839 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070417/ea477288/attachment-0003.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: make.code.defn_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070417/ea477288/attachment-0006.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Startup.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070417/ea477288/attachment-0007.pl 

From yye00 at cct.lsu.edu  Tue Apr 17 20:28:04 2007
From: yye00 at cct.lsu.edu (Yaakoub Y El Khamra)
Date: Tue, 17 Apr 2007 20:28:04 -0500
Subject: [Developers] new reduction patches, IOBasic
Message-ID: <46257424.8020904@cct.lsu.edu>


Please find attached the new reduction patches for IOBasic

Cheers
Yaakoub
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Startup.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070417/b083e405/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: WriteInfo.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070417/b083e405/attachment-0001.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: WriteScalar.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070417/b083e405/attachment-0002.pl 

From dprideout at gmail.com  Wed Apr 18 08:03:03 2007
From: dprideout at gmail.com (David Rideout)
Date: Wed, 18 Apr 2007 14:03:03 +0100
Subject: [Developers] unstructured mesh driver
Message-ID: <1ce81abb0704180603p5a846ae9s24a5057b2d2cc7e5@mail.gmail.com>

In August 2005 I wrote an implementation of the unstructured mesh
specification at
http://www.cactuscode.org/specs/Unstructured.html.  This includes a
driver UMDriver and modifications to the flesh.  Both are available at

cvs -d:pserver:cvs_anon at cvs.cct.lsu.edu:/Frameworks co CactusUMT

I did not submit the flesh changes as a patch, because I did not think
them appropriate for version 4.0, however I submit them now for
completeness.  They can be found in
CactusUMT/UMDriver/src/UnstructuredFlesh-5oct005.tbz.

Cheers,
David

From schnetter at cct.lsu.edu  Wed Apr 18 13:00:03 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 18 Apr 2007 13:00:03 -0500
Subject: [Developers] Thorns with names ending in "dummy"
In-Reply-To: <D1E8394B-17C5-48F2-BE0F-874FCF58BB3D@cct.lsu.edu>
References: <D1E8394B-17C5-48F2-BE0F-874FCF58BB3D@cct.lsu.edu>
Message-ID: <C82FAE4D-206E-462A-B41C-A011A1A57C7F@cct.lsu.edu>

On Apr 10, 2007, at 08:34:01, Erik Schnetter wrote:

> Is it not possible to have a thorn with a name ending in "dummy"?   
> I tried, and while the CST stage seems to succeed, a
>
> 	make *-build BUILDLIST="name_dummy"
>
> fails with
>
> 	nothing known about "name_dummy"

I found the place.  In lib/sbin/CST, "dummy" is unconditionally  
replaced by the empty string while sorting the list of thorns.

-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/20070418/335d5650/attachment.bin 

From yye00 at cct.lsu.edu  Wed Apr 18 13:53:27 2007
From: yye00 at cct.lsu.edu (Yaakoub Y El Khamra)
Date: Wed, 18 Apr 2007 13:53:27 -0500
Subject: [Developers] more patches
Message-ID: <46266927.8070102@cct.lsu.edu>


Greetings
These patches go to TestGlobalReduce and TestLocalReduce and IOJpeg. 
Also please find attached 2 cleaned up files for PUGHReduce, I had to 
make some modifications based on a conversation with Erik this morning. 
I will be going over the spec in more detail in the near future.

Cheers
Yaakoub
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Reduce_Avg.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070418/1ce12d33/attachment-0005.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Reduce_Maximum.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070418/1ce12d33/attachment-0006.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Reduce_Sum.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070418/1ce12d33/attachment-0007.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TestGlobalReduce.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070418/1ce12d33/attachment-0008.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Write.c_diff
Url: http://www.cactuscode.org/pipermail/developers/attachments/20070418/1ce12d33/attachment-0009.pl 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReduceGridArrays.c
Type: text/x-csrc
Size: 108863 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070418/1ce12d33/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReduceLocalArrays.c
Type: text/x-csrc
Size: 108519 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070418/1ce12d33/attachment-0003.bin 

From schnetter at cct.lsu.edu  Tue Apr 24 09:43:13 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 24 Apr 2007 09:43:13 -0500
Subject: [Developers] Thorn dependencies
Message-ID: <B49F313E-0079-4209-A1B5-35161CC37914@cct.lsu.edu>

I just activated the thorns Carpet and PUGHInterp together, because I  
made a mistake when editing a parameter file.  Surprisingly, Cactus  
did not complain.  Of course, I received a segmentation fault at run  
time.

I suggest to change the "REQUIRES PUGH" in PUGHInterp to "REQUIRES  
THORN PUGH", so that Cactus ensures that PUGH is active whenever  
PUGHInterp is active.  Similar changes should be made to other thorns.

-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/20070424/144c6666/attachment.bin 

From schnetter at cct.lsu.edu  Sat Apr 28 17:33:15 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 28 Apr 2007 17:33:15 -0500
Subject: [Developers] Fwd: [CactusMaint] CactusUtils/2079: Patch for thorn
	TimerReport: Output timer reports to a file instead of to stdout
References: <A1038CDF-FAAE-4F6D-9E2C-296EFF6916D1@cct.lsu.edu>
Message-ID: <90E0CFE4-3E58-48F9-BC36-8BEB16B42F85@cct.lsu.edu>

Begin forwarded message:

> From: Erik Schnetter <schnetter at cct.lsu.edu>
> Date: April 28, 2007 5:04:16 PM CDT
> To: Cactus Maintainers <cactusmaint at cactuscode.org>,  
> bugs at cactuscode.org, Tom Goodale <goodale at cct.lsu.edu>, gnats- 
> admin at cactuscode.org
> Subject: Re: [CactusMaint] CactusUtils/2079: Patch for thorn  
> TimerReport: Output timer reports to a file instead of to stdout
> Reply-To: CactusMaint <cactusmaint at cactuscode.org>
>
> http://www.cactuscode.org/cactus_cgi-bin/gnatsweb.pl?cmd=view% 
> 20audit-trail&database=cactus&pr=2079
>
> I have added a patch that implements a new flesh function  
> CCTK_SchedulePrintTimesToFile.  The internal schedule printing  
> functions take an additional FILE* argument, and the existing  
> CCTK_SchedulePrintTimes prints to stdout.
>
> -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.
>
>
>
> _______________________________________________
> CactusMaint site list
> CactusMaint at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/cactusmaint


-- 
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/20070428/c8d2aa7a/attachment.bin