From d.rideout at imperial.ac.uk  Mon Mar  5 10:06:49 2007
From: d.rideout at imperial.ac.uk (David Rideout)
Date: Mon, 5 Mar 2007 16:06:49 +0000
Subject: [Developers] macro as macro argument
Message-ID: <200703051606.50056.d.rideout@imperial.ac.uk>

I have a C macro which employs internal variables, e.g.

#define foo(arg1) { \
  int internal_var; \
  ... code(arg1) ... }

Often the macro is invoked multiple times in a single source file, which leads 
to a compiler warning about identical variables in scope or something like 
this.  I tried a hack:

#define foo(arg1, XX) { \
  int internal_var##XX; \
  ... code(arg1) ... }

which I wanted to call with

foo(bar, __LINE__)

to give each internal variable a unique name, but this instead makes each 
internal variable into 'internal_var__LINE__'.

Can someone more familiar with the workings of the C preprocessor suggest a 
way to avoid this compiler warning?

(I am trying to build an API in Cactus which uses macros, so in this sense the 
question is on-topic...)

Many thanks,
David

From schnetter at cct.lsu.edu  Mon Mar  5 10:34:42 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Mon, 5 Mar 2007 10:34:42 -0600
Subject: [Developers] macro as macro argument
In-Reply-To: <200703051606.50056.d.rideout@imperial.ac.uk>
References: <200703051606.50056.d.rideout@imperial.ac.uk>
Message-ID: <40A92CDE-DA1C-481B-A24F-D590BC8B3A01@cct.lsu.edu>

On Mar 5, 2007, at 10:06:49, David Rideout wrote:

> I have a C macro which employs internal variables, e.g.
>
> #define foo(arg1) { \
>   int internal_var; \
>   ... code(arg1) ... }
>
> Often the macro is invoked multiple times in a single source file,  
> which leads
> to a compiler warning about identical variables in scope or  
> something like
> this.  I tried a hack:
>
> #define foo(arg1, XX) { \
>   int internal_var##XX; \
>   ... code(arg1) ... }
>
> which I wanted to call with
>
> foo(bar, __LINE__)
>
> to give each internal variable a unique name, but this instead  
> makes each
> internal variable into 'internal_var__LINE__'.
>
> Can someone more familiar with the workings of the C preprocessor  
> suggest a
> way to avoid this compiler warning?

As shown, your code should not warn about identical variables in  
scope, since each macro closes its scope.  Do you have maybe other  
variables as well which have the same name?

Could you rewrite your code using inline functions, or maybe C++  
templates?  I often find this much cleaner than macros, and also much  
easier to debug.  You can use templates in C++ and have the remainder  
of your programme still in C style, if you prefer that.

If you want to continue with your existing approach, then the usual  
remedy is to add a bit of indirection by defining some additional  
macros with arguments.  See <http://www.decompile.com/cpp/faq/ 
file_and_line_error_string.htm> for an example; this doesn't do  
exactly what you want, but it handles __LINE__ and encounters a very  
similar error.

-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/20070305/8efce3aa/attachment.bin 

From d.rideout at imperial.ac.uk  Tue Mar  6 09:17:27 2007
From: d.rideout at imperial.ac.uk (David Rideout)
Date: Tue, 6 Mar 2007 15:17:27 +0000
Subject: [Developers] macro as macro argument
In-Reply-To: <40A92CDE-DA1C-481B-A24F-D590BC8B3A01@cct.lsu.edu>
References: <200703051606.50056.d.rideout@imperial.ac.uk>
	<40A92CDE-DA1C-481B-A24F-D590BC8B3A01@cct.lsu.edu>
Message-ID: <200703061517.27393.d.rideout@imperial.ac.uk>

Hi Erik,

Thanks for your reply.  I realize now that I did not explain the function of 
the macro sufficiently.  Indeed the code I posted does not generate compiler 
warnings.

This macro is meant to 'set up' a loop, so in a sense it has a final 'implied 
argument' which is a block of code enclosed in {}.  The warning comes when 
one uses this for a nested loop:

/home/rideout/Cactus/configs/causets/build/Playground/Distance.c:94: warning: 
declaration of 'SETS_word_index' shadows a previous local
/home/rideout/Cactus/configs/causets/build/Playground/Distance.c:94: warning: 
shadowed declaration is here

I sorted out a fix by reading appendix A12 of Kernighan & Richie carefully.  
It explains that macro arguments to ## are not expanded.

I realize that this loop macro could be replaced with something like the 
following in the calling code:

while (inline_function_with_static_vars(arg)) { ... user code ...}

Perhaps this is cleaner?  (Or maybe replacing 
inline_function_with_static_vars(arg) with a macro which passes around the 
internal variables as necessary.)  

Thanks again,
David

On Monday 05 March 2007 16:34, Erik Schnetter wrote:
> On Mar 5, 2007, at 10:06:49, David Rideout wrote:
> > I have a C macro which employs internal variables, e.g.
> >
> > #define foo(arg1) { \
> >   int internal_var; \
> >   ... code(arg1) ... }
> >
> > Often the macro is invoked multiple times in a single source file,
> > which leads
> > to a compiler warning about identical variables in scope or
> > something like
> > this.  I tried a hack:
> >
> > #define foo(arg1, XX) { \
> >   int internal_var##XX; \
> >   ... code(arg1) ... }
> >
> > which I wanted to call with
> >
> > foo(bar, __LINE__)
> >
> > to give each internal variable a unique name, but this instead
> > makes each
> > internal variable into 'internal_var__LINE__'.
> >
> > Can someone more familiar with the workings of the C preprocessor
> > suggest a
> > way to avoid this compiler warning?
>
> As shown, your code should not warn about identical variables in
> scope, since each macro closes its scope.  Do you have maybe other
> variables as well which have the same name?
>
> Could you rewrite your code using inline functions, or maybe C++
> templates?  I often find this much cleaner than macros, and also much
> easier to debug.  You can use templates in C++ and have the remainder
> of your programme still in C style, if you prefer that.
>
> If you want to continue with your existing approach, then the usual
> remedy is to add a bit of indirection by defining some additional
> macros with arguments.  See <http://www.decompile.com/cpp/faq/
> file_and_line_error_string.htm> for an example; this doesn't do
> exactly what you want, but it handles __LINE__ and encounters a very
> similar error.
>
> -erik

From goodale at cct.lsu.edu  Tue Mar  6 10:26:17 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Tue, 6 Mar 2007 16:26:17 +0000 (GMT)
Subject: [Developers] macro as macro argument
In-Reply-To: <200703061517.27393.d.rideout@imperial.ac.uk>
References: <200703051606.50056.d.rideout@imperial.ac.uk>
	<40A92CDE-DA1C-481B-A24F-D590BC8B3A01@cct.lsu.edu>
	<200703061517.27393.d.rideout@imperial.ac.uk>
Message-ID: <Pine.LNX.4.64.0703061624000.6645@fandango.dyndns.org>


