From smirnov at ms2.inr.ac.ru  Wed Jan 10 06:15:35 2007
From: smirnov at ms2.inr.ac.ru (A.Smirnov)
Date: Wed, 10 Jan 2007 15:15:35 +0300
Subject: [Developers] THORNLIST option
Message-ID: <20070110121535.GA32660@ms2.inr.ac.ru>

Hi, 
my question is about THORNLIST, THORNLIST_DIR, PROMPT, WARN options.

In the root Makefile these options are processed when  
setup_configuration.pl script was finished. Since setup_configuaration.pl
is responsible for setting options from config file (as environment variables),
it is not possible to get these options values  when setup_configuration.pl 
is finished. So, placing mentioned options into config file is useless.  

Maybe it is worth adding possibility to set THORNLIST, THORNLIST_DIR, PROMPT, 
WARN options from config file ?

Best regards, 
Alexey.  

From schnetter at cct.lsu.edu  Wed Jan 10 16:13:58 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 10 Jan 2007 16:13:58 -0600
Subject: [Developers] THORNLIST option
In-Reply-To: <20070110121535.GA32660@ms2.inr.ac.ru>
References: <20070110121535.GA32660@ms2.inr.ac.ru>
Message-ID: <ACF6CCCA-D85E-42A9-BA0F-0971B9365D14@cct.lsu.edu>

On Jan 10, 2007, at 06:15:35, A.Smirnov wrote:

> Hi,
> my question is about THORNLIST, THORNLIST_DIR, PROMPT, WARN options.
>
> In the root Makefile these options are processed when
> setup_configuration.pl script was finished. Since  
> setup_configuaration.pl
> is responsible for setting options from config file (as environment  
> variables),
> it is not possible to get these options values  when  
> setup_configuration.pl
> is finished. So, placing mentioned options into config file is  
> useless.
>
> Maybe it is worth adding possibility to set THORNLIST,  
> THORNLIST_DIR, PROMPT,
> WARN options from config file ?

The WARN option is already supported in the config file.  It sets a  
default that can be overwritten when the configuration is built.

The THORNLIST and THORNLIST_DIR are currently not supported, because  
we didn't think it would be useful.  When we create a configuration,  
then we usually use a set of options and a thorn list, and combine  
these for form a configuration.  We usually use the same set of  
options for different thorn lists, hence specifying a specific thorn  
list together with the options is not useful for us.

Of course, this is just how we use Cactus.  If you use Cactus  
differently, then adding THORNLIST and THORNLIST_DIR may be useful  
for you.  Especially THORNLIST_DIR may make sense  if you keep all  
your thorn lists in the same directory.  And PROMPT should be treated  
in the same way as WARN.

If others agree as well, do you then want to open a feature request?   
Or maybe even a patch?  Since WARN is already handled, you would  
handle the other options in the same way.

-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/20070110/9ccf5b25/attachment-0001.bin 

From jthorn at aei.mpg.de  Fri Jan 12 07:19:56 2007
From: jthorn at aei.mpg.de (Jonathan Thornburg)
Date: Fri, 12 Jan 2007 14:19:56 +0100 (CET)
Subject: [Developers] should we document that CCTK_MyProc(NULL) works?
Message-ID: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>

Hi,

With all current drivers (or at least all known to the people I've
talked to), it's legal to call CCTK_MyProc() with a NULL GH pointer,
and doing so works (CCTK_MyProc() returns the correct result).

IMHO this is very useful behavior.  For example, it lets code which
doesn't have a GH still generate unique filenames for logging debug
data.  The problem is, right now this behavior is not documented in
the Cactus Reference Manual.

Does anyone object to my documenting the current behavior in the
Cactus Reference Manual?  Should we go farther and also promise
(document) that this is guaranteed to work for any driver?

ciao,

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>      
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam


From dprideout at gmail.com  Fri Jan 12 07:29:46 2007
From: dprideout at gmail.com (David Rideout)
Date: Fri, 12 Jan 2007 13:29:46 +0000
Subject: [Developers] should we document that CCTK_MyProc(NULL) works?
In-Reply-To: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
References: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
Message-ID: <1ce81abb0701120529v2ebe84bfy39a15f66bcd21964@mail.gmail.com>

If it is guaranteed to work then there is no need for the argument.
Perhaps you might write that most drivers behave this way, but there
is no guarantee?  And that the calling routine might check that it
returns a valid (non-negative) value?

Cheers,
David

On 1/12/07, Jonathan Thornburg <jthorn at aei.mpg.de> wrote:
> Hi,
>
> With all current drivers (or at least all known to the people I've
> talked to), it's legal to call CCTK_MyProc() with a NULL GH pointer,
> and doing so works (CCTK_MyProc() returns the correct result).
>
> IMHO this is very useful behavior.  For example, it lets code which
> doesn't have a GH still generate unique filenames for logging debug
> data.  The problem is, right now this behavior is not documented in
> the Cactus Reference Manual.
>
> Does anyone object to my documenting the current behavior in the
> Cactus Reference Manual?  Should we go farther and also promise
> (document) that this is guaranteed to work for any driver?
>
> ciao,
>
> --
> -- Jonathan Thornburg <jthorn at aei.mpg.de>
>    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
>    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
>    "Washing one's hands of the conflict between the powerful and the
>     powerless means to side with the powerful, not to be neutral."
>                                       -- quote by Freire / poster by Oxfam
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>

From schnetter at cct.lsu.edu  Fri Jan 12 07:48:47 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 12 Jan 2007 07:48:47 -0600
Subject: [Developers] should we document that CCTK_MyProc(NULL) works?
In-Reply-To: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
References: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
Message-ID: <F6412FEF-2217-4174-9C65-3BDBD3BEE811@cct.lsu.edu>

On Jan 12, 2007, at 07:19:56, Jonathan Thornburg wrote:

> Hi,
>
> With all current drivers (or at least all known to the people I've
> talked to), it's legal to call CCTK_MyProc() with a NULL GH pointer,
> and doing so works (CCTK_MyProc() returns the correct result).

This is not quite true.  With Carpet, while you do get an answer and  
not a segmentation fault when passing a null pointer, the result may  
differ (or may differ in the future).  Without a GH, the driver can  
essentially only use MPI_COMM_WORLD to find MyProc and nProcs.  With  
a GH, Carpet can potentially know that there are different GHs, each  
associated with its own communicator, and each with different values  
for MyProc and nProcs.  This would be relevant in a multi-model  
environment.

Tom's idea was approximately that there could be one GH which is the  
global GH.  When passing a null pointer, Carpet would then use that  
GH implicitly.

This is currently not implemented.  For multi-model simulations,  
there is no global GH.  Instead, each Unix process has a unique GH,  
and it is this unique GH which is used if you pass a null pointer.   
But this may change.

For example, when you call MyProc or nProcs while interpolating, you  
should therefore always pass the same GH that you also pass to the  
interpolator.

-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/20070112/f650b2a3/attachment.bin 

From schnetter at cct.lsu.edu  Fri Jan 12 08:59:04 2007
From: schnetter at cct.lsu.edu (schnetter at cct.lsu.edu)
Date: Fri, 12 Jan 2007 08:59:04 -0600
Subject: [Developers] Patch: Make complex arithmetic more efficient and
	convenient
Message-ID: <D139CE54-0780-40F2-8FF6-2023AEB58956@cct.lsu.edu>

> Number:         2076
> Notify-List:
> Category:       Cactus
> Synopsis:       Patch: Make complex arithmetic more efficient and  
> convenient
> Confidential:   no
> Severity:       non-critical
> Priority:       medium
> Responsible:    goodale
> State:          open
> Class:          feature-request
> Submitter-Id:   user
> Arrival-Date:   Fri Jan 12 08:56:17 -0600 2007
> Originator:     Erik Schnetter
> Release:        Cactus 4.0.b16
> Organization:
> Environment:
> Description:
The enclosed patch makes complex arithmetic in C and C++ more  
efficient, and makes it much more convenient for C++, expecially when  
templates are used.

The flesh functions for complex arithmetic are defined (not only  
declared) by including Complex.c from the header file  
cctk_Complex.h.  They are declared "static inline", so the the  
compiler can inline them, but does not have to create an out-of-line  
copy for every source file.  Complex.c is also compiled stand-alone  
without the "static inline" prefix, so that out-of-line copies exist  
as well.

Add some new complex arithmetic functions, e.g. ComplexNeg to change  
the sign.

Make some complex arithmetic functions more efficient by using  
algorithms from glibc.  These algorithms are LGPL.  They should be  
faster and/or more accurate than the existing implementations.

For C++, define the usual arithmetic operators (+-*/ etc.) as inline  
functions calling the corresponding complex arithmetic functions.   
This makes it possible to use complex numbers in the same way as real  
numbers, which makes it possible to instantiate templates for both  
CCTK_REAL and CCTK_COMPLEX.  This leads to much code reduction in  
Carpet.
> How-To-Repeat:
> Fix:
Unknown
> Unformatted:

-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/20070112/bba276e9/attachment.bin 

From schnetter at cct.lsu.edu  Fri Jan 12 09:16:12 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 12 Jan 2007 09:16:12 -0600
Subject: [Developers] Patch: Make complex arithmetic more efficient and
	convenient
In-Reply-To: <D139CE54-0780-40F2-8FF6-2023AEB58956@cct.lsu.edu>
References: <D139CE54-0780-40F2-8FF6-2023AEB58956@cct.lsu.edu>
Message-ID: <58F8F70D-C244-4E50-9C7E-1D41DB367D07@cct.lsu.edu>

On Jan 12, 2007, at 08:59:04, schnetter at cct.lsu.edu wrote:

> For C++, define the usual arithmetic operators (+-*/ etc.) as  
> inline functions calling the corresponding complex arithmetic  
> functions.  This makes it possible to use complex numbers in the  
> same way as real numbers, which makes it possible to instantiate  
> templates for both CCTK_REAL and CCTK_COMPLEX.  This leads to much  
> code reduction in Carpet.

This would, of course, be much simpler if we defined CCTK_COMPLEX to  
be complex<CCTK_REAL> in C++.  Last time this was proposed there was  
the fear that not all C++ compilers would implement the corresponding  
part of the STL.  Does anybody know of such a C++ compiler on a  
system where C++ code in Cactus is used?

-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/20070112/573fc613/attachment.bin 

From goodale at cct.lsu.edu  Fri Jan 12 10:36:36 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Fri, 12 Jan 2007 16:36:36 +0000 (GMT)
Subject: [Developers] should we document that CCTK_MyProc(NULL) works?
In-Reply-To: <1ce81abb0701120529v2ebe84bfy39a15f66bcd21964@mail.gmail.com>
References: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
	<1ce81abb0701120529v2ebe84bfy39a15f66bcd21964@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0701121616120.4707@fandango.dyndns.org>


