Skip to content

Fujitsu Bizkaia#

Fujitsu

Overview#

Fujitsu Bizkaia is an HPC provider that gives your solvers access to a Fujitsu supercomputing cluster hosted in Bizkaia. The cluster is managed with Slurm, so your solver does not compute anything itself: it submits a batch job to the cluster, waits for it, and returns the output.

The cluster offers two kinds of compute:

Partition What it is Typical use
da GPU nodes, with access to the Fujitsu Digital Annealer Combinatorial optimisation problems expressed as QUBO, and any GPU workload
a64 ARM (A64FX) CPU nodes CPU-bound and vectorised workloads

The Digital Annealer is a processor specialised in large-scale combinatorial optimisation. It is not a gate-based quantum computer: it uses a digital architecture inspired by quantum computing to explore the solution space of problems formulated as QUBO (Quadratic Unconstrained Binary Optimization).

Note

This is the provider-specific page. The client API, the job options and the result format are the same for every HPC provider and are documented in How to create an HPC solver — read that page first, and come back here for what is specific to this cluster.

How it works#

The cluster lives in a private network and is not reachable from the internet. You do not have to deal with that: when your solver uses the Fujitsu Bizkaia provider, the platform, before your run() is called:

  1. Brings up a VPN into the private network.
  2. Logs in to the cluster and prepares Slurm access.
  3. Injects the cluster credentials and its scheduling defaults as environment variables, which the HPC client reads for you.

Your run() → submit a script → HPC client → Slurm over the VPN → cluster runs it on a da or a64 node → the job’s output comes back to your run().

Runs on the platform only

Solvers using this provider cannot be run locally with python app.py. The VPN, the cluster credentials and the HPC client only exist inside the QCentroid runtime. Develop the job logic locally if you want, but test the full solver on the platform.

Create a solver for Fujitsu Bizkaia#

1. Enable the provider#

Go to the Providers section, find Fujitsu Bizkaia and click Enable.

  • When requested, add the cluster username and password you received from the Fujitsu team.

These credentials are not your QCentroid ones

Your cluster user and password are issued by the Fujitsu team during onboarding and are different from the ones you use to sign in to the platform. You enter them once, here; from then on the platform injects them into your solvers and you never write them in your code.

2. Register your solver#

Go to My solvers → Add new solver, and then:

  1. Select one of the existing Use Cases.
  2. Select Fujitsu Bizkaia as the hardware provider for this solver.
  3. Choose the HPC language (python_hpc) in the programming language dropdown. This is what tells the platform to build your solver with the HPC client and the VPN this cluster needs.
  4. Complete the rest of the information and click Add new solver.

3. Implement your solver#

Write your qcentroid.py using the HPC client (see the example below), and push it to a Git repository.

4. Connect your repository#

Go to the Repositories section, click Connect a new repository, select the solver you just created, fill in the rest of the details and click Connect repository.

Your solver is now registered, wired to the cluster and ready to run. To launch it, see How to run a job.

Working with this cluster#

Choosing the partition and the resources#

The provider already configures sensible defaults for this cluster, so a solver that passes nothing at all still submits a valid job. Override them per job when you need to:

job_id = client.run_job(
    BATCH_SCRIPT,
    name="my-job",
    partition="da",          # "da" (GPU + Digital Annealer) or "a64" (ARM CPU)
    gres="gpu:1",            # one GPU per node; omit or use "" for CPU-only
    memory_per_node=4096,    # MB — see the warning below
    time_limit=10,           # minutes
    environment="login",     # so `module load` works
)

Always request memory explicitly

On the da partition, a job submitted without an explicit memory request never gets scheduled: it stays in PENDING forever, with a queue reason of Resources. The provider default covers you, but if you start overriding scheduling options, make sure memory_per_node is among them.

Cluster modules#

Software on the cluster is loaded with module. The Digital Annealer’s Python client, for instance, comes from its own module:

module load pyfjsvda/1.0.7-py3.11

Two things to remember for module to work inside your job:

  • Start the script with #!/bin/bash -l — the -l makes it a login shell.
  • Pass environment="login" to run_job(), so the cluster’s login environment is propagated to the job.

Ask the Fujitsu team which modules and versions are available: they change over time and are specific to this cluster.

Example solver#

A complete qcentroid.py that runs a job on the da partition:

qcentroid.py
import logging
from qcentroid_solver_runner.hpc import QCentroidHPCClient

logger = logging.getLogger("qcentroid-user-log")   # so progress shows in the dashboard

# "-l" runs a login shell, which is what makes `module` available.
BATCH_SCRIPT = """#!/bin/bash -l
module load pyfjsvda/1.0.7-py3.11

echo "Running on $(hostname)"
python3.11 -c 'print("Hello world from the Fujitsu cluster")'
"""


def run(input_data: dict, solver_params: dict, extra_arguments: dict) -> dict:
    logger.info("Submitting the job to the Fujitsu Bizkaia cluster...")

    with QCentroidHPCClient(logger=logger) as client:
        client.login()

        job_id = client.run_job(
            BATCH_SCRIPT,
            name="my-hpc-job",
            time_limit=10,         # minutes
            environment="login",   # so `module load` works
            # partition, memory and GPUs default to what the provider configured
        )
        logger.info("Submitted job %s", job_id)

        # Bound the wait: the cluster is shared, so queues can be long.
        client.wait_for_completion(job_id, poll_interval=5, queue_timeout=3600, run_timeout=600)

        result = client.get_job_results(job_id)

    logger.info("Job %s finished: %s (exit code %s)", result.job_id, result.state, result.exit_code)

    return {
        "job_id": result.job_id,
        "state": result.state,
        "succeeded": result.succeeded,
        "stdout": result.stdout,
        "stderr": result.stderr,
    }

To solve an actual QUBO problem, replace the one-liner with your own script: build the QUBO from input_data, call the Digital Annealer client, and write the solution where your solver can read it back. The full client reference — every run_job() option, the JobResult fields and how to publish assets — is in How to create an HPC solver.

Good to know#

  • Queue times can be long. The da partition’s GPUs are shared with other users, so a job may sit queued for a while before it starts. wait_for_completion() logs the queue reason on each poll; bound the wait with queue_timeout / run_timeout if your solver should not wait indefinitely.
  • A failed cluster job is not automatically a failed solver. Your run() still returns normally, reporting the state. Raise an exception yourself if you want the whole execution marked as failed.
  • Keep the job’s output. Drop the raw stdout, reports or plots into an additional_output folder to publish them as downloadable assets.
  • The Digital Annealer itself is documented by Fujitsu. QUBO formulation, DA parameters and the client library are covered by the material the Fujitsu team provides during onboarding; this page only covers reaching the cluster from a solver.

What’s next#

How to create an HPC solver

Run your solver

Edit or update this solver