Hi David,

if you want the argument expanded, just do

#define foo1(arg1, XX) foo(arg1, XX)

#define foo(arg1, XX) { \
int internal_var##XX; \
   ... code(arg1) ... }

and call foo1 with

foo1(bar, __LINE__)

as XX will get expanded in the call to the lower-level macro.

Cheers,

Tom

On Tue, 6 Mar 2007, David Rideout wrote:

> Hi Erik,
>
> Thanks for your reply.  I realize now that I did not explain the function of
> the macro sufficiently.  Indeed the code I posted does not generate compiler
> warnings.
>
> This macro is meant to 'set up' a loop, so in a sense it has a final 'implied
> argument' which is a block of code enclosed in {}.  The warning comes when
> one uses this for a nested loop:
>
> /home/rideout/Cactus/configs/causets/build/Playground/Distance.c:94: warning:
> declaration of 'SETS_word_index' shadows a previous local
> /home/rideout/Cactus/configs/causets/build/Playground/Distance.c:94: warning:
> shadowed declaration is here
>
> I sorted out a fix by reading appendix A12 of Kernighan & Richie carefully.
> It explains that macro arguments to ## are not expanded.
>
> I realize that this loop macro could be replaced with something like the
> following in the calling code:
>
> while (inline_function_with_static_vars(arg)) { ... user code ...}
>
> Perhaps this is cleaner?  (Or maybe replacing
> inline_function_with_static_vars(arg) with a macro which passes around the
> internal variables as necessary.)
>
> Thanks again,
> David
>
> On Monday 05 March 2007 16:34, Erik Schnetter wrote:
>> On Mar 5, 2007, at 10:06:49, David Rideout wrote:
>>> I have a C macro which employs internal variables, e.g.
>>>
>>> #define foo(arg1) { \
>>>   int internal_var; \
>>>   ... code(arg1) ... }
>>>
>>> Often the macro is invoked multiple times in a single source file,
>>> which leads
>>> to a compiler warning about identical variables in scope or
>>> something like
>>> this.  I tried a hack:
>>>
>>> #define foo(arg1, XX) { \
>>>   int internal_var##XX; \
>>>   ... code(arg1) ... }
>>>
>>> which I wanted to call with
>>>
>>> foo(bar, __LINE__)
>>>
>>> to give each internal variable a unique name, but this instead
>>> makes each
>>> internal variable into 'internal_var__LINE__'.
>>>
>>> Can someone more familiar with the workings of the C preprocessor
>>> suggest a
>>> way to avoid this compiler warning?
>>
>> As shown, your code should not warn about identical variables in
>> scope, since each macro closes its scope.  Do you have maybe other
>> variables as well which have the same name?
>>
>> Could you rewrite your code using inline functions, or maybe C++
>> templates?  I often find this much cleaner than macros, and also much
>> easier to debug.  You can use templates in C++ and have the remainder
>> of your programme still in C style, if you prefer that.
>>
>> If you want to continue with your existing approach, then the usual
>> remedy is to add a bit of indirection by defining some additional
>> macros with arguments.  See <http://www.decompile.com/cpp/faq/
>> file_and_line_error_string.htm> for an example; this doesn't do
>> exactly what you want, but it handles __LINE__ and encounters a very
>> similar error.
>>
>> -erik
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>

From schnetter at cct.lsu.edu  Tue Mar  6 11:35:32 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 6 Mar 2007 11:35:32 -0600
Subject: [Developers] macro as macro argument
In-Reply-To: <200703061517.27393.d.rideout@imperial.ac.uk>
References: <200703051606.50056.d.rideout@imperial.ac.uk>
	<40A92CDE-DA1C-481B-A24F-D590BC8B3A01@cct.lsu.edu>
	<200703061517.27393.d.rideout@imperial.ac.uk>
Message-ID: <0738960A-65CB-4FFB-B512-71B1187B715D@cct.lsu.edu>

David,

I would not express a multi-dimensional loop as a single while loop.   
I tried this, and it confuses the compiler optimiser.

The C++ Boost libraries (www.boost.org) have support for this kind of  
looping, built on templates.  I haven't used it myself, but I've  
talked to people, and it seems to be a very elegant solution.   
Hartmut Kaiser, one of the CCT scientists, is contributing to Boost;  
maybe he can point to a particular library that would be useful for you?

-erik

On Mar 6, 2007, at 09:17:27, David Rideout wrote:

> Hi Erik,
>
> Thanks for your reply.  I realize now that I did not explain the  
> function of
> the macro sufficiently.  Indeed the code I posted does not generate  
> compiler
> warnings.
>
> This macro is meant to 'set up' a loop, so in a sense it has a  
> final 'implied
> argument' which is a block of code enclosed in {}.  The warning  
> comes when
> one uses this for a nested loop:
>
> /home/rideout/Cactus/configs/causets/build/Playground/Distance.c: 
> 94: warning:
> declaration of 'SETS_word_index' shadows a previous local
> /home/rideout/Cactus/configs/causets/build/Playground/Distance.c: 
> 94: warning:
> shadowed declaration is here
>
> I sorted out a fix by reading appendix A12 of Kernighan & Richie  
> carefully.
> It explains that macro arguments to ## are not expanded.
>
> I realize that this loop macro could be replaced with something  
> like the
> following in the calling code:
>
> while (inline_function_with_static_vars(arg)) { ... user code ...}
>
> Perhaps this is cleaner?  (Or maybe replacing
> inline_function_with_static_vars(arg) with a macro which passes  
> around the
> internal variables as necessary.)
>
> Thanks again,
> David
>
> On Monday 05 March 2007 16:34, Erik Schnetter wrote:
>> On Mar 5, 2007, at 10:06:49, David Rideout wrote:
>>> I have a C macro which employs internal variables, e.g.
>>>
>>> #define foo(arg1) { \
>>>   int internal_var; \
>>>   ... code(arg1) ... }
>>>
>>> Often the macro is invoked multiple times in a single source file,
>>> which leads
>>> to a compiler warning about identical variables in scope or
>>> something like
>>> this.  I tried a hack:
>>>
>>> #define foo(arg1, XX) { \
>>>   int internal_var##XX; \
>>>   ... code(arg1) ... }
>>>
>>> which I wanted to call with
>>>
>>> foo(bar, __LINE__)
>>>
>>> to give each internal variable a unique name, but this instead
>>> makes each
>>> internal variable into 'internal_var__LINE__'.
>>>
>>> Can someone more familiar with the workings of the C preprocessor
>>> suggest a
>>> way to avoid this compiler warning?
>>
>> As shown, your code should not warn about identical variables in
>> scope, since each macro closes its scope.  Do you have maybe other
>> variables as well which have the same name?
>>
>> Could you rewrite your code using inline functions, or maybe C++
>> templates?  I often find this much cleaner than macros, and also much
>> easier to debug.  You can use templates in C++ and have the remainder
>> of your programme still in C style, if you prefer that.
>>
>> If you want to continue with your existing approach, then the usual
>> remedy is to add a bit of indirection by defining some additional
>> macros with arguments.  See <http://www.decompile.com/cpp/faq/
>> file_and_line_error_string.htm> for an example; this doesn't do
>> exactly what you want, but it handles __LINE__ and encounters a very
>> similar error.
>>
>> -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/20070306/cc584f10/attachment.bin 

