I was revisiting PyFR to familiarize myself with what’s changed, and I started with trying to re-run the incompressible 2d cylinder case. However, I’m finding that the incompressible 2-D cylinder example in the examples repository diverges with NaNs. I’ve attempted making changes to the artificial compressibility factor as well as the time and pseudo time steps to no avail.
I’ve also tried running a version of this case that I had run in earlier versions of PyFR, but also now diverges with NaNs in the latest release of PyFR. I’ve linked to my run files below; though, it mirrors pretty closely what’s already in the examples repository. Are there any changes I’ve overlooked that are needed to get this case to run in the latest release of PyFR?
Update: It appears that the case only seems to diverge when using the OpenCL backend with GiMMiK. Running the exact same case using the OpenMP backend seems to run fine; though, slower…
The case can be a little sensitive to compiler optimizations. As an example, when using the OpenMP backend and the Clang compiler the case will usually NaN unless one specifies cflags = -O3 which overrides the default of -Ofast. The issue appears to be Clang/LLVM derived compilers playing some games they’re not supposed to with fast math enabled.
You can try modifying:
and seeing if this resolves the issue. I believe it is a compiler issue, although have not been able to track down which kernel in particular is responsible.
I just ran this case with the pypi version of PyFR v1.12.1, with clblast 1.5.2, targeting a GPU. I didn’t run into any issues. I used the example opencl backend config from the documentation.
Have you run any tests on your Opencl install to check that it is fully functional?
I think the OS ships with the OpenCL Framework. I don’t think I’m running the PyPi version of PyFR, but I am running with version 1.12.1 and CLBlast 1.5.2. What tests are available to run in order to check whether OpenCL is built correctly?