Using Timing Files

Using Timing Files#

Model timing files contain a summary of various timing information for the run. It is helpful to check the timings after the run to verify that the model is running efficiently.


1. What are timing files and where are they located?#

An output file with a summary of timing information is produced after every CLM run. This file is placed in $CASEROOT/timing/cesm_timing.$CASE.$date, where $date is a datestamp set by CLM at runtime, and contains a summary of various timing information.

The first section in the timing output, “TIMING PROFILE”, summarizes general timing information for the run. The total run time and cost are given in several metrics including pe-hrs per simulated year (cost), simulated years per wall day (throughput), seconds, and seconds per model day. This provides general summary information quickly in several units for analysis and comparison with other runs. The total run time for each component is also provided, as is the time for initialization of the model. These times are the aggregate over the total run and do not take into account any temporal or processor load imbalances.

2. Use timing files to determine runtime variables#

Check out the timing file for our i1850_sp.basics case. It won’t be exactly the same every time you run the same case/configuration, but it should be similar. You should see something like this:

Overall Metrics: 
    Model Cost:             141.35   pe-hrs/simulated_year 
    Model Throughput:       282.53   simulated_years/day

The model throughput is the estimated number of model years that you can run in a wallclock day. Based on this, you can maximize the $CASE.run queue limit and change STOP_OPTION and STOP_N in env_run.xml.

For example, say a model’s throughput is 283 simulated_years/day. On Derecho, the maximum runtime limit is 12 hours. 283 model years/24 hours * 12 hours = 141.5 years. On the massively parallel computers, there is always some variability in how long it will take a job to run. On some machines, you may need to leave as much as 20% buffer time in your run to guarantee that jobs finish reliably before the time limit. For that reason we will set our model to run only 100 model years/job submission.

Continuing to assume that the run is on Derecho, we can set:

./xmlchange STOP_OPTION='nyears'
./xmlchange STOP_N=100

Next up#

In the next chapter, we will move on to learning about modifying our run type.

Contents