On 8 Aug 2013, at 01:04, Erik Schnetter <[email protected]> wrote:
> Carpet has accumulated a large set of timers and clocks. Most of these are > independent of Carpet. In the past, CycleClock was moved to a thorn of its > own, and I now suggest to move the timers to a new thorn "Timers" as well. > > Background: Cactus knows timers and clocks, which are different. A clock > measures something, such as wall time or CPU time. A timer is a collection of > clocks that can be started and stopped. CycleClock measures CPU cycles, and > is thus a high-accuracy clock. This email is about timers, i.e. about the API > that programmers use in the code to time certain tasks. > > I have extracted four classes out of Carpet and into a new thorn Timers: > > CactusTimer: C++ wrapper around standard Cactus timers > CactusTimerSet: knows about all CactusTimers that were ever created > Timer: hierarchical set of CactusTimers > TimerTree: helper class for Timer > > All of the code is C++, reasonably well written. > > As usual, introducing a new thorn is someone inconvenient since people need > to update their thorn lists. Thorn Timers is required by Carpet and will thus > be activated automatically. Additionally, some timer-related parameters > currently in Carpet are now in thorn Timers. > > Comments? Yes, this is a good thing to do. Changing thornlists is a minor inconvenience in comparison to changing parameter files; what happens if you use an old parameter file which makes use of the Carpet timer parameters? Would it be possible to leave the Carpet parameters, have them reported as deprecated in the output, and have the new thorns use them if they have been set? Additionally, the default parameters of the new thorn would give the same effect as the existing Carpet defaults. -- Ian Hinder http://numrel.aei.mpg.de/people/hinder
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