The only problem is that in principle drivers could be using a different 
processor mapping - e.g. when using MPI the driver could use a different 
communicator - which would give a different result with NULL than with a 
cGH, so I would prefer to not document that NULL is acceptable.  It is 
only used in the flesh in extreme cases, which are mainly before a driver 
has been initialised.

Cheers,

Tom

On Fri, 12 Jan 2007, David Rideout wrote:

> If it is guaranteed to work then there is no need for the argument.
> Perhaps you might write that most drivers behave this way, but there
> is no guarantee?  And that the calling routine might check that it
> returns a valid (non-negative) value?
>
> Cheers,
> David
>
> On 1/12/07, Jonathan Thornburg <jthorn at aei.mpg.de> wrote:
>> Hi,
>>
>> With all current drivers (or at least all known to the people I've
>> talked to), it's legal to call CCTK_MyProc() with a NULL GH pointer,
>> and doing so works (CCTK_MyProc() returns the correct result).
>>
>> IMHO this is very useful behavior.  For example, it lets code which
>> doesn't have a GH still generate unique filenames for logging debug
>> data.  The problem is, right now this behavior is not documented in
>> the Cactus Reference Manual.
>>
>> Does anyone object to my documenting the current behavior in the
>> Cactus Reference Manual?  Should we go farther and also promise
>> (document) that this is guaranteed to work for any driver?
>>
>> ciao,
>>
>> --
>> -- Jonathan Thornburg <jthorn at aei.mpg.de>
>>    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
>>    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
>>    "Washing one's hands of the conflict between the powerful and the
>>     powerless means to side with the powerful, not to be neutral."
>>                                       -- quote by Freire / poster by Oxfam
>>
>> _______________________________________________
>> 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  Fri Jan 12 10:43:25 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 12 Jan 2007 10:43:25 -0600
Subject: [Developers] should we document that CCTK_MyProc(NULL) works?
In-Reply-To: <Pine.LNX.4.64.0701121616120.4707@fandango.dyndns.org>
References: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
	<1ce81abb0701120529v2ebe84bfy39a15f66bcd21964@mail.gmail.com>
	<Pine.LNX.4.64.0701121616120.4707@fandango.dyndns.org>
Message-ID: <9BE0C08F-8E28-4D92-95E1-5F1DF5355E72@cct.lsu.edu>

Err, not documenting it at all is not a good idea.  This means that  
driver developers have to find out the hard way why their drivers  
crash, and why passing a null pointer is necessary.  I would document  
it as "MyProc and nProcs have to handle that case without crashing",  
but also telling the user that the results may not be as expected.

-erik

On Jan 12, 2007, at 10:36:36, Tom Goodale wrote:

> The only problem is that in principle drivers could be using a  
> different
> processor mapping - e.g. when using MPI the driver could use a  
> different
> communicator - which would give a different result with NULL than  
> with a
> cGH, so I would prefer to not document that NULL is acceptable.  It is
> only used in the flesh in extreme cases, which are mainly before a  
> driver
> has been initialised.
>
> Cheers,
>
> Tom
>
> On Fri, 12 Jan 2007, David Rideout wrote:
>
>> If it is guaranteed to work then there is no need for the argument.
>> Perhaps you might write that most drivers behave this way, but there
>> is no guarantee?  And that the calling routine might check that it
>> returns a valid (non-negative) value?
>>
>> Cheers,
>> David
>>
>> On 1/12/07, Jonathan Thornburg <jthorn at aei.mpg.de> wrote:
>>> Hi,
>>>
>>> With all current drivers (or at least all known to the people I've
>>> talked to), it's legal to call CCTK_MyProc() with a NULL GH pointer,
>>> and doing so works (CCTK_MyProc() returns the correct result).
>>>
>>> IMHO this is very useful behavior.  For example, it lets code which
>>> doesn't have a GH still generate unique filenames for logging debug
>>> data.  The problem is, right now this behavior is not documented in
>>> the Cactus Reference Manual.
>>>
>>> Does anyone object to my documenting the current behavior in the
>>> Cactus Reference Manual?  Should we go farther and also promise
>>> (document) that this is guaranteed to work for any driver?
>>>
>>> ciao,
>>>
>>> --
>>> -- Jonathan Thornburg <jthorn at aei.mpg.de>
>>>    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein- 
>>> Institut),
>>>    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/ 
>>> home.html
>>>    "Washing one's hands of the conflict between the powerful and the
>>>     powerless means to side with the powerful, not to be neutral."
>>>                                       -- quote by Freire / poster  
>>> by Oxfam
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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/20070112/9a2964c2/attachment.bin 

From goodale at cct.lsu.edu  Fri Jan 12 10:48:49 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Fri, 12 Jan 2007 16:48:49 +0000 (GMT)
Subject: [Developers] should we document that CCTK_MyProc(NULL) works?
In-Reply-To: <9BE0C08F-8E28-4D92-95E1-5F1DF5355E72@cct.lsu.edu>
References: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
	<1ce81abb0701120529v2ebe84bfy39a15f66bcd21964@mail.gmail.com>
	<Pine.LNX.4.64.0701121616120.4707@fandango.dyndns.org>
	<9BE0C08F-8E28-4D92-95E1-5F1DF5355E72@cct.lsu.edu>
Message-ID: <Pine.LNX.4.64.0701121646220.6560@fandango.dyndns.org>

Hi,

I'd forgotten that this could happen when I driver is present as well. 
Good point.  Drivers should certainly deal with this case.  So 
documentaing for users that the result is 'undefined' but that drivers 
will do their best is probably the best way to go.

Cheers,

Tom


On Fri, 12 Jan 2007, Erik Schnetter wrote:

> Err, not documenting it at all is not a good idea.  This means that driver 
> developers have to find out the hard way why their drivers crash, and why 
> passing a null pointer is necessary.  I would document it as "MyProc and 
> nProcs have to handle that case without crashing", but also telling the user 
> that the results may not be as expected.
>
> -erik
>
> On Jan 12, 2007, at 10:36:36, Tom Goodale wrote:
>
>> The only problem is that in principle drivers could be using a different
>> processor mapping - e.g. when using MPI the driver could use a different
>> communicator - which would give a different result with NULL than with a
>> cGH, so I would prefer to not document that NULL is acceptable.  It is
>> only used in the flesh in extreme cases, which are mainly before a driver
>> has been initialised.
>> 
>> Cheers,
>> 
>> Tom
>> 
>> On Fri, 12 Jan 2007, David Rideout wrote:
>> 
>>> If it is guaranteed to work then there is no need for the argument.
>>> Perhaps you might write that most drivers behave this way, but there
>>> is no guarantee?  And that the calling routine might check that it
>>> returns a valid (non-negative) value?
>>> 
>>> Cheers,
>>> David
>>> 
>>> On 1/12/07, Jonathan Thornburg <jthorn at aei.mpg.de> wrote:
>>>> Hi,
>>>> 
>>>> With all current drivers (or at least all known to the people I've
>>>> talked to), it's legal to call CCTK_MyProc() with a NULL GH pointer,
>>>> and doing so works (CCTK_MyProc() returns the correct result).
>>>> 
>>>> IMHO this is very useful behavior.  For example, it lets code which
>>>> doesn't have a GH still generate unique filenames for logging debug
>>>> data.  The problem is, right now this behavior is not documented in
>>>> the Cactus Reference Manual.
>>>> 
>>>> Does anyone object to my documenting the current behavior in the
>>>> Cactus Reference Manual?  Should we go farther and also promise
>>>> (document) that this is guaranteed to work for any driver?
>>>> 
>>>> ciao,
>>>> 
>>>> --
>>>> -- Jonathan Thornburg <jthorn at aei.mpg.de>
>>>>   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
>>>>   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
>>>>   "Washing one's hands of the conflict between the powerful and the
>>>>    powerless means to side with the powerful, not to be neutral."
>>>>                                      -- quote by Freire / poster by Oxfam
>>>> 
>>>> _______________________________________________
>>>> 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
>>> 
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/developers
>> 
>
>
>

From jthorn at aei.mpg.de  Fri Jan 12 11:08:16 2007
From: jthorn at aei.mpg.de (Jonathan Thornburg)
Date: Fri, 12 Jan 2007 18:08:16 +0100 (CET)
Subject: [Developers] should we document that CCTK_MyProc(NULL) works?
In-Reply-To: <Pine.LNX.4.64.0701121616120.4707@fandango.dyndns.org>
References: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
	<1ce81abb0701120529v2ebe84bfy39a15f66bcd21964@mail.gmail.com>
	<Pine.LNX.4.64.0701121616120.4707@fandango.dyndns.org>
Message-ID: <Pine.LNX.4.63.0701121806460.31683@xeon44.aei.mpg.de>

On Fri, 12 Jan 2007, Tom Goodale wrote:
> The only problem is that in principle drivers could be using a different 
> processor mapping - e.g. when using MPI the driver could use a different 
> communicator - which would give a different result with NULL than with a 
> cGH, so I would prefer to not document that NULL is acceptable.  It is 
> only used in the flesh in extreme cases, which are mainly before a driver 
> has been initialised.

It may also be of use in thorn code, though.
For example, I am currently using it for some debug code in
AEIThorns/AEILocalInterp (which is not passed a GH pointer), which
wants to generate a distinct file name for each processor so it can
log some debugging information.

ciao,

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>      
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam


From jthorn at aei.mpg.de  Fri Jan 12 11:09:16 2007
From: jthorn at aei.mpg.de (Jonathan Thornburg)
Date: Fri, 12 Jan 2007 18:09:16 +0100 (CET)
Subject: [Developers] should we document that CCTK_MyProc(NULL) works?
In-Reply-To: <Pine.LNX.4.64.0701121646220.6560@fandango.dyndns.org>
References: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
	<1ce81abb0701120529v2ebe84bfy39a15f66bcd21964@mail.gmail.com>
	<Pine.LNX.4.64.0701121616120.4707@fandango.dyndns.org>
	<9BE0C08F-8E28-4D92-95E1-5F1DF5355E72@cct.lsu.edu>
	<Pine.LNX.4.64.0701121646220.6560@fandango.dyndns.org>
Message-ID: <Pine.LNX.4.63.0701121808590.31683@xeon44.aei.mpg.de>

On Fri, 12 Jan 2007, Tom Goodale wrote:
> I'd forgotten that this could happen when I driver is present as well. 
> Good point.  Drivers should certainly deal with this case.  So 
> documentaing for users that the result is 'undefined' but that drivers 
> will do their best is probably the best way to go.

Ok, I will do this.

ciao,

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>      
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam


