Frequently asked questions

Common questions from researchers, partner-site administrators, prospective funders, and anyone else landing here for the first time. If your question is not here, ask us — answers land on this page if more than a couple of people ask the same thing.

If you are landing on this page first, the short version: Vishwanath Grid is a research-computing cluster that several Indian universities run together. The pilot site is live at MIT-WPU Pune; everything in the software stack is open-source.

For researchers

Who can use the cluster?

Researchers (PhD students, postdocs, faculty, and their students) at a Vishwanath Grid partner university. During Phase 0 that means MIT-WPU; in Phase 1 it expands to the next two partners. The Roadmap shows the timing.

If you are at a university that is not yet a partner but you want access, the path is to start a partnership conversation — see Partners.

What can I run?

Anything that fits within the published acceptable use policy. The typical workloads we expect: simulations (physics, chemistry, climate, biology), data-heavy analysis pipelines, machine-learning training runs, and the build/test infrastructure for reproducible research papers.

Common workloads we cannot serve well today: large multi-node MPI jobs that need a fast inter-node network (the pilot uses gigabit Ethernet, not InfiniBand), and GPU-heavy training on the latest data-centre GPUs (we have a small number of older GPUs for prototyping; multi-day runs on H100-class hardware belong elsewhere for now).

How do I get an account?

Email the contact address from your university email account. We will route you to the partner-site administrator who handles account provisioning. There is no per-user fee.

Will my data be safe?

Each partner site keeps physical control of its own hardware and storage. Home directories, scratch space, and project shares live on partner-site servers; nothing routes through a central cloud provider. Backups are the partner-site administrator's responsibility (most run their own off-site backup chain).

For unusually sensitive data — patient records, restricted datasets, things subject to export controls — please raise it with the operations team during account onboarding. We can usually arrange dedicated isolated storage, but we want to know upfront.

What does it cost me?

Nothing, for researchers at partner sites. The cluster is funded by the partner contributions of hardware and operating support; there is no per-job or per-CPU-hour billing between partners during Phase 0 or Phase 1.

How do I cite the cluster in a paper?

A suggested acknowledgement is available from [email protected]. We will add a published version to this page once Phase 0 has a few months of real usage behind it.

For partner-site administrators

What does my university actually contribute?

A small number of compute servers (commodity x86-64 is fine; we do not require exotic hardware), a one-line agreement on acceptable use, and a single point of contact who can be reached for on-campus operational questions.

Will my university lose control of the hardware?

No. The hardware stays physically on your campus, in your machine room, on your network. Your administrator has root access. The federation software runs as ordinary user-space services; it does not take over the box.

What if we want to leave the federation?

The memorandum of understanding includes a clean-exit clause: the partner can withdraw on three months' notice. The federation software gets uninstalled; the partner keeps the hardware and the local copies of researcher data. Nothing is locked in.

Who is liable if something goes wrong?

The detailed answer is in the partner agreement. The short version: each partner is responsible for their own hardware and their own users; the federation as a whole is not a separate legal entity that can be sued. As the federation grows, this is one of the things the foundation board (see Governance) will need to formalise.

For funders

What stage is the project at?

Phase 0 — pilot at one university, running today. Phase 1 — two more universities joining, in active progress. Phase 2 — the wider research toolkit on top of the cluster, planned. See the Roadmap for the longer view.

What is the funding model?

Phase 0 is funded and operated by MIT-WPU. Phase 1 funding conversations are open: we are talking to academic-partner sponsors and research-infrastructure funders about the engineering and operations costs of bringing the next two partner sites online.

How is the project structured?

Today: operated by the MIT-WPU research-computing group. In Phase 1 onward: a three-layer governance structure (partner advisory committee, operations team, foundation board). See Governance for detail.

Where can I see what has been built?

Code is public on Forgejo. The Roadmap lists the phase status. For a private walk-through, get in touch — happy to do a 30-minute call.

For everyone else

Why "Vishwanath Grid"?

Vishwanath (विश्वनाथ) — "Lord of the Universe", and the literal high peak. The name honours Dr. Vishwanath D. Karad, founder of MIT-WPU, where the pilot runs. Grid — the older name for what we now call federated or distributed computing, used by collaborations like the LHC Computing Grid and the Open Science Grid that we look to as institutional templates.

Is it open source?

Yes. Everything that runs the cluster is open-source under a permissive licence (Apache 2, MIT, BSD, or AGPL). The code that configures the federation — the Ansible playbooks, the operator scripts, the dashboards — is itself open and hosted on Forgejo.

Is the project affiliated with the government or with national HPC?

Not formally. The pilot is operated by MIT-WPU, a private university. We coordinate informally with national bodies where helpful, and we look to international collaborations — the LHC Computing Grid, the Open Science Grid, EuroHPC, the national HPC mission — as institutional templates. As the federation grows we expect formal collaboration to be on the table.

How does this differ from a commercial cloud?

Three things, in order of how much they matter:

1. Cost shape. A partner contributes a one-time hardware cost and a small operating cost; usage is then unbounded. A cloud bills per second of every workload.
2. Data residency. All hardware sits on partner campuses; no data crosses an international border or a commercial-cloud boundary.
3. Stack control. Every piece of software is open-source and under partner control. A vendor cannot turn it off, change the pricing, or deprecate the API.

The trade-off, honestly: a small federation cannot offer the elasticity of a cloud. If a workload needs a thousand GPUs for an hour, a cloud is the right answer. For the long-running scientific workloads that fill most academic compute, the federation is the better fit.