Validate simulations across three stages — run pre-flight checks on configuration files (parameter ranges, required fields, disk space), monitor runtime logs for residual growth, NaN/Inf, and adaptive dt collapse, and perform post-flight validation of results (physical bounds, mass/energy conservation, convergence). Diagnose failed simulations with probable-cause analysis and recommended fixes. Use when preparing to launch a simulation, checking whether a running job is healthy, verifying that finished results are trustworthy, or debugging a crash or blow-up, even if the user only says "my simulation crashed" or "can I trust these results."
Provide a three-stage validation protocol: pre-flight checks, runtime monitoring, and post-flight validation for materials simulations.
Requirements
Python 3.10+
No external dependencies (uses Python standard library only)
Works on Linux, macOS, and Windows
Inputs to Gather
Before running validation scripts, collect from the user:
Input
Description
Example
Config file
Simulation configuration (JSON/YAML)
simulation.json
Log file
Runtime output log
simulation.log
Metrics file
Post-run metrics (JSON)
results.json
Required params
Parameters that must exist
dt,dx,kappa
Valid ranges
Parameter bounds
dt:1e-6:1e-2
Decision Guidance
When to Run Each Stage
Is simulation about to start?
├── YES → Run Stage 1: preflight_checker.py
│ └── BLOCK status? → Fix issues, do NOT run simulation
│ └── WARN status? → Review warnings, document if accepted
│ └── PASS status? → Proceed to run simulation
│
Is simulation running?
├── YES → Run Stage 2: runtime_monitor.py (periodically)
│ └── Alerts? → Consider stopping, check parameters
│
Has simulation finished?
├── YES → Run Stage 3: result_validator.py
│ └── Failed checks? → Do NOT use results
│ → Run failure_diagnoser.py
│ └── All passed? → Results are valid
Choosing Validation Thresholds
Metric
Conservative
Standard
Relaxed
Mass tolerance
1e-6
1e-3
1e-2
Residual growth
2x
10x
100x
dt reduction
10x
100x
1000x
Script Outputs (JSON Fields)
Script
Output Fields
scripts/preflight_checker.py
report.status, report.blockers, report.warnings
scripts/runtime_monitor.py
alerts, residual_stats, dt_stats (alerts include NaN/Inf/overflow detection, residual growth, and dt collapse)
scripts/result_validator.py
checks, confidence_score, failed_checks, status (PASS / FAIL / INSUFFICIENT_DATA); confidence_score is null when no check ran
scripts/failure_diagnoser.py
probable_causes, recommended_fixes
Three-Stage Validation Protocol
Stage 1: Pre-flight (Before Simulation)
Run scripts/preflight_checker.py --config simulation.json
BLOCK status: Stop immediately, fix all blocker issues
Note: preflight_checker.py validates required keys, numeric ranges,
output-directory access, and disk space. It does not evaluate numerical
stability (CFL / diffusion-Fourier). For explicit stability gating use
skills/core-numerical/numerical-stability/scripts/cfl_checker.py.
All validation checks passed → proceed with confidence
0.75+
Most checks passed, minor issues
0.5-0.75
Significant issues, review carefully
< 0.5
Major problems, do not trust results
null (status INSUFFICIENT_DATA)
No recognized metrics fields; no check ran — NOT a pass. Inspect the metrics file.
A requested bound (--bound-min/--bound-max) with no matching field_min/field_max
in the metrics is reported as a failed bounds_unverifiable check, never a vacuous pass.
For variational/gradient-flow runs, pass --variational (or set "energy_variational": true
in the metrics) to enforce a strict monotone non-increasing energy check (energy_monotone);
otherwise a weaker energy_net_decrease check is used, which does not detect mid-run spikes.
Common Failure Patterns
Pattern in Log
Likely Cause
Recommended Fix
NaN, Inf, overflow
Numerical instability
Reduce dt, increase damping
max iterations, did not converge
Solver failure
Tune preconditioner, tolerances
out of memory
Memory exhaustion
Reduce mesh, enable out-of-core
dt reduced
Adaptive stepping triggered
May be okay if controlled
Verification checklist
Do not trust a validation verdict until each applicable item below is satisfied
with the concrete artifact named. Record these in your summary to the user.
Ran result_validator.py --json and confirmed results.status is PASS (not INSUFFICIENT_DATA) AND results.confidence_score == 1.0; a null score or INSUFFICIENT_DATA means no check ran — treat as unverified, not as a pass.
Listed results.checks and confirmed every requested check actually appears (e.g. mass_conserved, bounds_satisfied, no_nan, and energy_monotone/energy_net_decrease); confirmed results.failed_checks is empty and contains no bounds_unverifiable entry (which means a requested bound had no field_min/field_max to compare against).
For variational/gradient-flow models (Allen-Cahn, Cahn-Hilliard), passed --variational (or set "energy_variational": true) so energy_monotone is enforced; recorded that the weaker energy_net_decrease was NOT relied on, since it cannot detect mid-run energy spikes.
Recorded the mass drift tolerance used (--mass-tol, default 1e-3) and confirmed it matches the Conservative/Standard/Relaxed column appropriate to the run; did not silently accept the default for a tight-conservation problem.
Ran runtime_monitor.py --json and recorded residual_stats (min/max/last) and dt_stats; confirmed there are no alerts for NaN/Inf/overflow, residual growth above --residual-growth, or dt collapse below --dt-drop.
Confirmed numerical stability was gated separately via core-numerical/numerical-stability/scripts/cfl_checker.py (CFL/Fourier limit) — preflight_checker.py does NOT evaluate CFL/Fourier and a PASS preflight says nothing about temporal/spatial stability.
On any FAIL or alert, ran failure_diagnoser.py --json and recorded the probable_causes/recommended_fixes, rather than reusing the results.
Common pitfalls & rationalizations
Tempting shortcut
Why it's wrong / what to do
"Preflight passed, so the run is numerically stable."
preflight_checker.py checks required keys, ranges, output-dir writability, and disk space only. It does NOT compute CFL/Fourier. Gate stability with cfl_checker.py separately.
"result_validator printed a confidence score, so results are good."
An empty or unrecognized metrics file returns confidence_score: null and status INSUFFICIENT_DATA — that is "no check ran", not a pass. Verify recognized fields are present and status == PASS.
"Energy ends lower than it started, so the dissipative run is fine."
The default energy_net_decrease only compares first vs last and misses mid-run spikes. For gradient-flow models use --variational to enforce the strict monotone energy_monotone check.
"I asked for bounds and didn't get a bounds_satisfied: false, so bounds hold."
If field_min/field_max are absent the validator emits bounds_unverifiable (a FAILED check), never a vacuous pass. Ensure the metrics file actually carries the field extrema.
"The simulation finished without crashing, so the results are trustworthy."
Run completion is not correctness. Verify mass conservation, energy behavior, physical bounds, and a clean runtime_monitor alert list before using results.
"dt got smaller during the run, so the solver is failing."
runtime_monitor dt-collapse is direction-aware (running-max vs current) and only alerts past --dt-drop; a controlled adaptive ramp is expected. Check the actual dt_stats and whether an alert fired.
"I'll just use the default thresholds."
Defaults (--mass-tol 1e-3, --residual-growth 10, --dt-drop 100) are the Standard column; a conservation-critical problem needs the Conservative tolerances. Pick thresholds for the physics, then record them.
Security
Input Validation
Config file paths are validated for existence before parsing; non-existent paths produce clear errors (exit code 2)
--required parameter names are validated against a safe-character allowlist (^[A-Za-z0-9_.-]+$); names with shell metacharacters are rejected
--ranges entries are parsed as name:min:max with finite numeric bounds enforced and max > min required
--min-free-gb is validated as a finite positive number (negatives, zero, nan, inf rejected)
--residual-growth and --dt-drop thresholds are validated as finite positive numbers
--bound-min and --bound-max are validated as finite numbers (nan/inf rejected), and --bound-max > --bound-min is enforced; --mass-tol is validated as a finite positive number
Invalid input exits with code 2 and an explanatory message
File Access
preflight_checker.py reads a single user-specified config file (JSON/YAML) and checks disk space on the volume hosting the resolved output directory
runtime_monitor.py reads a single log file specified by --log; log files are size-limited (500 MB max) and rejected before parsing if larger
result_validator.py reads a single metrics file (JSON) specified by --metrics
failure_diagnoser.py reads a single log file specified by --log; log files are size-limited (500 MB max) before parsing
No scripts write to the filesystem; all output goes to stdout
Tool Restrictions
Read: Used to inspect script source, references, config files, and simulation logs
Bash: Used to execute the four Python validation scripts (preflight_checker.py, runtime_monitor.py, result_validator.py, failure_diagnoser.py) with explicit argument lists
Write: Used to save validation reports; writes are scoped to the user's working directory
Grep/Glob: Used to locate log files, config files, and search references
Safety Measures
No eval(), exec(), or dynamic code generation
All subprocess calls use explicit argument lists (no shell=True)
failure_diagnoser.py uses hardcoded, pre-compiled diagnostic regex patterns; runtime_monitor.py accepts optional --residual-pattern / --dt-pattern overrides that are compiled with re.compile (no eval) and applied only to the user's own log
Diagnostic strings emitted in output are drawn from the skill's fixed cause/fix table, not interpolated from raw log content
Limitations
Not a real-time monitor: Scripts analyze logs after-the-fact
Regex-based: Log parsing depends on pattern matching; may miss unusual formats
No automatic fixes: Scripts diagnose but don't modify simulations
References
references/validation_protocol.md - Detailed checklist and criteria
references/log_patterns.md - Common failure signatures and regex patterns
Version History
v1.2.2 (2026-06-24): Added a Verification checklist (evidence-based, tied to the four scripts' JSON outputs) and a Common pitfalls & rationalizations table to harden agent interpretation of validation verdicts.
v1.2.0 (2026-06-23): Corrected diagnostic regexes (no false convergence/blow-up on healthy logs), direction-aware dt-collapse detection, NaN/Inf scan in runtime monitor, strict variational energy check, non-vacuous bounds/confidence, config-relative output-dir + correct-volume disk check, and implemented the documented input-validation/file-size safeguards
v1.1.0 (2024-12-24): Enhanced documentation, decision guidance, Windows compatibility
v1.0.0: Initial release with 4 validation scripts
1---2name: simulation-validator3description: Validate simulations across three stages — run pre-flight checks on configuration files (parameter ranges, required fields, disk space), monitor runtime logs for residual growth, NaN/Inf, and adaptive dt collapse, and perform post-flight validation of results (physical bounds, mass/energy conservation, convergence). Diagnose failed simulations with probable-cause analysis and recommended fixes. Use when preparing to launch a simulation, checking whether a running job is healthy, verifying that finished results are trustworthy, or debugging a crash or blow-up, even if the user only says "my simulation crashed" or "can I trust these results."4---56# Simulation Validator78## Goal910Provide a three-stage validation protocol: pre-flight checks, runtime monitoring, and post-flight validation for materials simulations.1112## Requirements1314- Python 3.10+15- No external dependencies (uses Python standard library only)16- Works on Linux, macOS, and Windows1718## Inputs to Gather1920Before running validation scripts, collect from the user:2122| Input | Description | Example |23|-------|-------------|---------|24| Config file | Simulation configuration (JSON/YAML) | `simulation.json` |25| Log file | Runtime output log | `simulation.log` |26| Metrics file | Post-run metrics (JSON) | `results.json` |27| Required params | Parameters that must exist | `dt,dx,kappa` |28| Valid ranges | Parameter bounds | `dt:1e-6:1e-2` |2930## Decision Guidance3132### When to Run Each Stage3334```35Is simulation about to start?36├── YES → Run Stage 1: preflight_checker.py37│ └── BLOCK status? → Fix issues, do NOT run simulation38│ └── WARN status? → Review warnings, document if accepted39│ └── PASS status? → Proceed to run simulation40│41Is simulation running?42├── YES → Run Stage 2: runtime_monitor.py (periodically)43│ └── Alerts? → Consider stopping, check parameters44│45Has simulation finished?46├── YES → Run Stage 3: result_validator.py47│ └── Failed checks? → Do NOT use results48│ → Run failure_diagnoser.py49│ └── All passed? → Results are valid50```5152### Choosing Validation Thresholds5354| Metric | Conservative | Standard | Relaxed |55|--------|--------------|----------|---------|56| Mass tolerance | 1e-6 | 1e-3 | 1e-2 |57| Residual growth | 2x | 10x | 100x |58| dt reduction | 10x | 100x | 1000x |5960## Script Outputs (JSON Fields)6162| Script | Output Fields |63|--------|---------------|64| `scripts/preflight_checker.py` | `report.status`, `report.blockers`, `report.warnings` |65| `scripts/runtime_monitor.py` | `alerts`, `residual_stats`, `dt_stats` (alerts include NaN/Inf/overflow detection, residual growth, and dt collapse) |66| `scripts/result_validator.py` | `checks`, `confidence_score`, `failed_checks`, `status` (`PASS` / `FAIL` / `INSUFFICIENT_DATA`); `confidence_score` is `null` when no check ran |67| `scripts/failure_diagnoser.py` | `probable_causes`, `recommended_fixes` |6869## Three-Stage Validation Protocol7071### Stage 1: Pre-flight (Before Simulation)72731. Run `scripts/preflight_checker.py --config simulation.json`742. **BLOCK status**: Stop immediately, fix all blocker issues753. **WARN status**: Review warnings, document accepted risks764. **PASS status**: Proceed to simulation7778> Note: `preflight_checker.py` validates required keys, numeric ranges,79> output-directory access, and disk space. It does **not** evaluate numerical80> stability (CFL / diffusion-Fourier). For explicit stability gating use81> `skills/core-numerical/numerical-stability/scripts/cfl_checker.py`.8283```bash84python3 scripts/preflight_checker.py \85 --config simulation.json \86 --required dt,dx,kappa \87 --ranges "dt:1e-6:1e-2,dx:1e-4:1e-1" \88 --min-free-gb 1.0 \89 --json90```9192### Stage 2: Runtime (During Simulation)93941. Run `scripts/runtime_monitor.py --log simulation.log` periodically952. Configure alert thresholds based on problem type963. Stop simulation if critical alerts appear9798```bash99python3 scripts/runtime_monitor.py \100 --log simulation.log \101 --residual-growth 10.0 \102 --dt-drop 100.0 \103 --json104```105106### Stage 3: Post-flight (After Simulation)1071081. Run `scripts/result_validator.py --metrics results.json`1092. **All checks PASS**: Results are valid for analysis1103. **Any check FAIL**: Do NOT use results, diagnose failure111112```bash113python3 scripts/result_validator.py \114 --metrics results.json \115 --bound-min 0.0 \116 --bound-max 1.0 \117 --mass-tol 1e-3 \118 --json119```120121For variational / gradient-flow models (Allen-Cahn, Cahn-Hilliard), add122`--variational` to enforce a strict monotone non-increasing energy check.123124### Failure Diagnosis125126When validation fails:127128```bash129python3 scripts/failure_diagnoser.py --log simulation.log --json130```131132## Conversational Workflow Example133134**User**: My phase field simulation crashed after 1000 steps. Can you help me figure out why?135136**Agent workflow**:1371. First, check the log for obvious errors:138 ```bash139 python3 scripts/failure_diagnoser.py --log simulation.log --json140 ```1412. If diagnosis suggests numerical blow-up, check runtime stats:142 ```bash143 python3 scripts/runtime_monitor.py --log simulation.log --json144 ```1453. Recommend fixes based on findings:146 - If residual grew rapidly → reduce time step147 - If dt collapsed → check stability conditions148 - If NaN detected → check initial conditions149150## Error Handling151152| Error | Cause | Resolution |153|-------|-------|------------|154| `Config not found` | File path invalid | Verify config path exists |155| `Non-numeric value` | Parameter is not a number | Fix config file format |156| `out of range` | Parameter outside bounds | Adjust parameter or bounds |157| `Output directory not writable` | Permission issue | Check directory permissions |158| `Insufficient disk space at <path>` | Disk nearly full on the output volume | Free up space or reduce output |159| `Invalid parameter name` | `--required` name has disallowed characters | Use only letters, digits, `_`, `.`, `-` |160| `range max ... must be greater than min` | Inverted/degenerate `--ranges` or bounds | Ensure max > min |161| `must be a finite positive number` | `nan`/`inf`/negative threshold supplied | Pass a finite positive value |162| `Log file too large` | Log exceeds the 500 MB parse cap | Truncate or pre-filter the log |163164## Interpretation Guidance165166### Status Meanings167168| Status | Meaning | Action |169|--------|---------|--------|170| PASS | All checks passed | Proceed with confidence |171| WARN | Non-critical issues found | Review and document |172| BLOCK | Critical issues found | Must fix before proceeding |173174### Confidence Score Interpretation175176| Score | Meaning |177|-------|---------|178| 1.0 | All validation checks passed → proceed with confidence |179| 0.75+ | Most checks passed, minor issues |180| 0.5-0.75 | Significant issues, review carefully |181| < 0.5 | Major problems, do not trust results |182| `null` (status `INSUFFICIENT_DATA`) | No recognized metrics fields; **no check ran** — NOT a pass. Inspect the metrics file. |183184A requested bound (`--bound-min`/`--bound-max`) with no matching `field_min`/`field_max`185in the metrics is reported as a failed `bounds_unverifiable` check, never a vacuous pass.186For variational/gradient-flow runs, pass `--variational` (or set `"energy_variational": true`187in the metrics) to enforce a strict monotone non-increasing energy check (`energy_monotone`);188otherwise a weaker `energy_net_decrease` check is used, which does not detect mid-run spikes.189190### Common Failure Patterns191192| Pattern in Log | Likely Cause | Recommended Fix |193|----------------|--------------|-----------------|194| NaN, Inf, overflow | Numerical instability | Reduce dt, increase damping |195| max iterations, did not converge | Solver failure | Tune preconditioner, tolerances |196| out of memory | Memory exhaustion | Reduce mesh, enable out-of-core |197| dt reduced | Adaptive stepping triggered | May be okay if controlled |198199## Verification checklist200201Do not trust a validation verdict until each applicable item below is satisfied202with the concrete artifact named. Record these in your summary to the user.203204- [ ] Ran `result_validator.py --json` and confirmed `results.status` is `PASS` (not `INSUFFICIENT_DATA`) AND `results.confidence_score == 1.0`; a `null` score or `INSUFFICIENT_DATA` means no check ran — treat as unverified, not as a pass.205- [ ] Listed `results.checks` and confirmed every requested check actually appears (e.g. `mass_conserved`, `bounds_satisfied`, `no_nan`, and `energy_monotone`/`energy_net_decrease`); confirmed `results.failed_checks` is empty and contains no `bounds_unverifiable` entry (which means a requested bound had no `field_min`/`field_max` to compare against).206- [ ] For variational/gradient-flow models (Allen-Cahn, Cahn-Hilliard), passed `--variational` (or set `"energy_variational": true`) so `energy_monotone` is enforced; recorded that the weaker `energy_net_decrease` was NOT relied on, since it cannot detect mid-run energy spikes.207- [ ] Recorded the mass drift tolerance used (`--mass-tol`, default `1e-3`) and confirmed it matches the Conservative/Standard/Relaxed column appropriate to the run; did not silently accept the default for a tight-conservation problem.208- [ ] Ran `runtime_monitor.py --json` and recorded `residual_stats` (min/max/last) and `dt_stats`; confirmed there are no `alerts` for NaN/Inf/overflow, residual growth above `--residual-growth`, or dt collapse below `--dt-drop`.209- [ ] Confirmed numerical stability was gated separately via `core-numerical/numerical-stability/scripts/cfl_checker.py` (CFL/Fourier limit) — `preflight_checker.py` does NOT evaluate CFL/Fourier and a PASS preflight says nothing about temporal/spatial stability.210- [ ] On any `FAIL` or alert, ran `failure_diagnoser.py --json` and recorded the `probable_causes`/`recommended_fixes`, rather than reusing the results.211212## Common pitfalls & rationalizations213214| Tempting shortcut | Why it's wrong / what to do |215|-------------------|------------------------------|216| "Preflight passed, so the run is numerically stable." | `preflight_checker.py` checks required keys, ranges, output-dir writability, and disk space only. It does NOT compute CFL/Fourier. Gate stability with `cfl_checker.py` separately. |217| "`result_validator` printed a confidence score, so results are good." | An empty or unrecognized metrics file returns `confidence_score: null` and status `INSUFFICIENT_DATA` — that is "no check ran", not a pass. Verify recognized fields are present and `status == PASS`. |218| "Energy ends lower than it started, so the dissipative run is fine." | The default `energy_net_decrease` only compares first vs last and misses mid-run spikes. For gradient-flow models use `--variational` to enforce the strict monotone `energy_monotone` check. |219| "I asked for bounds and didn't get a `bounds_satisfied: false`, so bounds hold." | If `field_min`/`field_max` are absent the validator emits `bounds_unverifiable` (a FAILED check), never a vacuous pass. Ensure the metrics file actually carries the field extrema. |220| "The simulation finished without crashing, so the results are trustworthy." | Run completion is not correctness. Verify mass conservation, energy behavior, physical bounds, and a clean `runtime_monitor` alert list before using results. |221| "dt got smaller during the run, so the solver is failing." | `runtime_monitor` dt-collapse is direction-aware (running-max vs current) and only alerts past `--dt-drop`; a controlled adaptive ramp is expected. Check the actual `dt_stats` and whether an alert fired. |222| "I'll just use the default thresholds." | Defaults (`--mass-tol 1e-3`, `--residual-growth 10`, `--dt-drop 100`) are the Standard column; a conservation-critical problem needs the Conservative tolerances. Pick thresholds for the physics, then record them. |223224## Security225226### Input Validation227- Config file paths are validated for existence before parsing; non-existent paths produce clear errors (exit code 2)228- `--required` parameter names are validated against a safe-character allowlist (`^[A-Za-z0-9_.-]+$`); names with shell metacharacters are rejected229- `--ranges` entries are parsed as `name:min:max` with finite numeric bounds enforced and `max > min` required230- `--min-free-gb` is validated as a finite positive number (negatives, zero, `nan`, `inf` rejected)231- `--residual-growth` and `--dt-drop` thresholds are validated as finite positive numbers232- `--bound-min` and `--bound-max` are validated as finite numbers (`nan`/`inf` rejected), and `--bound-max > --bound-min` is enforced; `--mass-tol` is validated as a finite positive number233- Invalid input exits with code 2 and an explanatory message234235### File Access236- `preflight_checker.py` reads a single user-specified config file (JSON/YAML) and checks disk space on the volume hosting the resolved output directory237- `runtime_monitor.py` reads a single log file specified by `--log`; log files are size-limited (500 MB max) and rejected before parsing if larger238- `result_validator.py` reads a single metrics file (JSON) specified by `--metrics`239- `failure_diagnoser.py` reads a single log file specified by `--log`; log files are size-limited (500 MB max) before parsing240- No scripts write to the filesystem; all output goes to stdout241242### Tool Restrictions243- **Read**: Used to inspect script source, references, config files, and simulation logs244- **Bash**: Used to execute the four Python validation scripts (`preflight_checker.py`, `runtime_monitor.py`, `result_validator.py`, `failure_diagnoser.py`) with explicit argument lists245- **Write**: Used to save validation reports; writes are scoped to the user's working directory246- **Grep/Glob**: Used to locate log files, config files, and search references247248### Safety Measures249- No `eval()`, `exec()`, or dynamic code generation250- All subprocess calls use explicit argument lists (no `shell=True`)251- `failure_diagnoser.py` uses hardcoded, pre-compiled diagnostic regex patterns; `runtime_monitor.py` accepts optional `--residual-pattern` / `--dt-pattern` overrides that are compiled with `re.compile` (no `eval`) and applied only to the user's own log252- Diagnostic strings emitted in output are drawn from the skill's fixed cause/fix table, not interpolated from raw log content253254## Limitations255256- **Not a real-time monitor**: Scripts analyze logs after-the-fact257- **Regex-based**: Log parsing depends on pattern matching; may miss unusual formats258- **No automatic fixes**: Scripts diagnose but don't modify simulations259260## References261262- `references/validation_protocol.md` - Detailed checklist and criteria263- `references/log_patterns.md` - Common failure signatures and regex patterns264265## Version History266267- **v1.2.2** (2026-06-24): Added a Verification checklist (evidence-based, tied to the four scripts' JSON outputs) and a Common pitfalls & rationalizations table to harden agent interpretation of validation verdicts.268- **v1.2.0** (2026-06-23): Corrected diagnostic regexes (no false convergence/blow-up on healthy logs), direction-aware dt-collapse detection, NaN/Inf scan in runtime monitor, strict variational energy check, non-vacuous bounds/confidence, config-relative output-dir + correct-volume disk check, and implemented the documented input-validation/file-size safeguards269- **v1.1.0** (2024-12-24): Enhanced documentation, decision guidance, Windows compatibility270- **v1.0.0**: Initial release with 4 validation scripts
Run npx skillmds@latest add heshamfs/simulation-validator in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Validate simulations across three stages — run pre-flight checks on configuration files (parameter ranges, required fields, disk space), monitor runtime logs for residual growth, NaN/Inf, and adaptive dt collapse, and perform post-flight validation of results (physical bounds, mass/energy conservation, convergence). Diagnose failed simulations with probable-cause analysis and recommended fixes. Use when preparing to launch a simulation, checking whether a running job is healthy, verifying that finished results are trustworthy, or debugging a crash or blow-up, even if the user only says "my simulation crashed" or "can I trust these results." It is listed under Marketing & Growth on SkillMD.
This skill has not completed SkillMD's automated safety review yet. Capability flags: executes scripts. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
HeshamFS (@heshamfs) published this skill. Their other Agent Skills are listed on their SkillMD profile.
HeshamFS