From schnetter at cct.lsu.edu  Fri Jan 12 11:28:19 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 12 Jan 2007 11:28:19 -0600
Subject: [Developers] should we document that CCTK_MyProc(NULL) works?
In-Reply-To: <Pine.LNX.4.63.0701121806460.31683@xeon44.aei.mpg.de>
References: <Pine.LNX.4.63.0701121416310.28098@xeon44.aei.mpg.de>
	<1ce81abb0701120529v2ebe84bfy39a15f66bcd21964@mail.gmail.com>
	<Pine.LNX.4.64.0701121616120.4707@fandango.dyndns.org>
	<Pine.LNX.4.63.0701121806460.31683@xeon44.aei.mpg.de>
Message-ID: <92BBBEFD-B08E-4A0A-9D1E-D1D3C3B66812@cct.lsu.edu>

On Jan 12, 2007, at 11:08:16, Jonathan Thornburg wrote:

> On Fri, 12 Jan 2007, Tom Goodale wrote:
>> The only problem is that in principle drivers could be using a  
>> different
>> processor mapping - e.g. when using MPI the driver could use a  
>> different
>> communicator - which would give a different result with NULL than  
>> with a
>> cGH, so I would prefer to not document that NULL is acceptable.   
>> It is
>> only used in the flesh in extreme cases, which are mainly before a  
>> driver
>> has been initialised.
>
> It may also be of use in thorn code, though.
> For example, I am currently using it for some debug code in
> AEIThorns/AEILocalInterp (which is not passed a GH pointer), which
> wants to generate a distinct file name for each processor so it can
> log some debugging information.

This may not work under all circumstances.  Of course, for debugging,  
you do not care about all possible circumstances.

-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/20070112/7faf48ee/attachment.bin 

From zachetie at yahoo.com  Fri Jan 12 13:44:54 2007
From: zachetie at yahoo.com (Zach Etienne)
Date: Fri, 12 Jan 2007 11:44:54 -0800 (PST)
Subject: [Developers] AHFinderDirect + Cartoon with bitant symmetry?
In-Reply-To: <92BBBEFD-B08E-4A0A-9D1E-D1D3C3B66812@cct.lsu.edu>
Message-ID: <526037.85114.qm@web32709.mail.mud.yahoo.com>

Hello.

We (the Illinois group) require an apparent horizon finder in Cactus that works     with Cartoon2D + bitant (i.e., "equatorial") symmetry.  Does AHFinderDirect support this combination of symmetries?  

In my version of AHFinderDirect, it says (in AHFinderDirect/doc/TODO):
    detect Cartoon and rotate geometry interpolation into Cartoon plane

Thus I'm inclined to believe the answer to my question is "no".  If this is in fact the case, does anyone have a version of AHFinderDirect that supports Cartoon+bitant symmetry?

Thanks in advance for your reply.
-Zach Etienne,
  on behalf of the Illinois Group

 
---------------------------------
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/developers/attachments/20070112/61018e69/attachment.html 

From schnetter at cct.lsu.edu  Fri Jan 12 21:17:24 2007
From: schnetter at cct.lsu.edu (schnetter at cct.lsu.edu)
Date: Fri, 12 Jan 2007 21:17:24 -0600
Subject: [Developers] Patch: Call MPI_Finalize from the flesh
Message-ID: <D42EEA44-DD4F-4D7D-858B-958E17FFF552@cct.lsu.edu>

> Number:         2077
> Notify-List:
> Category:       Cactus
> Synopsis:       Patch: Call MPI_Finalize from the flesh
> Confidential:   no
> Severity:       serious
> Priority:       medium
> Responsible:    goodale
> State:          open
> Class:          feature-request
> Submitter-Id:   user
> Arrival-Date:   Fri Jan 12 21:15:58 -0600 2007
> Originator:     Erik Schnetter
> Release:        Cactus 4.0.b16
> Organization:
> Environment:
> Description:
MPI_Finalize should be called from CCTKi_ShutdownCactus, not from  
CactusDefaultShutdown.  After CactusDefaultShutdown has been called,  
the flesh still outputs schedule timing statistics.  This is against  
the MPI standard, which states that this may not work -- essentially,  
nothing "interesting" can be done after calling MPI_Finalize.  The  
routine CCTKi_ShutdownCactus is called later.
> How-To-Repeat:
> Fix:
Unknown
> Unformatted:

-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/20070112/87ffb852/attachment.bin 

From kellerma at aei.mpg.de  Sat Jan 13 09:47:49 2007
From: kellerma at aei.mpg.de (Thorsten Kellermann)
Date: Sat, 13 Jan 2007 16:47:49 +0100 (CET)
Subject: [Developers] AHFinderDirect + Cartoon with bitant symmetry?
In-Reply-To: <526037.85114.qm@web32709.mail.mud.yahoo.com>
References: <526037.85114.qm@web32709.mail.mud.yahoo.com>
Message-ID: <Pine.LNX.4.60.0701131642140.8388@xeon03.aei.mpg.de>

Hi Zach

Some month ago I tested the Cartoon + bitant + AHF for balck hole in 
Schwarzschild coordinates. I did only evolving the Lapse Function and it 
worked. I think you know you have to stagger the grid.

May be describe your problem more precisly.

Thorsten


On Fri, 12 Jan 2007, Zach Etienne wrote:

> Hello.
>
> We (the Illinois group) require an apparent horizon finder in Cactus that works     with Cartoon2D + bitant (i.e., "equatorial") symmetry.  Does AHFinderDirect support this combination of symmetries?
>
> In my version of AHFinderDirect, it says (in AHFinderDirect/doc/TODO):
>    detect Cartoon and rotate geometry interpolation into Cartoon plane
>
> Thus I'm inclined to believe the answer to my question is "no".  If this is in fact the case, does anyone have a version of AHFinderDirect that supports Cartoon+bitant symmetry?
>
> Thanks in advance for your reply.
> -Zach Etienne,
>  on behalf of the Illinois Group
>
>
> ---------------------------------
> Expecting? Get great news right away with email Auto-Check.
> Try the Yahoo! Mail Beta.

-- 
_________________________________________________________________________________

Thorsten Kellermann


Max-Planck-Institut fuer Gravitationsphysik
Albert Einstein Institut

Astrophysical Division
Numerical Relativity Group			Privat:

Am Muehlenberg 1		 		Heinrich-von-Kleist-Str.13
14476 Potsdam					14482 Potsdam
0049-331-567-7184				0049-331 - 5503402

Thorsten.Kellermann at aei.mpg.de
_________________________________________________________________________________


From schnetter at cct.lsu.edu  Sat Jan 13 10:24:07 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 13 Jan 2007 10:24:07 -0600
Subject: [Developers] AHFinderDirect + Cartoon with bitant symmetry?
In-Reply-To: <526037.85114.qm@web32709.mail.mud.yahoo.com>
References: <526037.85114.qm@web32709.mail.mud.yahoo.com>
Message-ID: <D1F20876-68C8-411D-A22A-D3FD399BDEBB@cct.lsu.edu>

On Jan 12, 2007, at 13:44:54, Zach Etienne wrote:

> Hello.
>
> We (the Illinois group) require an apparent horizon finder in  
> Cactus that works     with Cartoon2D + bitant (i.e., "equatorial")  
> symmetry.  Does AHFinderDirect support this combination of symmetries?
>
> In my version of AHFinderDirect, it says (in AHFinderDirect/doc/TODO):
>     detect Cartoon and rotate geometry interpolation into Cartoon  
> plane
>
> Thus I'm inclined to believe the answer to my question is "no".  If  
> this is in fact the case, does anyone have a version of  
> AHFinderDirect that supports Cartoon+bitant symmetry?

While AHFinderDirect does not know about the Cartoon symmetry, the  
Cartoon thorn knows how to interpolate to grid points everywhere in  
space, not just on the Cartoon plane.  Thus AHFinderDirect never  
needs to know that you have a Cartoon symmetry, although this would  
of course increase performance.

-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/20070113/36b3381e/attachment.bin 

From zachetie at yahoo.com  Sat Jan 13 16:43:33 2007
From: zachetie at yahoo.com (Zach Etienne)
Date: Sat, 13 Jan 2007 14:43:33 -0800 (PST)
Subject: [Developers] AHFinderDirect + Cartoon with bitant symmetry?
In-Reply-To: <D1F20876-68C8-411D-A22A-D3FD399BDEBB@cct.lsu.edu>
Message-ID: <593118.68343.qm@web32711.mail.mud.yahoo.com>

Thanks again for your replies.

I just modified AHFinderDirect to work with our Cactus thorns, and I'm getting the dreaded "one or more points on the trial horizon surface point is/are outside the grid (or too close to the grid boundary)" error message.  Our Cartoon-based code requires a grid with the following properties:

key: 0) xyz(arrayindex_x,arrayindex_y,arrayindex_z) = coordinate_value
1) x(0,0,0) = -dX/2; x(1,0,0) = +dX/2; x(2,0,0) = +3 dX/2; etc.
2) y(0,0,0) = -dY; y(0,1,0) = 0; and y(0,2,0) = +dY
3) z(0,0,0) = -dZ/2; z(0,0,1) = +dZ/2; z(0,0,2) = +3 dZ/2; etc.

I.e., we need 1 symmetry ghostzone in the x, y, and z directions.  

AHFinder (the AH finder in the CactusEinstein thorn) appears to work with this grid without any interpolation errors, but only (a) after I fixed a bug in that code having to do with the case where bitant+cartoon is assumed, and (b) when the interpolation order in LocalInterp is set to 1 ("uniform cartesian" interpolation).  [When the interpolation order is set to 2, LocalInterp has issues with a point where theta = pi/2 (i.e., z=0).]

To get AHFinderDirect to work with our grid, it appears as though I'll need to write my own Hermite+Lagrange interpolation routines or somehow modify the chosen stencil inside AEILocalInterp so that AEILocalInterp does not attempt to go off our grid.  Aside from reworking all our Cactus thorns to accept arbitrary values for ghost_size_x, ghost_size_y, and ghost_size_z, does anyone have a better idea?

-Zach

 
---------------------------------
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/developers/attachments/20070113/63d0b9f8/attachment-0001.html 

From schnetter at cct.lsu.edu  Sat Jan 13 17:32:38 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 13 Jan 2007 17:32:38 -0600
Subject: [Developers] Code tests
Message-ID: <70C31293-5667-47B3-9134-0D02FA408AA2@cct.lsu.edu>

Here is an idea for thorns that want to include self-tests.  Instead  
of using #ifdef to enable or disable the self-test code, introduce a  
boolean parameter "selftest".  If this parameter is true, then  
schedule the self-test routine e.g. into the Paramcheck bin, and use  
CCTK_ParamWarn to report test failures.

-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/20070113/0372bc98/attachment.bin 

From schnetter at cct.lsu.edu  Tue Jan 16 08:43:59 2007
From: schnetter at cct.lsu.edu (schnetter at cct.lsu.edu)
Date: Tue, 16 Jan 2007 08:43:59 -0600
Subject: [Developers] CactusUtils/2079: Patch for thorn TimerReport: Output
	timer reports to a file instead of to stdout
