metno/gpu-ocean

⛔️ DEPRECATED GPU Ocean Python/CUDA codebase

⛔️ DEPRECATED – GO TO https://github.com/metno/gpuocean

gpu-ocean

GPU Ocean codebase.

Installation

Requirements

In order to run this code, you need to have access to a CUDA enabled GPU, with CUDA toolkit and appropriate drivers installed.

Preparation steps on Windows

If you are on Windows, you also need to have installed Visual Studios and add the path to its bin folder in PATH. This is so that pycuda can find a C++ compiler. The following steps are an example how to yield those steps:

• Install NVIDIA CUDA Toolbox
• Install Visual Studio 2019 (Community version)
• Add a C++ compiler to the PATH variable of Windows
  1. Find folder which contains compiler (check C:\Program Files\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64)
  2. Open control panel "Edit the system environment variables"
  3. Click on "Environment variables"
  4. Select "Path" from the user variables and choose edit
  5. Add the folder from above as new path

Set-up

We recommend that you set up your python environment using the package manager Conda as follows:

• Install miniconda or miniforge.
  • If you choose to install Miniconda (a minimal subset of Anaconda), you must take care to not violate the commercial license of Anaconda introduced in Sep 2020. Miniconda is not bound by this licence, but downloading packages through the default channel pointing to anaconda seems to be. All commands in this instruction use the community-driven channel conda-forge, but to be sure to not violate the anaconda licence you can remove the default channel by

  conda config --remove channels defaults
  

  Or install miniforge instead, which "holds a minimal installer for Conda specific to conda-forge."
• Install jupyter notebook (unless you already have it installed on your system) by opening a terminal (or Anaconda prompt if on Windows) and type

  conda install -c conda-forge jupyter
  

• Install the conda extensions that allows jupyter notebook to select conda environments as kernels:

  conda install -c conda-forge nb_conda_kernels
  

• Create a new conda environment according to the environment file in this repository

  conda env create -f conda_environment.yml
  

• Activate the new environment

  conda activate gpuocean
  

• Install pycuda (but none of its dependencies) using pip:

  pip3 install --trusted-host files.pythonhosted.org --no-deps -U pycuda
  

• Installing latex for plotting

  sudo apt-get install texlive-latex-base texlive-latex-extra texlive-fonts-recommended dvipng cm-super
  

You should now be able to start a jupyter notebook server, open one of our notebooks, select the conda environment 'gpuocean' as kernel, and run the code.

Have fun!

Download all data files

cd <project root directory>
wget -r -np -nH -R "index.html*" -X icons http://gpu-ocean.met.no/gpu_ocean

For contributors

More information can be found in the wiki pages

gpu-ocean's Issues

Investigate possible OpenCL/OpenDrift-integration

Implement two-layer (non-linear) model in OpenCL

Simple OpenGL visualization using Python

Proof-of-concept drift component in OpenCL

FBL is non-deterministic (BUG)

Something fishy with FBL after the one-kernel rewrite. Commit e56e9f5 works deterministically, but the most recent master as of today (with the single kernel) gives banded errors on my laptop for "large" domain sizes. Uncovered by running the testCasesDemos/NumericalOrder.ipynb notebook.

The symptoms are "random" values in horizontal bands, perhaps (likely?) related to the block size. Perhaps the last row of shared memory of one variable is not initialized properly? Initial superficial debugging lead to nothing, so I suggest running cuda-memcheck to uncover the issue.

Implement wall boundary condition

Read forcing from NetCDF files

Set up CI connected to Github repo

• Compilation
• Run unit tests
• Run SWIG
• Run simple Python test program (using SWIG-ified code)

Initializing two-layer model from full 3D ocean model

Initializing of bathymetry from NetCDF files

Make Python wrapper for C++/OpenCL (SWIG)

Validation against existing drift codes (OpenDrift)

CDKLM nonsymmetric

CDKLM is no longer symmetric. In commit 35ad712 it appears to work well and give symmetric results, but in current master, c93d524, it is nonsymmetric.

Uncover by simulating a symmetric case, and plt.imshow(eta - eta[::-1, ::-1]) The more timesteps it runs it appears to become more unsymmetric.

Uncovered by running the NumericalOrder.ipynb notebook

Validation of two-layer (non-linear) model

Use the same OpenCL-files for both Python and C++ code bases

Make OpenDrift compatible NetCDF output

CDKLM central upwind cross flux

In CDKLM the cross flux term, huv, is evaluated upstream, "for consistency". It is not obvious what this consistency represents, and experimentation in commit d92b75b, branch havahol/cdklm_central_upstream, shows that second-order convergence is maintained also by using a central-upwind flux similar to the other flux terms.

We should look closer into which upwind formulation should be used for the cross flux terms.

The experiment above is based on PR #154