From schnetter at cct.lsu.edu  Tue Mar  6 11:53:37 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 6 Mar 2007 11:53:37 -0600
Subject: [Developers] AHFinderDirect accuracy for test suite
Message-ID: <300612F5-0FC9-4092-8E7A-8FABB81B5EB3@cct.lsu.edu>

I see some AHFinderDirect test cases fail because the absolute or  
relative difference of the results is about 1.0e-6 for some results.   
The test cases currently allow only an error of 1.0e-8.  Given that  
the test cases pass on some problems and fail on others, do we think  
that this is a real problem that could be solved e.g. by changing  
solver parameters, or should we just accept these errors?

AHFinderDirect's accuracy is set to 1.0e-12.  We could change  
compiler optimisation switches, which may (or may not) make a  
difference.

-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/20070306/4ecd2dca/attachment-0001.bin 

From zachetie at yahoo.com  Tue Mar  6 12:52:49 2007
From: zachetie at yahoo.com (Zach Etienne)
Date: Tue, 6 Mar 2007 10:52:49 -0800 (PST)
Subject: [Developers] Need a Working BAM_Elliptic and EllPETSc
In-Reply-To: <300612F5-0FC9-4092-8E7A-8FABB81B5EB3@cct.lsu.edu>
Message-ID: <492576.82075.qm@web32714.mail.mud.yahoo.com>

Hello.

We (the Illinois group) need an elliptic solver in Cactus.  Thus far, we have found that with our version of Cactus+AEIThorns (latest publicly available CVS from cactuscode.org and cvs.aei.mpg.de) neither BAM_Elliptic nor EllPETSc will work properly.  Ideally, we would like to use either.

I've detailed our problems with these two thorns in the below sections.

-= BAM_Elliptic Problems =-
BAM_Elliptic compiles just fine, but when I try to run it, it gives:
WARNING level 0 in thorn BAM_Elliptic processor 0
  (line 294 of /.../Cactus/configs/.../build/BAM_Elliptic/Cactus4_utils.c): 
  -> BAM requires PUGH::processor_topology to be set to "manual" or "automatic_old"
When I do what the warning suggests, I get a segfault (when attempting to set the topology to manual) or "Range error setting parameter 'PUGH::processor_topology' to 'automatic_old'" (when attempting to set the topology to automatic_old).  Looking at the source code, I conclude that this problem appears to be caused by a bugfix inside BAM_Elliptic/src/Cactus4_utils.c.  

Cry for help:
Does anyone have a version of BAM_Elliptic that does not have this issue with the latest PUGH?

-= EllPETSc Problems =-
Apparently the PETSc API has changed since the current CVS version of EllPETSc was written.  With the latest version of PETSc (petsc-2.3.2-p8), EllPETSc will not even compile, giving the error:
/.../Cactus/configs/.../build/EllPETSc/petsc_confmetric_solver.c(1046): error #165: too few arguments in function call
    ierr = SLESSolve(sles,b,soln,&its); CHKERRQ(ierr);

Cry for help:
Does anyone have a version of EllPETSc that works with the latest version of Cactus?  At the very least, does anyone know what version of PETSc EllPETSc was designed to work with?

Thanks for your reply.

-Zach Etienne, on behalf of the Illinois group


 
---------------------------------
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/developers/attachments/20070306/45ab1925/attachment.html 

From schnetter at cct.lsu.edu  Tue Mar  6 13:22:53 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Tue, 6 Mar 2007 13:22:53 -0600
Subject: [Developers] Need a Working BAM_Elliptic and EllPETSc
In-Reply-To: <492576.82075.qm@web32714.mail.mud.yahoo.com>
References: <492576.82075.qm@web32714.mail.mud.yahoo.com>
Message-ID: <BC28EE7F-6F6A-46FB-A264-31E217B70F08@cct.lsu.edu>

On Mar 6, 2007, at 12:52:49, Zach Etienne wrote:

> Hello.
>
> We (the Illinois group) need an elliptic solver in Cactus.  Thus  
> far, we have found that with our version of Cactus+AEIThorns  
> (latest publicly available CVS from cactuscode.org and  
> cvs.aei.mpg.de) neither BAM_Elliptic nor EllPETSc will work  
> properly.  Ideally, we would like to use either.

Hi Zach,

I'm sorry to hear you have problems.

> I've detailed our problems with these two thorns in the below  
> sections.
>
> -= BAM_Elliptic Problems =-
> BAM_Elliptic compiles just fine, but when I try to run it, it gives:
> WARNING level 0 in thorn BAM_Elliptic processor 0
>   (line 294 of /.../Cactus/configs/.../build/BAM_Elliptic/ 
> Cactus4_utils.c):
>   -> BAM requires PUGH::processor_topology to be set to "manual" or  
> "automatic_old"
> When I do what the warning suggests, I get a segfault (when  
> attempting to set the topology to manual) or "Range error setting  
> parameter 'PUGH::processor_topology' to 'automatic_old'" (when  
> attempting to set the topology to automatic_old).  Looking at the  
> source code, I conclude that this problem appears to be caused by a  
> bugfix inside BAM_Elliptic/src/Cactus4_utils.c.
>
> Cry for help:
> Does anyone have a version of BAM_Elliptic that does not have this  
> issue with the latest PUGH?

Are you using the development version of Cactus, or the stable  
release?  See <http://www.cactuscode.org/Toolkit/getcactus> for the  
distinction.

> -= EllPETSc Problems =-
> Apparently the PETSc API has changed since the current CVS version  
> of EllPETSc was written.  With the latest version of PETSc  
> (petsc-2.3.2-p8), EllPETSc will not even compile, giving the error:
> /.../Cactus/configs/.../build/EllPETSc/petsc_confmetric_solver.c 
> (1046): error #165: too few arguments in function call
>     ierr = SLESSolve(sles,b,soln,&its); CHKERRQ(ierr);
>
> Cry for help:
> Does anyone have a version of EllPETSc that works with the latest  
> version of Cactus?  At the very least, does anyone know what  
> version of PETSc EllPETSc was designed to work with?

The PETSc interface changes quite often.  I recently committed a  
change to the development version of Cactus that should make EllPETSc  
work with PETSc 2.3.2.  Are you using the stable release of Cactus or  
the development version?  Can you try the development version?

EllPETSc should work with PETSc 2.2.x.

-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/20070306/b4d64b38/attachment.bin 