Message-ID: <200701161443.l0GEhxXu025327@cactus.cct.lsu.edu>

>Number:         2079
>Notify-List:    developers at cactuscode.org
>Category:       CactusUtils
>Synopsis:       Patch for thorn TimerReport: Output timer reports to a file instead of to stdout
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    goodale
>State:          open
>Class:          feature-request
>Submitter-Id:   user
>Arrival-Date:   Tue Jan 16 08:43:59 -0600 2007
>Originator:     Erik Schnetter
>Release:        Cactus 4.0.b16
>Organization:
>Environment:
>Description:
Add a parameter to thorn CactusUtils/TimerReport to output the timer reports to files instead of to stdout.  The reports are often many lines long, and they use more than 80 characters per line, cluttering stdout.  Additionally, having them in files allows looking at timer reports from all processors without collecting all processors' stdout.

The implementation is a bit unelegant, since the flesh function CCTK_SchedulePrintTimes does not accest a FILE* argument.  Instead, TimerReport redirects all stdout to file before outputting the report, and unredirects afterwards.  This requires the system calls open, dup, and close, which are not part of the C standard (but are already autodetected when configuring Cactus).
>How-To-Repeat:
>Fix:
Unknown
>Unformatted:
 ----gnatsweb-attachment----
 Content-Type: application/octet-stream; name="TimerReport-outfile.diff"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="TimerReport-outfile.diff"
 
 SW5kZXg6IGludGVyZmFjZS5jY2wKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2NhY3R1c2RldmN2cy9D
 YWN0dXNVdGlscy9UaW1lclJlcG9ydC9pbnRlcmZhY2UuY2NsLHYKcmV0cmlldmluZyByZXZpc2lv
 biAxLjMKZGlmZiAtdSAtcjEuMyBpbnRlcmZhY2UuY2NsCi0tLSBpbnRlcmZhY2UuY2NsCTE2IE1h
 eSAyMDA0IDE0OjQ4OjI4IC0wMDAwCTEuMworKysgaW50ZXJmYWNlLmNjbAkxNiBKYW4gMjAwNyAx
 NDozODoyMiAtMDAwMApAQCAtMiwzICsyLDkgQEAKICMgJEhlYWRlcjogL2NhY3R1c2RldmN2cy9D
 YWN0dXNVdGlscy9UaW1lclJlcG9ydC9pbnRlcmZhY2UuY2NsLHYgMS4zIDIwMDQvMDUvMTYgMTQ6
 NDg6Mjggc2NobmV0dGVyIEV4cCAkCiAKIGltcGxlbWVudHM6IHRpbWVycmVwb3J0CisKKworCitD
 Q1RLX0lOVCBGVU5DVElPTiBJT19UcnVuY2F0ZU91dHB1dEZpbGVzIChDQ1RLX1BPSU5URVJfVE9f
 Q09OU1QgSU4gY2N0a0dIKQorCitSRVFVSVJFUyBGVU5DVElPTiBJT19UcnVuY2F0ZU91dHB1dEZp
 bGVzCkluZGV4OiBwYXJhbS5jY2wKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2NhY3R1c2RldmN2cy9D
 YWN0dXNVdGlscy9UaW1lclJlcG9ydC9wYXJhbS5jY2wsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEu
 MgpkaWZmIC11IC1yMS4yIHBhcmFtLmNjbAotLS0gcGFyYW0uY2NsCTggTWF5IDIwMDUgMTI6MTc6
 MjEgLTAwMDAJMS4yCisrKyBwYXJhbS5jY2wJMTYgSmFuIDIwMDcgMTQ6Mzg6MjIgLTAwMDAKQEAg
 LTE1LDYgKzE1LDEyIEBACiAgIDA6KiAgOjogIkF0IHRoaXMgaXRlcmF0aW9uIgogfSAtMQogCitT
 VFJJTkcgb3V0X2ZpbGVuYW1lICJGaWxlIG5hbWUgZm9yIHRpbWVyIHJlcG9ydHMiIFNURUVSQUJM
 RT1BTFdBWVMKK3sKKyAgIl4kIiAgIDo6ICJlbXB0eSBmaWxlbmFtZTogcHJpbnQgdG8gc3Rkb3V0
 IgorICAiXi4rJCIgOjogIm90aGVyd2lzZTogcHJpbnQgdG8gdGhhdCBmaWxlIgorfSAiIgorCiBC
 T09MRUFOIGJlZm9yZV9jaGVja3BvaW50ICJCZWZvcmUgYSBjaGVja3BvaW50IiBTVEVFUkFCTEU9
 QUxXQVlTCiB7CiB9ICJubyIKQEAgLTI1LDQgKzMxLDYgQEAKIAogc2hhcmVzOiBJTwogCitVU0VT
 IFNUUklORyBvdXRfZGlyCisKIFVTRVMgSU5UIGNoZWNrcG9pbnRfZXZlcnkKSW5kZXg6IHNjaGVk
 dWxlLmNjbAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY2FjdHVzZGV2Y3ZzL0NhY3R1c1V0aWxzL1Rp
 bWVyUmVwb3J0L3NjaGVkdWxlLmNjbCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4zCmRpZmYgLXUg
 LXIxLjMgc2NoZWR1bGUuY2NsCi0tLSBzY2hlZHVsZS5jY2wJMTYgTWF5IDIwMDQgMTQ6NDg6Mjgg
 LTAwMDAJMS4zCisrKyBzY2hlZHVsZS5jY2wJMTYgSmFuIDIwMDcgMTQ6Mzg6MjIgLTAwMDAKQEAg
 LTgsNiArOCwxMiBAQAogICBPUFRJT05TOiBnbG9iYWwKIH0gIlByaW50IHRoZSB0aW1lciByZXBv
 cnQiCiAKK1NDSEVEVUxFIFRpbWVyUmVwb3J0X091dHB1dCBBUyB6enpfVGltZXJSZXBvcnRfT3V0
 cHV0IEFUIENDVEtfVEVSTUlOQVRFCit7CisgIExBTkc6IEMKKyAgT1BUSU9OUzogZ2xvYmFsCit9
 ICJQcmludCB0aGUgdGltZXIgcmVwb3J0IgorCiBTQ0hFRFVMRSBUaW1lclJlcG9ydF9DaGVja3Bv
 aW50IEFTIHp6el9UaW1lclJlcG9ydF9DaGVja3BvaW50IEFUIENDVEtfQ0hFQ0tQT0lOVAogewog
 ICBMQU5HOiBDCmN2cyBkaWZmOiBEaWZmaW5nIGRvYwpjdnMgZGlmZjogRGlmZmluZyBzcmMKSW5k
 ZXg6IHNyYy9PdXRwdXQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY2FjdHVzZGV2Y3ZzL0NhY3R1
 c1V0aWxzL1RpbWVyUmVwb3J0L3NyYy9PdXRwdXQuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS43
 CmRpZmYgLXUgLXIxLjcgT3V0cHV0LmMKLS0tIHNyYy9PdXRwdXQuYwk4IE1heSAyMDA1IDEyOjE3
 OjIxIC0wMDAwCTEuNworKysgc3JjL091dHB1dC5jCTE2IEphbiAyMDA3IDE0OjM4OjIyIC0wMDAw
 CkBAIC04LDEyICs4LDIwIEBACiAgICBAdmVyc2lvbiAgICRIZWFkZXI6IC9jYWN0dXNkZXZjdnMv
 Q2FjdHVzVXRpbHMvVGltZXJSZXBvcnQvc3JjL091dHB1dC5jLHYgMS43IDIwMDUvMDUvMDggMTI6
 MTc6MjEgc2NobmV0dGVyIEV4cCAkCiAgQEAqLwogCisjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNs
 dWRlIDxzdGRsaWIuaD4KIAogI2luY2x1ZGUgImNjdGsuaCIKICNpbmNsdWRlICJjY3RrX1BhcmFt
 ZXRlcnMuaCIKICNpbmNsdWRlICJjY3RrX0FyZ3VtZW50cy5oIgogCisjaWZkZWYgSEFWRV9VTklT
 VERfSAorIyAgaW5jbHVkZSA8ZmNudGwuaD4KKyMgIGluY2x1ZGUgPHVuaXN0ZC5oPgorI2VuZGlm
 CisKKyNpbmNsdWRlICJ1dGlsX1N0cmluZy5oIgorCiAjaW5jbHVkZSAiY2N0a19TY2hlZHVsZS5o
 IgogCiBzdGF0aWMgY29uc3QgY2hhciAqcmNzaWQgPSAiJEhlYWRlcjogL2NhY3R1c2RldmN2cy9D
 YWN0dXNVdGlscy9UaW1lclJlcG9ydC9zcmMvT3V0cHV0LmMsdiAxLjcgMjAwNS8wNS8wOCAxMjox
 NzoyMSBzY2huZXR0ZXIgRXhwICQiOwpAQCAtMjgsNiArMzYsOCBAQAogICoqKioqKioqKioqKioq
 KioqKioqKiBMb2NhbCBSb3V0aW5lIFByb3RvdHlwZXMgKioqKioqKioqKioqKioqKioqKioqCiAg
 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
 KioqKioqKioqKiovCiAKK3N0YXRpYyB2b2lkIFByaW50VGltZXMgKENDVEtfQVJHVU1FTlRTKTsK
 KwogLyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
 KioqKioqKioqKioqKioqCiAgKioqKioqKioqKioqKioqKioqKioqICBTY2hlZHVsZWQgUm91dGlu
 ZSBQcm90b3R5cGVzICAqKioqKioqKioqKioqKioKICAqKioqKioqKioqKioqKioqKioqKioqKioq
 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KQEAgLTY4LDcgKzc4
 LDcgQEAKICAgICBDQ1RLX1ZJbmZvKENDVEtfVEhPUk5TVFJJTkcsCiAgICAgICAgICAgICAgICAi
 VGltZXIgUmVwb3J0IGF0IGl0ZXJhdGlvbiAlZCB0aW1lICVnIiwKICAgICAgICAgICAgICAgIGNj
 dGtfaXRlcmF0aW9uLCAoZG91YmxlKWNjdGtfdGltZSk7Ci0gICAgQ0NUS19TY2hlZHVsZVByaW50
 VGltZXMoTlVMTCk7CisgICAgUHJpbnRUaW1lcyhDQ1RLX1BBU1NfQ1RPQyk7CiAKICAgICBpZiAo
 bmV4dCkKICAgICB7CkBAIC05OCw3ICsxMDgsNyBAQAogICAgIENDVEtfVkluZm8oQ0NUS19USE9S
 TlNUUklORywKICAgICAgICAgICAgICAgICJUaW1lciBSZXBvcnQgYmVmb3JlIGNoZWNrcG9pbnRp
 bmcgYXQgaXRlcmF0aW9uICVkLCB0aW1lICVnIiwKICAgICAgICAgICAgICAgIGNjdGtfaXRlcmF0
 aW9uLCAoZG91YmxlKWNjdGtfdGltZSk7Ci0gICAgQ0NUS19TY2hlZHVsZVByaW50VGltZXMoTlVM
 TCk7CisgICAgUHJpbnRUaW1lcyhDQ1RLX1BBU1NfQ1RPQyk7CiAgICAgCiAgIH0KIH0KQEAgLTEw
 NywzICsxMTcsNzcgQEAKICAqKioqKioqKioqKioqKioqKioqKiAgICBJbnRlcm5hbCBSb3V0aW5l
 cyAgICoqKioqKioqKioqKioqKioqKioqKioqKgogICoqKioqKioqKioqKioqKioqKioqKioqKioq
 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwogCitzdGF0aWMgdm9p
 ZCBQcmludFRpbWVzIChDQ1RLX0FSR1VNRU5UUykKK3sKKyAgREVDTEFSRV9DQ1RLX0FSR1VNRU5U
 UzsKKyAgREVDTEFSRV9DQ1RLX1BBUkFNRVRFUlM7CisgIAorICBpbnQgbXlwcm9jOworICBjaGFy
 IGZpbGVuYW1lIFsxMDAwMF07CisgIAorICBzdGF0aWMgaW50IGZpcnN0X3RpbWUgPSAxOworICBp
 bnQgZmxhZ3M7CisgIGludCBjb25zdCBtb2RlID0gMDY0NDsgICAgICAgIC8qIHJ3LXItLXItLSwg
 b3IgYStyIHUrdyAqLworICAKKyAgaW50IGZkc2F2ZSwgZmRmaWxlOworICAKKyAgCisgIGlmIChD
 Q1RLX0VRVUFMUyAob3V0X2ZpbGVuYW1lLCAiIikpCisgIHsKKyAgICAvKiBQcmludCB0byBzdGRv
 dXQuICAqLworICAgIENDVEtfU2NoZWR1bGVQcmludFRpbWVzKE5VTEwpOworICB9CisgIGVsc2UK
 KyAgeworICAgIC8qIFByaW50IHRvIGEgZmlsZS4gICovCisjaWZuZGVmIEhBVkVfVU5JU1REX0gK
 KyAgICBDQ1RLX1dBUk4gKDEsICJDYW5ub3QgcmVkaXJlY3QgdGltZXIgcmVwb3J0IG91dHB1dCB0
 byBhIGZpbGU7IHRoZSBvcGVyYXRpbmcgc3lzdGVtIGRvZXMgbm90IHN1cHBvcnQgdGhpcyIpOwor
 I2Vsc2UgLyogI2lmZGVmIEhBVkVfVU5JU1REX0ggKi8KKyAgICAKKyAgICBteXByb2MgPSBDQ1RL
 X015UHJvYyAoY2N0a0dIKTsKKyAgICBVdGlsX3NucHJpbnRmIChmaWxlbmFtZSwgc2l6ZW9mIGZp
 bGVuYW1lLAorICAgICAgICAgICAgICAgICAgICIlcy8lcy4lMDRkLnR4dCIsIG91dF9kaXIsIG91
 dF9maWxlbmFtZSwgbXlwcm9jKTsKKyAgICAKKyAgICAvKiBhcHBlbmQgKi8KKyAgICBmbGFncyA9
 IE9fV1JPTkxZIHwgT19DUkVBVCB8IE9fQVBQRU5EOworICAgIGlmIChmaXJzdF90aW1lKQorICAg
 IHsKKyAgICAgIGZpcnN0X3RpbWUgPSAwOworICAgICAgaWYgKElPX1RydW5jYXRlT3V0cHV0Rmls
 ZXMgKGNjdGtHSCkpCisgICAgICB7CisgICAgICAgIC8qIHRydW5jYXRlICovCisgICAgICAgIGZs
 YWdzID0gT19XUk9OTFkgfCBPX0NSRUFUIHwgT19UUlVOQzsKKyAgICAgIH0KKyAgICB9CisgICAg
 CisgICAgLyogVGVtcG9yYXJpbHkgcmVkaXJlY3Qgc3Rkb3V0ICovCisgICAgZmZsdXNoIChzdGRv
 dXQpOworICAgIGZkc2F2ZSA9IGR1cCAoMSk7ICAgICAgICAgICAvKiBmZCAxIGlzIHN0ZG91dCAq
 LworICAgIGZkZmlsZSA9IG9wZW4gKGZpbGVuYW1lLCBmbGFncywgbW9kZSk7CisgICAgaWYgKGZk
 ZmlsZSA8IDApCisgICAgeworICAgICAgQ0NUS19WV2FybiAoMSwgX19MSU5FX18sIF9fRklMRV9f
 LCBDQ1RLX1RIT1JOU1RSSU5HLAorICAgICAgICAgICAgICAgICAgIkNvdWxkIG5vdCBvcGVuIHRp
 bWVyIHJlcG9ydCBvdXRwdXQgZmlsZSBcIiVzXCIiLCBmaWxlbmFtZSk7CisgICAgICBnb3RvIGNs
 ZWFudXA7CisgICAgfQorICAgIGNsb3NlICgxKTsKKyAgICBkdXAgKGZkZmlsZSk7ICAgICAgICAg
 ICAgICAgLyogZHVwIHRvIDEsIGkuZS4sIHN0ZG91dCBhZ2FpbiAqLworICAgIGNsb3NlIChmZGZp
 bGUpOworICAgIAorICAgIC8qIFByaW50IHRoZSBzY2hlZHVsZSB0byB0aGUgZmlsZSAqLworICAg
 IHByaW50ZiAoIlRpbWVyIFJlcG9ydCBhdCBpdGVyYXRpb24gJWQgdGltZSAlZzpcblxuIiwKKyAg
 ICAgICAgICAgIGNjdGtfaXRlcmF0aW9uLCAoZG91YmxlKSBjY3RrX3RpbWUpOworICAgIENDVEtf
 U2NoZWR1bGVQcmludFRpbWVzKE5VTEwpOworICAgIHByaW50ZiAoIlxuKioqKioqKioqKioqKioq
 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
 KioqKioqKipcbiIpOworICAgIAorICAgIC8qIFJlZGlyZWN0IHN0ZG91dCBiYWNrICovCisgICAg
 ZmZsdXNoIChzdGRvdXQpOworICAgIGNsb3NlICgxKTsKKyAgICBkdXAgKGZkc2F2ZSk7CisgIGNs
 ZWFudXA6CisgICAgY2xvc2UgKGZkc2F2ZSk7CisgICAgCisjZW5kaWYgIC8qICNpZmRlZiBIQVZF
 X1VOSVNURF9IICovCisgICAgCisgIH0KK30K
 

