RFour Energy · Tool Documentation

What the Tools Do With What They Don't Know

The uncertainty study and the report generator behave the same way in every RFour tool. This page is the single description of both. Each tool's own help panel covers only what is specific to that tool.

Every tool in this suite ends the same way: a number, a range around it, and a report that has to survive being read by someone who was not in the room. The machinery that produces those three things is shared, so it is documented once, here, rather than restated inside each tool. If a description here disagrees with a tool's own help panel, this page is the one that is maintained.


Two Questions, Not One

Two questions get asked of an uncertainty study, and they are not the same question. Which parameter moves the answer most? And which parameter is worth spending money to pin down? A parameter can be enormously influential and still not worth measuring, because it is already known well. The study answers both and shows where they disagree — which is usually the interesting part.

MethodWhat it doesWhat it is good for
TornadoSwings one parameter across its range with everything else held at base. Exact; two evaluations per parameter.Ranking raw influence, and reading how asymmetric or non-linear each response is.
Monte CarloSamples every parameter at once from triangular distributions on the same ranges, then reports P90/P50/P10 and a contribution ranking.How uncertain the answer actually is, and which uncertainty owns the spread once everything moves together.

Both rest on the same stated ranges, so the two views can be compared directly instead of resting on two different sets of assumptions. Ranges are editable; the defaults are starting points, not claims about your data.

Contribution to spread

Computed as the squared Spearman rank correlation between each sampled input and the output, normalised across parameters. Rank rather than linear correlation, so a monotonic but curved response is still credited properly. It approximates the first-order variance share — roughly, the fraction of the spread that would disappear if that one parameter were known exactly. That is the number to read when deciding where to spend on data.

Two Things the Study Will Tell You If You Let It

A bar marked † means one bound broke the model: at that value the calculation produced no usable answer, and the bar shows the side that solved, doubled. What breaks differs by tool — a material balance that will not converge, an IPR and VLP that no longer intersect — but the reading is the same in each. A bound that breaks the calculation is not a reason to leave the parameter off the chart. It is the strongest available evidence that the parameter matters, and the reason the marker exists rather than the bar being silently dropped.

A rejection warning means some fraction of the sampled cases did not evaluate. Those draws are absent from the percentiles, so P90 and P10 are conditional on the region where the model works rather than on the full ranges you stated. The warning names the parameter the failures cluster in. Narrow that range until the rejection rate falls below a few percent, or read the percentiles as bounds on a censored sample — but do not read them as if nothing had been discarded.

How Many Samples

The default sample count is set per tool, by measurement rather than by habit, because the cost of a single evaluation differs by three orders of magnitude across the suite. A material-balance evaluation costs well under a millisecond; a full nodal intersection costs tens of milliseconds. Each tool's help panel states its own default and the evidence behind it.

Two properties hold everywhere. The run is time-boxed rather than chunked by count — it draws samples until it has spent roughly 40 ms, then yields to the browser — so the interface stays responsive whatever the per-sample cost happens to be, and the progress line carries an estimate of the time remaining. And more samples cannot separate parameters that genuinely tie. When two contributors sit within a few points of each other and keep swapping places at every sample count, that is a real tie, not sampling noise. Only narrowing the input ranges will break it.

What the Study Does Not Cover

A tight P90–P10 band around the wrong model is worse than a wide band around the right one, because it looks like knowledge.

The distribution reflects only the parameters listed. It says nothing about whether the model itself is right — whether the drive mechanism has been diagnosed correctly, whether the IPR form suits the flow regime, whether the pressures are true static values at a common datum, whether the case has been matched to measured data at all. Those are structural questions, and no amount of sampling inside a wrong structure will surface them. Each tool's QC checklist exists for exactly that reason and is not optional.

The Report, and What It Carries

File → Report builds a self-contained HTML report of the solved case and opens it in a new tab rather than dropping it into the downloads folder. Solve first; the report requires valid results and reflects current inputs at the moment it is generated.

Where the Computation Happens

All computation runs locally in the browser. Engineering inputs are never transmitted; only credentials are sent, and only for authentication. Nothing you type into a tool reaches a server, which is also why a case survives only as long as the tab does unless you export it.

Correlations and formulations are implemented as published, and each tool names the methods it uses. Results are engineering estimates. They should be validated against independent volumetric, simulation or measured-performance work before being used in a reserves submission or an investment decision.

← Back to rfourenergy.com © 2026 RFour Energy