Targets and runs¶
A target is hardware you are considering. A run is one execution of the analysis, comparing your specification against every target you have added.
Adding targets¶
From the simulation page, choose Add Target and enter the vendor, model and CPU model. Suggestions come from the catalogue as you type. Then set the CPU count and memory.
Each target shows a status, the same one the server list uses: Graded, Grading…, Not graded or Not in catalogue. A part the catalogue does not hold is shown in red. See Reading the server list for what each status means. A target is usually graded straight away if we have graded that configuration before, otherwise within a minute or so of adding it.
A graded target can also say No core count, when the catalogue has no core count for its CPU. A run still goes ahead, but that target's licensing costs are estimated from your current estate's cores per server.
Editing a target shows its server, CPU and (if it has one) GPU separately, each as the catalogue entry it is matched to. For a target added from a SKU, it also says which SKU. Saving without changing them keeps them, so correcting the memory or the number of servers never changes the hardware. Change server, Change CPU or Change GPU opens that part only, as a box that searches the catalogue as you type.
Refresh Ratings asks for any grades that are missing or out of date. It queues the request rather than waiting for it, so the grades appear on the page shortly afterwards rather than the moment the button returns.
It cannot help a line marked Not graded or Not in catalogue. For a line that is not graded, our supplier has already answered that it holds no grade for it, and asking again gets the same answer. For a line that is not in the catalogue, the supplier does not know that server or CPU at all. In both cases, change the line to the nearest catalogue entry, or get in touch if the hardware is right and should be in the catalogue. See Reading the server list.
If your organisation has saved its standard builds, From SKU beside Add Target lists them with their status: tick any number (on a host-to-host simulation, each with its own quantity, 1 if you leave it empty), and each specification is copied in, already matched against the catalogue. Your SKU reference is carried onto the target and shown in the results and the PDF report. See Server SKUs.
Add as many targets as you like. Each one is analysed independently and they appear side by side in the results.
Each target costs one credit per run
Five targets means a run costs five credits, every time you run it. See Credits and billing.
Simulation types¶
Choose the type on the simulation page or at submission. You can change it at any time, as long as a run is not in progress.
| Type | What it does |
|---|---|
| Estate Refresh | Compares your whole estate against each target and works out how many of that target you would need to replace it. The default. |
| Host to Host | You state exactly how many target servers you intend to buy, and the two fleets are compared directly. |
| Discovery | Grades the estate you already run, with no target and no comparison. A flat one credit. |
Estate Refresh answers "if I replaced everything with this, what happens?". Host to Host answers "I am buying twelve of these — what changes?". Discovery answers "what have I actually got?" and is the right starting point when you are not yet comparing anything.
Your organisation may also have GPU variants of Estate Refresh and Host to Host available, which consider GPU-bearing servers only. If you do not see them, they are not enabled for your organisation.
Switching back to Estate Refresh clears target quantities
Host to Host needs a quantity per target; Estate Refresh calculates them. Switching back therefore blanks the quantities you entered.
Statuses¶
| Status | Meaning | What you can do |
|---|---|---|
| Draft | Created, no specification yet | Upload a CSV, add lines, import from a location |
| Validating | Lines are being matched, or are waiting on your review | Review matches, add or edit lines, add targets |
| Ready | No line waiting for review, at least one target added. Unmatched lines are left out of the run | Submit, add more targets, edit lines |
| Processing | A run is in progress | Wait. Editing is blocked |
| Paused | A run is waiting for API capacity and will continue on its own | Wait — see Paused runs. Do not resubmit |
| Complete | At least one run has finished | Read results, generate reports, submit further runs |
Cost parameters¶
Setting cost parameters is what unlocks the operational cost figures in your results and reports. Three are available:
| Parameter | What it is | Example |
|---|---|---|
| Maintenance cost per server | Annual cost of keeping one server running — support contract, parts, staff time | 1,200.00 |
| Licensing cost per core | Annual per-core licensing for software priced that way | 50.00 |
| Energy cost per kWh | What you actually pay for electricity | 0.15 |
Set them on the simulation page and they apply to every future run. You can also adjust them on the confirmation screen for one run only.
Anything you leave blank falls back to our platform assumption, and the report states plainly which figures were assumed rather than supplied. Supplying your own energy price is the single change that most improves the accuracy of the cost result.
Submitting a run¶
Choose Run Simulation. The confirmation screen shows how many source servers and targets will be analysed, what it costs, and what your balance is. Nothing is charged until you confirm.
A run usually takes a few minutes. You do not need to wait on the page — the simulation updates itself when the result arrives.
If a run is still processing after an hour, it is cancelled automatically and the credits are returned to your balance. You do not need to do anything to recover them.
Paused runs¶
Occasionally a run shows Paused rather than Processing, with a note that it is waiting for API capacity. Our hardware efficiency provider limits how many requests we may make in an hour, and a large run can reach that limit part-way through.
Nothing has gone wrong, and there is nothing for you to do:
- The targets already analysed are kept — the run picks up where it stopped.
- Your credits stay with the run. Nothing is refunded, because nothing failed.
- It restarts by itself, usually within a few minutes.
- You can close the page. We email you when the results are ready, as with any other run.
Do not submit the run again — a second copy would wait behind the same limit and cost you a second set of credits.
When the run finishes it looks like any other completed run, because it is: a pause changes nothing about the results.
In the rare case that capacity does not free up within 24 hours, the run finishes with whatever it managed to analyse, and the credits for the targets it could not reach are returned to your balance.
Run history¶
Every submission creates a new run with its own version number. The run history on the simulation page lists them all, with status, version, when it was submitted and a summary of the result.
Older runs stay readable even after you change the specification or targets, so you can compare what different configurations produced. This is what makes the duplicate-and-adjust approach below worth using.
Duplicating for what-if work¶
Duplicate creates a fresh draft from an existing simulation. It carries over the name, customer details and notes, but starts with no specification and no targets.
The usual pattern is to build a baseline, duplicate it, swap in different targets, and compare the results.
Finding a simulation again¶
The Simulations page lists everything you can see: your own work, private and shared alike, together with the simulations your colleagues have set to Shared. Anything a colleague has left private is not there — see Your account. The newest are at the top.
Three controls narrow the list, and they combine:
- Search matches on the simulation name, the customer name and the customer reference. Filling in customer details when you create a simulation is what makes this useful six months later — a reference number finds the job when nobody remembers what the simulation was called.
- Status shows only simulations at one point in their lifecycle — Draft, Validating, Ready, Processing or Complete, the same five described under Statuses. Validating picks up whatever was left mid-review, and Ready lists everything waiting to be run.
- Folders, in the sidebar, filter to one folder. No Folder gathers everything unfiled, which is the quickest way to find work that was never put away.
If a simulation you expect is missing, a filter is the usual reason — clearing the search box is not enough on its own when a folder is also selected.
Folders¶
Folders group simulations by project, client, or however you prefer. Create one from the sidebar on the Simulations page, and assign a simulation to it when creating or editing. Each folder shows how many simulations it holds.