HPC-10_mcastril_HPDAonline DiagGPU

Last edition: 06/11/20 09:35:58 by mcastril

The PI is responsible to closely follow the progress of the action, and especially to contact NEMO project manager if the delay on preview (or review) are longer than the 2 weeks expected.

  1. Summary
  2. Preview
  3. Tests
  4. Review


Action HPC-10_mcastril_HPDAonline DiagGPU
PI(S) Miguel Castrillo
Digest High Performance GPU Diagnostics Online - 2nd Phase. After having successfully ported the dia_hsb diagnostic into a toy model, achieving 50x speedup, this task will focus on implementing the rest of the diagnostics and improving the data transfer between CPU and GPU.
Dependencies HPC-04_MCastrillo_HPDAonlineDiagGPU (completed)
Branch source:/NEMO/branches/{YEAR}/dev_r{REV}_{ACTION_NAME}
Previewer(s) Italo Epicoco
Reviewer(s) Italo Epicoco
Ticket #2368


High performance data analytics solutions aiming at tackling the online diagnostics of the NEMO model will be explored as complementary components in the model diagnostics software eco-system. Online techniques leveraging fast (low latency and real-time) data analytics approaches (e.g. on fat nodes) will be evaluated in real cluster environments. In particular, an interface of NEMO to the High Performance Data Analitics (HPDA) framework will be designed and implemented for online diagnostics.

The rationale of this activity is to improve the NEMO computational performance by executing the computations for diagnostics on GPU.


As first step, the portability of NEMO diagnostic calculations to GPUs has been analyzed, exploring how to adapt these regions from the current MPI implementation to the CUDA paradigm. A toy model has been created to perform preliminary tests, that were done using the dia_hsb diagnostic. The code itself is executed 50x faster than in a single CPU but the data transfer to and from GPU is the main bottleneck.

The plan for the next months is to work on removing the CPU/GPU communications from the critical path, by using an asynchronous method or parallelizing them with a computation phase. At the same point the efficiency of the overall solution will be improved, by mitigating the impact of the offloaded data.

The last step will be to extend this approach to the rest of the diagnostics.

Documentation updates



Test case functionality: Test hardware and software requirements, test if sample code return value on the desirable range.

Test case setup:

  • Check if one or more compatible GPU is present
  • Check if GPU driver is compatible
  • Run sample and test returned value

Test case verification value:

  • Return logical value pointing if requirements are present.
  • Return float relative error from expected sample value. This value must be smaller than 0.1%.

Status of the test case as for now: Not developed yet.

Expected characteristics:

a) When the option is not activated, the code should pass all the set test and should not display any difference in results nor computational performance.

b) When the option is enabled, a system test must be performed to check if the system fulfills the minimum hardware requirement, there will be some differences that should be appreciable:

The implementation will reduce run time and have a small increase in memory fingerprint. The impact is expected to make the time of execution of the ported diagnostics routines negligible compared to the non GPU ported case.

The diagnostics results won't be bit-to-bit identical to CPU-only implementation runs or in other hardware but will be reproducible in the same hardware and stack software.

The ported diagnostic results will be dependent on float point implementation of the GPU hardware and software. There will be no change in other NEMO subroutines.


Last modified 2 months ago Last modified on 2020-06-11T09:35:58+02:00