- changed milestone to ET_2013_05
- removed comment
Carpet shouldn't stop the "CCTK_ total time" timer at Shutdown
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");
Keyword:
Comments (16)
-
reporter -
- 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.
-
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?
-
- 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.
-
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).
-
- 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?
-
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);
-
reporter - removed comment
TimerIsRunning would probably be better.
-
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.
-
- changed status to open
- removed comment
Please apply.
-
reporter - changed status to resolved
- removed comment
-
- 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.
-
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.
-
- removed comment
Thank you. Making sure that I am in Slab's thorn folder when typing svn update would likely have helped.
-
reporter - removed comment
Well, I only fixed the bug after you reported it here. So, now you can update.
-
- changed status to closed
- edited description
- Log in to comment