time-stepping — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited time-stepping (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Provide a reliable workflow for choosing, ramping, and monitoring time steps plus output/checkpoint cadence.
| Input | Description | Example |
|---|---|---|
| Stability limits | CFL/Fourier/reaction limits | dt_max = 1e-4 |
| Target dt | Desired time step | 1e-5 |
| Total run time | Simulation duration | 10 s |
| Output interval | Time between outputs | 0.1 s |
| Checkpoint cost | Time to write checkpoint | 120 s |
Is stability limit known?
├── YES → Use min(dt_target, dt_limit × safety)
└── NO → Start conservative, increase adaptively
Need ramping for startup?
├── YES → Start at dt_init, ramp to dt_target over N steps
└── NO → Use dt_target from start| Problem Type | Ramp Steps | Initial dt |
|---|---|---|
| Smooth IC | None needed | Full dt |
| Sharp gradients | 5-10 | 0.1 × dt |
| Phase change | 10-20 | 0.01 × dt |
| Cold start | 10-50 | 0.001 × dt |
| Script | Key Outputs |
|---|---|
scripts/timestep_planner.py | dt_limit, dt_recommended, ramp_schedule, notes |
scripts/output_schedule.py | output_times, interval, count |
scripts/checkpoint_planner.py | checkpoint_interval, checkpoints, overhead_fraction, warnings |
output_schedule.py count is endpoint-inclusive: it includes both t_start and t_end, so count = number_of_intervals + 1 (e.g. t=0..5 at 0.05 spacing yields 101 frames for 100 intervals).
scripts/timestep_planner.pyscripts/output_schedule.pyscripts/checkpoint_planner.pyUser: I'm running a 10-hour phase-field simulation. How often should I checkpoint?
Agent workflow:
python3 scripts/checkpoint_planner.py --run-time 36000 --checkpoint-cost 120 --max-lost-time 1800 --json# Plan time stepping with ramping
python3 scripts/timestep_planner.py --dt-target 1e-4 --dt-limit 2e-4 --safety 0.8 --ramp-steps 10 --json
# Schedule output times
python3 scripts/output_schedule.py --t-start 0 --t-end 10 --interval 0.1 --json
# Plan checkpoints for long run
python3 scripts/checkpoint_planner.py --run-time 36000 --checkpoint-cost 120 --max-lost-time 1800 --json| Error | Cause | Resolution |
|---|---|---|
dt-target must be positive | Invalid time step | Use positive value |
t-end must be > t-start | Invalid time range | Check time bounds |
checkpoint-cost must be < run-time | Checkpoint too expensive | Reduce checkpoint size |
| Observation | Meaning | Action |
|---|---|---|
| dt stable at target | Good | Continue |
| dt shrinking | Stability issue | Check CFL, reduce target |
| dt oscillating | Borderline stability | Add safety factor |
| Overhead | Acceptability |
|---|---|
| < 1% | Excellent |
| 1-5% | Good |
| 5-10% | Acceptable |
| > 10% | Too frequent, increase interval |
dt_recommended and dt_limit from timestep_planner.py and confirmed dt_recommended <= dt_limit with no "Recommended dt exceeds stability limit" note in the notes field.dt_limit value from the stability analysis (numerical-stability skill: CFL/Fourier/reaction limit) that was fed to --dt-limit, rather than guessing — and re-ran the planner after any parameter change.safety <= 1.0 was applied (a margin below the limit), and logged the notes array (e.g. "Recommended dt reduced by stability limit", min/max clamps) so the binding constraint is known.output_schedule.py count and verified it is endpoint-inclusive (count = intervals + 1, both t_start and t_end present), so frame counts and post-processing indices are not off-by-one.interval, method (daly vs cap), and overhead_fraction from checkpoint_planner.py, and confirmed overhead_fraction <= 0.10 (no warnings entry) against the overhead acceptability table.ValueError) and that quoted dt/interval/checkpoint values come from the JSON results, not from a run that printed a validation error.| Tempting shortcut | Why it's wrong / what to do |
|---|---|
"Implicit scheme, so any dt is fine — skip --dt-limit." | Unconditional stability is not accuracy; a large dt still ruins temporal error and resolves no transient. Still pass a physics-based dt-target and re-check the recommended dt against time scales. |
"Set --safety above 1.0 to take bigger steps." | safety is a margin at or below the limit; safety > 1.0 would return a dt above the stability limit, so the planner rejects it (exit 2). Lower dt-limit expectations or use a finer mesh instead. |
| "It ran without crashing, so the dt is valid." | Run completion is not correctness. Verify dt_recommended <= dt_limit, read the notes array, and re-plan whenever v_max, D, dx, or the scheme changes — the limit moves with them. |
"The output count looks one too many — drop the last frame." | count is endpoint-inclusive by design (intervals + 1); both t_start and t_end are real outputs. Trimming it silently loses the final state. |
| "Checkpoint every step to never lose work." | That drives overhead_fraction past 10% (the planner emits a warnings entry) and dominates runtime. Use --max-lost-time (cap) or --mtbf (Daly) so overhead stays in the Acceptable band. |
| "Reuse last week's dt/checkpoint plan; the model is basically the same." | Stability and optimal checkpoint interval depend on current dx, velocity/diffusivity, checkpoint-cost, and MTBF. Re-run the three scripts with current values rather than copying stale numbers. |
dt-target, dt-limit, safety, t-start, t-end, interval, run-time, checkpoint-cost, max-lost-time) are validated as finite positive numbers (non-finite values such as inf/nan are rejected)safety is bounded to <= 1.0 (a safety factor is a stability margin at or below the limit; values above 1.0 are rejected)ramp-steps and preview-steps are validated as non-negative integers with an upper bound of 1,000,000; only the previewed slice of the ramp is materialized to bound memory uset-end must exceed t-start; checkpoint-cost must be less than run-time)timestep_planner.py, output_schedule.py, checkpoint_planner.py) with explicit argument listseval(), exec(), or dynamic code generationshell=True)references/cfl_coupling.md - Combining multiple stability limitsreferences/ramping_strategies.md - Startup policiesreferences/output_checkpoint_guidelines.md - Cadence rules~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.