Compute tracking (Phase 0)

Long CFD and FEA solves run for days on a workstation while almost no hours are logged against them. Compute tracking records them so the compute is counted per project. Phase 0 counts; it never prices or invoices.

It lives in the Resources menu: Computers to take a machine, Usage to see what was used. Every figure in it is declared by an engineer (shown as user_entered), never measured.

Recording a solve: Take and Release

The normal way is Resources → Computers:

1. Find the machine and press + Take.
2. Pick the project (required: only projects you are on are offered), the software, the cores the solve uses (defaults to the machine's cores) and, for Ansys, the HPC packs held (0 to 3).
3. Recording starts now, and the machine shows Taken by your name on Computers so colleagues see it is in use. You have one open solve per machine; a second Take of the same machine is refused.
4. When the solve ends, press Release on Computers. Recording stops, you see how long was recorded, and the solve goes into the daily records. If a second solve is still running on that machine, tick still running, keep it open.

Everything happens in Otium: the SoftInWay Resources portal is not needed.

Saying when you will finish

The Take form has an optional Expected to finish (date and time in the company zone). Computers and Usage → Actively in use then show "Taken by Anna until ~Thu 18:00" so colleagues know when to ask for it. It is only a plan: when you press Release, the recorded end is that moment, never the planned time.

If the expected time passes and the solve is still open, you get one reminder by email (and in Teams through Oti Bot when your company has it): release the machine, or set a new expected end by opening the solve. Actively in use shows an overrunning flag meanwhile. Setting a new end arms one more reminder.

Reserving a machine ahead

Usage → Planned (and Reserve next to Take on Computers) books a machine for a later time: machine, project (required, only projects you are on), software, cores, HPC packs, from and to (company zone) and a note.

• Overlap: a reservation is refused when its cores plus the cores already reserved or taken in that window exceed the machine's physical cores. The message says who holds it. A solve taken with no expected end counts as holding the machine until it is released.
• Change or cancel: you can edit or cancel your own reservations. Admins and IT can cancel anyone's; the person is told by email.
• Start: when the reservation starts you get a reminder (email, and Teams when set up) with a one-click Take, already filled in.
• No-show: a reservation not taken within 2 hours of its start is released automatically and counted as a no-show, so machines do not sit idle.

Planned also shows a 14-day timeline, one row per machine: reservations, solves recording now and their expected end. Everyone sees who and when; project names show to the same people who see them on Computers.

Utilization adds Reserved h/day and No-shows next to Taken and Busy, so planned and actual use can be compared.

An admin can switch on Put reservations on the person's Outlook calendar under Usage → Settings. It uses the person's existing Outlook connection; people who have not connected Outlook (or not granted calendar write permission) simply get no calendar entry.

Recording a solve by hand

Resources → Usage → + Record a solve is for solves recorded after the fact, for example from the paper log kept before go-live:

• Machine (from the list; never typed), solver, version (optional), declared cores, start, end, who ran it, project (required), HPC packs (optional), note.
• Times are in the company reporting zone (Kyiv time unless an admin changed it before the first record). A time that doesn't exist when the clocks go forward is refused; a time that happens twice when they go back is read as the first one unless you tick the second one.
• Leave End empty for a solve still running. It stays open, outside every total, until you close it.
• The solve is split into one row per day, so a solve across a month end counts in each month for its own hours.

Corrections

Open a solve from the daily records (or the open list) and change it. A correction keeps the earlier version: its daily rows are voided and a full new set is written, and the history shows every version. The project can change but never be cleared. The person who saved it, the person who ran it, their manager and the project's managers can correct it.

Daily records and warnings

• Usage lists one line per day of each solve: machine, solver, project, hours, declared cores, core-hours, packs, with a total and a CSV export. You see your own solves, your team's if you manage people, and those on projects you manage; admins and finance see all.
• Warnings never block a record. Implausible width: more cores declared than the machine has. Allocation overcommit: solves overlapping on one machine that together claim more cores than it has. Missing registered width, duplicate identity and vCPU drift are about the machines themselves. A warning clears by itself once a correction or a machine change fixes it; the IT department can acknowledge a machine warning with a reason.

Computers

Computers lists every computer in the workspace once: the machines running the Fleet runner, live (load, GPU, who has taken it and for which project), and below them the computers Fleet doesn't list, such as the ones AI agents work on. A computer can be used by people, by AI agents, or both. Open a computer for its page; admins and the IT department edit its physical core count (Fleet reports logical cores), whether it is a workstation or a server, and its status. Only a workstation with confirmed cores can be taken for a solve. IT or an admin can also confirm the cores right on the Take page the first time a machine is taken.

Admins find the compute settings under Usage → Settings: the reporting zone, starting load collection, and the credential the Fleet service uses.

Machine load

Once collection has started, Otium stores each machine's whole-machine CPU load from the runner's check-ins. Machine load shows each machine per week: mean, peak, and check-ins received against expected. It shows no task, project or person. Raw check-ins are kept 90 days, then as daily figures.

On a computer's page, admins, IT and finance also see the machine's load over a chosen period with the solves recorded on it (software, cores, project; never a person).

Collection only starts after staff have been told what is collected, and with two-factor sign-in enforced.