From zachetie at yahoo.com  Tue Mar  6 15:07:18 2007
From: zachetie at yahoo.com (Zach Etienne)
Date: Tue, 6 Mar 2007 13:07:18 -0800 (PST)
Subject: [Developers] Need a Working BAM_Elliptic and EllPETSc
In-Reply-To: <BC28EE7F-6F6A-46FB-A264-31E217B70F08@cct.lsu.edu>
Message-ID: <644026.90567.qm@web32707.mail.mud.yahoo.com>

Erik,

Thanks for your help!

The way Cactus developers use CVS is a little foreign to me, since most open source groups that use CVS will provide tarballs of stable releases and will refer interested users/developers to their CVS tree for the bleeding-edge development source code.

Turns out, I was using the latest cvs.cactuscode.org:/cactus version of the code (which I _thought_ was the latest development version).  I suppose this was the most recent _stable_ Cactus release.  I just downloaded and compiled (!) the latest ...:/cactusdevcvs version with BAM_Elliptic, and it looks like BAM_Elliptic now runs, without crashing!

If I have problems with EllPETSc and the latest development version (recompiling PETSc now), I'll send another email.

Again, thanks!
-Zach


Erik Schnetter <schnetter at cct.lsu.edu> wrote: On Mar 6, 2007, at 12:52:49, Zach Etienne wrote:

> Hello.
>
> We (the Illinois group) need an elliptic solver in Cactus.  Thus  
> far, we have found that with our version of Cactus+AEIThorns  
> (latest publicly available CVS from cactuscode.org and  
> cvs.aei.mpg.de) neither BAM_Elliptic nor EllPETSc will work  
> properly.  Ideally, we would like to use either.

Hi Zach,

I'm sorry to hear you have problems.

> I've detailed our problems with these two thorns in the below  
> sections.
>
> -= BAM_Elliptic Problems =-
> BAM_Elliptic compiles just fine, but when I try to run it, it gives:
> WARNING level 0 in thorn BAM_Elliptic processor 0
>   (line 294 of /.../Cactus/configs/.../build/BAM_Elliptic/ 
> Cactus4_utils.c):
>   -> BAM requires PUGH::processor_topology to be set to "manual" or  
> "automatic_old"
> When I do what the warning suggests, I get a segfault (when  
> attempting to set the topology to manual) or "Range error setting  
> parameter 'PUGH::processor_topology' to 'automatic_old'" (when  
> attempting to set the topology to automatic_old).  Looking at the  
> source code, I conclude that this problem appears to be caused by a  
> bugfix inside BAM_Elliptic/src/Cactus4_utils.c.
>
> Cry for help:
> Does anyone have a version of BAM_Elliptic that does not have this  
> issue with the latest PUGH?

Are you using the development version of Cactus, or the stable  
release?  See  for the  
distinction.

> -= EllPETSc Problems =-
> Apparently the PETSc API has changed since the current CVS version  
> of EllPETSc was written.  With the latest version of PETSc  
> (petsc-2.3.2-p8), EllPETSc will not even compile, giving the error:
> /.../Cactus/configs/.../build/EllPETSc/petsc_confmetric_solver.c 
> (1046): error #165: too few arguments in function call
>     ierr = SLESSolve(sles,b,soln,&its); CHKERRQ(ierr);
>
> Cry for help:
> Does anyone have a version of EllPETSc that works with the latest  
> version of Cactus?  At the very least, does anyone know what  
> version of PETSc EllPETSc was designed to work with?

The PETSc interface changes quite often.  I recently committed a  
change to the development version of Cactus that should make EllPETSc  
work with PETSc 2.3.2.  Are you using the stable release of Cactus or  
the development version?  Can you try the development version?

EllPETSc should work with PETSc 2.2.x.

-erik

-- 
Erik Schnetter 

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



_______________________________________________
Developers mailing list
Developers at cactuscode.org
http://www.cactuscode.org/mailman/listinfo/developers


 
---------------------------------
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.cactuscode.org/pipermail/developers/attachments/20070306/e5788c70/attachment.html 

From baiotti at aei.mpg.de  Mon Mar 12 03:56:20 2007
From: baiotti at aei.mpg.de (Luca Baiotti)
Date: Mon, 12 Mar 2007 10:56:20 +0100
Subject: [Developers] PREREGRID bin
Message-ID: <45F523C4.7010101@aei.mpg.de>

Hi,

I would like also the PREREGRID bin to be printed in the schedule tree 
at the beginning of a run.

Is this possible?


Thanks,

Luca.


From baiotti at aei.mpg.de  Mon Mar 12 03:58:12 2007
From: baiotti at aei.mpg.de (Luca Baiotti)
Date: Mon, 12 Mar 2007 10:58:12 +0100
Subject: [Developers] CCTK_ParameterSet
Message-ID: <45F52434.1010903@aei.mpg.de>

Hi,

I would like the function CCTK_ParameterSet to be available also for 
Fortran.

Is it possible?

Thanks,

Luca.


From tradke at aei.mpg.de  Mon Mar 12 05:15:13 2007
From: tradke at aei.mpg.de (Thomas Radke)
Date: Mon, 12 Mar 2007 12:15:13 +0100
Subject: [Developers] CCTK_ParameterSet
In-Reply-To: <45F52434.1010903@aei.mpg.de>
References: <45F52434.1010903@aei.mpg.de>
Message-ID: <45F53641.6070308@aei.mpg.de>

Luca Baiotti wrote:
> Hi,
> 
> I would like the function CCTK_ParameterSet to be available also for 
> Fortran.
> 
> Is it possible?

It surely is possible. Does anything speak against it ?

-- 
Cheers, Thomas.

From goodale at cct.lsu.edu  Mon Mar 12 05:31:46 2007
From: goodale at cct.lsu.edu (Tom Goodale)
Date: Mon, 12 Mar 2007 11:31:46 +0000 (GMT)
Subject: [Developers] CCTK_ParameterSet
In-Reply-To: <45F53641.6070308@aei.mpg.de>
References: <45F52434.1010903@aei.mpg.de> <45F53641.6070308@aei.mpg.de>
Message-ID: <Pine.LNX.4.64.0703121131360.21210@fandango.dyndns.org>

On Mon, 12 Mar 2007, Thomas Radke wrote:

> Luca Baiotti wrote:
>> Hi,
>>
>> I would like the function CCTK_ParameterSet to be available also for
>> Fortran.
>>
>> Is it possible?
>
> It surely is possible. Does anything speak against it ?

Go ahead.

From jtao at cct.lsu.edu  Tue Mar 13 17:05:01 2007
From: jtao at cct.lsu.edu (jtao at cct.lsu.edu)
Date: Tue, 13 Mar 2007 17:05:01 -0600
Subject: [Developers] ifndef in DXYDG_guts.h
Message-ID: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>

I don't know if this was considered as a bug and has been fixed
in the development version of CactusEinstein. I saw the following
statments in DXYDG_guts.h,

#ifndef DXYDG_GUTS
#define DXYDG_DECLARE

Where DXYDG_GUTS is never defined anywere.