From schnetter at cct.lsu.edu  Tue Jan 16 08:52:12 2007
From: schnetter at cct.lsu.edu (schnetter at cct.lsu.edu)
Date: Tue, 16 Jan 2007 08:52:12 -0600
Subject: [Developers] CactusUtils/2079: Patch for thorn TimerReport: Output
	timer reports to a file instead of to stdout
Message-ID: <A4D9AF9C-E4E5-4B8A-801F-CF2942CD020D@cct.lsu.edu>

> Number:         2079
> Notify-List:    developers at cactuscode.org
> Category:       CactusUtils
> Synopsis:       Patch for thorn TimerReport: Output timer reports  
> to a file instead of to stdout
> Confidential:   no
> Severity:       non-critical
> Priority:       low
> Responsible:    goodale
> State:          open
> Class:          feature-request
> Submitter-Id:   user
> Arrival-Date:   Tue Jan 16 08:43:59 -0600 2007
> Originator:     Erik Schnetter
> Release:        Cactus 4.0.b16
> Organization:
> Environment:
> Description:
Add a parameter to thorn CactusUtils/TimerReport to output the timer  
reports to files instead of to stdout.  The reports are often many  
lines long, and they use more than 80 characters per line, cluttering  
stdout.  Additionally, having them in files allows looking at timer  
reports from all processors without collecting all processors' stdout.

The implementation is a bit unelegant, since the flesh function  
CCTK_SchedulePrintTimes does not accest a FILE* argument.  Instead,  
TimerReport redirects all stdout to file before outputting the  
report, and unredirects afterwards.  This requires the system calls  
open, dup, and close, which are not part of the C standard (but are  
already autodetected when configuring Cactus).
> How-To-Repeat:
> Fix:
Unknown
> Unformatted:

-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/20070116/72b0ca26/attachment.bin 

From schnetter at cct.lsu.edu  Tue Jan 16 08:55:50 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 16 Jan 2007 08:55:50 -0600
Subject: [Developers] Cactus/2078: specify the number of processors
	required to run a testsuite
In-Reply-To: <200701161243.l0GChuh9024538@cactus.cct.lsu.edu>
References: <200701161243.l0GChuh9024538@cactus.cct.lsu.edu>
Message-ID: <08FE5084-C970-427D-92FC-B80B15301E96@cct.lsu.edu>

On Jan 16, 2007, at 06:43:56, tradke at aei.mpg.de wrote:

>> Number:         2078
>> Notify-List:
>> Category:       Cactus
>> Synopsis:       specify the number of processors required to run a  
>> testsuite
>> Confidential:   no
>> Severity:       critical
>> Priority:       high
>> Responsible:    goodale
>> State:          open
>> Class:          feature-request
>> Submitter-Id:   user
>> Arrival-Date:   Tue Jan 16 06:43:56 -0600 2007
>> Originator:     Thomas Radke
>> Release:
>> Organization:
>> Environment:
>> Description:
> Some testsuites are known to work only on a single processor,  
> others generate output files which format depends on the number of  
> processors used to create them.
>
> The attached patch extends the existing testsuite mechanism in such  
> a way that thorn developers can now specify the number of  
> processors required to run all testsuites or a specifiy one  
> successfully using the NPROCS option in a test.ccl - similar to  
> using RELTOL and ABSTOL to set the tolerances for testsuites.
>> How-To-Repeat:
>> Fix:
>> Unformatted:

That is a good idea.  I second this patch.

-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/20070116/65d70c02/attachment.bin 

From goodale at cct.lsu.edu  Tue Jan 16 10:59:07 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Tue, 16 Jan 2007 16:59:07 +0000 (GMT)
Subject: [Developers] CactusUtils/2079: Patch for thorn TimerReport:
 Output timer reports to a file instead of to stdout
In-Reply-To: <A4D9AF9C-E4E5-4B8A-801F-CF2942CD020D@cct.lsu.edu>
References: <A4D9AF9C-E4E5-4B8A-801F-CF2942CD020D@cct.lsu.edu>
Message-ID: <Pine.LNX.4.64.0701161656440.3712@fandango.dyndns.org>


On Tue, 16 Jan 2007, schnetter at cct.lsu.edu wrote:

> Add a parameter to thorn CactusUtils/TimerReport to output the timer reports 
> to files instead of to stdout.  The reports are often many lines long, and 
> they use more than 80 characters per line, cluttering stdout.  Additionally, 
> having them in files allows looking at timer reports from all processors 
> without collecting all processors' stdout.

Sounds like a nice idea.

> The implementation is a bit unelegant, since the flesh function 
> CCTK_SchedulePrintTimes does not accest a FILE* argument.  Instead, 
> TimerReport redirects all stdout to file before outputting the report, and 
> unredirects afterwards.  This requires the system calls open, dup, and close, 
> which are not part of the C standard (but are already autodetected when 
> configuring Cactus).

It would probably be cleaner to introduce

CCTK_SchedulePrintTimesToFile

which takes a FILE * argument or a file descriptor (the latter would be 
good for reporting timing info to a web page, but the former is better if 
multiplexing with other things on stdout) and then have both the thorn and 
the flesh CCTK_SchedulePrintTimes use this routine.

Cheers,

Tom

From dprideout at gmail.com  Mon Jan 22 16:14:52 2007
From: dprideout at gmail.com (David Rideout)
Date: Mon, 22 Jan 2007 22:14:52 +0000
Subject: [Developers] support gnu C/C++ compilers in cygwin
Message-ID: <1ce81abb0701221414o10c02a2t8def8c4efb6aeac6@mail.gmail.com>

The enclosed patch allows Cactus to build with gnu compilers in
cygwin.  I did not test it with Fortran.

-David


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

From schnetter at cct.lsu.edu  Mon Jan 22 21:50:57 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 22 Jan 2007 21:50:57 -0600
Subject: [Developers] Unclear error message from test suite
Message-ID: <03C0BBED-C9D5-4682-B8B9-D10D05674CEC@cct.lsu.edu>

For the test case CarpetEvolutionMask_test, which fails because the  
output files have different names, the following happens (I do not  
show all output here; I show only lines relevant to kxx):

   Issuing mpirun -np 1 /Users/eschnett/Cvanilla/exe/cactus_einstein- 
redshift-gcc-debug /Users/eschnett/Cvanilla/arrangements/Carpet/ 
CarpetEvolutionMask/test/CarpetEvolutionMask_test.par
      kxx_maximum.xg in archive but not created in test
      kxx_minimum.xg in archive but not created in test
      kxx_norm1.xg in archive but not created in test
      kxx_norm2.xg in archive but not created in test
             kxx.average.asc not in thorn archive
             kxx.count.asc not in thorn archive
             kxx.maximum.asc not in thorn archive
             kxx.minimum.asc not in thorn archive
             kxx.norm1.asc not in thorn archive
             kxx.norm2.asc not in thorn archive
             kxx.norm_inf.asc not in thorn archive
             kxx.sum.asc not in thorn archive
   Failure: 44 files compared, 38 differ, 32 differ significantly

   Files which differ strongly:
     [29] kxx_maximum.xg
     [30] kxx_minimum.xg
     [31] kxx_norm1.xg
     [32] kxx_norm2.xg
   Choose file by number or [c]ontinue [c]
    --> 32

   File kxx_norm2.xg of test CarpetEvolutionMask_test for thorn  
CarpetEvolutionMask
   Choose action [l]ist, [x]graph, [y]graph, [g]nuplot, [c]ontinue [c]
    --> d


   Both versions of this file do not exist.  Please choose a  
different option.

   File kxx_norm2.xg of test CarpetEvolutionMask_test for thorn  
CarpetEvolutionMask
   Choose action [l]ist, [x]graph, [y]graph, [g]nuplot, [c]ontinue [c]
    --> l

Archived file: kxx_norm2.xg

"kxx v time
0.0000000000000 0.0000000000000
0.1000000000000 0.0139806363863
0.2000000000000 0.0279785541896
0.3000000000000 0.0420109309316
0.4000000000000 0.0560946961843
0.5000000000000 0.0702464750806
   File kxx_norm2.xg of test CarpetEvolutionMask_test for thorn  
CarpetEvolutionMask
   Choose action [l]ist, [x]graph, [y]graph, [g]nuplot, [c]ontinue [c]
    -->



The message "Both versions of this file do not exist." is unclear.   
What does it mean?  As written, it means that neither version (nor  
the one in the repository nor the one just created) exists.  This is  
clearly wrong.  Maybe it should read "This file was not created by  
the test case"?

Also, when I listed the file, it is not clear from the output that  
this file was not created.  The output actually indicates that the  
file exists, but is empty.

-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/20070122/fb23d3d1/attachment-0001.bin 

From dprideout at gmail.com  Thu Jan 25 10:16:53 2007
From: dprideout at gmail.com (David Rideout)
Date: Thu, 25 Jan 2007 16:16:53 +0000
Subject: [Developers] support gnu C/C++ compilers in cygwin
In-Reply-To: <1ce81abb0701221414o10c02a2t8def8c4efb6aeac6@mail.gmail.com>
References: <1ce81abb0701221414o10c02a2t8def8c4efb6aeac6@mail.gmail.com>
Message-ID: <1ce81abb0701250816y453f7df7o6971909fdba4141f@mail.gmail.com>

Lydia Philpott has found that Cactus does not build on a fresh default
checkout of cygwin, even with this revised known-architectures file.
The make that ships with the current version of cygwin is broken,
yielding errors regarding "multiple target patterns".  She found a
solution at https://projects.coin-or.org/BuildTools/wiki/current-issues.
 Additionally she had to add latex packages to get the ThornGuide to
build.

Perhaps we should have a cygwin FAQ?

Cheers,
David

On 1/22/07, David Rideout <dprideout at gmail.com> wrote:
> The enclosed patch allows Cactus to build with gnu compilers in
> cygwin.  I did not test it with Fortran.
>
> -David
>
>
>

From schnetter at cct.lsu.edu  Thu Jan 25 10:42:58 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Thu, 25 Jan 2007 10:42:58 -0600
Subject: [Developers] support gnu C/C++ compilers in cygwin
In-Reply-To: <1ce81abb0701250816y453f7df7o6971909fdba4141f@mail.gmail.com>
References: <1ce81abb0701221414o10c02a2t8def8c4efb6aeac6@mail.gmail.com>
	<1ce81abb0701250816y453f7df7o6971909fdba4141f@mail.gmail.com>
Message-ID: <D570D0D6-725D-4CFE-8EDF-85EC5D79AC7A@cct.lsu.edu>

On Jan 25, 2007, at 10:16:53, David Rideout wrote:

> Lydia Philpott has found that Cactus does not build on a fresh default
> checkout of cygwin, even with this revised known-architectures file.
> The make that ships with the current version of cygwin is broken,
> yielding errors regarding "multiple target patterns".  She found a
> solution at https://projects.coin-or.org/BuildTools/wiki/current- 
> issues.
>  Additionally she had to add latex packages to get the ThornGuide to
> build.
>
> Perhaps we should have a cygwin FAQ?

There is one; it is called "README.Windows".  It begins by explaining  
that you should install Cygwin to use Cactus on Windows.  The  
information in there is unfortunately old; for example, it lists  
versions that are known to work, but these versions are old and no  
one seems to have updated them recently.  Most current developers  
seem to not use Windows, but the Mac sections of the build system  
have recently been polished.

Lydia, thanks for your hint regarding the make problem.  If you use  
Cygwin and have additional information, do you want to help us by  
updating this file?

-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/20070125/772bd8a6/attachment.bin 

From tradke at aei.mpg.de  Fri Jan 26 04:59:34 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Fri, 26 Jan 2007 11:59:34 +0100
Subject: [Developers] Unclear error message from test suite
In-Reply-To: <03C0BBED-C9D5-4682-B8B9-D10D05674CEC@cct.lsu.edu>
References: <03C0BBED-C9D5-4682-B8B9-D10D05674CEC@cct.lsu.edu>
Message-ID: <45B9DF16.6020204@aei.mpg.de>

Erik Schnetter wrote:
> For the test case CarpetEvolutionMask_test, which fails because the  
> output files have different names, the following happens (I do not  show 
> all output here; I show only lines relevant to kxx):
> 
> ...
> The message "Both versions of this file do not exist." is unclear.   
> What does it mean?  As written, it means that neither version (nor  the 
> one in the repository nor the one just created) exists.  This is  
> clearly wrong.  Maybe it should read "This file was not created by  the 
> test case"?

Hmm, I couldn't fully follow the logic here either.

> Also, when I listed the file, it is not clear from the output that  this 
> file was not created.  The output actually indicates that the  file 
> exists, but is empty.

I solved this problem by fixing a bug in the in the RunTestUtil.pl 
script (which goes back to earlier versions of Cactus releases). Now 
files which are missing in the testsuite output but should be there are 
reported separately. And they are not offered anymore to the user for an 
interactive comparison between expected and generated output files.

-- 
Cheers, Thomas.

From schnetter at cct.lsu.edu  Fri Jan 26 09:29:27 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Fri, 26 Jan 2007 09:29:27 -0600
Subject: [Developers] Unify screen layout of test suite results
Message-ID: <0487C13D-5328-4610-A65B-5445351AEEEA@cct.lsu.edu>

I noticed that the test suite results are reported with an ad-hoc  
screen layout.  Some messages are preceded by an empty line, others  
are not; some are indented 3 characters, others about 10 characters.

I would like to use a uniform format: For each file about which there  
is a message, indent by 3 spaces, if there is additional information  
about that file, indent that by 6 spaces.  Each message begins with  
the file name, followed by a colon.  Empty lines only between the  
different sections.

Thomas, would that break your automated report parser?

-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/20070126/2fc0e72b/attachment.bin 

From tradke at aei.mpg.de  Fri Jan 26 09:48:57 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Fri, 26 Jan 2007 16:48:57 +0100
Subject: [Developers] Unify screen layout of test suite results
In-Reply-To: <0487C13D-5328-4610-A65B-5445351AEEEA@cct.lsu.edu>
References: <0487C13D-5328-4610-A65B-5445351AEEEA@cct.lsu.edu>
Message-ID: <45BA22E9.3010506@aei.mpg.de>

Erik Schnetter wrote:
> I noticed that the test suite results are reported with an ad-hoc  
> screen layout.  Some messages are preceded by an empty line, others  are 
> not; some are indented 3 characters, others about 10 characters.
> 
> I would like to use a uniform format: For each file about which there  
> is a message, indent by 3 spaces, if there is additional information  
> about that file, indent that by 6 spaces.  Each message begins with  the 
> file name, followed by a colon.  Empty lines only between the  different 
> sections.
> 
> Thomas, would that break your automated report parser?

