A computational result is more useful when another person—and your future self—can reconstruct how it was produced.
Record the complete configuration
Save the solver name and version, parameter values, time and memory limits, number of threads, random seed, model variant, and computing environment. Default parameters can change between software releases, so “solver defaults” is rarely a complete experimental description.
Keep data and code identifiable
Each result should be traceable to an exact dataset and source revision. Stable instance names, checksums, and a recorded source-control revision help prevent accidental comparisons between different inputs or implementations.
Define metrics before running
- Wall-clock time and termination status.
- Primal and dual bounds.
- Relative and absolute optimality gaps.
- Node counts, iteration counts, or other algorithm-specific work measures.
- Solution quality and feasibility checks.
Preserve unsuccessful runs
Timeouts, numerical failures, and infeasible results are part of the evidence. Removing them can make a method appear more reliable than it is. Store them with explicit status labels and investigate recurring patterns.
Make the final table regenerable
The figures and tables in a report should be produced from raw results by a documented script. Manual copying makes it difficult to correct mistakes or incorporate new experiments consistently.
Minimum reproducibility package
A strong minimum package contains the data or a precise data reference, source code, environment information, run configurations, raw results, and the scripts that create reported tables and figures.