I am also concerned about the usage of the spatial order
parameter in the loops. Shouldn't it be better to define the
order of spatial derivatives with a macro and keep the same
interface for all the derivatives ? Conditional statments
will not appear in the loops and it is still easy to
go to other orders.

e.g.

#define FD_ORDER 8
#if FD_ORDER == 2
#define DX(var,i,j,k)   i2dx*(var(i+1,j,k) - var(i-1,j,k))
...
#elif FD_ORDER == 4
#define DX(var,i,j,k)   i4dx*(-var(i+2,j,k) + var(i-2,j,k) \
                         + 8.d0*(var(i+1,j,k) - var(i-1,j,k)))
...
#elif FD_ORDER == 8
#define DX(var,i,j,k) i8dx* \
         (  3.d0*(var(-4 + i,j,k) - var(4 + i,j,k)) \
         - 32.d0*(var(-3 + i,j,k) - var(3 + i,j,k)) \
         +168.d0*(var(-2 + i,j,k) - var(2 + i,j,k)) \
         -672.d0*(var(-1 + i,j,k) - var(1 + i,j,k)))
...
#endif

Regards,
Jian



From schnetter at cct.lsu.edu  Wed Mar 14 08:20:01 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 14 Mar 2007 09:20:01 -0500
Subject: [Developers] ifndef in DXYDG_guts.h
In-Reply-To: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>
References: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>
Message-ID: <DB677B4E-C173-4BFB-AD03-53316E181092@cct.lsu.edu>

On Mar 13, 2007, at 18:05:01, jtao at cct.lsu.edu wrote:

> I don't know if this was considered as a bug and has been fixed
> in the development version of CactusEinstein. I saw the following
> statments in DXYDG_guts.h,
>
> #ifndef DXYDG_GUTS
> #define DXYDG_DECLARE
>
> Where DXYDG_GUTS is never defined anywere.

This is clearly an error.  Luckily a harmless one; code won't be  
skipped but only duplicated, which can at most result in errors,  
given how the code is structured.  Thanks!

> I am also concerned about the usage of the spatial order
> parameter in the loops. Shouldn't it be better to define the
> order of spatial derivatives with a macro and keep the same
> interface for all the derivatives ? Conditional statments
> will not appear in the loops and it is still easy to
> go to other orders.
>
> e.g.
>
> #define FD_ORDER 8
> #if FD_ORDER == 2
> #define DX(var,i,j,k)   i2dx*(var(i+1,j,k) - var(i-1,j,k))
> ...
> #elif FD_ORDER == 4
> #define DX(var,i,j,k)   i4dx*(-var(i+2,j,k) + var(i-2,j,k) \
>                          + 8.d0*(var(i+1,j,k) - var(i-1,j,k)))
> ...
> #elif FD_ORDER == 8
> #define DX(var,i,j,k) i8dx* \
>          (  3.d0*(var(-4 + i,j,k) - var(4 + i,j,k)) \
>          - 32.d0*(var(-3 + i,j,k) - var(3 + i,j,k)) \
>          +168.d0*(var(-2 + i,j,k) - var(2 + i,j,k)) \
>          -672.d0*(var(-1 + i,j,k) - var(1 + i,j,k)))
> ...
> #endif

This would make it impossible to choose the order at run time.

We have measured the performance of the code, and we find that these  
if statements to not decrease performance.  I know that there is  
folklore that if statements in loop are very expensive, but this is  
not the case for this code.  We assume that we either benefit from  
branch prediction or that the other operations are so expensive that  
branch misprediction is not relevant.

-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/20070314/b99387e4/attachment.bin 

From schnetter at cct.lsu.edu  Wed Mar 14 08:36:32 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 14 Mar 2007 09:36:32 -0500
Subject: [Developers] ifndef in DXYDG_guts.h
In-Reply-To: <DB677B4E-C173-4BFB-AD03-53316E181092@cct.lsu.edu>
References: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>
	<DB677B4E-C173-4BFB-AD03-53316E181092@cct.lsu.edu>
Message-ID: <498AB998-40C6-4712-935A-42B6A10A72B8@cct.lsu.edu>

On Mar 14, 2007, at 09:20:01, Erik Schnetter wrote:

> On Mar 13, 2007, at 18:05:01, jtao at cct.lsu.edu wrote:
>
>> I am also concerned about the usage of the spatial order
>> parameter in the loops. Shouldn't it be better to define the
>> order of spatial derivatives with a macro and keep the same
>> interface for all the derivatives ? Conditional statments
>> will not appear in the loops and it is still easy to
>> go to other orders.

I have heard that Penn State uses Kranc <http://numrel.aei.mpg.de/ 
Research/Kranc/> to generate code automatically.  I have heard that  
they generate different routines for each spatial differencing  
order.  This still allows switching at run time (since several  
routines are present), but allows each routine to be optimised  
independently.

-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/20070314/554a2065/attachment.bin 

From hinder at gravity.psu.edu  Wed Mar 14 09:15:42 2007
From: hinder at gravity.psu.edu (Ian Hinder)
Date: Wed, 14 Mar 2007 11:15:42 -0400
Subject: [Developers] ifndef in DXYDG_guts.h
In-Reply-To: <498AB998-40C6-4712-935A-42B6A10A72B8@cct.lsu.edu>
References: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>	<DB677B4E-C173-4BFB-AD03-53316E181092@cct.lsu.edu>
	<498AB998-40C6-4712-935A-42B6A10A72B8@cct.lsu.edu>
Message-ID: <45F8119E.2080401@gravity.psu.edu>

Erik Schnetter wrote:
> On Mar 14, 2007, at 09:20:01, Erik Schnetter wrote:
> 
>> On Mar 13, 2007, at 18:05:01, jtao at cct.lsu.edu wrote:
>>
>>> I am also concerned about the usage of the spatial order
>>> parameter in the loops. Shouldn't it be better to define the
>>> order of spatial derivatives with a macro and keep the same
>>> interface for all the derivatives ? Conditional statments
>>> will not appear in the loops and it is still easy to
>>> go to other orders.
> 
> I have heard that Penn State uses Kranc
> <http://numrel.aei.mpg.de/Research/Kranc/> to generate code
> automatically.  I have heard that they generate different routines for
> each spatial differencing order.  This still allows switching at run
> time (since several routines are present), but allows each routine to be
> optimised independently.

Indeed, however this was done based on the *assumption* that having an
if statement in the inner loop would be expensive.  I suspect that it
might be possible to add such a statement without incurring a
performance penalty (for the reasons Erik stated in his previous email).
 It is on my list of things to try, as it would make the code (both the
script, and the generated code) a lot cleaner.

-- 
Ian Hinder
hinder at gravity.psu.edu
http://www.gravity.psu.edu/~hinder