Not where the reports for individual testsuites are concerned; this 
information is stored in individual files "<testsuite>.diffs" in the 
"TEST/<configuration>/<thorn>/" subdir and is simply imported as is into 
the integration test output.
The only information which is parsed by the integration test script is 
the one stored in "TEST/<configuration>/summary.log" from which the 
number of available testsuites and the number of passed/failed tests is 
extracted.
So feel free to unify and beautify the testsuite script output as you like.

BTW: If you want to take a look at the Cactus integration test scripts 
that I'm running every night:

   cvs -d :pserver:cvs_anon at cvs.aei.mpg.de:/eScienceCVS co 
AstroGrid/Cactus/IntegrationTests   # login with password 'anon'

-- 
Cheers, Thomas.

From schnetter at cct.lsu.edu  Mon Jan 29 11:24:58 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 29 Jan 2007 11:24:58 -0600
Subject: [Developers] Unify screen layout of test suite results
In-Reply-To: <45BA22E9.3010506@aei.mpg.de>
References: <0487C13D-5328-4610-A65B-5445351AEEEA@cct.lsu.edu>
	<45BA22E9.3010506@aei.mpg.de>
Message-ID: <E49EF824-33D7-48ED-9D07-E134DCC3443C@cct.lsu.edu>

On Jan 26, 2007, at 09:48:57, Thomas Radke wrote:

> Erik Schnetter wrote:
>> I noticed that the test suite results are reported with an ad-hoc
>> screen layout.  Some messages are preceded by an empty line,  
>> others  are
>> not; some are indented 3 characters, others about 10 characters.
>>
>> I would like to use a uniform format: For each file about which there
>> is a message, indent by 3 spaces, if there is additional information
>> about that file, indent that by 6 spaces.  Each message begins  
>> with  the
>> file name, followed by a colon.  Empty lines only between the   
>> different
>> sections.
>>
>> Thomas, would that break your automated report parser?
>
> Not where the reports for individual testsuites are concerned; this
> information is stored in individual files "<testsuite>.diffs" in the
> "TEST/<configuration>/<thorn>/" subdir and is simply imported as is  
> into
> the integration test output.
> The only information which is parsed by the integration test script is
> the one stored in "TEST/<configuration>/summary.log" from which the
> number of available testsuites and the number of passed/failed  
> tests is
> extracted.
> So feel free to unify and beautify the testsuite script output as  
> you like.

Do we require a patch for this change?

-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/20070129/b3b94b2b/attachment.bin 

From tradke at aei.mpg.de  Tue Jan 30 02:49:32 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Tue, 30 Jan 2007 09:49:32 +0100
Subject: [Developers] Unify screen layout of test suite results
In-Reply-To: <E49EF824-33D7-48ED-9D07-E134DCC3443C@cct.lsu.edu>
References: <0487C13D-5328-4610-A65B-5445351AEEEA@cct.lsu.edu>	<45BA22E9.3010506@aei.mpg.de>
	<E49EF824-33D7-48ED-9D07-E134DCC3443C@cct.lsu.edu>
Message-ID: <45BF069C.3060503@aei.mpg.de>

Erik Schnetter wrote:
> On Jan 26, 2007, at 09:48:57, Thomas Radke wrote:
> 
>> Erik Schnetter wrote:
>>
>>> I noticed that the test suite results are reported with an ad-hoc
>>> screen layout.  Some messages are preceded by an empty line,  others  
>>> are
>>> not; some are indented 3 characters, others about 10 characters.
>>>
>>> I would like to use a uniform format: For each file about which there
>>> is a message, indent by 3 spaces, if there is additional information
>>> about that file, indent that by 6 spaces.  Each message begins  with  
>>> the
>>> file name, followed by a colon.  Empty lines only between the   
>>> different
>>> sections.
>>>
>>> Thomas, would that break your automated report parser?
>>
>>
>> Not where the reports for individual testsuites are concerned; this
>> information is stored in individual files "<testsuite>.diffs" in the
>> "TEST/<configuration>/<thorn>/" subdir and is simply imported as is  into
>> the integration test output.
>> The only information which is parsed by the integration test script is
>> the one stored in "TEST/<configuration>/summary.log" from which the
>> number of available testsuites and the number of passed/failed  tests is
>> extracted.
>> So feel free to unify and beautify the testsuite script output as  you 
>> like.
> 
> 
> Do we require a patch for this change?

I'd say this counts as documentation, it doesn't change any 
functionality. Thus shouldn't need to go through our patch approval 
procedure.

-- 
Cheers, Thomas.

From goodale at cct.lsu.edu  Tue Jan 30 04:40:08 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Tue, 30 Jan 2007 10:40:08 +0000 (GMT)
Subject: [Developers] Unify screen layout of test suite results
In-Reply-To: <45BF069C.3060503@aei.mpg.de>
References: <0487C13D-5328-4610-A65B-5445351AEEEA@cct.lsu.edu>
	<45BA22E9.3010506@aei.mpg.de>
	<E49EF824-33D7-48ED-9D07-E134DCC3443C@cct.lsu.edu>
	<45BF069C.3060503@aei.mpg.de>
Message-ID: <Pine.LNX.4.64.0701301037530.32291@fandango.dyndns.org>

On Tue, 30 Jan 2007, Thomas Radke wrote:

> Erik Schnetter wrote:
>> On Jan 26, 2007, at 09:48:57, Thomas Radke wrote:
>>
>>> Erik Schnetter wrote:
>>>
>>>> I noticed that the test suite results are reported with an ad-hoc
>>>> screen layout.  Some messages are preceded by an empty line,  others
>>>> are
>>>> not; some are indented 3 characters, others about 10 characters.
>>>>
>>>> I would like to use a uniform format: For each file about which there
>>>> is a message, indent by 3 spaces, if there is additional information
>>>> about that file, indent that by 6 spaces.  Each message begins  with
>>>> the
>>>> file name, followed by a colon.  Empty lines only between the
>>>> different
>>>> sections.
>>>>
>>>> Thomas, would that break your automated report parser?
>>>
>>>
>>> Not where the reports for individual testsuites are concerned; this
>>> information is stored in individual files "<testsuite>.diffs" in the
>>> "TEST/<configuration>/<thorn>/" subdir and is simply imported as is  into
>>> the integration test output.
>>> The only information which is parsed by the integration test script is
>>> the one stored in "TEST/<configuration>/summary.log" from which the
>>> number of available testsuites and the number of passed/failed  tests is
>>> extracted.
>>> So feel free to unify and beautify the testsuite script output as  you
>>> like.
>>
>>
>> Do we require a patch for this change?
>
> I'd say this counts as documentation, it doesn't change any
> functionality. Thus shouldn't need to go through our patch approval
> procedure.

Part of the reason for the patch procedure is to ensure that there is 
discussion beforehand and that people are in sync, so since this has been 
discussed and isn't going to come as a surprise, and we've already covered 
what might be broken by it, it should be fine to just go ahead.

Cheers,

Tom

From schnetter at cct.lsu.edu  Tue Jan 30 13:54:42 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 30 Jan 2007 13:54:42 -0600
Subject: [Developers] Unify screen layout of test suite results
In-Reply-To: <Pine.LNX.4.64.0701301037530.32291@fandango.dyndns.org>
References: <0487C13D-5328-4610-A65B-5445351AEEEA@cct.lsu.edu>
	<45BA22E9.3010506@aei.mpg.de>
	<E49EF824-33D7-48ED-9D07-E134DCC3443C@cct.lsu.edu>
	<45BF069C.3060503@aei.mpg.de>
	<Pine.LNX.4.64.0701301037530.32291@fandango.dyndns.org>
Message-ID: <BC7958F4-39E6-43E8-BBBB-883C7C1D395D@cct.lsu.edu>

On Jan 30, 2007, at 04:40:08, Tom Goodale wrote:

> On Tue, 30 Jan 2007, Thomas Radke wrote:
>
>> Erik Schnetter wrote:
>>> On Jan 26, 2007, at 09:48:57, Thomas Radke wrote:
>>>
>>>> Erik Schnetter wrote:
>>>>
>>>>> I noticed that the test suite results are reported with an ad-hoc
>>>>> screen layout.  Some messages are preceded by an empty line,   
>>>>> others
>>>>> are
>>>>> not; some are indented 3 characters, others about 10 characters.
>>>>>
>>>>> I would like to use a uniform format: For each file about which  
>>>>> there
>>>>> is a message, indent by 3 spaces, if there is additional  
>>>>> information
>>>>> about that file, indent that by 6 spaces.  Each message begins   
>>>>> with
>>>>> the
>>>>> file name, followed by a colon.  Empty lines only between the
>>>>> different
>>>>> sections.
>>>>>
>>>>> Thomas, would that break your automated report parser?
>>>>
>>>>
>>>> Not where the reports for individual testsuites are concerned; this
>>>> information is stored in individual files "<testsuite>.diffs" in  
>>>> the
>>>> "TEST/<configuration>/<thorn>/" subdir and is simply imported as  
>>>> is  into
>>>> the integration test output.
>>>> The only information which is parsed by the integration test  
>>>> script is
>>>> the one stored in "TEST/<configuration>/summary.log" from which the
>>>> number of available testsuites and the number of passed/failed   
>>>> tests is
>>>> extracted.
>>>> So feel free to unify and beautify the testsuite script output  
>>>> as  you
>>>> like.
>>>
>>>
>>> Do we require a patch for this change?
>>
>> I'd say this counts as documentation, it doesn't change any
>> functionality. Thus shouldn't need to go through our patch approval
>> procedure.
>
> Part of the reason for the patch procedure is to ensure that there is
> discussion beforehand and that people are in sync, so since this  
> has been
> discussed and isn't going to come as a surprise, and we've already  
> covered
> what might be broken by it, it should be fine to just go ahead.

Committed.

-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/20070130/ad0b46d2/attachment-0001.bin 

From szilagyi at aei.mpg.de  Wed Jan 31 11:21:47 2007
From: szilagyi at aei.mpg.de (Bela Szilagyi)
Date: Wed, 31 Jan 2007 18:21:47 +0100
Subject: [Developers] flush-ing stdout in cctk_vinfo
Message-ID: <200701311821.48043.szilagyi@aei.mpg.de>

After some hours of fooling myself (while checking stdout of various processes 
from the same run), I realized that a 

fflush(stdout);

after debugging CCTK_VInfo(...) messages is crucial if one cares for every 
single line of output.  One of my processes hangs and I want to know which 
process is at what point in the source  code.

The loss of output lines is there even if I request, in the 
comand line, that, output would not be buffered.

Apparently the non-buffering options are implemented in a way that would not 
work across all systems, (e.g., peyote nodes).

Can we add the "flush" to the end of the cctk_vinfo?  From what I understand, 
Jonathan Thornburg  has already suggested this...



-- 
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 Jan 31 11:41:19 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 31 Jan 2007 11:41:19 -0600
Subject: [Developers] flush-ing stdout in cctk_vinfo
In-Reply-To: <200701311821.48043.szilagyi@aei.mpg.de>
References: <200701311821.48043.szilagyi@aei.mpg.de>
Message-ID: <D44FB6C9-8CB0-4943-A8E9-6B66AC025A4E@cct.lsu.edu>

