On 2013-08-14, at 18:56 , rhaas@tapir.caltech.edu wrote:
User: rhaas Date: 2013/08/14 07:56 PM
Modified: /trunk/ einsteintoolkit.th
Log: add Timers thorn (required by Carpet)
I apologize for requiring the Timer thorn without due notice.
I was debugging a particular memory allocation problem for about a week, and in the course of this, I cleanup up many stretches of code in Carpet and CarpetLib. I suspected that the timers were at fault, so I isolated the code and added parameters to disable the timers. Alas, the timers were not at fault. However, having the timers separated seemed like a good idea, and instead of throwing away all the clean-ups, or re-implementing the solution anew, I decided to push all clean-ups together with the work-around that avoids the problem.
-erik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all,
I apologize for requiring the Timer thorn without due notice.
But there was due announcement (and a kind of go ahead):
http://cactuscode.org/pipermail/users/2013-August/003390.html
:-)
Yours, Roland
- -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
On 15 Aug 2013, at 03:17, Roland Haas roland.haas@physics.gatech.edu wrote:
Signed PGP part Hello all,
I apologize for requiring the Timer thorn without due notice.
But there was due announcement (and a kind of go ahead):
http://cactuscode.org/pipermail/users/2013-August/003390.html
:-)
Erik, you didn't answer about whether parameter files need to be changed; if they do, I think this is quite a disruptive change. Also, why not make the dependence of Carpet on the Timers thorn optional? This would increase modularity.
On 2013-08-15, at 2:15 , Ian Hinder ian.hinder@aei.mpg.de wrote:
On 15 Aug 2013, at 03:17, Roland Haas roland.haas@physics.gatech.edu wrote:
Signed PGP part Hello all,
I apologize for requiring the Timer thorn without due notice.
But there was due announcement (and a kind of go ahead):
http://cactuscode.org/pipermail/users/2013-August/003390.html
:-)
Erik, you didn't answer about whether parameter files need to be changed; if they do, I think this is quite a disruptive change. Also, why not make the dependence of Carpet on the Timers thorn optional? This would increase modularity.
My main concern was to avoid the memory leak.
We can add parameters to Carpet, use them from thorn timers, and add warnings if they are set. Are there volunteers for this work? I feel that I deserve a break after fighting the Intel compiler for a week, and adding parameters and warnings doesn't require the deep understanding of Carpet that tracking down memory leaks does. (I want to re-emphasize that the code was fine, this memory leak was (probably) a problem with the Intel compiler, and the current code only contains a work-around to avoid the problem, it doesn't "correct" the problem.)
We can also make thorn Timers optional, probably either by sprinkling (and there will be many, probably more than a hundred) #ifdefs, or by introducing wrapper classes around all the Timers classes in all thorns that want to optionally depend on Timers. Neither is ideal...
-erik
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Ian Hinder -
Roland Haas