Is your fluidsim run plan ready for its first pilot?

Paste a fluidsim 0.9 JSON plan. Your browser runs the fluidsim skill's own three planning tools on it - the validator, the grid and storage estimator, the dry-run script generator - with the same output as the Python, free, nothing uploaded. A paid run drafts a plan from a description of your study, or reviews a plan against the skill's scientific acceptance gate.

Each example has a saved model run - the whole page, free.

Study

Plan (strict JSON, the skill's schema 1.1)config.json

Drop a plan .json here, or

Paste or drop a plan, or start from the skill's example.

Estimator options (defaults are the skill's)

--precision-bytes --workspace-factor --safety-factor --compression-ratio

Peak memory = resident state x workspace x safety; bounds 2-64, 1-10 and 1-20, as the skill enforces.

Result (free, in your browser, no AI)

solver_config_validator.py

grid_resource_estimator.py

simulation_dry_run.py

Flags

Resource envelope

Quantity	Estimate	Declared bound	Fits

Grid

Axis	n	L	dx = L/n	k_max after truncation

Validator stdout

Estimator stdout

Dry-run stdout and script

The same checks with the skill's scripts

Free: no account, no run.

Notes (optional: context, or the review to act on after a hand-over)

Anything to ask (optional)

Check a plan first to price the review.

Raw model reply

The reply did not parse as the structured result, so it is shown as it arrived.

Your recent runs

What this does, and what it does not

The fluidsim agent skill ships three standard-library Python tools for planning a bounded fluidsim 0.9.0 run: solver_config_validator.py checks a strict JSON plan against a static profile of the Cartesian pseudospectral solvers (grid, dealiasing, time bounds, forcing, output, scientific statements, resources, execution mode, pinned versions); grid_resource_estimator.py turns the grid into a conservative peak-memory, storage and output-file envelope and compares it with the plan's declared RAM, disk and file bounds; simulation_dry_run.py writes a launch script that only prints a dry run unless it is given --execute and the exact reviewed config id. This page runs JavaScript ports of all three. Checked against the Python on 16,200 runs of fuzzed plans under CPython 3.11.2 (15,000 of them again under 3.13.6), stdout and exit code were identical in every one - including the cases where the Python stops with an uncaught exception, which the page reports as a crash rather than inventing a report.

One behaviour cannot be matched exactly: when two or more of the plan's scientific text fields are invalid, which one the Python names depends on its per-process hash seed. The page names the first in the skill's listing order and lists the others as extra flags. And where a save period is written as a string with non-ASCII digits, Python's float() accepts it and the page does not.

A plan that passes, and fits its resources, establishes neither numerical convergence nor physical validity - the skill is explicit, and so is every review. The paid lanes read only the plan, the tools' results and your notes; the page re-runs the skill's tools on every drafted plan and checks every review against them. Derived from the agent skill @k-dense-ai/fluidsim (k-dense-ai/scientific-agent-skills; see the notice). No fluidsim code is included and nothing here runs a simulation. Core-Hour Check is an independent page and is not affiliated with the FluidDyn project, which develops fluidsim, or with K-Dense Inc.