Illustration: Seismic interpretation belongs in the data centre, not under a desk Virtual desktop infrastructure has a mixed reputation, mostly earned in general office deployments where it solved a problem that was not that expensive and introduced one that was. The specialist graphics case is different, and seismic interpretation is the clearest example I know.

The situation it fixes

An interpreter works on a seismic volume measured in hundreds of gigabytes or terabytes. The visualisation is genuinely demanding: large volumes rendered interactively, with attribute computation and horizon picking that want a serious GPU.

So the geoscientist gets a workstation. An expensive one, refreshed every three or four years, with a professional graphics card. It sits under a desk in an office, or in a remote location, or at a partner site.

And the data lives in the data centre, because it is too large to live anywhere else.

Which means the data travels to the compute. Over a WAN, or over a site link, or on a physical disk. Copies proliferate. Each copy is a version control problem, a storage cost, and a security exposure.

What moving the workstation changes

Put the graphics workstation next to the data as a virtual machine with a GPU, and what crosses the network is pixels rather than data. A remoting protocol designed for this sends a compressed display stream that is orders of magnitude smaller than the dataset and, crucially, has a fixed bandwidth requirement regardless of how large the survey is.

The consequences compound.

Data stops moving. One authoritative copy. No synchronisation, no stale local versions, no disk in a bag.

Security improves substantially. Seismic data is among the most commercially sensitive assets an operator holds. It never lands on an endpoint. For joint ventures and contractor access this is transformative: a partner gets a session, not a copy, and access ends when you end it.

Remote and international work becomes practical. An interpreter in one country works on data held in another at full interactivity. For organisations with distributed teams or with data residency requirements that keep the data in-country, this is frequently the only workable architecture.

GPUs get shared. Interpreters do not render continuously. They think, read, discuss, and then render hard for twenty minutes. Dedicated workstations are idle most of the day. Pooled GPUs in the data centre can be sized for concurrent demand rather than for headcount, and profile-based partitioning lets a heavy interpretation user and a light viewer share hardware appropriately.

The refresh cycle changes shape. Instead of buying a hundred workstations every three years, you upgrade server hardware and everyone gets the benefit immediately. No desk visits, no imaging, no shipping.

Where it is hard

Latency. Interactive 3D is unforgiving. The rule of thumb is that this works well under about 40 to 50 milliseconds round trip and becomes noticeably unpleasant beyond it. Measure the actual latency from each location before promising anything, and be honest where the answer is bad.

Application certification. The major interpretation packages have supported virtualized GPU configurations for years, but supported means a specific hypervisor, specific driver versions, and specific GPU profiles. Get the vendor’s statement for your combination in writing. This is the constraint that most often reshapes a design.

Storage. You have concentrated the I/O of many workstations onto shared storage. The aggregate demand from a room full of interpreters loading volumes is substantial and bursty, and sizing it from average figures will disappoint.

Licensing. Application licences, the desktop OS licensing, the virtualization platform, and the GPU software licensing. Four lines, and they add up. Model them all before comparing against workstation cost.

The users. Geoscientists have strong and well-founded opinions about their tools. A deployment that is slightly worse than what they had will be rejected, correctly. Pilot with the most demanding users rather than the most agreeable ones, and be prepared to leave the extreme cases on physical hardware.

How I would build the business case

Count the workstations and their refresh cost. Add the storage consumed by duplicated datasets, which is usually larger than anyone expects. Add the WAN capacity currently spent moving data. Add the administrative cost of managing distributed high-value endpoints. Add whatever value you place on data not leaving the building.

Against that, put the server and GPU cost, the storage performance uplift, the software licensing, and the deployment effort.

The case is usually strong for organisations with many interpreters, multiple sites, or partner access requirements. It is weak for a handful of interpreters in one building next to the data, where the existing arrangement is already efficient.

The part that is actually the argument

Not cost. Control. A model where the data never leaves the data centre, access is granted per session, and a departing contractor’s access ends with a click is a materially different security posture from one where terabytes of survey data are on laptops and portable disks.

In an industry where the data is the asset, that is usually the sentence that carries the decision.