01
Computing on GPUs
Efficient Krylov solvers, kernel fusion, mixed precision and multiple right-hand sides. Much of modern GPU performance depends on how often data moves—and whether algorithms can be reorganised to move it less.
Parallel & scientific computing
Parallel thinking.
Scientific progress.
I’m Eero Vainikko, Professor of Distributed Systems at the University of Tartu. I study how parallel algorithms and modern hardware can work together to solve demanding scientific problems.
FIG. 01 / DOMAIN DECOMPOSITIONMatching subdomains in the xy-plane.
Institute of Computer ScienceUniversity of Tartu, Estonia
Computer Science MScProgramme director & thesis supervisor
Delta Centre · Room 3038Narva mnt 18, Tartu
01 / Research
From mathematical ideas
to scalable computation.
My work connects numerical methods, parallel programming, and the practical challenges of scientific computing.
02
Domain decomposition
Breaking large PDE problems into smaller, interacting subproblems. Overlapping Schwarz methods and preconditioning for challenging Helmholtz systems.
03
Parallel scientific systems
Connecting algorithms with their execution on real machines. Performance, communication, and reproducible experiments across CPUs, GPUs, and HPC systems.
Selected work / DD29 proceedings
Solving Helmholtz problems
with GPU-accelerated FGMRES.
Combining an outer flexible Krylov solver with overlapping Schwarz preconditioning and GPU subdomain solvers. The work explores simultaneous local solves and the role of multiple right-hand sides in efficient computation.
Read the paper · PDF GPU-Accelerated FGMRES with Overlapping Schwarz Preconditioner for Efficient Solution of Helmholtz EquationsTHEORY, IMPLEMENTATION, EXPERIMENT.More publications on Google Scholar
02 / MSc thesis supervision
A good question.
A place to begin.
Interested in parallel computing? Explore a possible thesis direction, then get in touch to shape a question around your interests and experience.
Featured thesis directions · Autumn 2026
01Kernel fusion for GPU Krylov solvers
How much memory traffic and launch overhead can we eliminate with fused GPU kernels?
GPU & ACCELERATORS
Kernel fusion for GPU Krylov solvers
How much memory traffic and launch overhead can we eliminate with fused GPU kernels?
A starting experiment
Implement fused vector operations in CG or GMRES and compare them with separate kernels. Measure kernel launches, GPU memory traffic, bandwidth utilisation, true residuals and time-to-solution across problem sizes.
Useful background
Python or C/C++, numerical linear algebra and GPU programming. Start with vector updates and compatible reductions; respect data dependencies and global synchronisation requirements.
Discuss this directionSeparate kernels
Update xwrite / readScale x
Fused kernel
Update + scale xkeep intermediate values in registers
Compatible operations can share a memory pass. Whole solver iterations may still require separate kernels and global reductions.
02Mixed- and adaptive-precision FGMRES–RAS
Can lower-precision subdomain solves accelerate the solver while preserving robustness?
GPU + PARALLEL SOLVERS
Mixed- and adaptive-precision FGMRES–RAS
Can lower-precision subdomain solves accelerate the solver while preserving robustness?
A starting experiment
Compare FP64 local solves against FP32 and adaptive-precision restricted additive Schwarz (RAS) preconditioners inside flexible GMRES (FGMRES). Track convergence, a true residual evaluated in FP64, memory traffic and time-to-solution.
Useful background
Floating-point arithmetic, iterative methods and Python or C/C++. Begin with fixed precision choices, then adapt local accuracy or precision as the outer iteration progresses.
Discuss this direction03Asynchronous multi-GPU domain decomposition
Can subdomains make progress independently instead of waiting for global synchronisation?
DISTRIBUTED / HPC
Asynchronous multi-GPU domain decomposition
Can subdomains make progress independently instead of waiting for global synchronisation?
A starting experiment
Implement synchronous and asynchronous Schwarz/RAS variants for a model elliptic PDE. Compare convergence and time-to-solution under controlled communication delays and workload imbalance, then investigate a multi-GPU implementation.
Useful background
Numerical linear algebra, MPI and GPU programming. Define how stale boundary data and termination are handled; move to Helmholtz problems after establishing reliable baseline behaviour.
Discuss this direction04Fused block Krylov methods for multiple right-hand sides
Can several related linear systems be solved more efficiently together than separately?
GPU + PARALLEL SOLVERS
Fused block Krylov methods for multiple right-hand sides
Can several related linear systems be solved more efficiently together than separately?
A starting experiment
Compare independent CG solves, Block CG and a GPU block implementation with fused operations. Vary the number of right-hand sides and measure memory traffic, arithmetic intensity, convergence and scalability.
Useful background
Iterative methods and GPU programming. Start with Hermitian positive-definite systems suitable for standard Block CG. Extensions to complex symmetric Helmholtz systems require an appropriate Krylov variant and checks for breakdown and loss of rank.
Discuss this direction05AI-guided GPU kernel optimisation
Can machine learning choose an efficient solver configuration for a particular GPU?
AI FOR HPC
AI-guided GPU kernel optimisation
Can machine learning choose an efficient solver configuration for a particular GPU?
A starting experiment
Benchmark alternative fusion strategies, work-group sizes and solver configurations. Compare a learned autotuner with simple heuristics and search baselines, including tuning costs and performance on unseen problems.
Useful background
Python, GPU benchmarking and basic machine learning. Use problem and hardware characteristics as inputs, separate training and evaluation workloads, and verify numerical correctness for every configuration.
Discuss this direction06Communication-avoiding Krylov and Schwarz methods
When does extra local computation cost less than communicating more often?
PARALLEL SOLVERS / HPC
Communication-avoiding Krylov and Schwarz methods
When does extra local computation cost less than communicating more often?
A starting experiment
Compare a conventional solver with a communication-reducing variant. Vary subdomain size, overlap and communication latency; measure reductions, exchanged data, iteration counts, true residuals and total runtime.
Useful background
Numerical linear algebra and MPI. Begin with one method, such as pipelined CG on positive-definite problems, and examine the trade-off between communication savings, stability and extra work.
Discuss this directionFurther research directions
Other interests for discussion include Processing-in-Memory for iterative solvers; energy-to-solution optimisation; performance portability across GPU architectures; dynamic CPU–GPU execution; LLM-assisted HPC optimisation; numerical stability of invertible neural networks; and reproducible HPC experiments with Jupyter.
Have a related idea? Get in touch to discuss a suitable research question and scope.
Possible research directions, with the final scope and supervision arrangements agreed in discussion.
Let’s find your research question.
Send a short introduction, the direction that interests you, and a little about your programming and mathematics background. An initial idea is enough to start a conversation.