Advice and Recommendations

The Advice tab turns a finished job's telemetry into recommendations for what to request next time, in prose rather than a scorecard.

It uses NCI's Gadi charging model for recognised Gadi queues. On an unknown or non-Gadi queue, the tab still shows utilisation advice but does not show an SU estimate.

The charging model

Job Cost (SU) = charge rate × max(NCPUs, mem ÷ mem-per-core) × walltime USED

Three consequences worth internalising.

Booking too much walltime costs nothing

You are charged on walltime used, not booked. A job that books 10 hours and runs for 2 is charged for 2.

So the advice never tells you to trim walltime to save money, because it would not. It frames walltime as queue turnaround instead: a smaller request is easier for the scheduler to place, which usually means you wait less.

Cutting memory usually saves nothing

The charge takes the greater of your core count and your memory proportion. On a queue with 192 GB across 48 cores, that is 4 GB per core — so a job booking 48 cores and 100 GB is charged for the cores, and dropping to 50 GB changes nothing at all.

Memory only matters when it is the term setting your price. The tab works out which term is binding and tells you, rather than reflexively suggesting you ask for less.

Cores you did not use are pure waste

This is the one that genuinely costs. Booking 48 cores and using 18 means you paid for 48.

Why the suggestions carry headroom

Suggested memory and walltime figures include 50% headroom above the observed peak or duration. The core suggestion instead describes how many cores appeared busy; it is a starting point for a scaling test, not a promised safe request.

Peaks are sampled. A spike shorter than the sampling interval is invisible, so sizing to exactly what was observed risks hitting a memory or walltime limit. A job that dies at hour nine costs far more than a slightly generous booking.

What it checks

• Cores — booked against actually used, and whether the shape suggests poor scaling rather than over-booking.
• Memory — peak against booking, and whether memory is the binding term.
• Walltime — used against booked, framed as turnaround.
• Queue — whether the job's profile suits the queue it ran in.
• Multi-node balance — whether one node did much less work than its peers.

What it will not do

It will not tell you your code is inefficient. It can see that 18 of 48 cores were busy; it cannot see whether that is because the code does not scale, the problem was too small to spread, or a rank crashed early. Those have different fixes and the telemetry does not distinguish them.

Use the Cores tab alongside it — the shape of that chart is usually what tells you which situation you are in.

Partial data

If a job ran long enough that the app is only holding a trailing window of samples, the advice says so rather than presenting a window as a whole-run average. Missing nodes, nodes that stopped early, and a non-zero or unknown exit status also appear as caveats; size a future run from a successful, complete job where possible.

Whole-run totals on the Summary tab are unaffected — those come from the merged summary, which is computed from the complete stream on the HPC side.