Carpet shouldn't stop the "CCTK_ total time" timer at Shutdown

Create issue
Issue #1141 closed
Frank Löffler created an issue

Currently, Carpet stops the "CTTK total time" timer in Shutdown. This now emits a warning since the flesh tries to stop this timer as well. Also, the comment close to this code is wrong and needs to be changed/removed: Carpet/src/Shutdown.c:59

    // Stop all timers before shutdown, since timers may rely on data
    // structures which are destroyed during shutdown
    int const ierr = CCTK_TimerStop ("CCTK total time");


Comments (16)

  1. Ian Hinder
    • removed comment

    I don't think we can release the toolkit in a state where you get a warning like this on every single run you do. It doesn't give much confidence to the users.

  2. Frank Löffler reporter
    • removed comment

    We know that trying this isn't really a problem (since the double stopping is prevented). Thus, what about increasing the warning level, let's say to 4?

  3. Erik Schnetter
    • removed comment

    In most cases, starting or stopping a timer multiple times is a serious problem, since the timer values will be wrong. Thus, a visible warning is needed.

    We either need to correct the problem that prompted this code in Carpet, or keep the code. If no one is working on this, then we need to release with the warning.

  4. Frank Löffler reporter
    • removed comment

    Double starting/stopping will not pose a serious problem to the code. From the definitions of the warning levels:

    #define CCTK_WARN_ABORT    0    /* abort the Cactus run */
    #define CCTK_WARN_ALERT    1    /* the results of this run will be wrong, */
                                    /* and this will surprise the user, */
                                    /* but we can still continue the run */
    #define CCTK_WARN_COMPLAIN 2    /* the user should know about this, */
                                    /* but the problem is not terribly */
                                    /* surprising */
    #define CCTK_WARN_PICKY    3    /* this is for small problems that can */
                                    /* probably be ignored, but that careful */
                                    /* people may want to know about */
    #define CCTK_WARN_DEBUG    4    /* these messages are probably useful */
                                    /* only for debugging purposes */

    Now, it all depends on how you define 'results of this run'. Most users will consider the timers to be a side product, not part of the main 'results'. CCTK_WARN_PICKY sounds best to me, but then that is still shown using simfactory defaults, thus I suggested CCTK_WARN_DEBUG (4).

  5. Ian Hinder
    • removed comment

    My original suggestion was to modify the flesh function which displays the timers on shutdown to only stop the timers if they are currently running. With the new flag, isn't this straightforward to implement?

  6. Frank Löffler reporter
    • removed comment

    Currently there is no interface to get to that information outside of CactusTimers.c. We could add a function to the Cactus API:

      int CCTK_TimerRunning(const char *name);
      int CCTK_TimerRunningI(int this_timer);
  7. Frank Löffler reporter
    • changed status to open
    • changed milestone to ET_2012_11
    • removed comment

    Attached is a patch which adds this functionality to Cactus and uses it to only stop this timer in case it is running.

  8. Roland Haas
    • changed status to open
    • removed comment

    I get very many errors

    WARNING[L1,P1] (Cactus): CCTK_TimerStartI: Trying to start timer "Slab/copy_back_noflip" (130) which is already running.

    when running the ML_BSSN_EE_sgw3d test of ML_BSSN_Test on 4 MPI processes.

    Attached please find the test log file.

  9. Frank Löffler reporter
    • changed status to resolved
    • removed comment

    This was a bug in CactusNumerical/Slab. Because of a typo it tried to start the timer again when it should stop it instead. This is now fixed as of r86.

  10. Roland Haas
    • removed comment

    Thank you. Making sure that I am in Slab's thorn folder when typing svn update would likely have helped.

  11. Frank Löffler reporter
    • removed comment

    Well, I only fixed the bug after you reported it here. So, now you can update.

  12. Log in to comment