# PyFR 1.12.1 Producing NaNs with 2D Incompressible Cylinder Example **URL:** \ **Category:** Cases\ **Tags:** opencl\ **Created:** [3 July 2021 19:16 UTC](https://pyfr.discourse.group/t/pyfr-1-12-1-producing-nans-with-2d-incompressible-cylinder-example/426 "2021-07-03T19:16:10Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Zach-Davis](https://yyz2.discourse-cdn.com/free1/user_avatar/pyfr.discourse.group/zach-davis/32/237_2.png) [@Zach-Davis](https://pyfr.discourse.group/u/Zach-Davis)\ **Post date:** [3 July 2021 19:16 UTC](https://pyfr.discourse.group/t/pyfr-1-12-1-producing-nans-with-2d-incompressible-cylinder-example/426/1 "2021-07-03T19:16:10Z")
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? [2d\_cylinder.ini](https://cvws.icloud-content.com/B/ASM9stTpQF_yLZBN6Tq9NEfbVXXUAVWpowoK2vnXASMetU7mCQboNtF2/2d_cylinder.ini?o=Aiof6VX72wW-6eNSB6hHUGn7iWO_qrMtknRnJNiRRHUO&v=1&x=3&a=CAogT6CElsG1VocVh4wZFuO6t9irSgTekw8n2JTPtgzKHpMSZRCXu7zupi8Yt7Lz7qYvIgEAUgTbVXXUWgToNtF2aiKvAHbn62KcndOdwVJMzK-wMrQD-EOSF29roB6w_95aWCczciIZgjug0gBBhZ2ZqYrF9ISqR5nyM5CRTXSCrPJAWKnkBnwJ&e=1625340827&fl=&r=3d72c301-636a-4ac5-8cdf-f5fce3577042-1&k=CPEo9SBWhIubpG0Iv8fHag&ckc=com.apple.clouddocs&ckz=com.apple.CloudDocs&p=29&s=OBSeGCHHp0UWa_bzEDMlkBvifPM) [2d\_cylinder.msh](https://cvws.icloud-content.com/B/ASsB3bKbfTeUlkBouYa3rHGJKLg-Acli4lrQ_wzJqvB3nqQ2O2bXAYXc/2d_cylinder.msh.gz?o=Ase3AWvGs3y5wtRKZquQ3sOhoGG9nyQkV7M9B2j_pVgb&v=1&x=3&a=CAogljNBkNsWONzZKg9BvKJJsxqyuTwxzxK0Lr7YKr6pJwUSZRCLs8Pupi8Yq6r67qYvIgEAUgSJKLg-WgTXAYXcaiLg9xDj_qqVIAZ8336Q5Pid2c4bY6Egy6LM3_IkemZ9sGzZciITt7zKbio6rkJmCkp1SHMdDaM2lydaadVoP_090Z933C8V&e=1625340941&fl=&r=1965a73e-ad9e-4675-b775-020132a1a149-1&k=8QouRh-layc5_PbuK2m3Yw&ckc=com.apple.clouddocs&ckz=com.apple.CloudDocs&p=29&s=EmkS3UV2b_4YDjEJSbla_sSc1D0) 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… Thanks! ---
**Author:** ![fdw](https://avatars.discourse-cdn.com/v4/letter/f/a587f6/32.png) [@fdw](https://pyfr.discourse.group/u/fdw)\ **Post date:** [3 July 2021 23:28 UTC](https://pyfr.discourse.group/t/pyfr-1-12-1-producing-nans-with-2d-incompressible-cylinder-example/426/2 "2021-07-03T23:28:06Z")
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. Regards, Freddie. ---
**Author:** ![Zach-Davis](https://yyz2.discourse-cdn.com/free1/user_avatar/pyfr.discourse.group/zach-davis/32/237_2.png) [@Zach-Davis](https://pyfr.discourse.group/u/Zach-Davis)\ **Post date:** [4 July 2021 01:47 UTC](https://pyfr.discourse.group/t/pyfr-1-12-1-producing-nans-with-2d-incompressible-cylinder-example/426/3 "2021-07-04T01:47:31Z")
Thanks, Freddie. I removed the compiler flag altogether and re-built PyFR. Still NaNs, unfortunately. ---
**Author:** ![WillT](https://avatars.discourse-cdn.com/v4/letter/w/bc79bd/32.png) [@WillT](https://pyfr.discourse.group/u/WillT)\ **Post date:** [4 July 2021 16:57 UTC](https://pyfr.discourse.group/t/pyfr-1-12-1-producing-nans-with-2d-incompressible-cylinder-example/426/4 "2021-07-04T16:57:44Z")
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? ---
**Author:** ![Zach-Davis](https://yyz2.discourse-cdn.com/free1/user_avatar/pyfr.discourse.group/zach-davis/32/237_2.png) [@Zach-Davis](https://pyfr.discourse.group/u/Zach-Davis)\ **Post date:** [4 July 2021 17:32 UTC](https://pyfr.discourse.group/t/pyfr-1-12-1-producing-nans-with-2d-incompressible-cylinder-example/426/5 "2021-07-04T17:32:52Z")
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? ---
**Author:** ![WillT](https://avatars.discourse-cdn.com/v4/letter/w/bc79bd/32.png) [@WillT](https://pyfr.discourse.group/u/WillT)\ **Post date:** [4 July 2021 22:19 UTC](https://pyfr.discourse.group/t/pyfr-1-12-1-producing-nans-with-2d-incompressible-cylinder-example/426/6 "2021-07-04T22:19:14Z")
Maybe give this test suite a go: > **[elhigu/opencl-testsuite](https://github.com/elhigu/opencl-testsuite)** > > Cross platform (Visual Studio,Xcode,clang,gcc...) testsuite for OpenCL. Based on CMake and LLVM's lit test framework. - elhigu/opencl-testsuite ---
**Author:** ![Zach-Davis](https://yyz2.discourse-cdn.com/free1/user_avatar/pyfr.discourse.group/zach-davis/32/237_2.png) [@Zach-Davis](https://pyfr.discourse.group/u/Zach-Davis)\ **Post date:** [4 July 2021 23:16 UTC](https://pyfr.discourse.group/t/pyfr-1-12-1-producing-nans-with-2d-incompressible-cylinder-example/426/7 "2021-07-04T23:16:53Z")
Thanks, Will. The test suite doesn’t seem to indicate any issues with my OpenCL installation that I can interpret: ######## Platforms selected with regex: AMD ######## 5334435958873927497 : Apple / AMD Radeon R9 M295X Compute Engine ######## ----------- running the suite ----------- ######## Testing Time: 1.15s Expected Passes : 9 [100%] Built target check