From schnetter at cct.lsu.edu  Wed Mar 14 09:39:13 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 14 Mar 2007 10:39:13 -0500
Subject: [Developers] ifndef in DXYDG_guts.h
In-Reply-To: <45F8119E.2080401@gravity.psu.edu>
References: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>	<DB677B4E-C173-4BFB-AD03-53316E181092@cct.lsu.edu>
	<498AB998-40C6-4712-935A-42B6A10A72B8@cct.lsu.edu>
	<45F8119E.2080401@gravity.psu.edu>
Message-ID: <4A162D38-A575-44AC-B242-2F36DF39599C@cct.lsu.edu>

On Mar 14, 2007, at 10:15:42, Ian Hinder wrote:

> Erik Schnetter wrote:
>> On Mar 14, 2007, at 09:20:01, Erik Schnetter wrote:
>>
>>> On Mar 13, 2007, at 18:05:01, jtao at cct.lsu.edu wrote:
>>>
>>>> I am also concerned about the usage of the spatial order
>>>> parameter in the loops. Shouldn't it be better to define the
>>>> order of spatial derivatives with a macro and keep the same
>>>> interface for all the derivatives ? Conditional statments
>>>> will not appear in the loops and it is still easy to
>>>> go to other orders.
>>
>> I have heard that Penn State uses Kranc
>> <http://numrel.aei.mpg.de/Research/Kranc/> to generate code
>> automatically.  I have heard that they generate different routines  
>> for
>> each spatial differencing order.  This still allows switching at run
>> time (since several routines are present), but allows each routine  
>> to be
>> optimised independently.
>
> Indeed, however this was done based on the *assumption* that having an
> if statement in the inner loop would be expensive.  I suspect that it
> might be possible to add such a statement without incurring a
> performance penalty (for the reasons Erik stated in his previous  
> email).
>  It is on my list of things to try, as it would make the code (both  
> the
> script, and the generated code) a lot cleaner.

*assumption*: See "root of all evil", aka "premature optimisation".

I just came across a nice article: <http://www.flounder.com/ 
optimization.htm>.

-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/20070314/d203c91d/attachment.bin 

From hinder at gravity.psu.edu  Wed Mar 14 09:56:04 2007
From: hinder at gravity.psu.edu (Ian Hinder)
Date: Wed, 14 Mar 2007 11:56:04 -0400
Subject: [Developers] ifndef in DXYDG_guts.h
In-Reply-To: <4A162D38-A575-44AC-B242-2F36DF39599C@cct.lsu.edu>
References: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>	<DB677B4E-C173-4BFB-AD03-53316E181092@cct.lsu.edu>	<498AB998-40C6-4712-935A-42B6A10A72B8@cct.lsu.edu>	<45F8119E.2080401@gravity.psu.edu>
	<4A162D38-A575-44AC-B242-2F36DF39599C@cct.lsu.edu>
Message-ID: <45F81B14.2000504@gravity.psu.edu>

Erik Schnetter wrote:
> On Mar 14, 2007, at 10:15:42, Ian Hinder wrote:
> 
>> Erik Schnetter wrote:
>>> On Mar 14, 2007, at 09:20:01, Erik Schnetter wrote:
>>>
>>>> On Mar 13, 2007, at 18:05:01, jtao at cct.lsu.edu wrote:
>>>>
>>>>> I am also concerned about the usage of the spatial order
>>>>> parameter in the loops. Shouldn't it be better to define the
>>>>> order of spatial derivatives with a macro and keep the same
>>>>> interface for all the derivatives ? Conditional statments
>>>>> will not appear in the loops and it is still easy to
>>>>> go to other orders.
>>>
>>> I have heard that Penn State uses Kranc
>>> <http://numrel.aei.mpg.de/Research/Kranc/> to generate code
>>> automatically.  I have heard that they generate different routines for
>>> each spatial differencing order.  This still allows switching at run
>>> time (since several routines are present), but allows each routine to be
>>> optimised independently.
>>
>> Indeed, however this was done based on the *assumption* that having an
>> if statement in the inner loop would be expensive.  I suspect that it
>> might be possible to add such a statement without incurring a
>> performance penalty (for the reasons Erik stated in his previous email).
>>  It is on my list of things to try, as it would make the code (both the
>> script, and the generated code) a lot cleaner.
> 
> *assumption*: See "root of all evil", aka "premature optimisation".

Agreed, though in my defense, it was also easier to do it this way (a
change in the user script) than to modify Kranc at the time...

-- 
Ian Hinder
hinder at gravity.psu.edu
http://www.gravity.psu.edu/~hinder

From jshalf at lbl.gov  Wed Mar 14 10:10:17 2007
From: jshalf at lbl.gov (John Shalf)
Date: Wed, 14 Mar 2007 09:10:17 -0700
Subject: [Developers] ifndef in DXYDG_guts.h
In-Reply-To: <45F81B14.2000504@gravity.psu.edu>
References: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>
	<DB677B4E-C173-4BFB-AD03-53316E181092@cct.lsu.edu>
	<498AB998-40C6-4712-935A-42B6A10A72B8@cct.lsu.edu>
	<45F8119E.2080401@gravity.psu.edu>
	<4A162D38-A575-44AC-B242-2F36DF39599C@cct.lsu.edu>
	<45F81B14.2000504@gravity.psu.edu>
Message-ID: <4EF914A4-EE1D-4C4D-AA15-AD4343EE34AD@lbl.gov>


Well, the conditionals caused lots of problems for the vector  
machines when we were trying to get the code running on the Earth  
Simulator a few years ago.  (they get implemented as vector mask  
operations, which are wasteful).  However, I think the X2 may well be  
one of the last vector machines we will see for a while. If we start  
using GPUs or Cell processors (not likely very soon), then branch  
penalties will become something to worry about again.

It is certainly interesting to perform the experiment (perhaps even  
using standalone_BSSN) to ensure that our assumptions about the  
quality of branch-prediction are indeed true.  But the intuition  
about modern branch predictors is probably true (they are pretty  
damned good these days).

-john

On Mar 14, 2007, at 8:56 AM, Ian Hinder wrote:
> Erik Schnetter wrote:
>> On Mar 14, 2007, at 10:15:42, Ian Hinder wrote:
>>> Erik Schnetter wrote:
>>>> On Mar 14, 2007, at 09:20:01, Erik Schnetter wrote:
>>> Indeed, however this was done based on the *assumption* that  
>>> having an
>>> if statement in the inner loop would be expensive.  I suspect  
>>> that it
>>> might be possible to add such a statement without incurring a
>>> performance penalty (for the reasons Erik stated in his previous  
>>> email).
>>>  It is on my list of things to try, as it would make the code  
>>> (both the
>>> script, and the generated code) a lot cleaner.
>>
>> *assumption*: See "root of all evil", aka "premature optimisation".
>
> Agreed, though in my defense, it was also easier to do it this way (a
> change in the user script) than to modify Kranc at the time...

