[Developers] Fwd: [CactusMaint] CactusUtils/2079: Patch for thorn TimerReport: Output timer reports to a file instead of to stdout

[Erik Schnetter]

On May 17, 2007, at 06:00:58, Thomas Radke wrote:

> Erik Schnetter wrote:
>> The message below proposes a patch to the flesh.  Thomas, Jonathan,
>> Tom, could you have a look?
>
> With this new flesh function CCTK_SchedulePrintTimesToFile() your  
> patch
> to thorn TimerReport becomes partially obsolete, I presume. I have  
> added
> a new patch (attachement 2 on
> http://www.cactuscode.org/cactus_cgi-bin/gnatsweb.pl?cmd=view% 
> 20audit-trail&database=cactus&pr=2079)
> which should replace the old one. Two comments to this one:
>
>   * In schedule.ccl the TimerReport_Output routine at TERMINATE  
> must be
>     scheduled BEFORE DriverTerminate, otherwise you will run into a
>     'null communicator' MPI error when calling 'CCTK_MyProc(cctkGH)'.
>     This slight rescheduling of routines implies that we can't measure
>     the exact time spent in the TERMINATE bin but the inaccuracy  
> should
>     be negligible.
>
>   * Declaring a large local array 'char filename [10000];' in Output.c
>     is potentially dangerous and probably overkill anyway. I reduced
>     its size to 200 characters which should suffice.

I think Posix specifies that files names can be up to 1023 characters  
long.  What if a file name is longer, e.g. because it contains a  
URL?  File names can easily be longer than 80 characters, so a hard  
limit of 200 is dangerously close.

Why do you think that 10000 is dangerous?  This space will be  
allocated on the stack for a brief time.  Do you think that the stack  
cannot handle this?  BSSN_MoL has so many local variables that it  
requires much more stack space, or the compiler has to allocate the  
variables somewhere else (which may happen).  Is there a machine  
where stack space is an issue?

I don't agree with a limit of 200.  I think the limit needs to be  
either very large, or I will replace it by an automatic allocation,  
although this complicates the code.

-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/20070517/79b106b3/attachment.bin