On Jan 31, 2007, at 11:21:47, Bela Szilagyi wrote:

> After some hours of fooling myself (while checking stdout of  
> various processes
> from the same run), I realized that a
>
> fflush(stdout);
>
> after debugging CCTK_VInfo(...) messages is crucial if one cares  
> for every
> single line of output.  One of my processes hangs and I want to  
> know which
> process is at what point in the source  code.
>
> The loss of output lines is there even if I request, in the
> comand line, that, output would not be buffered.
>
> Apparently the non-buffering options are implemented in a way that  
> would not
> work across all systems, (e.g., peyote nodes).
>
> Can we add the "flush" to the end of the cctk_vinfo?  From what I  
> understand,
> Jonathan Thornburg  has already suggested this...

We discussed this, and we decided that this would be too expensive in  
general.  Instead we added a command line option "-b" which lets you  
specify whether to flush never, after every line, or after every  
print statement.  This is for all output, not just for CCTK_INFO.   
The default setting is chosen by the operating system, probably  
depending on whether the output goes to a terminal or into a file.

Here are the command line options that Cactus currently understands:

Usage: exe/cactus_bench-wavetoy-carpet [-h] [-O] [-o paramname] [-L  
n] [-W n] [-E n] [-r[o|e|oe|eo]] [--logdir <dir>] [-b <no|line|full>]  
[-S] [-T] [-t name] [--parameter-level <level>] [-v]  
<parameter_file_name>

Valid options:
-h, --help                           : gets this help.
-O[v], --describe-all-parameters     : describes all the parameters.
                                        v makes this verbose, i.e.,  
it gives
                                        a verbose description of all  
parameters.
-o, --describe-parameter <paramname> : describe the given parameter.
-L, --logging-level <n>              : Sets the logging level to n.
-W, --warning-level <n>              : Sets the warning level to n.
-E, --error-level <n>                : Sets the error level to n.
-r, --redirect[o|e|oe|eo]            : Redirects standard output and/or
                                        standard error to files.
     --logdir <dir>                   : Sets the output directory for  
logfiles
                                        created by the '-r' option
-b, --buffering <no|line|full>       : Set stdout buffering mode.
-S, --print-schedule                 : Print the schedule tree, then  
exit.
-T, --list-thorns                    : Lists the compiled-in thorns.
-t, --test-thorn-compiled <name>     : Tests for the presence of  
thorn <name>.
     --parameter-level <level>        : Sets the amount of parameter  
checking,
                                        level can be strict, normal,  
relaxed.
-v, --version                        : Prints the version.
-i, --ignore-next                    : Ignores the next argument.

-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/20070131/23ca7a83/attachment.bin 

From szilagyi at aei.mpg.de  Wed Jan 31 11:56:37 2007
From: szilagyi at aei.mpg.de (Bela Szilagyi)
Date: Wed, 31 Jan 2007 18:56:37 +0100
Subject: [Developers] flush-ing stdout in cctk_vinfo
In-Reply-To: <D44FB6C9-8CB0-4943-A8E9-6B66AC025A4E@cct.lsu.edu>
References: <200701311821.48043.szilagyi@aei.mpg.de>
	<D44FB6C9-8CB0-4943-A8E9-6B66AC025A4E@cct.lsu.edu>
Message-ID: <200701311856.37386.szilagyi@aei.mpg.de>

Erik,

I am using the 

-bno -reo 

options but these do not work.  I.e., in spite of my command line

cactus_harm -reo -bno myparfile.par >& mylogfile.out

I am loosing output lines in various CCTK_Proc[...].out files.

Adding 

 fflush(stdout) ;

into my own code, after CCTK_VInfo(...), has solved the problem.

So my suggestion is to add the fflush() into CCTK_VInfo(...), perhaps 
conditional to an extra parameter. 


On Wednesday 31 January 2007 18:41, Erik Schnetter wrote:
> We discussed this, and we decided that this would be too expensive in ?
> general. ?Instead we added a command line option "-b" which lets you ?
> specify whether to flush never, after every line, or after every ?
> print statement. ?This is for all output, not just for CCTK_INFO. ?
> The default setting is chosen by the operating system, probably ?
> depending on whether the output goes to a terminal or into a file.

-- 
Bela Szilagyi
----------------------------------------------------
Max-Planck-Institut f?r Gravitationsphysik
Albert-Einstein-Institut
Tel: +49 331 567 7632
Fax: +49 331 567 7649
----------------------------------------------------



From jthorn at aei.mpg.de  Wed Jan 31 11:58:07 2007
From: jthorn at aei.mpg.de (Jonathan Thornburg)
Date: Wed, 31 Jan 2007 18:58:07 +0100 (CET)
Subject: [Developers] flush-ing stdout in cctk_vinfo
In-Reply-To: <D44FB6C9-8CB0-4943-A8E9-6B66AC025A4E@cct.lsu.edu>
References: <200701311821.48043.szilagyi@aei.mpg.de>
	<D44FB6C9-8CB0-4943-A8E9-6B66AC025A4E@cct.lsu.edu>
Message-ID: <Pine.LNX.4.63.0701311848310.22763@xeon44.aei.mpg.de>

Hi,

On Jan 31, 2007, at 11:21:47, Bela Szilagyi wrote:
> After some hours of fooling myself (while checking stdout of various
> processes
> from the same run), I realized that a
> 
> fflush(stdout);
> 
> after debugging CCTK_VInfo(...) messages is crucial if one cares for every
> single line of output.  One of my processes hangs and I want to know which
> process is at what point in the source  code.
> 
> The loss of output lines is there even if I request, in the
> comand line, that, output would not be buffered.
> 
> Apparently the non-buffering options are implemented in a way that would not
> work across all systems, (e.g., peyote nodes).
> 
> Can we add the "flush" to the end of the cctk_vinfo?

On Wed, 31 Jan 2007, Erik Schnetter wrote:
> We discussed this, and we decided that this would be too expensive in general.
> Instead we added a command line option "-b" which lets you specify whether to
> flush never, after every line, or after every print statement.  This is for
> all output, not just for CCTK_INFO.

Well, Reading The Fine Source Code reveals that the -b (a.k.a. --buffering)
option turns into a call on CCTKi_CommandLineSetBuffering(), which is
defined in src/main/CommandLine.c starting at line 481 in the current
CVS version.  What this code actually does is this:

void CCTKi_CommandLineSetBuffering (const char *argument)
{
  if (! strcmp (argument, "no"))
  {
    /* Switch to unbuffered mode (best for debugging) */
    setvbuf (stdout, NULL, _IONBF, 0);
  }
  else if (! strcmp (argument, "line"))
  {
    /* Switch to line buffered mode (good for screen output) */
    setvbuf (stdout, NULL, _IOLBF, 0);
  }
  else if (! strcmp (argument, "full"))
  {
    /* Switch to fully buffered mode (fastest) */
    setvbuf (stdout, NULL, _IOFBF, 0);
  }
  else
  {
    CCTK_VWarn (1, __LINE__, __FILE__, "Cactus",
                "Stdout buffering mode '%s' not recognised, "     
                "not changing the default setting", argument);
  }
}

That is, it actually sets the C stdio buffering for  stdout .  It does
not set the C stdio buffering for  stderr  , but as I understand the C
standard, this is supposed to be line buffered by default anyway.  The
code also does not force an explicit  fflush(stdout)  after each
CCTK_VInfo(), either here or in the implementation of CCTK_VInfo()
(which is in src/main/WarnLevel.c, starting at line 229).

In my opinion, the fact that Bela used  --buffering line , yet (as I
understand it) found additional output appearing when he did explicit
flushes, constitutes a bug of some sort.  I'm not quite sure whether
it's caused by stdout and stderr not being synchronized, or a bug in
stdio that isn't handling line buffering properly, but from the user's
perspective, asking for  --buffering line  and not getting it constitues
a bug.

Given this, IMHO Bela's suggestion is a reasonable workaround, which
would certainly avoid the bug in many, albeit not all, cases.  That is,
we would change the code so that if  --buffering line  is specified,
CCTK_VInfo() does an explicit  fflush(stdout)  just before returning.

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>      
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam


From jthorn at aei.mpg.de  Wed Jan 31 12:12:24 2007
From: jthorn at aei.mpg.de (Jonathan Thornburg)
Date: Wed, 31 Jan 2007 19:12:24 +0100 (CET)
Subject: [Developers] flush-ing stdout in cctk_vinfo
In-Reply-To: <Pine.LNX.4.63.0701311848310.22763@xeon44.aei.mpg.de>
References: <200701311821.48043.szilagyi@aei.mpg.de>
	<D44FB6C9-8CB0-4943-A8E9-6B66AC025A4E@cct.lsu.edu>
	<Pine.LNX.4.63.0701311848310.22763@xeon44.aei.mpg.de>
Message-ID: <Pine.LNX.4.63.0701311910540.23074@xeon44.aei.mpg.de>

Hi,

I wrote
> In my opinion, the fact that Bela used  --buffering line , yet (as I
> understand it) found additional output appearing when he did explicit
> flushes, constitutes a bug of some sort.  I'm not quite sure whether
> it's caused by stdout and stderr not being synchronized, or a bug in
> stdio that isn't handling line buffering properly, but from the user's
> perspective, asking for  --buffering line  and not getting it constitues
> a bug.
> 
> Given this, IMHO Bela's suggestion is a reasonable workaround, which
> would certainly avoid the bug in many, albeit not all, cases.  That is,
> we would change the code so that if  --buffering line  is specified,
> CCTK_VInfo() does an explicit  fflush(stdout)  just before returning.

Sorry, I now realise bela specified   -bno   .  But I think this
makes the case even stronger -- he asked for *no* output buffering,
but yet there clearly was some buffering (since explicit flushing
gave additional output).

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>      
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam


From yye00 at cct.lsu.edu  Wed Jan 31 13:55:36 2007
From: yye00 at cct.lsu.edu (Yaakoub Y El Khamra)
Date: Wed, 31 Jan 2007 13:55:36 -0600
Subject: [Developers] Cactus Mojave
Message-ID: <45C0F438.3000703@cct.lsu.edu>


Greetings
We have recently updated the Cactus Code website and added a section 
about Mojave, the Cactus Code Eclipse interface, complete with screen 
shots of Mojave in action. Eclipse is an integrated development 
environment (IDE, http://www.eclipse.org) that comes complete with 
various plugins and a plethora of community developed plugins including 
a parallel debugger (http://www.eclipse.org/ptp). Please take the time 
to check out Mojave and if you run into problems or have features that 
you want implemented please let us know. The URL is: 
http://www.cactuscode.org/Community/Mojave/


Cheers
Yaakoub