From schnetter at cct.lsu.edu  Wed Mar 14 11:29:22 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 14 Mar 2007 12:29:22 -0500
Subject: [Developers] ifndef in DXYDG_guts.h
In-Reply-To: <4EF914A4-EE1D-4C4D-AA15-AD4343EE34AD@lbl.gov>
References: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>
	<DB677B4E-C173-4BFB-AD03-53316E181092@cct.lsu.edu>
	<498AB998-40C6-4712-935A-42B6A10A72B8@cct.lsu.edu>
	<45F8119E.2080401@gravity.psu.edu>
	<4A162D38-A575-44AC-B242-2F36DF39599C@cct.lsu.edu>
	<45F81B14.2000504@gravity.psu.edu>
	<4EF914A4-EE1D-4C4D-AA15-AD4343EE34AD@lbl.gov>
Message-ID: <391302A0-9CB0-4078-B5D9-E64D7BABA5EC@cct.lsu.edu>

On Mar 14, 2007, at 11:10:17, John Shalf wrote:

> It is certainly interesting to perform the experiment (perhaps even
> using standalone_BSSN) to ensure that our assumptions about the
> quality of branch-prediction are indeed true.  But the intuition
> about modern branch predictors is probably true (they are pretty
> damned good these days).

Let me clarify: We did in fact perform this experiment last December,  
and the result was that the overall performance increase was lost in  
the noise (somewhere around 1% or 2%, I cannot remember the exact  
number).  We did not have a good intuition about modern branch  
predictors: we actually assumed that we could speed up the code a  
lot, but the experiment proved us wrong.  There is nothing like a  
dose of reality.

This was the work of Jennifer Seiler, a physics student at the AEI.   
She specialised parts of BSSN_MoL, removing many if statements, not  
just those for finite differencing operators.  She also removed if  
statements choosing gauge conditions and selecting formulations.  We  
decided in the end that the performance gain (if any) was not worth  
the added complication.

-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/20070314/4a442022/attachment.bin 

From jtao at cct.lsu.edu  Wed Mar 14 17:49:59 2007
From: jtao at cct.lsu.edu (jtao at cct.lsu.edu)
Date: Wed, 14 Mar 2007 17:49:59 -0600
Subject: [Developers] ifndef in DXYDG_guts.h
In-Reply-To: <391302A0-9CB0-4078-B5D9-E64D7BABA5EC@cct.lsu.edu>
References: <20070313170501.chdqv3k8hs0s44o8@webmail.cct.lsu.edu>
	<DB677B4E-C173-4BFB-AD03-53316E181092@cct.lsu.edu>
	<498AB998-40C6-4712-935A-42B6A10A72B8@cct.lsu.edu>
	<45F8119E.2080401@gravity.psu.edu>
	<4A162D38-A575-44AC-B242-2F36DF39599C@cct.lsu.edu>
	<45F81B14.2000504@gravity.psu.edu>
	<4EF914A4-EE1D-4C4D-AA15-AD4343EE34AD@lbl.gov>
	<391302A0-9CB0-4078-B5D9-E64D7BABA5EC@cct.lsu.edu>
Message-ID: <20070314174959.65qk4t7kw0os4kks@webmail.cct.lsu.edu>

Quoting Erik Schnetter <schnetter at cct.lsu.edu>:
> This was the work of Jennifer Seiler, a physics student at the AEI.
> She specialised parts of BSSN_MoL, removing many if statements, not
> just those for finite differencing operators.  She also removed if
> statements choosing gauge conditions and selecting formulations.  We
> decided in the end that the performance gain (if any) was not worth
> the added complication.

Actually, it comes to the question that how often one expects to choose
local spatial order. I personally don't think that will be done very often.

As for the code, adding a macro to control the finite difference order as
I suggested in my previous post will definite reduce the complication if one
wants to go to higher orders. In that case one doesn't need to add
additoinal macro functions (ADM_D**) and there will be no need to add
more else if branches in the code.

As for the performance, one will not lose anything by moving
conditional statements out. However, tests probably should be done on
different architectures to see how much one loses to decide if it is worth
adding branches.

Anyway, adding a macro like that is kind of against the idea of Cactus to
use parameters to control runs.

Regards,
Jian



From schnetter at cct.lsu.edu  Wed Mar 14 21:26:30 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Wed, 14 Mar 2007 22:26:30 -0500
Subject: [Developers] PREREGRID bin
In-Reply-To: <45F523C4.7010101@aei.mpg.de>
References: <45F523C4.7010101@aei.mpg.de>
Message-ID: <04482F8D-A3FC-41BD-9CAE-8483F5EC00DE@cct.lsu.edu>


On Mar 12, 2007, at 04:56:20, Luca Baiotti wrote:

> Hi,
>
> I would like also the PREREGRID bin to be printed in the schedule tree
> at the beginning of a run.
>
> Is this possible?

Can you try the attached 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: schedule.diff
Type: application/octet-stream
Size: 7437 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070314/4273793f/attachment.obj 
-------------- next part --------------

-------------- 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/20070314/4273793f/attachment.bin 

From baiotti at aei.mpg.de  Thu Mar 15 05:45:22 2007
From: baiotti at aei.mpg.de (Luca Baiotti)
Date: Thu, 15 Mar 2007 12:45:22 +0100
Subject: [Developers] PREREGRID bin
In-Reply-To: <04482F8D-A3FC-41BD-9CAE-8483F5EC00DE@cct.lsu.edu>
References: <45F523C4.7010101@aei.mpg.de>
	<04482F8D-A3FC-41BD-9CAE-8483F5EC00DE@cct.lsu.edu>
Message-ID: <45F931D2.4040901@aei.mpg.de>

Hi Erik,

I tried the patch and it works.


Thanks,

Luca.


Erik Schnetter wrote:
> 
> On Mar 12, 2007, at 04:56:20, Luca Baiotti wrote:
> 
>> Hi,
>>
>> I would like also the PREREGRID bin to be printed in the schedule tree
>> at the beginning of a run.
>>
>> Is this possible?
> 
> Can you try the attached patch?
> 
> -erik


From schnetter at cct.lsu.edu  Thu Mar 15 08:28:41 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Thu, 15 Mar 2007 09:28:41 -0500
Subject: [Developers] PREREGRID bin
In-Reply-To: <45F931D2.4040901@aei.mpg.de>
References: <45F523C4.7010101@aei.mpg.de>
	<04482F8D-A3FC-41BD-9CAE-8483F5EC00DE@cct.lsu.edu>
	<45F931D2.4040901@aei.mpg.de>
Message-ID: <CC9A429D-B274-484C-8D8E-FFAC9A283416@cct.lsu.edu>

Is the output correct?  Do all the timing numbers make sense?  Is the  
order of the schedule bins all right?  Is it now confusion because  
there are so many bins?  Did I forget some bins?

-erik

On Mar 15, 2007, at 06:45:22, Luca Baiotti wrote:

