Closed kburns closed 2 years ago
Can also discuss other performance tracking things that we've been thinking about (e.g. transform/transpose counts) here, or in another PR/issue.
Thanks, Ben! I think the easiest thing will be to rebase this onto the valid_modes stuff after that's merged.
This PR currently just adds some basic built-in timings for IVPs to reduce boilerplate and provide more consistent performance evaluations across scripts. The IVP solvers now internally time:
1) "Setup time" meaning everything from solver initialization to the beginning of the first iteration. 2) "Warmup time" meaning the time for the first N iterations, where N is adjustable and can be set at/after solver initialization, and defaults to 10. 3) "Run time" meaning the time for all iterations after N.
The
solver.log_stats
method can be used to easily log these at the end of an IVP, along with the "CPU time" of the simulation in cpu-hrs, and the "Speed" of the simulation in mode-stages/cpu-sec. Here "modes" is the total number of coeff-space degrees of freedom, calculated from adding the sizes of all the subproblem matrices (so the true DOF count even for spheres, etc.). And "stages" is the total number of RHS evaluations, computed as the total iterations times the stages-per-iteration for the chosen timestepper. So this should put the multistep and RK methods closer to the same footing. The string formatting for these is customizable via a keyword argument to the method.Any thoughts? This seems like a good core set of basic stats to report at the end of most simulations. Do we prefer the examples to use this method and have reduced boilerplate, or to be more explicit as before?