Carpet Timer object gives 0 the first time it is read

Create issue
Issue #1550 closed
Ian Hinder created an issue

The getTime method of the Carpet Timer object returns a value of 0 the first time it is read. The following test demonstrates the problem:

SCHEDULE Timer_TestTimer at startup
{
  LANG: C
} "Test the timers"


#include <unistd.h>
  extern "C"
  int Timer_TestTimer()
  {
    Timer timer("Test");
    timer.start();
    unsigned int reason = sleep(1);
    double val = timer.getTime();
    assert(reason != 0 || val > 0.5);
    timer.stop();
  }

This is a regression since the original version of the Timer class, possibly introduced during the move of the class from Carpet to Timers. A symptom is that the evolution timer tree shows "inf" for the percentage of the total time the first time it is used, since the Evolve timer used to normalise the time values has been read as zero.

The underlying Cactus timers do not suffer from this problem, so there is something wrong in the logic for the Timer class. The following test passes:

SCHEDULE Timer_TestCactusTimers at startup
{
  LANG: C
} "Test the Cactus timers"


  extern "C"
  int Timer_TestCactusTimers()
  {
    int handle = CCTK_TimerCreate("TestTimer");
    cout << "handle == " << handle << endl;
    assert(handle >= 0);
    CCTK_TimerStartI (handle);
    unsigned int reason = sleep(1);
    CCTK_TimerStopI (handle);

    static cTimerData * timer = 0;
    if (not timer) timer = CCTK_TimerCreateData ();
    assert (timer);
    CCTK_TimerI (handle, timer);

    const cTimerVal* tv = CCTK_GetClockValue("gettimeofday", timer);
    assert(tv);

    double val = CCTK_TimerClockSeconds(tv);
    assert(reason != 0 || val > 0.5);

    return 0;
  }

Keyword:

Comments (5)

  1. Erik Schnetter
    • removed comment

    This code works for me when I ensure that the code is scheduled AFTER Timer_Startup.

    Note that the function getTime() returns the current time of the -- wait for it -- innermost currently running timer. This is, in most cases, not the time of the timer which is actually queried. However, TimerNode's getTime() function works as one would expect.

    My test code is committed as CarpetExtra/TestTimers2.

  2. Erik Schnetter
    • removed comment

    I may have been overly optimistic with my statement above. I now see the error that you describe.

  3. Erik Schnetter
    • changed status to resolved
    • removed comment

    The Cactus timer was not stopped while reading it. The explicit code above changed the order compared to CactusTimer.cc, so it was not affected.

  4. Log in to comment