> Hi Erik,
>
> I tried the patch and it works.
>
>
> Thanks,
>
> Luca.
>
>
> Erik Schnetter wrote:
>>
>> On Mar 12, 2007, at 04:56:20, Luca Baiotti wrote:
>>
>>> Hi,
>>>
>>> I would like also the PREREGRID bin to be printed in the schedule  
>>> tree
>>> at the beginning of a run.
>>>
>>> Is this possible?
>>
>> Can you try the attached patch?
>>
>> -erik
>
> _______________________________________________
> 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/20070315/c8b47557/attachment.bin 

From baiotti at aei.mpg.de  Thu Mar 15 10:02:09 2007
From: baiotti at aei.mpg.de (Luca Baiotti)
Date: Thu, 15 Mar 2007 17:02:09 +0100
Subject: [Developers] PREREGRID bin
In-Reply-To: <CC9A429D-B274-484C-8D8E-FFAC9A283416@cct.lsu.edu>
References: <45F523C4.7010101@aei.mpg.de>	<04482F8D-A3FC-41BD-9CAE-8483F5EC00DE@cct.lsu.edu>	<45F931D2.4040901@aei.mpg.de>
	<CC9A429D-B274-484C-8D8E-FFAC9A283416@cct.lsu.edu>
Message-ID: <45F96E01.8010508@aei.mpg.de>

Erik Schnetter wrote:
> Is the output correct?  Do all the timing numbers make sense?  

Yes, yes. To me.

Is the
> order of the schedule bins all right?  

Yes, but for a better description one should look at the Carpet 
documentation...

> Is it now confusion because there are so many bins?  

Not so much, referring just to the printed schedule. It is OK.

Did I forget some bins?

I don't know of additional bins.


Ciao,

Luca.


From szilagyi at aei.mpg.de  Thu Mar 15 10:10:56 2007
From: szilagyi at aei.mpg.de (Bela Szilagyi)
Date: Thu, 15 Mar 2007 17:10:56 +0100
Subject: [Developers] PREREGRID bin
In-Reply-To: <45F96E01.8010508@aei.mpg.de>
References: <45F523C4.7010101@aei.mpg.de>
	<CC9A429D-B274-484C-8D8E-FFAC9A283416@cct.lsu.edu>
	<45F96E01.8010508@aei.mpg.de>
Message-ID: <200703151710.56929.szilagyi@aei.mpg.de>

If it is about bins --

im some versions of Carpet you have POST*INITIAL bins.  Can those be displayed 
as well?  Or are those shown already?


On Thursday 15 March 2007 17:02, Luca Baiotti wrote:
> Erik Schnetter wrote:
> > Is the output correct?  Do all the timing numbers make sense?
>
> Yes, yes. To me.
>
> Is the
>
> > order of the schedule bins all right?
>
> Yes, but for a better description one should look at the Carpet
> documentation...
>
> > Is it now confusion because there are so many bins?
>
> Not so much, referring just to the printed schedule. It is OK.
>
> Did I forget some bins?
>
> I don't know of additional bins.
>
>
> Ciao,
>
> Luca.
>
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers

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



From schnetter at cct.lsu.edu  Thu Mar 15 10:16:52 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Thu, 15 Mar 2007 11:16:52 -0500
Subject: [Developers] Fwd: [CactusMaint] Cactus/2086: PATCH: Output Carpet's
	schedule bins in the schedule
References: <200703151610.l2FGAWLo022038@cactus.cct.lsu.edu>
Message-ID: <AE4B89FC-0F1C-4757-8505-344113E2FDC7@cct.lsu.edu>

Begin forwarded message:

> From: schnetter at cct.lsu.edu
> Date: March 15, 2007 11:10:32 AM CDT
> To: goodale at cct.lsu.edu, gnats-admin at cactuscode.org,  
> cactusmaint at cactuscode.org
> Cc: baiotti at aei.mpg.de
> Subject: [CactusMaint] Cactus/2086: PATCH: Output Carpet's schedule  
> bins in the schedule
> Reply-To: bugs at cactuscode.org, CactusMaint  
> <cactusmaint at cactuscode.org>
>
>> Number:         2086
>> Notify-List:    baiotti at aei.mpg.de
>> Category:       Cactus
>> Synopsis:       PATCH: Output Carpet's schedule bins in the schedule
>> Confidential:   no
>> Severity:       non-critical
>> Priority:       medium
>> Responsible:    goodale
>> State:          open
>> Class:          feature-request
>> Submitter-Id:   user
>> Arrival-Date:   Thu Mar 15 10:10:32 -0600 2007
>> Originator:     Erik Schnetter
>> Release:        Cactus 4.0.b16
>> Organization:
>> Environment:
>> Description:
> Output all of Carpet's schedule bins in the schedule and when  
> printing the schedule timers.
>
> Tested by Luca Baiotti.
>> 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/20070315/93b45d20/attachment.bin 

From schnetter at cct.lsu.edu  Sat Mar 17 14:55:43 2007
From: schnetter at cct.lsu.edu (Erik Schnetter)
Date: Sat, 17 Mar 2007 15:55:43 -0500
Subject: [Developers] Fwd: [CactusMaint] Cactus/2087: PATCH: Make GF
	reductions callable from Fortran
References: <200703172054.l2HKskN4021268@cactus.cct.lsu.edu>
Message-ID: <5FA92674-ABCE-4099-BB04-FE2622DF22A0@cct.lsu.edu>

Begin forwarded message:

> From: schnetter at cct.lsu.edu
> Date: March 17, 2007 3:54:46 PM CDT
> To: goodale at cct.lsu.edu, gnats-admin at cactuscode.org,  
> cactusmaint at cactuscode.org
> Subject: [CactusMaint] Cactus/2087: PATCH: Make GF reductions  
> callable from Fortran
> Reply-To: bugs at cactuscode.org, CactusMaint  
> <cactusmaint at cactuscode.org>
>
>> Number:         2087
>> Notify-List:
>> Category:       Cactus
>> Synopsis:       PATCH: Make GF reductions callable from Fortran
>> Confidential:   no
>> Severity:       critical
>> Priority:       high
>> Responsible:    goodale
>> State:          open
>> Class:          sw-bug
>> Submitter-Id:   user
>> Arrival-Date:   Sat Mar 17 14:54:46 -0600 2007
>> Originator:     Erik Schnetter
>> Release:        Cactus 4.0.b16
>> Organization:
>> Environment:
>> Description:
> There is a long-standing problem in calling CCTK_Reduce from  
> Fortran: Since this function uses a variable argument list, certain  
> architectures (especially x86_64) do not support calling it from  
> Fortran.
>
> The enclosed patch provides a new routine CCTK_Reduce1 which does  
> not use a variable argument list.  Instead of passing the list of  
> grid function indices as variable arguments, it expects them to be  
> passed in as array.
>
> This new routine will be superceded by the new reduction interface  
> once this becomes available.
>
> See <http://www.cactuscode.org/pipermail/users/2004-September/ 
> 001224.html> for the original bug report and the original  
> suggestion for this patch.
>> 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/20070317/bf32f5d0/attachment-0001.bin